IE9 RTM and Citrix ICA files

I ran various IE9 betas and RCs without issue when it came to opening and launching Citrix ICA files.  Once I installed the RTM version however, they failed to open.  The file would download, and then just sort of hang.  If I went to the site with Firefox, I had no issues.  Today I learned that to resolve this, you simply need to uninstall "Citrix online plug-in - web", and then reinstall the web client when prompted through your Citrix portal.  Much better now...

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

Cross-forest Certificate Enrollment

When deploying Cross-forest Certificate Enrollment with Windows Server 2008 R2, one of the steps is to add the issuing CA to the "Cert Publishers" group in the domains which will be auto-enrolling with the new CA.  Ran into a small issue at a client in which that wasn't possible because the "Cert Publishers" group was a domain global group, which can only contain members from the domain in which the group exists.

To get around this, you have to modify the "Cert Publishers" group to be a domain local group.  This is the default for all domains created as Windows Server 2003 or new, but for Windows 2000 domains, it was created as a domain global group.  This design change is detailed in this KB article.

The UI does not allow you change the group scope for this group; changing the scope can still be done with dsmod.  Use the following syntax:

dsmod group <DN of Cert Publishers Group> -scope l

For example:

dsmod group "CN=Cert Publishers,CN=Users,DC=domain,DC=com" -scope l

Full details on using dsmod to change the scope can be found here.

ISA/TMG Error: Cannot Connect to the Configuration Storage Server

After replacing the certificate used by CSS (for ISA), or EMS (for TMG) under the ISASTGCTRL service’s certificates, you may still have issues with ISA not connecting to the CSS (or TMG not connecting to the EMS), and you may see the following error in Server event logs:

Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36870
Date: 3/9/2010
Time: 7:33:44 PM
User: N/A
Computer: COMPUTER
Description:
A fatal error occurred when attempting to access the SSL server
credential private key. The error code returned from the cryptographic
module is 0x6.

When the certificate is selected during the initial setup, the process grants the account that the CSS is run under Read access to that certificates key, which is found in the following location for Server 2003:

C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

For Server 2008 and up it is in:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

When you replace the certificate manually, those permissions aren’t granted to the new key.  To resolve this, you must find the file the correlates to the certificate being used.  To do this, view the certificate in the Certificates MMC and locate the Serial Number of the certificate.

From a command prompt, run:

certutil –store my

In the output, locate the certificate with the matching Serial Number.

================ Certificate 0 ================
Serial Number: 17359643000000000060
Issuer: CN=My CA
NotBefore: 2/23/2010 9:22 AM
NotAfter: 2/23/2011 9:22 AM
Subject: CN=L3K1126.mydomain.com
Non-root Certificate
Template: MSComputer, MS Computer
Cert Hash(sha1): c1 6a 3b 75 79 2e 69 33 bf 9d 22 a6 33 e0 71 99 25 ef e2 94
  Key Container = 18793fa9a3498d84c0242ad7d16ae373_2c047212-c86a-4f64-90d7-61c4e5337707
  Provider = Microsoft RSA SChannel Cryptographic Provider
Encryption test FAILED

The “Key Container” attribute is the name of the associated file in the MachineKeys directory.  Grant the account that the ISA Configuration Storage (or TMG EMS) is running under READ permissions to that file.  By default, ISA & TMG are run as “NETWORK SERVICE”, so most likely it should look like this when you are done:

This should begin to work immediately on ISA with no service restarts or reboots required.  I haven’t tested it with TMG but I would think the same thing would be true.  If not, simply restart the ISA/TMG services or reboot.