Create a 32bit DSN for VMware Update Manager

If you are installing a VMware Update Manager database onto an existing 64bit SQL server, you will need to add a 32bit DSN in order for the VMware Update Manager installer to find the database that you wish install to. Firstly create a new empty database for VMware Update Manager using SQL Management Studio:

Adding a new database in SQL Management Studio

Next locate and run odbcad32.exe which can be found c:\Windows\SysWow64, and add a new system DSN on the system tab. Then, choose the relevant driver for your DSN, in my case ‘SQL Server Native Client 10.0’, as shown below.

Choose the relevant SQL Server Driver version for the DSN

Assign a name to the DSN, and then specify the SQL instance that hosts the database:

Assign a name to your new 32bit DSN

Then specify the database that you are creating the DSN for under the ‘Change the default database to:’ section. Finally click next, and finish to complete creating the new DSN:

Specify the database that you are creating the DSN for

Now, when you run the VMware Update Manager installation you should be able to select the appropriate database in the ‘Use an existing supported database’ section and continue with your installation:

Select your 32bit DSN in the VMware Update Manager installation

Windows Server 2008 R2 SP1 install breaks RDP

After installing Service Pack 1 via windows update on a Windows Server 2008 R2 machine the other day, I discovered that I could no longer use remote desktop connection to access the server remotely. At first I wasn’t sure if the whole service pack installation was botched, but further testing revealed that all other functions of this server were operating normally. A quick google search showed that I was not alone in experiencing this problem, in fact there is enough information out there to solve this without another blog post from yours truly, but there is a bit of conflicting information so I thought I would document my experience to hopefully help others.

The problem manifests itself like this:

You try to RDP the affected server and it goes through the enitre logon process, and just when you think it is going to fire up the remote desktop it bombs out. An event was logged in the application log in my case event 4005 with a source of Winlogon, stating ‘The Windows logon process has terminated unexpectedly’ (shown below), although I have read of slightly different errors on other blog posts. Checking the Terminal Services logs indicate that the logon has completed successfully.

Event 4005 Source Winlogon after Service Pack 1 install on Windows Server 2008 R2

This situation it turns out, occurs when both KB2621440 and KB2667402 are applied to a system before Service Pack 1 is applied, as they effectively leave some of the RDP DLL files out of sync, specifically rdpcorekmts.dll. Now, alot of the posts I read online stated that you simply needed to uninstall the KB2777402 update, reboot, and then reapply it to solve this problem. I tried this first and it did not work. Various posts also stated that RDP started working after the removal of this patch, again this was not the case for me although I am sure it is correct in some cases.

So the fix I used in the end was this:

Firstly I uninstalled both KB2621440 and KB2667402 via Control Panel, Uninstall a Program, View Installed Updates, and then rebooted the server. I expected the DLLs to be set back to a working state at this point but this was not the case. Luckily in my case I had physical access to the server. Other posts state that the two updates can be uninstalled remotely using the following commands if you do not have that luxury:

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2667402 /quiet /forcerestart”

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2621440 /quiet /forcerestart”

Note, that the commands above will restart the server

As RDP still didn’t work for me at this point contrary to other information, I ran:

sfc /scannow

This picked up some issues and required a reboot. After rebooting the server I was able to use RDP again. That was great, but didn’t help with the fact that the two patches that were removed were to address the Critical RDP vulnerability MS12-020. I certainly didn’t fancy not applying these patches to this server so I reapplied KB2621440 and KB2667402 via Windows Update, and rebooted the server. Thankfully after this I had a fully patched server and working RDP.

If you need to do all of this remotely and find that you still can’t RDP the server after removing the two patches using the commands above I recommend running sfc /scannow using PSEXEC:

psexec \\SERVER sfc /scannow

Then when the scan is finished performing a remote reboot using:

psexec \\SERVER shutdown -r -t 01

This should get your RDP back to a working state, and then you can reapply the removed updates. I have not corfirmed this but expect this fix will also work for Windows 7.