Blog: Windows 2008 Server

During a level platforms monthly maintenance window, there was a server that decided it wanted to do updates the following week and not the night of the scheduled maintenance.  It appears for some reason it didn’t receive the update policy until after the scheduled time so it set the schedule to the following week.  If you have this problem, the follow procedure worked for me:

1. Log into the SC.
2. Go to Patch Management – Settings
3. Click on Windows Update Agent Policies, and select the appropriate server group.
4. On the Policy tab, change the Automatic Update option to “Auto download and notify for install”
5. Log into the server that you are having problems with and run the following command in command prompt:
   • wuauclt.exe /detectnow
   • Windows Server 2008 makes it a little more friendly.  You can just open up the Windows Server Update Service console and click on the “Check for updates” link.

I was recently assisting a client who was receiving TSCAL (licensing) errors when logging into 2008 terminal server via a Wyse thin client.  After researching found that it was caused by the default User not having write access to the registry that is needed to be able to re-write the hardware ID under MS licensing.  Here is how I was able to fix the problem: [more]

1. Login as Administrator locally in to the device and disable the write filter
2. Launch the registry editor and navigate in to Hkey_local_machine\Software\Microsoft\
3. Select MSLicensing > right click select Permission  > Click on Advance tab
4. Set the User  and the Power User  to have full control

As part of a Citrix environment overhaul, another network engineer and I discovered a very frustrating limitation of using group policy with Citrix published applications. The problem centers around the inability to apply IE group policy settings using loopback mode processing. I'll warn you ahead of time, there are lots of details so hang with me....and remember this is all going to converge at the application of group policy. Here is what we found...

When a user with an empty roaming profile (new user) has their profile created as the result of running a published application, the user portion of the registry hive (ntuser.dat) is not created in its entirety. The users' hive can be loaded and a number of noticeable differences exist between it and the default user registry hive. If the user profile is created by logging on locally (console), via RDP to the same machine, or via Citrix published desktop on the same machine, the profile that is created is complete. I was unable to find any noticeable differences between the default user registry hive and that of the newly created roaming user profile when the profile was created in this way. Additionally, once an incomplete profile had been created via published application session, the profile could NOT be "fixed" by logging on via RDP or published desktop. Once the registry hive was created in an incomplete fashion, it seemed to be affected from then on. So why are we talking profiles...I thought this was about group policy? Well, it is...I'm getting there. [more]

We found that users running published applications did not have group policy correctly applied. We were trying to set policies on Internet Explorer using Internet Control Panel settings in the user portion of the GPO. Specifically, IE security zone settings such as trusted and intranet sites would not apply. We also noticed that each security zone seemed to be locked. In the Security tab of the Internet Options dialog box, all the icons were the same....blue IE symbol with a lock next to it. The "Sites" button and the "Custom Level" button were also grayed out. So, here is the where the profile problem merges with the group policy problem. I found that by manually exporting certain keys from the default user profile registry hive under \Software\Microsoft\Windows\CurrentVersion\Internet Settings\ and importing them into in a incomplete user registry hive, I could fix the problem. That is, once the keys existed in the user registry hive that pertained to the settings I was trying to set via group policy, the policy was applied correctly...no issues. Makes sense right....if the group policy is setting registry keys in order to apply certain policies, it’s not going to work if the keys don't exist in the first place.

So things have come full circle. Group policy isn't working because the user profile is messed up. So why is the user profile not getting created correctly? Well, this is actually a Microsoft problem --> http://support.microsoft.com/kb/899270. And the script they provide doesn’t work…we tried it. Actually, there is more to the problem than that, but here is a summary of the information that we gathered. By design, Citrix published applications, remote applications in Windows 2008, and the "start this application on connection" functionality of RDP (mstsc.exe) running against Windows 2003 servers implement limited logon functionality so that the session footprint is smaller than a normal desktop session. Part of the "limited functionality" is that the user session does not start explorer.exe. So, any application that depends wholly or in part on explorer.exe could have issues. Some of the important pieces of functionality that explorer.exe implements are the following:

1. The run registry entry
2. The RunOne registry entry
3. Startup applications 

If you have ever noticed the small gray box that is displayed the first time you log on as a new user, you have seen the effects of explorer.exe running at session logon. It goes by fast, but it says something like "applying internet explorer customizations", "setting up windows media player..."...stuff like that. That little box is normally initiated by explorer.exe. It is called runonce.exe. What we found was that if we initiated runonce.exe in a logon script, the user was created correctly when running published application; thus, group policy was applied correctly as well. Testing also showed that this process could also fix a previously created broken user registry hive (ntuser.dat). All we had to do is add the following to our logon.bat file

start /MIN %windir%\system32\runonce.exe /AlternateShellStartup

Citrix has documented this problem in a support article (http://support.citrix.com/article/CTX104374) and they refer back to the previous MS KB listed above. Numerous forums threads exist on this issue and we were unable to find a resolution elsewhere that did not include scripting registry imports to the user profile at logon. This workaround seems to be a more flexible and reliable.

I was tasked with upgrading a 2003 Windows Server to 2008 over the weekend recently and ran into a few minor issues trying to get the upgrade started. The main one was that the Server 2008 installer would not continue past the compatibility check as long as Windows PowerShell 1.0 was installed. PowerShell 1.0 was released as a hotfix prior to server 2003 SP2 and was included in the SP2 package. When I went into Add/Remove Programs, I didn’t see the PowerShell update in the list. Even after removing SP2, PowerShell was still present on the server and would not allow the Server 2008 upgrade to even start. [more]

I wanted to try manually uninstalling the hotfix from the $NtUninstallKBXXXXXX$ folders located in C:\Windows, but the folder that housed the PowerShell 1.0 hotfix info was nowhere to be found. Most likely, someone had removed those folders to clean up disk space or they were removed with the installation of SP2. In either case, I was stuck.

Fortunately, we had another Server 2003 32bit machine running out on the network that still had the $NtUninstallKBXXXXXX$ folder that I needed. I copied it over to this original box and tried the uninstaller. It successfully uninstalled PowerShell without any extra registration on my part! After this was removed, the upgrade to Server 2008 ran smoothly.

I had applied Windows updates to a customer’s Windows 2008 R2 server that had Microsoft Threat Management Gateway installed, and I could not RDP to the server after rebooting.  I connected to the server locally and could tell from netstat that the server was not listening at all on port 3389.

It turns out that there was a problem with the RDP-tcp protocol not working because it was configured to listen on all available network adapters.  This being a proxy server, it had internal and dmz network adapters.  To fix this issue, set the RDP-tcp protocol to only bind to the internal network adapter. [more]

• Open Remote Desktop Session Host Configuration.
• Open th/e properties of the RDP-Tcp protocol underneath Connections.
• In the Network Adapter tab, change the setting from “All network adapters configured with this protocol” to the specified internal network adapter and hit apply.
• On the Actions bar to the right, click Disable Connection and then Enable Connection to reset it.
• Run netstat to confirm that the server is listening on port 3389 again.

The other day I was setting up a scheduled task on a 2008 server using Microsoft's "new" task scheduler.  The task scheduler is pretty robust with lots of bells and whistles, but I ran into a subtle problem with the "Start-in" field on the "application to run" section.  When setting up my task, I had used the Shift+Right Click feature to "Copy as path" the folder where my script was located.  When using this feature the copied path is contained within double quotes (regardless of if there are spaces in the path).  The problem is the "Start-in" field cannot contain quotes.  If it does, your scheduled task will fail to start.

Thankfully, the error code returned quickly led me to the following article: http://www.arcomit.co.uk/support/kb.aspx?kbid=000058.  Once I removed the double quotes everything worked great.

Windows 2008 terminal servers handle user profiles slightly differently than Windows 2003. 

1. Windows 2008 (and Windows 7) profiles use a different format from previous versions.  You will notice in the roaming profile folder that you get a new folder with a .v2 extension; this is to prevent the new format from being applied to older OS’s.  Essentially, the user has two different roaming profiles; one for older OS’s and one for Windows 2008 (and Windows 7).  (\\servername\profile_share\username\tsprofile for older machines, \\servername\profile_share\username\tsprofile.v2 for Windows 2008 terminal servers)
2. They finally manage to delete the user profile when the user logs off.  I’ve noticed two issues related to this.
   • The Users folder (formerly Documents and Settings) starts having multiple folders with the users name.  wcbtest, wcbtest.datacenter, wcb.datacenter.001, wcb.datacenter.002, etc.  The event log shows an error when trying to delete the profile folder, saying that it is not empty.  I have not looked in-depth yet; there may be a solution to this.
   • If you want to run the group policy results wizard, you have to do it while the user is logged in.
3. If the roaming profile location is unavailable, the user gets a temporary profile every time.  On Windows 2003, you would get an error saying the roaming profile location could not be contacted (if I remember correctly), but the local profile would be normal.

On any VMware virtual machine running Windows 2008 or 2008 R2 that was created using v4.1, the advanced configuration parameter disk.enableUUID is set to TRUE. Basically, this enables application-level quiescence in the VM. If the VM was created on ESX prior to v4.1, the advanced configuration setting does not exist. So, if you want to get application consistency on a VADP (vStorage API style) initiated backup, it won’t happen if that setting isn’t set to TRUE. This is a problem because a number of vendors (CommVault included) don’t support this feature yet. Since it is a default for new VMs, they won’t back up correctly.

The bottom line is... make sure you are absolutely sure you are getting application consistent backups by checking the app logs on the VM when doing the backup. You may not be getting as consistent of a backup as you think.

I had an IT consulting customer email me requesting assistance with extending the system partition on a Windows 2003 virtual machine. The partition had been running low on disk space for a while. The customer had extended the vmdk using VMware, but was unable to extend the partition using diskpart. This is normal behavior for a Windows 2003 system so I scheduled downtime so that I could use VMware Converter to fix the problem.

I have done this operation a number to times in the past. You simply tell Converter to convert the VM and target the same ESX cluster with the imported copy. During the operation, VMware gives you the option to change the partition size. Windows recognizes the partition size change at first boot and you are good to go. However, the customer failed to tell me that they had un-marked the c:\ drive partition as active while trying to get the disk to extend. When I shut the VM down to clone it, it never came back up. Neither did the imported copy. Both were completely useless. They would boot to an “Operating System not found” error. [more]

I tried fixboot and fixmbr from the recovery console but neither worked. I ended up restoring from a CommVault backup. Later, based on some comments from coworkers, I decided to see if I could fix this problem by mounting the disk to another VM and adding back the “active partition” status. I mounted the vmdk that was broken to a Windows 2008 server and using disk manager re-marked the partition as active. Sure enough, after dismounting from the temp VM the original VM booted up no problem. Just one more reason to use virtual machines.