Uninstalling Virtual Machine Additions in Hyper-V

The error message "this installer may only be run inside of a virtual machine" appears when you try to remove old virtual machine additions (from Virtual Server 2005/Virtual PC 2004) when running the virtual machine in Hyper-V.

The migration guidelines recommend the removal (but do not mandate it) of the Virtual Machine Additions. But this is probably because later versions of the additions can be removed from inside Hyper-V, earlier versions cannot.

The problem is the existence of this software stops the installation of the Hyper-V Integration Services.

So to remove the Virtual Machine Additions of the Hyper-V guest (that has been previously used in Virtual PC/Server) you need to do the following:

1. Shutdown the Hyper-V virtual guest
2. Share the folder containing the VHD for this guest
3. Install Virtual PC 2007 or later on another computer
4. Create a new virtual guest on the Virtual PC, pointing the VHD property to the shared VHD on the network and do not create undo disks.
5. Boot the Virtual PC guest and uninstall the Virtual Machine Additions. Any prompts about new hardware should be ignored by pressing the Cancel button.
6. The removal process will require a reboot. Once the reboot has completed you can then shutdown the virtual PC.
7. Remove the Virtual PC guest, stop sharing the VHD folder and restart the guest in Hyper-V.
8. Install the Hyper-V Integration Services.

If the virtual guest is so old as to have a Standard PC HAL installed then attempts to install the Integration Services results in the following error "Setup cannot upgrade the HAL in this virtual machine. Hyper-V integration services can be installed only on virtual machines with an ACPI-compatible HAL. For information about hardware requirements, see the Hyper-V documentation".

This cannot be fixed and so if you have an old virtual machine that has a Standard PC HAL (from Device Manager > Computer) then do without the integration services or rebuild the guest from scratch.

Message Tracking Logs ‘And/Or’ Error

The following message appears in the Exchange Server 2003 message tracking logs:

The object 'and/or' in the message tracking logs can't be found in the directory.  The object may have been deleted.  The tracking history may be incorrect.

This is an error that can be ignored as it does not mean that the email message that you are tracking has not been delivered (discounting other errors that is).

This error occurs in the Exchange Server 2003 tracking logs because the logs store the name of the recipients server, and if the recipients server is determined to be ‘and/or’ then that is what the log will read.

I have noticed that this error occurs when Exchange Server 2003 talks to Exim 4.69 servers with the following welcome message:

220-server.fqdn ESMTP Exim 4.69 #1 date time
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.

This welcome message is spread across three lines and the last line reads “220 and/or bulk e-mail”. Exchange uses the first word following 220<space> (and not 220<dash>) as the server name.

For example, the following is the welcome banner displayed by Postini/Google, which is a single line:

220 Postini ESMTP 108 y6_19_2c0 ready.  CA Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements.

Therefore Exchange will identify this server in the message tracking logs as “Postini”.

Editing the Registry on x64 Windows Computers

This is, in the main, just a quick note to myself! When editing the registry on a Windows x64 based computer, but the program that will read those registry settings is a 32 bit application then you need to change the location that you edit to the “Wow6432Node” rather than the usual location.

Note that when blogs and other technical articles write down a registry key they do not often mention that the registry location you need to change is not what they have written down!

For example, there is a problem in the Windows 7 RC release in which Internet Explorer 8 does not show some webpages resulting in an error “A webpage is not responding on the following website:” (see http://support.microsoft.com/kb/970858). The registry key describes setting the hangresistance value, but as Internet Explorer is a 32 bit application you need to set the hangresistance value at HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\ and not at HKLM\SOFTWARE\Microsoft\Internet Explorer\MAIN\.

If you follow the advice in the Microsoft support article KB970858 then it will not fix the problem on a 64 bit machine. You need to edit the Wow6432Node value instead.

There is an x64 version of Internet Explorer installed, but the common one that people use is the 32 bit version – if you use both, set both registry keys.