Viewing Server 2008 R2 Roles shows "Error"

Two posts in one day.  That might be a new record for me.

I had a 2008 R2 server that wouldn't install Roles properly via PowerShell.  When viewing the Roles with Server Manager, it simply said "Error".  How useful.

Looking in the event log I found this:

Log Name:      Application
Source:        Application Error
Date:          12/30/2010 11:18:47 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      server.domain.loc
Description:
Faulting application name: TrustedInstaller.exe, version: 6.1.7600.16385, time stamp: 0x4a5bc4b0
Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b802
Exception code: 0xc00000fd
Fault offset: 0x0000000000051ae3
Faulting process id: 0x9fc
Faulting application start time: 0x01cba845913dc3d6
Faulting application path: C:\Windows\servicing\TrustedInstaller.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: dc0dfe78-1438-11e0-8fd9-0050568900bb
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2010-12-30T17:18:47.000000000Z" />
    <EventRecordID>1935</EventRecordID>
    <Channel>Application</Channel>
    <Computer>server.domain.loc</Computer>
    <Security />
  </System>
  <EventData>
    <Data>TrustedInstaller.exe</Data>
    <Data>6.1.7600.16385</Data>
    <Data>4a5bc4b0</Data>
    <Data>ntdll.dll</Data>
    <Data>6.1.7600.16559</Data>
    <Data>4ba9b802</Data>
    <Data>c00000fd</Data>
    <Data>0000000000051ae3</Data>
    <Data>9fc</Data>
    <Data>01cba845913dc3d6</Data>
    <Data>C:\Windows\servicing\TrustedInstaller.exe</Data>
    <Data>C:\Windows\SYSTEM32\ntdll.dll</Data>
    <Data>dc0dfe78-1438-11e0-8fd9-0050568900bb</Data>
  </EventData>
</Event>

Generally, this seems to happen when the install process is interrupted (hard stopping a VM or a server losing power during an install).  Here are the steps taken to resolve the issue:

1. Installed the System Update Readiness Tool for Windows Server 2008 R2.  This tools runs when installed, so you don't have to actually run it.
2. View the resulting log file (%SYSTEMROOT%\Logs\CBS\CheckSUR.log)
3. Found the offending files:

Summary:
Seconds executed: 131
Found 1 errors
  CBS MUM Corrupt Total count: 1

Unavailable repair files:
    servicing\packages\Package_for_KB2207566_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum
    servicing\packages\Package_for_KB2207566_RTM~31bf3856ad364e35~amd64~~6.1.1.0.cat

4. Change permissions on the %SYSTEMROOT%\servicing\packages directory to allow administrators Modify rights.
5. Copy the offending files from a different Server 2008 R2 server to the %SYSTEMROOT%\servicing\packages directory on the problem server.
6. Reinstall the offending package (in my case KB2207566).
7. Re-run the SUR Tool (by re-installing it).
8. View the resulting log file (%SYSTEMROOT%\Logs\CBS\CheckSUR.log)
9. Verify the errors have been resolved:

Summary:
Seconds executed: 211
No errors detected

10. View Roles with Server Manager.

Properties Not Returned using Get-ADObject

Server 2008 R2 now includes Active Directory Web Services (ADWS), a new way to access AD information.  The new AD cmdlets available in Server 2008 R2 (and Windows 7 with the Remote Server Administration Tools installed), use these web services when accessing a remote domain controller.

I've been working on a script to automate the build process for remote domain controllers.  The steps include installing the AD DS role, creating the AD site, subnet, and site link, and then running dcpromo with an answer file.  As part of this, I came across an issue where a specific property was not being returned to me, but definitely did exist.  Using Get-ADObject and specifying the remote server, I was trying to get the site that a subnet was linked to, but it wasn't being returned.

Get-ADObject -Identity "CN=172.20.3.0/24,CN=Subnets,CN=Sites
,CN=Configuration,DC=domain,DC=loc" -server 2008r2dc.domain.loc:3268
-properties siteObject | fl

Yielded the following results:

DistinguishedName : CN=172.20.3.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=domain,DC=loc
Name              : 172.20.3.0/24
ObjectClass       : subnet
ObjectGUID        : 4c189c9f-ae09-4967-be81-ecf1dd293444

Notice that the "siteObject" property I specifically requested in the cmdlet is not there.  As it turns out, in troubleshooting connectivity to the remote server, I had specified the port of 3268 (global catalog) but never took it back out once I resolved my issue (which turned to be something completely unrelated).  Because I was querying the GC, that attribute was not present.  So, if the cmdlet is run without specifying the port, it queries over the default ADWS port of 9389 and the property is returned.

Get-ADObject -Identity "CN=172.20.3.0/24,CN=Subnets,CN=Sites
,CN=Configuration,DC=domain,DC=loc" -server 2008r2dc.domain.loc
-properties siteObject | fl

Yielded the following results:

DistinguishedName : CN=172.20.3.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=domain,DC=loc
Name              : 172.20.3.0/24
ObjectClass       : subnet
ObjectGUID        : 4c189c9f-ae09-4967-be81-ecf1dd293444
siteObject        : CN=Site001,CN=Sites,CN=Configuration,DC=domain,DC=loc

Hopefully my gaffe will be of help to someone else...