Since some protocols are identified by a prefix (ftp:// http:// https://) I decided to use rdp:// as the prefix to launch mstsc.exe. I have combined the necessary registry keys and the required JScript file into a single .bat file that allows for easy installation/uninstallation of the rdp hyperlink association. When you run rdp.bat you are presented with 3 options:

Option 1. Adds registry key HKCR\rdp which contains the parameters needed to associate the rdp:// prefix with a file created in C:\Windows called hyperlink-rdp.js. The JScript file is responsible for some string manipulation that trims the rdp:// prefix and then passes the remaining string (server name) to mstsc.exe to try and establish the rdp session.

Option 2. Removes registry key HKCR\rdp and the C:\Windows\hyperlink-rdp.js file.

Option 3. Exits the batch file.

After you use rdp.bat to create the hyperlink association you can launch an rdp session by clicking any hyperlink in the form of:

rdp://someserver

Typing rdp://someserver into your browser or windows explorer address bar will also launch the Microsoft Terminal Services Console and attempt to establish a session.

Note: When clicking an rdp:// hyperlink for the first time from a browser it is likely that you will receive a prompt that the browser is trying to launch a local application. You will need to allow this in order for the Microsoft Terminal Services Console to be opened and a session established.

After creating the rdp association on my Windows computer I added a specific link to the device in my Zenoss web console by:

1) Navigating to the device
2) Clicking the options drop down arrow
3) Selecting More --> zProperties
4) Adding a HTML hyperlink to the zLinks property

The syntax for a standard HTML hyperlink is:

<a href="rdp://someserver">rdp://someserver</a>

Although the above hyperlink works, I later discovered that Zenoss makes use of TALES expressions, one of which can be substituted for the server name (someserver) in this instance. If you use TALES you would only need to set the hyperlink once globally for all Windows servers by:

1) Navigating to Devices --> Server --> Windows
2) Clicking the zProperties tab
3) Adding the Zenoss TALES hyperlink to the zLinks property

The syntax for the Zenoss TALES hyperlink is:

<a href="rdp://${here/id}">rdp://${here/id}</a>

You will then have a clickable hyperlink on the Status tab from within the Windows device (or any new devices you add if you use the Zenoss friendly hyperlink):

Note: If you are planning to run rdp.bat on Windows Vista or Windows 7 you will need to run it with Administrator privileges. You can do this by right clicking rdp.bat and choosing 'Run as administrator':

Download rdp.bat - HERE

When the host had finished booting it naturally tried to reconfigure HA as necessary, but within two minutes it was appearing as being disconnected from vCenter. Initially I was a little stumped because I instinctively tried to SSH onto the host and was able to do so. This immediately ruled out any form of network or connectivity problem. For the sake of speed I decided to restart the host just incase a service had failed when it was booting up. After the host restarted it appeared in vCenter as usual. I then noticed an error on the host and checked the Alarms tab. The alarm triggered was:

Host connection and power state

The alarm was weird since I had only upgraded the RAM on the host. I couldn't correlate the significance of the alarm and the host disconnecting from the vCenter server. I assumed I had disturbed one of the power cables on the host but a quick check revealed both PSUs in the host had a live power feed and this alarm doesn't actually monitor the power anyway.

I decided to use the vSphere client to connect directly to the host. As soon as it connected I received an information message explaining the host was being managed by the vCenter server, but the IP address listed (for the vCenter server) was 127.0.0.1. This was clearly incorrect.

When a host is added to vCenter it uses the IP address stored within vCenter located in:

Administration --> vCenter Server Settings --> Runtime Settings --> vCenter Server Managed IP

A quick look at this setting on the vCenter server revealed that the Managed IP was blank.

I assumed that as the Managed IP was blank hosts were trying to connect to themselves instead of the vCenter server.

I used nano to open /etc/opt/vmware/vpxa/vpxa.conf on the host and it contained the following:

<vpxa>
...
<serverIp>127.0.0.1</serverIp>
...
</vpxa>

After changing the vCenter Server Managed IP address using the vSphere client I disconnected from both the vCenter server and the host. I then connected back onto the host using the vSphere client and it was now being managed by the vCenter server with the correct IP address. A quick check on the vCenter server itself revealed that the Host connection and power state alarm had ceased. I also verified that the vpxa.conf on the host was reporting the correct IP address.

I assume that this issue may have been caused during the upgrade from ESX 3.5 to vSphere 4. I had never experienced this problem before and it has not reoccured since.

These were as follows:

1. TCP port 135
2. TCP port 2701
3. TCP port 2702

Of course a port/service should never be exposed unless absolutely required. The best practice to reduce the level of exposure would be to also configure the scope of the users that can connect to the above ports. This should be limited to specific computers that have the SCCM ConfigMgr Console installed.

To do this using Group Policy I navigated to the following location in a GPO:

Computer Configuration --> Administrative Templates --> Network --> Network Connections --> Windows Firewall --> Domain Profile --> Windows Firewall: Define inbound port exceptions

I then defined the following exceptions:

135:TCP:(scope):enabled:SCCM
2701:TCP:(scope):enabled:SCCM
2702:TCP:(scope):enabled:SCCM

Note: (scope) is either "*" (for all networks - although this is not advised) or a comma-separated list that contains any number or combination of these:

IP addresses, such as 10.0.0.1
Subnet descriptions, such as 10.2.3.0/24
The string "localsubnet"

After adding the above exceptions to clients via an existing GPO I could successfully connect to them using the Remote Tools feature in SCCM.

The machine had recently been re-imaged but as the organisation I work for requires that all users be local administrators on their own computer I suspected spyware/malware was to blame. Before I re-imaged the computer again (to be sure the machine was cleaned) I had a quick look at rectifying the connectivity issue. It seemed that Winsock2 (a Windows API that defines how Windows network software should access network services such as TCP/IP) had been corrupted. To manually reinstall TCP/IP and fix the Winsock2 issue I performed the following:

1. Browse Control Panel and then Network Connections
2. Right-click on your network connection, and then click Properties
3. Click the Install button
4. Click Protocol and then click Add
5. Click Have Disk when asked to Select a Network Protocol
6. Browse to C:\Windows\inf (inf is hidden), then select Nettcpip.inf and click OK
7. On the list of available protocols, click Internet Protocol (TCP/IP), and then click OK
8. Restart computer

Following this process the buttons for 'Network ID' and 'Change' were no longer greyed out.

Here is the error:

Host CPU is incompatible with the Virtual Machine's requirements at CPUID level 0x1 register 'ecx'.
Host bits: 0000:0000:0000:0000:0010:0010:0000:0001
Required: 1000:0000:0000:000x:xxx0:0x1x:xxx0:x001
Mismatch detected for these features:
*General incompatibilities; refer to KB article 1993 for possible solutions.

The only recent change was the upgrade to vSphere 4. The error detailed an incompatibility issue between the host and Virtual Machine CPU. The host hardware hadn't changed so I decided to investigate the Virtual Machine. After a quick look at the affected Virtual Machine's .vmx configuration file I noticed what appeared to be a CPU ID Mask. I checked the .vmx configuration against a couple of other Virtual Machines that were still able to VMotion and sure enough the CPU ID Mask was not present in these Virtual Machines.

The 5 lines in the non VMotion'ing Virtual Machine's .vmx file were:

cpuid.1.ecx = "R----R----R--R-0-----------H-R--"

cpuid.1.ecx.amd = "R---------------------------R---"
cpuid.80000001.ecx.amd = "------------------RR-RR---------"
cpuid.80000001.edx = "----R---------------------------"
cpuid.80000001.edx.amd = "--------------------------------"

I shut the Virtual Machine in question down and removed the 5 lines above from the .vmx file. I powered on the Virtual Machine and tried to VMotion it. I still received the same error as above. I shut down the Virtual Machine again, verified that the CPU ID Mask was not present in the .vmx and then powered it back on. After the second full shutdown I could successfully VMotion the Virtual Machine again.

NOTE: I have noticed that if you edit a .vmx file before shutting a Virtual Machine down it appears that the changes are overwritten because the running configuration is saved over the top of the existing configuration in the .vmx file itself. The easiest way to make a change to a .vmx is to shut the Virtual Machine down before editing it.

The CPU ID Mask can also be modified from the vSphere client by:

1) Shutdown the Virtual Machine
2) Right-click the Virtual Machine and select "Edit Settings..."
3) Select the "Options" tab
4) Click on "CPUID Mask"
5) Click on the "Advanced..." button

This issue affected 3 of 8 Virtual Machines in my 3 node vSphere cluster and I'm unsure why it only affected certain Virtual Machines. There seems to be nothing in common (that I could think of anyway) between the 3 affected Virtual Machines that I believe could have attributed to this problem.

EDIT (29/10/09): It seems VMware are now aware of the problem and have issued a workaround that requires you to use the vSphere client to remove the CPU ID mask. KB1011294

One of the new features of vSphere is the ability to resize disks without having to shut down the Virtual Machine. This was previously impossible in VI3. This greatly speeds up the resizing process which can be executed in a couple of stages:

1) Use the vSphere Client to edit the settings of the Virtual Machine in question. Select the hard disk and modify it's provisioned size as appropriate. Click OK to apply these changes - resizing the .vmdk file.

2) Verify that the .vmdk has been resized by opening the Management Console -> Disk Management to find the unallocated space on the disk that resides in the .vmdk (distinguished by the black colour in the legend at the bottom.) In this case you can see I have increased the size by 5GB.

Right click on the disk (in this case 'Disk 0') and select properties. On the Volumes tab make a note of the unallocated space, in my case it is 5122MB.

Download Dell's EXTPART and extract it on the server that contains the disk you want to resize. Navigate to c:\dell\ExtPart (the default extracted location) and run extpart.exe. When prompted enter the the Windows drive letter of the disk on the Virtual Machine e.g. c:. When prompted for the size to extend the partition by enter the number noted down earlier (I used 5122 in this example.) After doing so the disk should be resized. You can check this by opening the Management Console -> Disk Management and verifying the size of the partition.

NB - If you receive the following error:

"Unable to connect to c: or it does not exist"

There are a couple of workarounds that you could try.

1) Close the Management Console (if it is open) and try extpart.exe again.

2) Try restarting the VM in safe mode and then run extpart.exe. This is not ideal but it is still easier than other methods I have tried to resize .vmdk files.

I had already used a KiXtart logon script to configure 'Cached Mode' for my Outlook 2003/7 clients by modifying some HKCU registry keys for users - Regkey to enable & disable Outlook 2003 cached mode.

After setting up an Outlook client in VMware Workstation I configured RPC-HTTPS and exported the regkey from the post above (see below for the key.) A fresh install of Outlook with a clean profile and the above key imported revealed that the settings for RPC-HTTPS are stored in the same place as those in the post for enabling cached mode. A combination of changing the values in Outlook and using Regmon allowed me to narrow down exactly what each registry value is used for and the data that each value needs to contain (the data for each registry value is stored as type REG_BINARY which as hexadecimal is unreadable.)

Here is an outline of the registry key and each value with my own description:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\(profilename)\13dbb0c8aa05101a9bb000aa002fc45a

00036623 = Enables 'Connect to Microsoft Exchange using HTTP' as well as 'On fast/slow networks...'
00036627 = Sets the proxy server authentication type (data: 01000000 -> Basic, 02000000 -> NTLM)
001f6622 = Sets the 'proxy server for Exchange' (https://) text box
001f6625 = Sets the 'this principle name' text box

One other registry key I had to set (as per KB820281) to stop clients being prompted for a username/password was:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

lmcompatibilitylevel = 3

I amended my KiXtart login script as follows with the new registry keys, values and their data. The next time users logged on they were connected using RPC over HTTPS:

WRITEVALUE("HKLM\SYSTEM\CurrentControlSet\Control\Lsa", "lmcompatibilitylevel", "3", "REG_DWORD")
WRITEVALUE("HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\13dbb0c8aa05101a9bb000aa002fc45a", "00036623", "2b000000", "REG_BINARY")
WRITEVALUE("HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\13dbb0c8aa05101a9bb000aa002fc45a", "00036627", "02000000", "REG_BINARY")
WRITEVALUE("HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\13dbb0c8aa05101a9bb000aa002fc45a", "001f6622", "xxxx", "REG_BINARY")
WRITEVALUE("HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\13dbb0c8aa05101a9bb000aa002fc45a", "001f6625", "xxxx", "REG_BINARY")

You can verify that users are connected using RPC over HTTPS by holding down CTRL and SHIFT on the keyboard and using the mouse to right-click the system tray icon. Click on the 'Connection Status...' option and you will see that the 'Conn' column displays multiple connections of type: HTTPS.

I powered on the Virtual Machine after removing the old NIC and adding the new vmxnet3 NIC and logged into Windows. I could see Windows installing the relevant drivers for the new vmxnet3 adaptor that it had detected and Windows was prompting for a reboot. Before doing so I tried to set the IP address on the new NIC so that when the Virtual Machine rebooted it was immediately available on the network. When I tried to do so I was prompted with an error:

"The IP address you have entered for this network adapter is already assigned to another adapter"

Since I had 'physically' removed the original adaptor I checked device manager to try and uninstall it but it was not listed. When a device is removed from a physical server but was not uninstalled it becomes hidden in device manager. To view hidden devices you need to open a command prompt:

Start -> run -> cmd

Now type the following:

SET DEVMGR_SHOW_NONPRESENT_DEVICES=1
START DEVMGMT.MSC

This will start device manager with the option to 'Show hidden devices'. To enable this option go to:

View -> Show hidden devices

Now when you browse Network Adaptors you will see the hidden NIC (it will be ghosted out) and can right click and uninstall it.

After uninstalling the old NIC I was able to set the IP address of the server on the new NIC with no issues. After a reboot the server was operational again.

Here is what I was presented with when I tried to logon:

Around the time it happened I remember the OS volume running extremely low on space and figured it may be a corrupt user profile. So I renamed the profile and then tried to logon to the server again using Remote Desktop. I was again presented with the same logon screen with black text fields. After a quick search on the Microsoft knowledge base I came across an article that seemed to offer a workaround:

KB906510

I had a quick check of the HKEY_USERS\.Default\Control Panel\Colors registry key and surely enough lots of the colours were set to "0 0 0":

[HKEY_USERS\.DEFAULT\Control Panel\Colors]
"ActiveBorder"="212 208 200"
"ActiveTitle"="10 36 106"
"AppWorkSpace"="128 128 128"
"Background"="102 111 116"
"ButtonAlternateFace"="181 181 181"
"ButtonDkShadow"="64 64 64"
"ButtonFace"="212 208 200"
"ButtonHilight"="255 255 255"
"ButtonLight"="212 208 200"
"ButtonShadow"="128 128 128"
"ButtonText"="0 0 0"
"GradientActiveTitle"="166 202 240"
"GradientInactiveTitle"="192 192 192"
"GrayText"="128 128 128"
"Hilight"="10 36 106"
"HilightText"="255 255 255"
"HotTrackingColor"="0 0 128"
"InactiveBorder"="0 0 0"
"InactiveTitle"="0 0 0"
"InactiveTitleText"="0 0 0"
"InfoText"="0 0 0"
"InfoWindow"="0 0 0"
"Menu"="0 0 0"
"MenuText"="0 0 0"
"Scrollbar"="0 0 0"
"TitleText"="0 0 0"
"Window"="0 0 0"
"WindowFrame"="0 0 0"
"WindowText"="0 0 0"
"MenuHilight"="0 0 0"
"MenuBar"="0 0 0"

I exported the same registry key from another server (that wasn't affected) and imported it into the registry of the server that was displaying the black logon screen. After logging off and back onto the server (no reboot necessary) the colours had returned to what they were previously:

The registry key values I exported came from a Server running Server 2003 Enterprise Edition but I have compared them to those of Server 2003 Standard Edition and they are the same. You can download the correct registry values from here:

Download registry values for KB906510

I have seen issues before on Windows XP machines where I couldn't open or run compiled HTML .chm from a network share (.chm files would fail to display any content in the same fashion as this problem was.) The only differences in this case being the file was local, it was on my desktop on my Vista computer!

After eventually right clicking the .chm file and checking properties I noticed an option at the bottom of the 'General' tab:

The option explained that "This file came from another computer and might be blocked to help protect this computer."

Since I had downloaded this help file from Microsoft's website I knew it could be trusted and clicked on the 'unblock' button. After which I could open the file as per normal and it displayed both the table of contents and all of the information/content.

Note - files with a .chm extension could potentially execute commands on your computer leaving you subject to malicious attack. If the .chm file is untrusted you shouldn't click the unblock button and open the file.