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

^{Courtesy http://www.johnnyf.com/}

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

I've seen a lot of documentation out there about the "wuauclt /detectnow" option as a way to force XP's Automatic Updates or Vista's Windows Update to redetect updates.  This is especially useful during a Patch Tuesday cycle, when it's important to make sure that clients are behaving the way you would expect after approving new updates.  However I've had mixed (read: no) luck with "detectnow", so here's how I've forced the detection routine to get started.  The following instructions work on Vista - and should work on XP as well.

• Delete the computer from the WSUS console - it will readd itself during detection
• net stop "Windows Update"
• Delete the contents of the c:\Windows\SoftwareDistribution
• net start "Windows Update"
• From an elevated command prompt, execute "wuauclt /detectnow /resetauthorization"

Note - you may not be prompted immediately to install updates, but at this point when processing is complete (you can watch the updates download and the associated processes working on the new patches from within Task Manager) you should be able to open Windows Update from within Control Panel, and see that you have updates waiting to install.

This will force the Windows Update client to download all updates once again, but it will trigger the installation routine.  Probably not a good idea on production workstations, but this works great in a test environment.

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...