In Part 1 and Part 2 we looked at deploying the start of an Active Directory using Vmware Player for testing purposes. In Part 3 we’ll look at deploying additional virtual machines and promoting them to domain members.

At the completion of Part 2, we should have one “template” virtual machine that will be copied each time we need a new VM and one deployed domain controller for the domain of our choice (invurted.local).

Building on this we want an additional member server for the domain. This server will use the Active Directory to authenticate users.

As in Part 2, there are two options for deploying a virtual machine
a) Build it from scratch, or;
b) Copy an existing virtual machine and copy it.

For ease of deployment, we are going to copy the _TMPL-inv-dc01 virtual machine.

Right click and select Copy on the directory of _TMPL-inv-dc01. In the same directory, right click and select Paste or use the Edit menu in Windows Explorer to paste. This may take a couple of minutes to copy. The virtual machine that we built takes up 6.50 GB (6,983,880,704 bytes) on my hard drive.

Once the copy is complete, we can rename the new copy to something more meaningful than _TMPL-inv-dc01 – Copy. Right click on the folder that has been created, select rename and call it inv-srv01.

Now the virtual machine is ready to start up. At this point, be aware that there are some Windows 2008 configuration changes needed before we can make the server a domain member. The IP address and machine name, at the least, will need to be changed.

Because the files for the machine are a direct copy of the “template”, the following should happen.

As you can see, the directory is called inv-srv01 and the Vmware virtual machine configuration (.vmx extension) still has the inv-dc01 name. This is not a major problem and can be fixed by right clicking the file, selecting Rename and changing the name to inv-srv01. DO NOT change the contents of the file as it contains configuration information that points to other files in the directory. Improperly edits can result in non-bootable virtual machines.

Once the file is renamed, open it using Vmware Player and the wait for the virtual machine to boot. Hopefully you get the following dialogue box.

Select the “I copied it” option and press OK.

We are immediately prompted to install Vmware Tools in the new virtual machine. The template that we made was post-operating system installation, but pre-install of Vmware Tools. Choose to either install now or be reminded later.

When we run an ipconfig in the virtual machine, the IP address is allocated from a DHCP pool that is managed by Vmware Player. This IP address won’t be able to communicate with the domain that we created and, therefore, won’t be able to join the domain.

Setting the IP address can be done any number of ways, the previous tutorial used the netsh command:
The interface that we are interested in is Local Area Connection.

netsh interface ip set address name="Local Area Connection" static 192.168.0.20 255.255.255.0 192.168.0.1 1

and, most importantly, set the DNS IP address. This is required to join the domain successfully. Again, at the command prompt:

netsh interface ip set dns "Local Area Connection" static 192.168.0.10

Now we can join the domain. There are multiple ways to joing the domain, but we’re doing so much at the command line, we may as well keep going.

From a DOS prompt, type hostname and press enter.

The hostname is the randomly generated when we created the virtual machine and installed the Windows 2008 operating system. Renaming the computer will be done using the command line and the command NETDOM. We are still not part of the domain. so the command syntax is pretty straight forward:

netsh renamecomputer win-agimt9cb3rv /newname inv-srv01

The renamecomputer win-agimt9cb3rv will change to whatever your hostname is.

This command will require a reboot to apply the new name. Once rebooted, login and open a command prompt again.

Test connectivity to the network, ping invurted.local. Any response from the network is considered successful. Again, from the command line:

netdom join inv-srv01 /domain:invurted.local /userd:administrator /passwordd:P@ssw0rd

This command requires a reboot when successful. If it fails, check your IP address and, especially, DNS address to make sure they are right.

Once rebooted, login as username invurted\administrator with the password word P@ssw0rd and now we have one domain joined Windows 2008 server!

That’s Part 3 complete. Any suggestions where to go from here? Please email me (contactme [at] invurted dot com).

In Part 1 we installed Vmware Player and installed Windows 2008 R2 Enterprise into a virtual machine. In this second part, we’ll look at setting up another virtual machine and deploying our first domain controller for the testing environment.

We could definitely go back and setup another virtual machine using the the same process as before. However, this takes too long; the least of which we have to wait for Windows 2008 R2 to re-install.

An easier option is to copy the existing virtual machine files to a new directory and paste it as a new virtual machine.

1. Right click on our perviously built virtual machine (inv-dc01), select Copy and then right click and Paste into the same directory. This will create two copies of the virtual machine, inv-dc01 (the original) and inv-dc01 – Copy. This process can be repeated as many times as we like until the local drive is full.

   

   For the moment, all that is required is the two copies of the virtual machine.

2. Rename inv-dc01 – Copy to _TMPL-inv-dc01. Now we have a TEMPLATE version of a virtual machine with Windows 2008 R2 installed and can continue to take copies of it as needed.

Onto setting up our domain controller.

1. Open the Vmware virtual machine configuration file by double clicking or right click and open the Vmware virtual machine configuration file with Vmware Player.
   
2. Once the operating system has started, use CTRL+ALT+INSERT to get to the login screen.
   
   At this point login as the user we created or login as Administrator. If you login as Administrator, Windows will prompt you to change the password. The Administrator password will also have to meet complexity requirements ie. uppercase, lowercase, letter, number and special characters.
3. Next up is the all important Vmware Tools. VMware Tools package adds drivers and utilities to improve the graphical performance for different guest operating systems, including mouse tracking. The package also enables some integration between the guest and host systems, including shared folders, plug-and-play devices, clock synchronisation, and cutting-and-pasting across environments.
   
   Click “Install Tools” in the bottom bar of the window to start the install process.
4. You may want to close this window for the moment to allow the Vmware Tools installer to run.
5. If this dialog fails to appear, open Windows Explorer, browse to the CD drive of the virtual machine and run setup.exe manually.
   
   Install Vmware Tools using the default settings; there is no real benefit to be gained from changing the default options in our scenario.
   
   Once the installer has completed, reboot the virtual machine and then log back in when it has restarted.

Once the desktop is initialised, there are a couple of configurations required before we can create the domain controller. Primarily, the IP address and the Windows machine name.

1. The domain controller ABSOLUTLEY has to have a statically assigned IP address, and the easiest (and most fun!) way to do this is set it via the command line:

   netsh interface ip show config

   
   This will show all the adapters currently available to the virtual machine. The interface that we are interested in is Local Area Connection. Once we have establised that it is available and has an IP address allocated from DHCP, it needs to be changed to a static IP address.

   netsh interface ip set address name="Local Area Connection" static 192.168.0.10 255.255.255.0 192.168.0.1 1

   This set the static IP of 192.168.0.10, subnet mask of 255.255.255.0 and default gateway (which we don’t need for the moment) of 192.168.0.1. For the purposes of completeness, it’s best to put the gateway in.
   DNS is still required, but configuring the domain controller will automatically install this service on the domain controller.
   Running ipconfig from the command line should verify the configuration has been applied.

2. Finally we’re at the point of installing the domain controller! From the command prompt, run dcpromo to start the install.
   
3. From here it is a simple matter of following the prompts.
   • At the Active Directory Domain Services Installation Wizard make sure Use advanced mode installation is NOT selected and press Next.
   • The next window is a warning about incompatibilites with Windows NT 4.0. Just press Next.
   • Choose a Deployment Configuration – Check the Create a new domain in a new forest and press Next.
   • Name the Forest Root Domain – In the FQDN of the forest root domain enter the name of your network. For our purposes, any name will do. invurted.local is acceptable. Press Next.
   • Set forest functional level – Select Windows 2008 R2 from the drop down list. This will mean that all domain controllers have to have at least Windows 2008 R2 as their operating systems. Press Next.
   • Additional Domain Controllers – Make sure the DNS Server option is ticked and press Next. Select Yes for any dialog boxes that appear.
   • Location for Database, Log Files and SYSLOG – Accept the default locations and press Next.
   • Directory Services Restore Mode Password – Enter the password of P@ssw0rd in both fields and press Next.
   • Summary – Verify your settings and press Next.
   • Active Directory Domain Services Installation WizardActive Directory will now start installing. At the completion, reboot the virtual machine. If everything is successful, upon reboot, your domain controller setup is complete.

Upon successful restart and login using the Administrator username and password, we want to look at our new domain. From the start menu, select Administrative Tools and launch the Active Directory Users and Computer program. This will allow us to create any users, groups and Organisation Units that are required.

I almost forgot! We need to rename our domain controller. In previous versions of Windows this was painful, especially as the virtual machine is a domain controller. In Windows 2008 there is more tolerance to name changes. It’s not the sort of thing that I would want to do regularly, but is possible.
In the start menu, right click on Computer and select Properties.

Chose Change settings and accept any warnings that appear on screen.

In the Sytem Properties, select Change and, again, accept any warning that appear.

In the computer name field enter the new name for the computer. For our purposes, inv-dc01 will do fine. Press OK twice and then close the system properties. At this point, it is a good idea to restart the machine again.

That’s Part 2 complete. In Part 3 we’ll look at configuring the virtual machine as a domain member server.

As ever, if you have any questions, please email me (contactme [at] invurted dot com).

Following a number of requests, I have written a tutorial on setting up a Windows 2008 testing environment. Part 1 looks at installing Vmware Player and setting up the first virtual machine
ASSUMPTIONS:

• A supported operating system is used. Vmware Player supports most Microsoft operating systems as well as a number of Linux distributions. For the purposes of this tutorial, Windows 7 is the operating system used as the base.
• The account on the Windows 7 base operating system is either a member of the Local Administrators group or can elevate priveledges as required.
• At least 50 – 100 GB of storage space is available for all the virtual machines. It’s better to err on the side of caution.
• Vmware Player is the chosen hypervisor. Vmware Workstation could as easily be used if available. We use Vmware Player as the hypervisor due to it’s cross platform compatibility and its free licensing.
• We are only doing the setup of the first virtual machine. Further configuration will be done in subsequent tutorials.

On to the fun bits! As with most hypervisor technologies, the result of what we are doing here is allowing me to run two (or more) instances of operating systems on the one hardware platform. Vmware Player is our chosen hypervisor because it removes a lot of the guess work from deploying virtual machines. Vmware Workstation definitely gives us more granular control over the final conifguration. For our purposes, the default RAM, CPU and storage configurations are more than acceptable.

1. Install Vmware player following all the default configuration options. There is little need to change the installation path etc. unless absolutley necessary.
2. Once installed, run the program and select “Create new Virtual Machines”.
   
   This will start the wizard driven configuration of the new virtual machine that we will use as the basis for the testing environment.
3. One of the first configuration options is the installation media. We’re focussing on the first two options; providing either a CDROM or an ISO file to install from. It’s possible to network boot a virtual machine, but that’s something for later.
   If we load a CDROM into the drive, Vmware Player should recognise the operating system. Similarly with an ISO file.
   
4. Next up, the all important licence key. Windows 2008 R2, Enterprise will install without a key being provided. It will install in Evaluation Mode giving us sixty days to activate with a valid licence. Again, for purely testing purposes, we can ignore the licence key and come back to it later if we need to. The only configuration to be aware of is the version of Windows 2008 to install. The CDROM (or ISO file, in this case) has a number of different versions available. Make sure Windows 2008 R2 Enterprise is the selected option.
   
   The only other piece of information needed is the first user who is installed. The username can be Administrator, but Vmware Player will throw back a warning. Windows 2008 doesn’t treat the Administrator account the same as previous operating systems. To perform most administrative functions, we still have to elevate the credentials. The user name is invurted and a password of P@ssw0rd to meet complexity requirements.
5. Now we apply the name and location of the virtual machine. This is where the space requirement comes in. By default, Vmware Player saves the virtual machine files to the current user’s directory. Both the name and the save location can be changed at this point. A recommendation would be make sure the volume that you are saving the virtual machines to has enough space for all the hard disks that will be created.
   
6. The next step is to configure the virtual hard disk. In the physical world this would be the hard disk used as an installation target for Windows. It’s exactly the same in the virtual machine. The main difference is that the size represents the maximum size that the “physical” hard drive will be reported as to the Windows operating system.
   
   As this server will only provide domain controller and networking services for the lab environment, it’s been configured as a 20GB hard drive. In the real world, we would attach a second virtual hard drive of larger size that would store all of the application data, leaving the operating system with a volume all to itself.
7. Almost there!
   
   We have our final configuration ready to go. Before powering on the virtual machine for the first time, we need to customise the virtual machine.
   
   The networking configuration is the one major limitation of Vmware Player. Vmware Workstation has a lot more configuration options available.
   The three options are:
   • Bridged – the virtual machine will use an available physical adapter for the virtual machine. This will appear on the network as a separate device from the host operating system. As out virtual machine will be a domain controller, we don’t want to expose it to the real, potentially production, nework.
     DO NOT use a bridged adapter unless you are absolutley certain it is required.
   • NAT – the virtual machine will use the same IP address assigned to a physical adapter. Both the virtual machine and the host OS will appear on the network as the “same” device.
     DO NOT use a bridged adapter unless you are absolutley certain it is required.
   • Host only – This will create a software based virtual switch that virtual machines will be plugged into. The virtual machine will have no network connectivity unless a virutal routing device is created. This is the safest option as it removes the ability for our test lab to interfere with the real, production network.
8. As the machine powers up for the first time, we should see the familiar Windows starting screen. If at this point you don’t see it, check that the CDROM or ISO file is properly mounted.
   
   We need to mount the CDROM or ISO file through this interface.
   
   Once this is done, press CTRL+ALT+INSERT to force a reset of the virtual machine. If you hit CTRL+ALT+DELETE, this will open up the option to get to the task manager of the host operating system.
9. Go and get a cup of tea, sit back and relax because Windows 2008 is installing and there’s very little required at this point.
   
   Once Windows has finished installing, we should be presented with this screen. From this point on, there is no difference between the virual machine and a real version of Windows 2008.
   Power off the virtual machine and move onto Part 2!

That’s Part 1 complete. In Part 2 we’ll look at configuring the virtual machine as a domain controller and deploying additional servers for the rest of the lab.

As ever, if you have any questions, please email me (contactme [at] invurted dot com).

Well, haven’t I been out of the loop for a while?! Thankfully, my unemployment lasted nowhere near as long as I would have expected in the harsh economic climate and I am adjusting brilliantly to corporate/enterprise life once again (like there would be any doubt!)

All bragging aside, I have been working on a Storage Craft disaster recovery (DR) solution combining Vmware and Microsoft Distributed File System. The basic structure is this:

Storagecraft takes snapshots/incremental backups of virtual machines in the existing infrastructure and places them into a folder on it’s local storage that is then replicated across the WAN to the DR site. The DR site, also a Storagecraft server and also having a standalone ESX 3.5 server, can restore images of these machines with a fifteen minute tolerance of when the machine failed. This is all reliant on the most recent incremental backups being transmitted across the wire successfully.

Of course, as a DR site, the client is extremely interested in as much reporting as possible and this includes DFS. There is a builtin reporting function in DFS that requires manual intervention to trigger. The client requires automated reporting, as you would expect.

After trawling the internet, I found a workable solution combining a script and task scheduling in Windows 2003 R2.

As an aside, there was this handy little reference that I stumbled across as well. Nothing too surprising, but definitely worth thinking about.

The solution for the reporting was a script ripped from:

http://blogs.technet.com/filecab/articles/437214.aspx

and it looks like this:

#######
## REM This script needs to run as a daily scheduled task by someone who has
## REM local administrator rights for all machines in reported RG. This script
## REM will generate a health report for all members of the replication group,
## REM with backlog based on a specified reference member. When reports are
## REM complete they will be saved to a specified share. When ALL reports are
## REM done, mail will be sent to the specified e-mail alias with links to the
## REM share.
#######

cl_mail.exe smtp server:my_smtphost to:some_Alias@domain.com from:your_alias@domain.com subject:"DFS Replication Health Reports %DDMMYYYY%" message:@%TEMP%\healthMessageBody.txt auth:sspi


The only potential problems are:

• The requirement for a command line email utility
• Only notification of the report’s location, not the report itself
• Size over time. Each report generated takes about 60KB of disk space.
• The format of the report ie. XML/HTML

Still, it’s better than nothing!!

For my first non-Vmware post in a while, this is kind of interesting!

As part of a select group of our key customers, you are invited to participate in the Beta Program for the Microsoft® Hyper-VT Security Guide. This guide is designed to provide guidance, instructions, and recommendations to help you elevate the security of virtualized Windows Server® environments to meet your business-critical needs.

The Hyper-V Security Guide provides the following information to address your security concerns around server virtualization:

Hardening Hyper-V: Prescriptive guidance for hardening the Hyper-V server role, including several best practices for installing and configuring Hyper-V with a focus on security. These best practices include measures for reducing the attack surface of Hyper-V as well as recommendations for properly configuring secure virtual networks and storage devices on a Hyper-V host server.
Delegating virtual machine management: Prescriptive guidance to help you safely and securely delegate administrative access to virtual machine resources within an organization.
Protecting virtual machines: Prescriptive guidance for securing virtual machine resources, including best practices and detailed steps for protecting virtual machines by using a combination of file system permissions, encryption, and auditing.
By participating in this Beta Program, you can provide timely feedback about the guidance to our team to help us ensure that it meets your needs when released!

What’s the timeline for the Beta review?
The Beta review period runs through March 4th, 2009. We need to receive your input during this period for your feedback to be included in the final release of the project.

Where do I download the Beta?
To download the Beta and submit feedback, please join the Program Connect Web site. After joining the Beta review program, bookmark this link to the program site to get the latest information about the project

How and where do I provide feedback?
To provide us your feedback please read the feedback instructions.

We look forward to hearing from you! Thanks for taking the time to review the Beta material. Please let us know if you have any questions.

I am really interested to see how Hyper-V stacks up against its’ quite formidable competition. The question that always springs to ming whenever I look at Microsoft’s Hyper-V is, “If I am an entirely Microsoft house, why not use a virtualisation product optimised for my environment?”

Interesting times …

Guys are hard at work with the labs at the moment here in sunny Hobart, and so I begin trawling the blogs (as is my want). I discovered this brilliant little gem from Mike DiPetrill’s blog.

This post demonstates the awesome power of the Vmware API and the ease of use we get from the VI Toolkit for Windows! The script will move a VM from one ESX host to another, without making use of VMware VMotion. The drawback is that the VM becomes unresponsive for a period of time (usually a few seconds). This is roughly functionally equivalent to Microsoft’s Quick Migration feature, except that this was done in 130 lines of script.

There are no permanent enemies in politics, just permanent interests, the truism goes; and this is apparently true in business as well. InternetNews.com has learned that VMware has joined arch-rival Microsoft’s third-party server virtualization validation program (SVVP).

“VMware is proud to be a part of SVVP,” Carl Eschenbach, executive vice president of worldwide field operations, said in an email sent to InternetNews.com. “VMware is looking forward to working closely with Microsoft to complete the certification of VMware ESX under the SVVP program to provide customers the support they need to gain the flexibility and benefits of working in virtualized environments.”

ESX is one of VMware’s hypervisors(define), and Microsoft’s certification is necessary if customers using VMware new policy Microsoft announced today. That policy says Microsoft will provide technical support for 31 server applications deployed on its hypervisors or on “any other third-party validated virtualization platform.”

The initial announcement of SVVP participants in June named Cisco Systems, Citrix Systems, Novell, Sun Microsystems and Virtual Iron. A Microsoft spokesperson would not specifically confirm VMware’s participation and told InternetNews.com to “please contact [VMware public relations manager] with questions regarding VMware’s participation.”

VMware and Microsoft (NASDAQ: MSFT) are locked in a battle for the burgeoning virtualization market. Microsoft released its Hyper-V hypervisor earlier than scheduled, and it’s believed that EMC, which owns VMware, forced out Diane Greene as CEO and replaced her with former Microsoft executive Paul Maritz to help better combat Microsoft.

VMware’s chief financial officer, Mark Peek, admitted during its second quarter earnings call recently that competition from Microsoft will impact his company’s earnings negatively.

In the same call, VMware’s new CEO, Paul Maritz, said that the key to competing with Microsoft is “to stay ahead [in the market] and that’s exactly what we intend to do.” And, shortly after Maritz’s assumption of the reins at VMware, the company brought out a free version of its hypervisor, ESXi.

So why is VMware making nice with Microsoft? It really has no choice: Regardless of its newness, Hyper-V is a definite contender, especially because it runs on Microsoft’s popular SharePoint Server 2008.

So, an uneasy alliance is good business. “VMware has been collaborating with Microsoft and other ISVs (independent software vendors) to ensure that our customers are supported at the highest possible level,” VMware’s Eschenbach said.

Corporations are experimenting with Hyper-V, if only for now, to learn what it can do. “We’re using Hyper-V right now, it’s another utility for us to go out there and play with,” Kevin Murphy, chief technology officer at NEI, which makes physical and virtual appliances for independent software vendors, told InternetNews.com.

For its part, Microsoft gives its users a break by making VMware integration easier and avoids further controversy: In February 2007, VMware charged Microsoft with leveraging its ownership of the Windows operating system and applications that permeate corporate IT to drive customers to use Microsoft virtualization products. VMware barely stopping short of accusing Microsoft of antitrust law violations.

SOURCE: http://www.internetnews.com/

The constant question with Vmware is, “Can I cluster using Microsoft Clustering Services?”

The answer now, thankfully, is yes you can. And just to stretch it out a bit more there’s this!

Chris Skinner who works for Vmware as a Technical Trainer has put together another awesome white paper. This time he’s proving that you can virtualise Virtual Center AND put it into a Microsoft Cluster.

Like all his previous papers, this one is distributed freely but without warranty or guarantee. So, it’s a case of reader beware! However, after reading it and testing, it looks the goods!

ClusteringVC25.pdf

The Microsoft near-term strategy to win the virtualization market is clear: deliver a low cost hypervisor with basic management capabilities to attract SMBs, deliver a centralized management console which simplifies the migration from VMware ESX to Hyper-V to attract the Enterprises, call for support and interoperability the entire partners ecosystem to attract both.

Today at the Microsoft Management Summit 2008 the company puts on the table another piece of this strategy, opening the much awaited beta program of System Center Virtual Machine Manager (SCVMM) 2008.

The product was expected not only because it can finally manage Hyper-V hosts, but mostly because it promises to seamlessly manage VMware ESX hosts as well.

Microsoft hopes that its customers, already implementing the competing hypervisor, stop using VirtualCenter and turn to SCVMM 2008 for any task (including VMotion!). Unfortunately this goal seems hard to achieve considering some limitations that plague this first attempt.
For instance there are no current plans to manage the ESX hosts patching, which is a critical feature demanded for years by VMware customers and finally implemented in VI 3.5 through the new Update Manager (VUM): even if Microsoft WSUS can easily patch the guest OSes, until it will also patch ESX itself customers will still have to open the VirtualCenter console every day.

On top of that, there is the evident “feature-delay” that Microsoft will suffer forever: in any moment VMware can deliver new VirtualCenter capabilities so to maintain its console a mandatory component or at least a highly desirable one.
It would be much different if SCVMM could directly control the ESX hosts: at that point Microsoft could win the customers offering the product at a fraction of the price. But this seems unlikely since VMware offers the ESX management APIs only through VirtualCenter.

Nonetheless SCVMM 2008 is very interesting: besides managing Hyper-V and ESX, it now includes a new feature called Performance and Resource Optimization (PRO) which continuously monitors the virtual infrastructure and suggests how virtual machines should be improved (upgrading the virtual hardware) or moved across the available virtualization host to achieve the best performance.

The PRO engine is influenced by some pre-defined policies and SCVMM administrators can decide to approve/ignore each suggestion or automate the process.
Additionally, PRO is extensible through 3rd party management packs, which can give further indications to SCVMM on how to move workload in the virtual data center.

Microsoft is expected to add further functionalities in the second beta of SCVMM 2008.

SOURCE: http://virtualization.info

This started happening in the 2823 Virtual PCs.

http://blogs.msdn.com/virtual_pc_guy/archive/2005/10/24/484461.aspx

Under certain circumstances with a Windows XP / 2003 operating system – intelppm.sys and processr.sys can cause a virtual machine running under Virtual PC / Virtual Server to crash (by default this will cause the Windows guest operating system to reboot automatically – but if you have changed this setting you will see a blue screen).  The reason for this crash is because these drivers are attempting to perform an unsupported operation inside of the virtual machine (like upgrading the physical processors microcode, changing power state on the physical processor).

Today this problem only occurs on Centrino and AMD K8 processors.  Most people see this problem when they move a virtual machine that was created on another type of processor to a computer running one of these types of processors (and then they usually see the problem when they attempt to shutdown their virtual machine for the first time).  Now you may be wondering why you have not heard about this problem more often – and the reason for that is that if these drivers fail once – they are smart enough to not attempt to perform the operation that failed again.

If you are seeing this problem repeatedly you can manually disable these drivers (with no negative side effect) by going to the following location in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor

Or

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm

And changing the Start value to 4.

In the mean time we have made some subtle changes to the way our hardware exposes the processor in Virtual Server R2 so that in future products these drivers should never get loaded inside of virtual machines.