Here, are instructions for integrating the Hyper-V RTM (!) Integration Components device drivers into a WinPE image.  This is based on Mike Sterling's post on the same topic, however the scripts below have been updated to use RTM Hyper-V bits.

1. Create your WinPE build folder, if you haven't already done so.  See Building a WinPE Image from Scratch for help (follow only steps 1 through 5).
2. In the root of your build folder, download the appropriate integration batch file from the bottom of this post.
3. Locate Windows6.0-KB951634-x86.msu.  This file is on the c:\windows\system32\vmguest.iso, located on any Hyper-V enabled host.  The update file should be located in the Support folder of the ISO.  Copy this file to the root of your WinPE build folder - the same location as your integration batch script.
4. From the Windows PE Tools Command Prompt, execute the integration script.  If everything went correctly, you'll see "PEIMG completed the operation successfully." listed seven times in the output of the script.
5. At this point your WinPE build is updated.  Resume steps 7 through 9 in Building a WinPE Image from Scratch to complete the process.

If you have questions about the above, please e-mail me at jason.huitt@colostate.edu - I've run both of these scripts successfully as of today, and now have working x86 and x64 WinPE ISOs.  My trust WinPE flash drive has been updated as well.  You'll love the integrated mouse and NIC support when building Hyper-V VMs.  No more Legacy Network Adapter!

Integrate_x86.bat (1.10 kb)

Integrate_x64.bat (1.12 kb)

http://cameronfuller.spaces.live.com/Blog/cns!A231E4EB0417CB76!1318.entry

Guest OS processor utilization will not affect processor utilization on the host OS, per se.

We have recently come across an issue with Server 2008.  The problem came to light when a 2008 DC was brought up with the same computer name as an existing server elsewhere in the forest.  The 2008 server began throwing the following error to the System Log:

Source: Kerberos    Event ID: 11

The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is cifs/SERVERNAME (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occurring remove the duplicate entries for cifs/SERVERNAME in Active Directory.

Microsoft has information about discovering duplicate Service Principal Names in KB321044, however the recommended steps may not necessarily reveal the duplicate SPN.  A better explanation for this problem is located here: http://blog.joeware.net/2008/07/17/1407/

The short story is as follows…  It appears that Server 2008 is less tolerant of server names that are duplicated in other locations within the forest.  This is a known issue with WINS dating back to Windows 2000 Server, but it appears to cause problems on Server 2008 regardless of whether WINS is in use.  The problem is caused by some services (apparently both on the client and server) still using NETBIOS names to query Active Directory to find a resource – which will yield multiple results when two or more servers have the same NETBIOS names.  The solution to the problem is to ensure that every server (and domain-joined workstation) has a unique name within the forest.

A server experiencing these symptoms may be unable to authenticate logins, as Kerberos in this state is “broken”.  You may also notice Group Policy replication failure events being logged.  We also saw workstations that would attempt to log in to the domain for upwards of 30 minutes.  Rebooting the DCs appeared to provide temporary relief (on the order of 10-15 minutes), but shortly thereafter the above conditions would return.

Hyper-V went RTM officially this morning.  Some fixes I've noticed already:

• Closing the Virtual Machine Connection window no longer yields a program crashed exception.
• VMs start, stop and save much more quickly than in RC1
• Machine Save State files are able to be used after the RTM upgrade (not so going from RC0 to RC1)

Press Release:
http://www.microsoft.com/presspass/features/2008/jun08/06-26hyperv.mspx

Download full RTM bits:
http://www.microsoft.com/downloads/details.aspx?FamilyId=F3AB3D4B-63C8-4424-A738-BADED34D24ED&displaylang=en

Vista SP1 x64 Management Console:
http://www.microsoft.com/downloads/details.aspx?FamilyId=88208468-0AD6-47DE-8580-085CBA42C0C2&displaylang=en
Vista SP1 x86 Management Console:
http://www.microsoft.com/downloads/details.aspx?FamilyId=BF909242-2125-4D06-A968-C8A3D75FF2AA&displaylang=en
Server 2008 x86 Management Console:
http://www.microsoft.com/downloads/details.aspx?FamilyId=6F69D661-5B91-4E5E-A6C0-210E629E1C42&displaylang=en

Here's a quick way to add Directory Service Restore Mode to the boot options menu in Server 2008.  From an elevated command prompt, execute the following commands:

• bcdedit /copy {default} /d "Directory Service Repair Mode"
• bcdedit /set {<GUID for new entry>} safeboot dsrepair

Where <GUID for new entry> can be cut and pasted from the results of the first command executed.  You can control menu timeouts from within System Properties.

Microsoft replaced NTBackup.exe with wbadmin in Windows Server 2008.  My first brush with this new program came with a necessary System State Backup prior to applying a schema mod to our Test Forest this morning.  Our Test Forest runs on virtual machines (Hyper-V), and we haven't been building these VMs with more than a system volume to date.  This came back to bite me this morning...  First I attempted to take System State Backup to a network drive, then to the local system volume.  Here's the output...

C:\Windows\system32>wbadmin start systemstatebackup -backuptarget: \\server\share.
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.

Starting System State Backup [6/16/2008 10:10 AM]
Retrieving volume information...

This would backup the system state from volume(s) Local Disk(C:) to \\server\share. Do you want to start the backup operation?
[Y] Yes [N] No y

Creating a system state backup to a shared network folder is not allowed. To store a system state backup on a shared network folder, first run the backup to a local volume and then copy the backup to the shared network folder.

C:\Windows\system32>wbadmin start systemstatebackup -backuptarget:c:
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.

Starting System State Backup [6/16/2008 10:18 AM]
Retrieving volume information...

This would backup the system state from volume(s) Local Disk(C:) to c:. Do you want to start the backup operation?
[Y] Yes [N] No y

ERROR - The location for backup is a critical volume.

Good times...  Turns out that Microsoft disabled the ability to save System State backups to the system volume (termed a "critical" volume here).  There is a fix for this in the form of a registry change.  The article is located here: http://support.microsoft.com/kb/944530.  Note that to implement this change, you will need to create a new key under the HKLM\System\CurrentControlSet\Services\wbengine, as well as adding the necessary entry.  Simply adding the entry to the existing key will NOT achieve the desired behavior.

PS: Here's a spot on look at AD Backup and Restore in Server 2008: http://technet.microsoft.com/en-us/magazine/cc462796(TechNet.10).aspx

In working on deploying Windows Server 2008 in our Test Forest, we've been troubleshooting compatibility between our in-house identity management solution's Active Directory sync application, and Server 2008 64 bit.  The IM solution reads account information from an Oracle database, and uses LDAP to update accounts within AD.  Our problems this morning revolved around getting the correct Oracle client installed on the server (32 bit vs. 64 bit).  We took a snapshot on VMWare of our new 2008 root test forest DC, in order to play with the installation order of the different versions of Oracle.  As an aside, we eventually settled on needing on the 64 bit Oracle client, and we were forced to change our Connection String within the compiled VB.Net/C# application to access the Oracle driver in a different way.  The fix for this, creating and editing a dummy UDL file, deserves it's own blog post, but I've got bigger phish to phry at the moment.

So, in doing this testing we on three separate occasions reverted to our snapshot image, which was taken after promoting the DC and installing DNS, but before any Oracle client installations and prior to transferring FSMO roles (I'm counting my lucky stars here - we're practicing our full migration to 2008, and FSMO transfer was next on the list after Oracle).  The snapshots applied correctly, and really helped us solve our Oracle problems.

About two hours later, I was attempting to recreate the scheduled tasks that call our sync application.  I created a Domain Admin account with a strong password to use as the logon account for the task within the Test Forest, and then set about assigning that account to the task.  I used the Browse button to find the account, was able to select it, and configure the rest of the options for the task.  However as soon as I clicked the final OK, I got an error that I was using an invalid account.  A quick check of AD yielded the account, but I was unable to select it no matter what I tried.  I wondered if perhaps the account in question needed to be a member of the Local Administrators group in order to log on to the server and start the task, so I went to make that change from within Server Manager, but at this step I couldn't find the account when I would attempt to browse.  It was at this point that I realized I was probably in trouble.

I attempted to force a replication using ReplMon from the Server 2003 Support Tools (a handy GUI for a lot of the replication functionality that RepAdmin.exe provides), but noticed immediately that both of the replication partners for the DC in question were failing with the error "The destination server is currently rejecting replication requests."  Google pointed to a couple things to try, including the handy "repadmin /options <servername>", which reported that the options DISABLE_INBOUND_REPL and DISABLE_OUTBOUND_REPL were set.  Manually changing these options yielded no results.  Another Google search pointed to checking for a paused NETLOGON service, which indeed was the case, and I turned straight over to the Directory Service Event Log to find event ID 2095, which points to the following KB article: http://support.microsoft.com/?scid=kb%3Ben-us%3B875495&x=17&y=10

The short story is this: reverting to a snapshotted VM image put Active Directory on that DC in a state in which it other DCs did not realize that it was dealing with an old version of the AD database.  If we had restored AD in such a manner that other DCs were notified, they would appropriately replicate the "missing" data, and all DCs would continue on their merry way.  Not so in the case of a snapshot - you'll want to read the above article for a full description of the problem.

Bottom line: If you end up with a DC in this condition, you will need to forcibly demote the DC using ADSIEdit.  DCPromo fails with the same error reported by ReplMon "The destination server is currently rejecting replication requests."  It's a good thing this all happened in our Test Forest, and a damn good thing we learned about this before we virtualize any production Domain Controllers...

The Remote Server Administration Tools (RSAT) for Vista were released this week.  The tools require Vista SP1, and allow you to manage Server 2008 and in many cases Server 2003.

Microsoft Remote Server Administration Tools for Windows Vista with SP1 (x86): http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960

Microsoft Remote Server Administration Tools for Windows Vista with SP1 (x64): http://www.microsoft.com/downloads/details.aspx?FamilyId=D647A60B-63FD-4AC5-9243-BD3C497D2BC5

To install Hyper-V on a Server Core OS, execute the following two commands:

• BCDEdit /set hypervisorlaunchtype auto
• start /w OCSetup Microsoft-Hyper-V

The documentation for Hyper-V does not mention the BCDEdit step.  OCSetup will automatically perform the BCDEdit step normally, but it will only perform that operation after the first reboot following the Hyper-V installation.  If you don't perform the first step manually, it will take a second reboot in order to get the Hypervisor to load.  Thanks to MSDN's Mike Kolitz and his blog Virtual Varia for pointing this out.

Note: You may have to start the Hyper-V installation prior to running BCDEdit, as BCDEdit will throw an error if it realizes there is no Hypervisor to enable.  In such a case, fire up Task Manager and open a second command prompt, so you'll have somewhere to fire off the BCDEdit command prior to OCSetup's required reboot.

If you attempt to boot into Windows PE from a Hyper-V virtual machine, you may not be able to immediately access network resources as you would expect.  This is because a default VM configuration in Hyper-V includes the synthetic network card, which is not visible to any OS that doesn't have the Integration Components installed.  To enable network functionality on a Windows PE VM, remove the existing network card from your configuration, then select Add Hardware, and choose the Legacy Network Adapter.

You'll need to remove and re-add the synthetic network adapter (listed simply as Network Adapter in Hyper-V VM settings) when you have Vista or Server 2008 installed.