What you need is Loopback processing (See here for more details http://support.microsoft.com/kb/231287). Loopback processing is most often needed for kiosk type machine or common use computer lab scenarios.

Open up the Group Policy Object and navigate to “Computer Configuration -> Policies -> Administrative Templates -> System -> Group Policy“.

Open the “User Group Policy loopback processing mode” policy and set it to “Enabled“.

The next option is the “Mode” to use. Set the mode to “Replace” if you want no other User Policies to be in effect on the particular machines you are targeting, or “Merge” if you want all other User Policy settings to apply as well as the settings specified in the loopback policy.

I have been around Group Policy for a while and have never needed this setting before (the need for user targeted policies to a set of machines has never come up), so going through all the motions of setting policy security restrictions and changing the OU location of both the policy, the machines and the users in testing chewed up well over an hour of fiddling time. Setting a policy for loopback processing is easy, the hard part is realising that loopback processing is what you need to do in the first place.

I have been waiting for the ESM tools for Exchange 2010 to hopefully work with Exchange 2003 but that hasn’t happened either. Although I did find a really quick and easy solution this morning after reading the following posts on TechNet (Exchange System Manager for exchange 2003)

You will need to download the Exchange System Manager for Windows Vista then use something like WinRAR to extract the contents.

You will also need to make sure you already have the RSAT tools installed (Remote Server Admin Tools)

Finally open up a Command Prompt as Administrator. Browse to the directory that contains the ESMVISTA.MSI file. Run the following:

ESMVISTA.MSI /q

Once this is done you should be able to open the “Active Directory and Computers” and edit an Exchange User with all the required email tabs.

The upgrade the VMWare ESX 4.0 Update 1 ran smoothly and all hosts came back to life after the upgrade as they should. Installation of the client on Windows 7 was also painless, and best of all it actually worked.

To anyone from VMWare who may be watching, it would be nice if you had some form of announcements mailing list so we could be informed of these updates being made available.

There are certain things that when it doesn’t work you wouldn’t be surprised. We all have that application that hasn’t been updated in years but we still need to use on a regular basis. I can somewhat understand why these things don’t work within a new operating system. But for something that gets updated on a regular basis to not work, that is a different story altogether and that really annoys me.

Given that some form of Windows 7 has been available to vendors for a long time it shows VMWare with a high level of contempt for it’s users. There is absolutely no excuse for there not to be an update to support Windows 7, especially considering there have been reports of it not working from early RC days.

The official response from VMWare (KB 1011329) is to just use a XP virtual machine. There is not even a mention on how long they will take to fix the issue.

Kiwi Si at Techhead has found a better workaround but still while this gets things working there should be a better option. We all pay a lot of money for VMWare and as such should deserve better treatment.

I run 4gb of ram in my laptop so I though that I would go 64 bit (and get back that extra 600 or so mb of ram that gets stolen on 32bit machines). The initial install went well, including the install and subsequent windows update yielded a full set drivers for my machine (except the fingerprint sensor, for which Dell haven’t released a Windows 7 driver for yet either).

Everything started to fall apart when I needed to install the Cisco VPN Client. No deal, the Cisco VPN Client wont install on 64 bit windows installs. After some research I found that people were having success using the new XP Mode feature of Windows 7. XP Mode allows you to run an XP virtual machine on select hardware (needing CPU virtualization support). I quickly realised that this wouldn’t be very practical as you can only access the VPN resources from within the virtual machine (I also had limited success in actually getting the Cisco client installed in the XP Mode machine anyway).

So that was it. I need VPN access for my work, and 64 bit was getting in the way of that. Back to 32 bit I go. The installation ran just as smoothly as the 64 bit install, and once again with a full suite of drivers (still with the exception of the fingerprint reader, but that’s not a big loss).

It may be just me but the 32 bit installation even feels like it is performing better then the 64 bit installation, windows feel snappier to move around, open and close and the machine is quicker to boot as well as resume from hibernation. The question that I am left with is that we can run 32 bit applications on a 64 bit platform with wow (Windows on Windows) so why can’t there be a similar situation for drivers. I understand there would be a performance hit for doing this but with 64 bit being ultimately pushed as the way forward there needs to be a solution to allow legacy applications and devices to operate.

To quickly access the hosts file go Start -> Run -> Type drivers -> Ok.

This will bring up the folder before the hosts file, just double click into the etc directory from there.

The other method is to create a new shortcut on your Start Menu or Desktop with the following as the target

%windir%system32notepad.exe "c:WINDOWSsystem32driversetchosts"

Two easy methods to access your hosts file.