FIM 2010 R2 High CPU with Mmsscrpt.exe

I recently had issue in which mmsscrpt.exe would peg one CPU and hang indefinitely during an sync to the FIM Service MA.  My environment is a single Windows Server 2008 R2 box.  My run sequences consisted of delta imports and delta sync to my two data MAs (SQL and AD) and to the FIM service.  These were followed by an export and a delta import delta sync to the same MAs.  All was fine until the final delta import and delta sync ran.  When it did mmsscrpt.exe jumped to consume one thread and the runs effectively stopped.

Also, a run of full imports and full syncs on all MAs did not show the problem, it was only when the exports were introduced.

In an effort to fix it, I upgraded my FIM 2010 R2 from RTM (4.1.2273.0) to Hotfix Rollup 1 (4.1.2548.0) – no change.

I found a similar issue on the FIM Forum, but it was caused by a .Net Framework bug.  I already had all of the current updates, so those hotfixes were not relevant to me.  However, it was mentioned in there that turning off Exchange 2010 provisioning caused the issue to go away.  The same was true for me, which was the light bulb moment – PowerShell.

In my environment I had deployed the Windows Management Framework 3.0 (PowerShell 3.0, WMI, & WinRM) so that I could use Server 2012’s Server Manager with the older operating systems.  I figured PowerShell 3.0 was breaking something with the remote PowerShell call done when provisioning Exchange, so I went to remove WMF 3.0.  In doing so, I noticed that I apparently had deployed the WMF 3.0 BETA.  I removed it, rebooted, and the issue was gone.

Finally, after realizing it was a beta, I download the current installer for WMF 3.0 (RTM) and installed it.  After another reboot, the issue did not return.

So, the bottom line is that the WMF 3.0 Beta is incompatible with FIM 2010 R2 (not tested with FIM 2010, but I’d be willing to bet it causes issues there too).

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

Exchange Management Shell Quick Reference

Exchange 2007 introduces a new management platform called the Exchange Management Shell, based on Windows PowerShell, formerly codenamed "Monad". This quick reference guide provides a list of frequently used cmdlets, important conventions, and useful tips. The information is presented by feature area, such as recipient, transport, and database administration. This quick reference guide applies to Exchange 2007 SP1 and the RTM version of Exchange 2007.

http://www.microsoft.com/downloads/details.aspx?familyid=01a441b9-4099-4c0f-b8e0-0831d4a2ca86&displaylang=en&tm

Exchange 2007 and the legacyExchangeDN

Jim McBee has a great post on his blog (complete with a Powershell script) for upgrading a mail-enabled user to a mailbox-enabled user and setting the old legacyExchangeDN as an X500 address. Leveraging the X500 address ensures that any old emails, nicknames, etc. still resolve to the correct user after the change.