Archive for the ‘Server 2008’ Category

Windows Update Error 80244023

Thursday, March 10th, 2011

Just a quick one here. I am sure there are a number of other fixes around for this error, but a reminder here to check for the simple things.

Running Windows Update using WSUS on Windows Server 2008. Clicked the Check for Updates option and this error came up.

Check your proxy settings. If you use a proxy trhen ensure that you can access your configured WSUS server through the proxy, or disable the proxy. It seems that when you run the check manually it uses the system proxy settings (set in Internet Explorer) but when it is run automatically it does not. Seems strange behaviour – but that is how it appears to work.

If you are getting this error on a standalone PC not connected to an enterprise network, then it is highly likely that this will not apply to you.

7 people found this post useful.

Redirected My Documents folders showing as ‘Documents’ rather than the users name

Monday, December 20th, 2010

Had a complaint from a member of staff recently that all students work folders showed up as My Documents when he was browsing through their work.

Many of you may have been directed to this Microsoft KB as a ‘solution’. http://support.microsoft.com/kb/947222

Not much of a solution if you ask me. Redirection to a subfolder would work, but do you really want to change something that significant on your network? Enable exclusive access would be fine if you didn’t need to give other people access to the documents folder. In a student-teacher situation, teachers need to be able to see the students work, so this doesn’t work for us. Option 3 – deny permission to the desktop.ini. We have 1400 students. That’s a lot of changes – yes I could use xcacls or subinacl to automate it, but what a headache.

The best ‘solution’ that we have come up with, is to simply delete the desktop.ini file at logoff. We created a VB Script, which looks for a desktop.ini file in the user’s My Documents folder, and if it exists then delete it. Attach this into a GPO that affects the user as a logoff script.

The code we used is:

On Error Resume Next
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")
DocsPath = WSHShell.SpecialFolders("MyDocuments")
If FSO.FileExists (DocsPath & "\desktop.ini") Then
  FSO.DeleteFile (DocsPath & "\desktop.ini")
End If

Next time the user logs on and then off again, the desktop.ini file will be deleted, and the folder will show as the username of the user.

Shame there isn’t a GPO option which allows you to turn off this feature. On a home machine it is great, but in a corporate environment you need to be able to turn off the fancy features and see exactly what you have got.

2 people found this post useful.

Specified Port is Unknown error when adding Network Printers

Thursday, July 1st, 2010

Just finished investigating and resolving an error whereby the message ‘Specified Port is Unknown’ appears when adding a network printer. This was first noticed when running a login script that add’s printers didn’t actually add any printers.

To fix this problem, you need to delete references to the printer drivers in the registry. I had already deleted any references to any network printers in an earlier attempt to fix the problem, so I wil;l include that as a step as it will not affect any functionality.

  1. Open Registry Editor, making sure that you have administrator rights.
  2. Expand HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Architecture\Drivers\Version-3
  3. Delete any subkeys for printer drivers that have been installed.
  4. Expand HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Print\Printers
  5. Delete any subkeys that reference any network printers.
  6. Close Registry Editor
  7. Restart the Print Spooler services

After this had been completed, all of the shared printers as part of the login script connected and functioned as they should.

All I can imagine is that one of the drivers was corrupt, or information had not been removed from the registry when a printer was removed.

4 people found this post useful.

Windows 2008 R2 RDS: Print Spooler Stops

Wednesday, June 2nd, 2010

We have two servers running Windows Server 2008 R2 Remote Desktop Services. On both servers the Print Spooler service kept randomly stopping. In the Application event log, we noticed this error keep appearing:

Faulting application name: spoolsv.exe, version 6.1.7600.16385, timestamp: 0x4a5bd3d1
Faulting module name: ntdll.dll, version 6.1.7600.16385, timestamp: 0x4a5bd3d1
Exception code: 0xc0000374

After trying to replicate the problem, we found that it only occurred when certain groups of users, all with the same login script, logged in to the server. Part of this login script adds some network printers for the user.

Turns out, we had just updated one of the print drivers for the printers, and whenever the user logged in, it was unable to install the new print drivers, because of the user’s access rights. Instead of it popping up asking for an administrators credentials to add the driver, the print spooler service was just failing.

The fix in this case was to simply log in as an administrator, add the printer, so that the driver gets installed.

Other fixes that I found on the internet all relate to driver issues, so do check that the drivers you are using are suitable for Windows Server 2008 and are WHQL.

Login Script Not Running Windows 2008 Remote Desktop Services (Terminal Services)

Monday, May 24th, 2010

Call today: User has not got any network drives when logging on to the thin clients.

The setup for this is as follows:

  • 2 x Windows Server 2008 R2 servers running RDS, DNS round robin, load balanced.
  • 56 x ThinStation 2.2.2 clients

A VBS login script is applied using Group Policy. All student users have a Mandatory Roaming Profile.

Any user that was not the user that I used to create the template could not run the login script. Took quite a while to work out that the mandatory profile was the cause.

To solve the problem:

  1. Open Registry Editor
  2. Select HKEY_USERS, then click File –> Load Hive
  3. Select the mandatory profile file (NTUSER.MAN) and give it a name.
  4. Right click on the key that you typed in in step 3 and select Permissions.
  5. Remove the user that you used to create the Mandatory Profile
  6. Add in the Authenticated Users (or a different group if you want to restrict access further) and assign it Full Control.
  7. Propagate the permissions to all child objects.
  8. Select the hive that you added in step 3, click File –> Unload Hive
  9. Test.

I suggest creating a backup of the original hive before you make any changes. Just in case.

Now, whenever a user logs in the script should run, and create all of the necessary network drives that you have defined in your script.

ISA 2006: Re-design

Wednesday, April 7th, 2010

Just been working on our ISA infrastructure. We have 2 ISA servers, 1 for staff, and 1 for students. Main reason for the separate servers is that each ‘group’ have to go through a different upstream proxy server. (Bit of a pain, but that’s what we have to do.)

Simple task this morning, block a couple of sites and add a new HTTP signature in for blocking. Open up the ISA Management console and off we go.

Upon opening, I was greeted with a dozen rules and a number of separate filters. I knew that ISA performance had been suffering recently, but not really had the time to do anything about it. It looks like over time, as requirements have changed and extra sites and services needed restricting or allowing, the design of the firewall rules, and web chaining rules had become one giant mess.

Taking the opportunity of a bit of time for once, took all of the rules, deleted them and started from scratch. Managed to get 14 rules down to 3. Took a look at the web chaining rules, and reorganised them into a more logical order. Traffic is all now told to attempt to go direct to the source instead of the upstream proxy. Previously, all traffic was directed to the upstream proxy, and then told to go direct if it didn’t match a rule. (I think that makes sense!).

Other than making the whole configuration simpler (always a good feature), the re-design has had two positive side effects that weren’t planned for. ISA performance has improved by around 50%. Request times are taking half a s long to process as they were before. Also, YouTube has started working!! Something in the configuration was stopping YouTube from loading and playing videos, but in the mess of rules, we could not determine what the problem was.

Today I have determined that every so often, you need to really challenge an existing design to ensure that it is as simple, and as functional as it needs to be.

Sharepoint Search 2007: Your License for Office Server Search has expired.

Tuesday, April 6th, 2010

Just been fixing the problem mentioned above. Lets set the scene here: Walk in this morning, coffee, boot up. Open up IE, need to update a record on our asset log. Enter the asset ID into the search bar, press enter. Easy day ended. 9:10am.

‘Your license for Office Server Search has expired’

We have recently upgraded from SharePoint standard to SharePoint Enterprise (recently being the middle of last week). It seems that whenever a configuration change (i.e change of license, installation of a language pack) occurs on a SharePoint server, some of the permissions that SharePoint require are changed on the server. These settings are then reset to their correct values by running the ‘SharePoint Products and Technologies Configuration Wizard’. When running the wizard, ensure you select the options that leave your topology in the same configuration as it is now. (Assuming that you don’t want to change anything.) Afterwards, you should be able to search. Took a couple of refreshes in the browser, but all working.

I did find that straight afterwards, search performance was not as I expected. About 15 minutes later, performance resumed. On our system it started a crawl as soon as the wizard completed (which completed around 10-15 mins later). Not sure if this is a feature that happens on all installations or not. Might be a warning if you have a larger topology, and a crawl might negatively affect your performance. It may mean that you run the wizard afterwards.

So, today’s early morning lesson is: Runthe Sharepoint Products and Technologies Configuration Wizard after any change to the SharePoint server.

Now, asset updated, and back to the coffee.

Backup Exec 12: Remote SharePoint Agent – Access Denied

Wednesday, February 17th, 2010

Just coming to the end of fixing a very frustrating problem with Backup Exec 12, and backing up our SharePoint 2007 farm. After over 8 hours on the phone and extra work done by email with Symantec engineers, I have a solution.

Here’s the basic information:

SharePoint Server:

  • Windows Server 2008 Standard x64
  • SharePoint Server 2007 Standard x64
  • Backup Exec Remote Agent for SharePoint
  • A second server runs the Backup Exec program, and a third dedicated database server hosts the Backup Exec database.

    The main problem is described well in the following Symantec document (which is what they keep referring me to) http://seer.entsupport.symantec.com/docs/300675.htm

    After going through a number of fixes, mainly checking that you have actually given permissions to all of the necessary areas (I can’t say exactly what you need at the minute, I still have some very sweeping permissions in place from testing) and creating the SPSWrapperV3.exe.config files, we still weren’t getting anywhere.

    After fixing another program (on Vista this time) which had issues relating to User Account Control, gave it a try.

    On Windows Server 2008, go into Control Panel -> User Accounts then select Turn User Account Control On or Off.

    After a restart backups start working!!

    Not sure who I am more frustrated at right now: Symantec for not making software that works with UAC, but is supposedly designed for Server 2008, or Microsoft for putting the feature in. Totally see why it exists, and most of the time I like it’s existence. Some of the time it is a total pain.

    1 person found this post useful.

    Group Policy Client Service Failed the Login: Access is Denied

    Monday, September 28th, 2009

    This error has been annoying me for nearly 4 hours now.

    We have a terminal server for students. All students use a mandatory profile, located on a share so that it can be accessed by all of the servers in the farm.

    I thought this would be easy to set up, so I did the following:

    1. Log in as a user (that does not have the profile path set) to create a local profile on the machine.
    2. Configure the profile as you require and then log off.
    3. Log on as an administrator.
    4. Open up System Properties –> Advanced –> User Profiles
    5. Select the profile that you created in steps 1 -3 and select Copy To.
    6. Specify the location and a security group and the intended user. Click OK and verify that the folder exists in the new location.
    7. Go to the location and rename NTUSER.DAT to NTUSER.MAN to make it mandatory.
    8. Set the user profile location for all your desired users.
    9. Log in and test.

    All was going well. I was at step 8, and failure struck. Group Policy Client Service Failed the Login: Access is Denied.

    Check the following first, as simple solutions:

    • The user has read access to the share.
    • The user profile is owned by the DOMAIN\Administrators group.
    • Ensure the desired group has got read access to the entire profile (you can replace all permissions).

    After checking this and repeating the whole process twice, I started looking at something else. The NTUSER.DAT file is a registry hive, which contains keys with their own security on them. So:

    1. Open up Registry Editor
    2. Select HKEY_USERS and then rtight click and Load Hive
    3. Browse to the location of the profile and open NTUSER.MAN
    4. Give the key a temporary name. e.g Profile.
    5. Right click the name you just gave and choose permissions.
    6. Make sure the desired group is listed and has Full Control permissions.
    7. Propagate all these permissions to all child objects.
    8. Unload the hive and close Registry Editor

    This cured the problem for me. Now all of the intended users can pick up the profile and work as desired.

    I understand from my Googling that this is a problem with some Vista users to. I have not tried this as a solution for them, but would be interested to hear if it does solve it.

    4 people found this post useful.