New version PCNS, new FIM hotfix

On Aug 24th Microsoft released a new version of PCNS. Version number 4.1.2515.0.

No release notes are provided with the download. However, this version number matches the version number of the latest FIM R2 hotfix rollup http://support.microsoft.com/kb/2734159 and it does tell us what is fixed:

Assume that you run Password Change Notification Service (PCNS) setup together with the SCHEMAUPDATE=TRUE option and the schema is updated successfully. In this situation, an error message is displayed at the end of the setup process incorrectly.
After this update is installed, the Setup program does not display the error message when the schema update is successful.

It should be noted that this FIM hotfix is only for FIM 2010 R2 (version 4.1.2273.0)

Apparently there were some issues with unicode characters for usernames in the FIM Portal and folders and filenames with unicode characters that the Sync Service used.

FIM Sync had a problem with deleting AD users that had active sync devices added to their account – solved!

Full import on a large connector space was sometimes having a problem with obsoletion and getting an error “0 is not a valid DN depth”

There have also been some issues with the upgrade to R2 failing while trying to upgrade the sync engine. They now have a tool that you can get from support to work around the failure by upgrading the database separately.

The hotfix solves a problem introduced by R2 (build 2273) incorrect removal of members from sets and groups where the filter looks like: /Person[(FirstName=”John”) or (FirstName=”Bill)]

There is even a fix for FIM certificate management “to improve error messages handling.”

How to import the Domain attribute into the FIM Portal Part 2

In Part 1 of How to import the Domain attribute into the FIM Portal I provided you the simple technique for the single domain forest, and the technique that works although is a bit unwieldy – that of looking at the first 41 characters of the object’s SID and using a lookup table through nested IIF statements and this doesn’t .

What if there was a simpler way?

What about using the Domain Component option in the attribute flow?

Well the problem is that the component starts from left and goes to the right, so if you have objects of varying OU depth, you can’t use this to get what you need reliably. You can use this to get the rDN but that is all. If only you could input negative numbers to tell it to go right to left that would be something. But then that would still have problems with domains of varying depths.

Of course this wouldn’t work if the NetBios Domain Name is not the first domain component of the DN. For example, SnappySlackers.com but NetBios Name of HQ.

What about all of those functions in the Sync Rules? Can we use those? Yes.

If we replace the “,DC=” with the | and use the Word function to split it up and grab the one we want.

Word(ReplaceString(dn,",DC=","|"),2,"|")

What if the DC= comes across as lower case? What if one of the OU’s contains the pipe character:

Word(ReplaceString(ReplaceString(UpperCase(dn),"|"," "),",DC=","|"),2,"|")

Although we still face the same exception about NetBios Domain Name, we can use IIF to handle the exceptions. So if SnappySlackers.com has a netbios domain name of HQ but all of the others have a corresponding NetBios Domain name such as NA.SnappySlackers.com is NA and EMEA.SnappySlackers.com is EMEA then the following would work and would even handle new domains as long as the NetBios Domain Name and the first Domain Component match.

IIF(Eq(Word(ReplaceString(ReplaceString(UpperCase(dn),"|"," "),",DC=","|"),2,"|"),”snappyslackers”),”HQ”,Word(ReplaceString(ReplaceString(UpperCase(dn),"|"," "),",DC=","|"),2,"|")

How to import the Domain attribute into the FIM Portal Part 1

If you have a single domain forest then you should use a constant flow in your sync rule or advanced attribute flow. If you have a multi-domain forest, then using a constant in the advanced attribute flow won’t work.

You could create multiple inbound sync rules one for each domain with scoping filters and then use a constant. However, this seems like a waste.

You could also follow the guidance provided in article originated by my friend Markus Vilcinskas and maintained by the community http://social.technet.microsoft.com/wiki/contents/articles/648.how-do-i-synchronize-users-from-active-directory-domain-services-to-fim.aspx

Which for one domain looks like this:

IIF(Eq(Left(ConvertSidToString(objectSid),41),"S-1-5-21-4220550486-1538840966-3184992408"),"FABRIKAM","Unknown")

and for three looks like:

IIF(Eq(Left(ConvertSidToString(objectSid),41),"S-1-5-21-4220550486-1538840966-3184992408"),"FABRIKAM",IIF(Eq(Left(ConvertSidToString(objectSid),41),"S-1-5-21-4220550586-1538840966-3184992408"),"SnappySlackers",IIF(Eq(Left(ConvertSidToString(objectSid),41),"S-1-5-21-4220550486-1538840966-3184992408"),"bluesky","Unknown")))

However it requires ferreting out the SIDs of the domains (although Markus does provide a script to generate the expression http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/50088024-d86a-49dc-bb03-3243ebd677eb ). This technique uses the fact that the first 41 characters of the SID (after converting it to a string) of every object is the domain SID.

As you can see the custom expression gets very unwieldy, very fast. In Part 2 I shall propose a more elegant solution that works in all cases with one notable exception, that can be worked around.