Today I encountered a volume-licensed Vista box that had not been activated for more than 180 days.  I was under the impression that Reduced Functionality Mode (RFM) had gone away with Service Pack 1, however when I attempted to log into the box, I was greated with an activation dialog box, and clicking cancel returned me to a log on prompt.  Here's how I got back around the problem...

• From the Activation dialog, click on one of the Help links.  This will pull up the Help and Support window.
• In Help and Support, do a search for "command prompt".  One of the returned links will show you how to open a command prompt, and will provide a link to do this for you.  Go ahead and open the command prompt in this manner - while I was in this activation mode, I was unable to use Ctrl+Alt+Del to pull up Task Manager, and had to get to a place where I could actually do some work.
• If you need to connect to a VPN in order to access your company's KMS server, do so now.
• In order to manually activate Vista from the command line, you have to run slmgr.vbs from an elevated command prompt.  How do you launch an elevated command prompt without right clicking on an icon to launch a UAC prompt?  Here's a nifty trick:
  • Run "control schedtasks" to bring up the Task Scheduler interface.
  • Create a new task to run cmd.exe without any triggers.  Also make sure to check the option for "Run with highest privileges" on the General tab.  This will set the task up to run with elevation.
  • Right click your newly created task and click Run.  Lo and behold, you've got a command prompt running with elevation!  Note "Administrator: taskeng.exe" in the title of the command prompt window.
• Now that you are elevated, run "cscript slgr.vbs -ato".  Assuming this volume-licensed copy of Vista had been previously activated, you should now be re-activated.
• Log off using the "logoff" command, and then log back in.  At this point you should be staring at your desktop once again.

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

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.

For ISO creation (ripping from source media), as well as CD boot image extraction (useful when slipstreaming), I use IsoBuster, available here: http://www.isobuster.com/

For ISO mounting, I use SlySoft's Virtual CloneDrive, available here: http://www.slysoft.com/en/download.htm

For creating my own ISOs (not from a source CD/DVD), I have come to increasingly rely on a Windows Automated Installation Kit tool called OSCDIMG.exe.  This little gem can create ISOs of all kinds and flavors, and includes an option for creating a bootable ISO by including an extracted CD boot image.  It's quite fast and reliable, and can make ISOs out of WIM files with zero hassle.

With special thanks to Microsoft's Michael Greene on the Off Campus blog...

The Network and Sharing Center provides an extra set of "click throughs" on the way to setting an IP address in Vista.  Here's the quick and dirty way in:

Start -> ncpa.cpl

I remember it by thinking "Network Connections Physical Adapters".

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

Release Candidate 0 of Hyper-V was released on March 19th.  Details about the release and instructions for installing it are available here: http://blogs.technet.com/jhoward/archive/2008/03/19/Hyper_2D00_V-RC0-release-is-available-for-download.aspx

Hyper-V RC0 Update (x64): http://www.microsoft.com/downloads/details.aspx?FamilyId=DDD94DDA-9D31-4E6D-88A0-1939DE3E9898

To manage Hyper-V RC0 from another 2008 or Vista management box, you'll need to install one of the following patches:

Windows Vista SP1 Management Tool for Hyper-V RC0 (x64): http://www.microsoft.com/downloads/details.aspx?FamilyId=450931F5-EBEC-4C0B-95BD-E3BA19D296B1

Windows Vista SP1 Management Tool for Hyper-V RC0 (x86): http://www.microsoft.com/downloads/details.aspx?FamilyId=BC3D09CC-3752-4934-B84C-905E78BE50A1

Update for Windows Server 2008 (KB949219) (x86): http://www.microsoft.com/downloads/details.aspx?FamilyId=B7464B44-821D-4A7C-9D9C-7D74EC14437C

I currently have a Hyper-V RC0 installation on a test machine running 2008 Enterprise x64 Server Core, being managed by a separate 2008 Enterprise x86 Full Installation workstation.  The new release of Hyper-V definitely brings a marked performance increase in both VM operation and in management.

NOTE: You must install the Hyper-V RC0 x64 update on any Server 2008 Guest OSes in order for the Integration Components to work.  They are built into the RTM 2008 OS, but they are not compatible with RC0 without the full upgrade.