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.

This document from Microsoft on Server Core indicates that you can perform the following steps to enable read-only remote access to Device Manager on a Server Core installation:

• Device Manager. You must first enable the Allow remote access to the PnP interface policy setting. To do this, on a computer running Windows Vista or a full installation of Windows Server 2008, open the Local Group Policy Editor MMC snap-in, connect to the computer running a Server Core installation, navigate to Computer Configuration\Administrative Templates\Device Installation, and then enable Allow remote access to the PnP interface. Restart the computer running a Server Core installation.

The problem is this: I have been unable to find any way to open another computer's Local Group Policy via gpedit.msc.  I've looked at Windows XP, Vista RTM and SP1, and 2008 - all to no avail.  The solution is to create a domain-based GPO with the above setting, and then either reboot Server Core, or run gpupdate /force to force updated processing of Group Policy.  With this policy in place, you can successfully open a read-only view of Device Manager.

I don't recall when (if ever) gpedit.msc has been capable of opening another computer's Local Group Policy remotely, so if someone comes across a way to do this I'd appreciate hearing about it.

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.

We had an Exchange 2007 user report that she was sporadically unable to receive e-mail.  When we began looking into the problem, any bounced messages were being returned with 550 5.1.4 RESOLVER.ADR.Ambiguous; ambiguous address as the error code, and the error was being generated by our Exchange 2007 HTS.  There is very little documentation covering this particular error, so we were left scratching our heads for some time.  It quickly became clear that the "ambiguous address" was coming from a duplicate SMTP address assignment somewhere in Active Directory, but we had looked through all SMTP addresses on our Exchange 2007 accounts and could not find the duplicate assignment.  We also searched through Mail Contact objects, with the same result.

The following PowerShell command provided the right level of illumination: $AdminSessionADSettings.ViewEntireForest=$true

We then executed the following command to find the duplicate object: Get-MailContact *lastname*

When we changed our Active Directory visibility setting from within the Exchange Management Shell, we were able to find a contact object in one of our child domains that was setup by an Exchange 2003 administrator to forward messages back to our Exchange 2007 mailbox.  However that contact object had been aimed at an SMTP address assigned to the Exchange 2007 mailbox, and thus Ambiguous Name Resolution (ANR) failed to differentiate between the child domain contact object, and our Exchange 2007 mailbox.  We are unsure at this time why the child domain administrator was able to duplicately assign our "taken" SMTP address to a contact object in the first place, however removing the offending contact object corrected the problem.

Upon upgrading to Service Pack 1 for SC Operations Manager 2007, I began receiving the following alert:

Alert: Agent proxying needs to be enabled for a health service to submit discovery data about other computers.

Source: scom1.

Path: scom1.

Last modified by: System

Last modified time: 3/6/2008 2:32:21 PM

Alert description: Details:Health service ( 93A0E708-5148-5975-BD36-373E8E5A1610 ) should not generate data about this managed object ( F227C8F1-E50E-F847-9378-45EB7135B901 ).

The problem with this Alert (which appears to be new in SP1), is that your RMS is reported as the source server, when in fact there is another Agent throwing the error (in our case, Agent Proxying is already enabled on our RMS).  I found the following blog post from Marius Sutara at Microsoft that explaining that performing the following SQL query on your OperationsManager database will show you which managed Agent is throwing the error:

SELECT * FROM BaseManagedEntity WHERE BaseManagedEntityId = '<GUID>'      <- Where <GUID> is the "managed object" GUID reported in the OpsMgr alert (the second GUID listed)

In our case this returned a single row, and I was able to determine the problem Agent by looking at the Path field.

Here's a great blog post on why WS08 is called SP1.

http://blogs.msdn.com/iainmcdonald/archive/2008/02/15/windows-server-2008-is-called-sp1-adventures-in-doing-things-right.aspx

I have to agree - Microsoft got it right on this one.  Plus I think there's an added level of confidence inherent in knowing that the same kernel code is running on both our clients and servers.  I suspect this will mean that, in the end, Vista and WS08 are going to be with us for longer than even Microsoft wants to believe.