FIM2010R2–Workflow Activities Can Now Trigger Authorization Workflows

In the initial R1 release of FIM, any updates that were made to the object by a workflow did not trigger any authentication workflows. Within the R2 framework, the API now allows for the addition of a new flag called “ApplyAuthorizationPolicy” as a boolean.

This can be integrated into workflows where the operations that are occuring should be authorized by another user such as adding multiple members and needing individual approvals on each member. The workflow activity would take the list of members and individually submit requests for each member to get approvals.

The application of the new flag, in a code snippet provided to me by one of the developers I work with, is provided below.

this.UpdateUserResourceActivity_ActorId1 = actorId;

this.UpdateUserResourceActivity_ResourceId1 = targetId;

this.UpdateUserResourceActivity_ApplyAuthorizationPolicy1 = true;

Anyway, this is really handy for those of us who had call to use the “RMClient” project from codeplex to perform this task within the R1 framework.

FIM2010–“Deprecated Features and Planning for the Future” Technet Article…

Every once in a while, I go digging about the various sites to see what I haven’t read before in regards to the FIM documentation. I kept missing this one however, a client recently pointed it out to me and I think this should be carefully reviewed by everyone who uses FIM to ensure that features that you are actively using are not removed.

The technet article is at this URL –> http://technet.microsoft.com/en-us/library/jj879229(v=ws.10).aspx

Key things that concern me are:

• Run Profile Changes – This bullet indicates a phasing out of the “combined” run profiles that are very important, at least when it comes to the functionality of the ones including the delta synchronization components. I have many clients who actively use the “Delta Import and Delta Synchronization” profile to prevent unnecessary processing of filtered disconnectors to allow more frequent synchronization. As this profile will process any “changed” objects including filtered disconnectors, they are evaluated when the data from the connected data source changes by default. Running a delta import and delta synchronization and two discrete steps means that the delta synchronization step will test all the filtered disconnectors to ensure they should still be in that state. In one client where there are 1,000’s of these items, even processing at 50 filtered objects per second adds 20 seconds per 1000 objects to the sync time. Scale that to 100,000 and suddenly its added 2,000 seconds (over 33 minutes) to the process!
• Attribute Precedence – This feature is removing equal precedence. Admittedly, I’m not a big fan of this function anyway, however, it still doesn’t address precedence issues with the FIM MA, as we can’t do manual precedence anyway. I would love to see this functionality modified so that the FIM MA allows for rules extensions and therefore, manual precedence. This would simplify many things I have to do for some clients without having to do some sort of weird work-around. (That said, I want to be able to do basic functions with reference attributes in classic code as well as in decision based flows in declarative rules – see “A Case for Declarative Rules Use” post which describes my issues with reference attributes)
• Attribute Flows – Allow Nulls – There are changes proposed for the “Allow Nulls” feature which would have this permanently enabled. I just think this is bad karma. I use this quite a bit to “protect” attributes from a future misconfiguration that may lead to the “necessary attribute” being deleted and/or an export error to be thrown. Sometimes protecting people from themselves is necessary and this is an important tool in that arsenal.
• Attribute Flows – Do Not Recall Attributes – This one goes hand in hand with the allow nulls. In many cases, when an object is disconnected and is the primary source for data, a recall of the attributes will cause the nulls that would otherwise be exported to other connected directories. There are best practices where these attributes should be replaced with a lower precedence source but given that it has to be selected by the user whether to recall or not, I would suggest it be left in. An enhancement to this would be to allow the “remaining” attributes to no longer be enforced within the precedence model and if a new “lower” source with a connector to the metaverse is updated with a new value, the system should accept the new value instead of following precedence rules against the “missing” contributing connector.
• Transaction Properties – YIKES! This was an important method for communicating information between different DLLs for a transaction. This would remove an important component for sending communication signals between the rules extensions and mvextension DLLs so that different tasks can be completed based on the outcome of tests performed during other parts of the objects synchronization processing.

I’ve also noted that they are removing the CLM MA. I find this interesting and wonder how the certification provisioning requests are to be managed within this system. Is there a new method that Microsoft is proposing for this tool or are they planning to decouple it as a separate product outside the realm of the FIM framework?

Anyway, take a look at the posting and see if you have similar or different concerns. I think it is important that we provide appropriate feedback to the product team so that we don’t end up with having to establish workarounds for common items that we may have been using fairly frequently and would like to continue to use.

FIM2010–Bay Area FIM Users Group

Yesterday marked a good day for FIM in the Bay Area. A FIM users group was organized with participation from many different companies including current users of FIM, groups considering FIM, Microsoft product group representatives as well as third party integrators.

There were presentations of FIM deployments in real world situations including how the product was deployed, how obstacles were overcome and the end-user reception of the functionality provided to them.

Thanks to Simon Thorpe (of Microsoft) for organizing the event. Hopefully this event can continue to grow so discussion can grow among the organizations to share improvement in how to do things in FIM and meet others who are working with it!

Anyone in the area who is interested in future instances of the user group are encouraged to leave comments here. Let’s try to keep this ball rolling!

FIM2010–Beware of “Zombie” Approvals

This is one of those interesting items that pops up now and then when dealing with FIM and workflows. I’ve recently made some major changes to some approval workflows and pushed the changes to a production environment. What ended up happening however, is that any approvals that were queued that used the old workflows that were deprecated were no longer operable.

The approvals simply hung around in a users approval queue and threw an error that the system was unable to complete the approval when either accepted or denied. The just continued to lurch through the system like “zombies”.

The removal of the “zombies” was available using two options:

1. If the owner was frustrated that they had all these hung approvals, it was possible to create an MPR and go in and delete the offensive objects thereby removing them from the queue.

2. The “zombies” appear to have a shelf life and have started to age out of the system using the normal 30 day object expiration (after the timeout period has expired).

I’m continuing to monitor this however, it was an interesting little side effect that I hadn’t quite anticipated when making the change to how the approvals were being completed in the environment.

FIM2010 R2–Thank you!

I have to admit, sometimes there are changes made to a product which are really good. This one is about doing the R2 upgrades which I know a lot of people have been having a lot of pain and something I whined about a while ago when it took more than 15 days to the upgrade.

After working with a client and Microsoft, they did a lot of testing on the database and the upgrade now takes place in about 3.5 hours. I would say that is a considerable improvement to the overall operation of the system and something that makes me very happy.

FIM 2010 R2–Custom Workflow Activity Version Numbers

There are times when a look at something and realize that best practices for development and the way a product uses the objects may collide. This is the case with the development best practice of version numbers on workflow activity DLLs and their implementation within FIM.

In the case of the custom workflow activity DLLs that are registered within the GAC, it is easily remembered that the Activity Information Configuration (AIC) within the FIM Service must also be updated. (Remember, the version number is part of the “Assembly Name” value for example –> “FIMActivities.MyWorkflow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=12345abcde1234”)

What is sometimes missed is that the “Assembly Name” is used in the XOML for the workflow definitions where the custom activity is used. So therefore, it is necessary to either go in and add the new activity in again or manually updating the XOML with the new version number. The XOML for the activity is present in the “Advanced View” and is what is used by the GUI to render the workflow for the normal view. If the XOML is updated, go back and validate that the settings have been maintained or, if necessary, reset them to the proper values.

This is a more of a nuisance issue that once you’re aware of it, something that is easily prepared for through process development.

FIM 2010 R2–Diving into Filtered Outbound Synchronization Rules

So, I’m a bit behind the curve right now. I have been on a long engagement and we’re only starting to move towards the R2 version of FIM right now. I have to admit there are quite a few new things I like in the release but most of all, the filtered outbound synchronization rules are probably my favorite right now.

The filtered outbound synchronization rules are a huge improvement over the existing method for outbound synchronization rules but there are some trade offs. Key things of note are:

• Filtered Outbound Synchronization rules still have the option to codelessly provision an object into the connected directory. There is however, no option to deprovision the object once it is no longer being applied to the object.
• The criteria used in the FIM Service can still be used for the Outbound Synchronization rules in many cases so long as the Metaverse contains the information. This may result in more import rules from the FIM MA but in the long run, I really think it is worth it.
• To deprovision objects that were provisioned using the filtered outbound synchronization rules, the metaverse extension provisioning code will have to be used to call the deprovision()
• The outbound synchronization rules are limited to comparison of values and therefore, if there are comparisons between attributes or wanting to look back into the connector space of the object, these rules will not apply. Classic rules using a rules extension may still be the best choice.

In my implementations, this will save a lot of workflow churn in the FIM Service. I no longer have to add and remove the synchronization rules based on transitions into a set. This is especially important because I can now use the filtered outbound synchronization rules to switch out reference values where I couldn’t before (e.g. A disabled group no longer flows a populated reference attribute but a blank one). This took two synchronization rules, two sets, two workflows and two MPRs to implement before and that isn’t even including the ERE churn that has to pass through the FIM MA for it to operate.

Looking at it from a straight numbers perspective when looking at the total metaverse object count, this is huge. For simple implementations where the simple criteria can be met in the metaverse, it is now possible to remove the ERE’s. In an environment where there are 100,000 groups being synchronized and provisioned to active directory this is 100,000 ERE objects I no longer have to have in my environment. SWEET!