1dent1ty cHa0s

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