1dent1ty cHa0s

The first official Service Pack (MIIS SP3 if you're keeping score) for ILM 2007 FP1 has been released. Brjann Brekkan reports the following:

This update sets a new base line for future coming updates to ILM with much easier deployment of such updates. The biggest and most important update in this Services Pack is that we now support provisioning of mailboxes on Exchange 2010.

 

The AD Management Agent now has a drop down box to choose Exchange Server 2010 or 2007. With Exchange 2010 provisioning there MA uses Remote Powershell to connect to the Exchange Server so no need to have the Exchange admin tools installed on the ILM machine.

In addition I made the following notes:

• The SP is, of course, cumulative, so if you've only deployed some of the hotfix rollups in the past you will be completely covered when you move to SP1.
• In order to utilize the Exchange 2010 provisioning support you will need to upgrade to PowerShell 2.0 to support PowerShell Remoting capabilities. This removes the requirement of having Exchange Admin tools installed locally for Exchange 2010 provisioning, but it is unclear whether or not this extends to Exchange 2007 provisioning.
• You must use the ExchangeUtils.CreateMailbox method while populating the msExchHomeServerName attribute (used by Exchange 2010) to invoke the provisioning of Exchange Mailboxes; it is unclear whether or not using any of the previous tricks will still work.

You can find the Service Pack here:

KB977791 - ILM 2007 FP1 Service Pack 1 (build 3.3.1139.2)

Had to wrap my brain around this one just recently – the FIM web service requires that you submit any datetime attributes with a very specific format with absolutely no wiggle room. This presents somewhat of a challenge when you are sourcing datetime values from multiple sources like MS SQL, Oracle and LDAP directories like AD/AD LDS.

When writing to the FIM web service the date needs to appear in this ISO 8601 format:

yyyy-MM-ddTHH:mm:ss.fff

For example:

2009-11-06T07:00:00.000

Now, there is no magic SQL or .NET function I've found that gets you precisely the format you need so you have to do some manipulation yourself in order to get it to export properly. While we're here, let's look at some additional caveats regarding dates with FIM:

• If the value is coming from the Synchronization Service (MIIS/ILM) then it needs to originate as a string data type – there are no datetime types in the metaverse, so you will find yourself converting datetime values to string types.
• The portal expects the time to be in UTC (GMT or Zulu) time, so you need to adjust the time to your own time zone before submitting it otherwise the portal will adjust it when presenting it to you through the portal. For instance, we're in the special Arizona (MST/GMT-7) time zone, so to adjust a midnight timestamp I have to add 7 hours and then the FIM portal will display it to me as midnight.
• The web service requires the fractional seconds component to be present (true as of RC1 Update 2) – if you don't submit the fractional seconds it will reject it.
• The web service requires precisely three digits of fractional precision to be specified; however, SQL itself is only so precise. You can generally submit the first two digits but you should zero the third if you require fractional precision, otherwise, zero all three (.000). If you don't get the precision correct, you will end up with confirming export errors since the third digit will shift.
• You can't specify timezone or any 'z' components

.NET Conversion

To do this in .NET you can adapt the following code into a handy function:

DateTime dtFileTime = DateTime.FromFileTime(csentry[strSourceAttribute].IntegerValue);
// Convert to UTC, format string using custom format similiar to round trip "o" format
// NOTE: SQL's precision for fractional time makes storage and confirmation of anything more than two digits problematic
//      It's better to simply enforce .000 for fractional time here since it's not absolutely critical
mventry[strDestinationAttribute].Value = dtFileTime.ToUniversalTime().ToString("yyyy'-'MM'-'dd'T'HH':'mm':'ss'.000'");

TSQL Conversion

To do the conversion in TSQL it's a bit more difficult as I can't seem to find any functions that will automatically adjust the timezone for you. In any case, the approach is similar:

SELECT
--source attribute is already datetime/datetime2
[DATE_OF_HIRE] = CONVERT(nvarchar(30), DATEADD(hour, 7, [DATE_OF_HIRE]) , 126) + '.000'
--source attribute needs to be converted to datetime2
,[TERMINATION_DATE] = CONVERT(nvarchar(30), DATEADD(hour, 7, CAST([TERMINATION_DATE] AS datetime2(7))), 126) + '.000'
FROM tMyHRSource

Anyone who has worked with me on projects know I prefer doing my data manipulation prior to doing any imports to the Synchronization Service so I love the SQL approach and I apply this transform so that my dates appear in the connector space already in the proper format. When this is coming from a sources like AD you don't have that luxury so you need to apply this in a rules extension.

On this, the last day of 2009 I find myself posting two additional bugs on Connect (please vote up if you feel you are impacted):

• RC1 – Updates cannot be slipstreamed into base install

This issue relates to deploying additional Service instances after you've patched your existing installation beyond build 2560 (RC1). If you need to recover an instance of the FIM Service, or you simply want to scale-out your deployment by adding additional services on new systems you have to install the base RC1 MSI package. When doing so, if you install against the existing database it will fail since it's been upgraded. You now have two options:

1. Backup and Detach the patched database, taking all Service instances offline, install 2560 and then patch followed by restoring the original database, or

2. Install the new service against a dummy db, patch, and then point to the original db

Using the first option results in a clean install but is hardly an option in a production deployment since you need to take all of the services offline incurring an outage. The second option incurs no outage but leads to the second bug…this bug describes how it's currently not possible to slipstream updates into the base install.

I really like the way WSS 3.0's installer handles cumulative updates and service packs – you just copy them into the Updates folder of the extracted install and it will apply them during the installation automatically.

• RC1.2 – Service & Portal Repair does not fix FIM_* SQL Jobs

This bug is caused when you choose option 2 above – when you specify a new dummy db (FIMServiceDelMe for example) during the new service install, the installation modifies the FIM_* SQL jobs and points them to the new database. When you run repair and point the install back to the original db it does not update the jobs with the original database. If you find yourself in this condition, just edit the steps of each job and reselect the original database.

In either case, I think it's critical to be able to slipstream updates.

I was also able to confirm this bug:

• RDP: Post import – Case sensitivity is not changing by CustomExpression or Portal change

In my case I was just exporting updates to the title attribute to the portal that contained case changes. The exports would complete, but the confirming delta and even full imports would result in the exported-change-not-reimported error. According to the notes, this is not planned to be fixed by RTM, so vote this up if you feel it's important.

Well, chalk this one up to either an aspect of delta imports I just never noticed before or something specific to the way the FIM MA pages through large objects. Remember that the FIM MA is interacting with the FIM web service and then parsing the XML objects into connector space objects. So, what happens if you get a REALLY big group?

In the picture above we see the results of a Delta Import, but notice that the connector space GUID's are repeated. This is the FIM MA paging through a really large member attribute. I wasn't able to ascertain how many additions each entry represented, but I was able to watch the total count of members increase after each new object was added.

Needless to say, it's NOT a good idea when building groups to leave the default "all eligible objects" filter clause in with the intention to correct it later. :)

My next question is whether or not it's possible or advantageous to change whatever paging value the FIM MA is using.

Back in ILM 2 RC0 we had the use of the contains() function both from the Filter Builder control and from direct filter xoml modification in both Sets and Groups.  In FIM 2010 RC1 and later this important function was removed – most likely due to issues surrounding it's stability and performance. If there is one thing I've become most understanding of is how features will get dropped if they jeopardize the ship date of a product and as the FIM team cannot afford any additional slippages, I can see why they may have dropped contains() from the list of supported functions. If you search through the Connect portal you'll find a number of bugs attributed it's use or misuse but I digress.

Having the ability to use such a powerful function is severely missed, and not just by my immediate customers. If you concur, then please vote for the reinstatement of the contains() function:

https://connect.microsoft.com/site433/feedback/ViewFeedback.aspx?FeedbackID=519852

This was already picked up elsewhere whilst I was out on vacation but I still had to add my "way cool" for the extra detail. Thanks Darryl!

With RC1 Update 1 we can start to see some of the dedication the product group has been talking about over the past year to ensure greater scalability in large environments. With the new service partitions it allows you to rollout portals focused at specific user segments which addresses portal response issues that were rampant before. Addressing the performance perception from end users is critical and should not be undervalued as there is nothing that will sink a project quicker than poor reception from your user community. Terms like "sluggish", "slow", or phrases like "it timed out when I tried to do x" makes it quickly through management and all of the sudden your big investment is cast aside.

Mark my words, features like this will drive better long term adoption and uptake in enterprises.

The next bottleneck to address then becomes the single SQL Server instance which all of the service partitions run against; however, I doubt this will be addressed in this version of the product. Perhaps the ILM "3" candidate (still in early planning stages) will seek to address this by adding capabilities to partition the FIM Service Database as well. Until then, you need to scale UP your SQL Server investment for FIM 2010 Service Database.

Darryl Russi's Blog : Service Partitions - Multiple Middle Tiers, Request & Workflow Processing