Selecting the Custom (advanced) option allowed me to remove existing partitions and install Windows 7 as I would have expected to out of the box, instead of having to perform a Vista to Windows 7 upgrade. After successful installation of the OS I installed the remaining drivers and then tried to activate. During the activation process I was prompted with an error.

The following failure occurred while trying to use the product key:

Code:
0xC004F061

Description:
The Software Licensing Service determined that this specified product key can only be used for upgrading, not for clean installations.

To activate Windows 7 after I used the upgrade disc to perform a clean installation I changed one registry key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\OOBE

Value: MediaBootInstall= 1 changed to 0

After modifying the registry key I was able to activate successfully.

Download the regkey change - HERE

As far as W32Time (the Windows time service) is concerned, at the topmost level within the domain is the domain controller on which the PDC Emulator Flexible Single Master Operation (FSMO) role resides. This can be configured to synchronize it's time with a reliable external time source. By default all other domain controllers internally synchronize their time with the PDC Emulator. Similarly all domain member client computers synchronize their time with the domain controller that authenticates them.

Configuring the domain controller where the PDC Emulator role resides should be the only computer in the domain that requires any manual intervention to have the precise time on all domain client computers.

To find out which server the PDC Emulator role resides on open the Active Directory Users and Computers (ADUC) snap-in. Then right click on your domain and select 'Operations Masters'. Browsing the PDC tab will show you where the PDC Emulator role currently resides.

On the domain controller where the PDC Emulator resides you can configure it to synchronize its time with an external source by using the following command:

net time /setsntp:<ip/dns>

Use the following example to set multiple external time sources to sync with:

net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org"

You can also configure this manually by modifying the following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

NtpServer=<ip/dns>
Type=NT5DS change this to Type=NTP

After making the above changes restart the W32Time service by issuing the following commands at a command prompt:

net stop w32time
net start w32time

NOTE: If you don't configure the PDC Emulator to synchronize its time with an external source it will simply use its own (CMOS) clock. Doing so will occasionally cause an error to appear in the event log on the server that resembles the following:

Event Type: Error
Event Source: W32Time
Event Category: None
Event ID: 12

Event description: Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source.

NOTE: If you experience a client with time synchronization problems ensure that it has the correct time zone set. If needed, the time service can be reset using the following commands:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync

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.

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.

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

After a quick look in the application log on the server I could see that there was an error reported by the SQL instance (I use the SQL Server Express edition default installation for VCenter installations) just before the vpxd service had also logged an error. The first error appeared to be related to the vpxd service starting and establishing a connection to the SQL database. During the connection the authentication had failed and so the vpxd service had failed to start as per the second error.

The immediate reason for this happening seemed to be because during boot up the vpxd service was attempting to start before the SQL service, except the vpxd service was almost relying on the SQL service having started before so that it could establish a connection to the SQL database. Without the SQL service starting prior to the vpxd service there was no way that the connection could be established.

I found that the workaround to this issue is to make the vpxd service dependent on the SQL Server service so that it waits for the SQL Server service to start before it attempts to start itself and a connection to the SQL database is established.

The easiest way to do this is:

1) Establish the service name of the SQL instance for VCenter. If you have installed VCenter using SQL Server Express edition then by default the name is 'MSSQL$SQLEXP_VIM'. If you have used a different version of SQL Server you will need to open the computer management console services snapin (start -> run -> services.msc) and find the service called SQL Server. Right click on the service and select properties to view the service name and make a note of it.

2) Note: You can download the following regkey changes for SQL Server Express - HERE

Open regedit (start -> run -> regedit) and navigate to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd

Open the Multi String value for DependOnService by double clicking on the value. On a new line add the service name of your SQL instance. I added the following on a new line because I use SQL Server Express edition:

3) Close the registry editor, open services.msc again and check that the VMware VirtualCenter Server service is now dependent on the relevant the relevant SQL Server service.

Since making the vpxd service dependent on the SQL Server service I have not had a problem rebooting a server running VCenter where the VMware VirtualCenter Server service fails to start.

Here is the logon screen before the registry key has been added:

Here is what happens if a user selects the "Log on using dial-up connection" checkbox before logging on:

Setting the following registry key will disable the checkbox, disabling all users from using the dial-up connection feature:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

you will need to manually create a new string value (REG_SZ) called RasDisable. Set the value's data to 1.

Here is the final result:

And finally here is what I wrote to add the regkey to all computers using a KiXtart startup script through Group Policy:

;===============================================
;===============================================
;
; DISABLE LOGON USING DIAL-UP CONNECTION
;
;===============================================
;===============================================

IF READVALUE("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon", "RasDisable") <>"1"
WRITEVALUE("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon", "RasDisable", "1", "REG_SZ")
ENDIF

NOTE: I've noticed that the quote marks are not displayed properly on this page. Here is the KiXtart script in its intended form:

Download Here

The following registry key allows you to enable it again and can obviously be scripted to run for users at logon:

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

Change the data stored within the 00036601 (REG_BINARY) value. These are the usable items of data that can be stored within the key value:

84 01 00 00 = cached mode enabled for email (the default setting pre SP3)
84 05 00 00 = cached mode enabled for email, and public folders
04 00 00 00 = cached mode disabled (default setting post SP3)

1. Open the registry editor on the client (regedit)

2. Find the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\LANDesk\VirusProtect6\CurrentVersion\AdministratorOnly\Security

3. Change the data stored within the UseVPUninstallPassword value from 1 to 0

4. Clost regedit and try uninstalling Symantec Antivirus from the client. It should now uninstall without prompting for the password.

You can alternatively make the Registry key change (I.e. perform all of the above steps) by saving the following file to your computer, double clicking the file and merging the contents with your registry:

Download Here (you may need to right click this link and use "save as" to save it)

In a situation where you are running a Symantec Antivirus Server managing clients you will probably want to script the registry key change through a start-up script.