I am having a problem with flow precedence in FIM. This is a brand new FIM 2010 RTM installation with current updates from Microsoft Update. There are two MAs: one for FIM and the other for AD. The FIM MA has both IAF and EAF for displayName. The AD MA has a declarative inbound sync rule for displayName. The AD MA has a precedence of 1 and the FIM MA has a precedence of 2. Equal Precedence is not selected. If I run a “Full Sync” from the AD MA, the displayName value from AD flows to the Metaverse as expected and is queued up for export to FIM. If I run a “Full Sync” from the FIM MA, the displayName value from FIM flows into the Metaverse. This is unexpected because the FIM MA has a lower precedence and should not overwrite a value that came from AD. It is also unexpected because the results of a sync for a particular record should not change based on which MA it was initiated from. If I replace the declarative rule with an old school IAF in the AD MA, precedence works as expected. (And when I switch back to declarative, it breaks again.) Any suggestions?

No explanation ... but a confirmation.. I'm seeing the same thing - except FIM is 3rd behind 2 SQL MA's By alternating between syncing the FIM and the SQL MA's its apparent that the FIM MA when synced will always flow its attribute even though declared precedence is lower. And as you indicated, only when the sync is run by FIM MA...Some kind of MA 'Super Power" ..and definitely not as expected..

How have you verified that the FIM MA flows something into the metaverse? If, given your description of your precedence configuration, the FIM MA flows something into the metaverse, you should contact PSS for further investigation because this is an unexpected behavior. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I do have attributes flowing from the FIM MA into the metaverse (the referenced displayName and a couple of other things.) In fact, if I delete the inbound displayName flow from FIM I only one one source for the information and displayName will flow out to FIM as expected. As Frank posted, it appears that the FIM MA has some sort of super power. I will open up a PSS case, thanks.

Rex, Try setting equal precedence in the MV designer for this attribute. Any time I am flowing an attribute for both import and export using the FIM MA, if I don't use equal precedence, I see behavior similiar to what you are experiencing.

Equal precedence is actually what I wanted. I found that with equal precedence set and after updating the value in AD it did not flow to FIM. As part of the diagnostic process I unchecked equal precedence and explicitly set AD to have precedence. That didn't work either, thus my question. I assume that whatever is preventing normal precedence from working is also messing up the equal precedence that I actually desire.

I've had similar instances but it was limited to boolean values and multiple SR rules. Regardless of how precedence was set the last MA run in full sync mode seemed to update the MV. It was an interesting behaviour. I worked around it by defining classic rules (using a rules extension) because of the boolean bug that Jorge had logged where the "true" constant value sometimes changed to a 1 (detailed in this article here) Thanks B

As an update, both PSS and the product team have reproduced this problem. The product team is investigating.

I do have attributes flowing from the FIM MA into the metaverse (the referenced displayName and a couple of other things.) In fact, if I delete the inbound displayName flow from FIM I only one one source for the information and displayName will flow out to FIM as expected. As Frank posted, it appears that the FIM MA has some sort of super power. I will open up a PSS case, thanks. I discovered this little gem months ago and just figured it was by design. After I got over the fact that the FIM MA does indeed have 'super powers' I asked myself "why am I even flowing this back into the MV?" I think I was just blindly following the "Getting Started" stuff. Anyway, once I answered that question the answer was easy and I removed the inbound flows. This could be by design since precedance is defined at the MV level but then again could be a bug.

Heard from PSS yesterday that this is a bug and they have developed a fix internally. That fix is in testing. In my case I have an attribute that can be changed both in the FIM Portal and in Active Directory so I do want both inbound flows. Your point is valid though, if you have multiple inbound flows to the same attribute you should verify that you really need to.

Any ETA? This is a big problem... Having to switch to classic is a bad fix especially when codeless is what everybody wants.. I was able to work around it by setting at least one of the attributes in classic, you don't have to set all to classic... Would be nice if the case issue in the FIM ma was also fixed.......Joe Stepongzi - Identity Management Consultant www.microsoftIdM.com,ilmXframework.codeplex.com

Scratch that.. I just replicated it.. and you have to remove them.... pretty sad.. client is not going to be happy when I tell them this.Joe Stepongzi - Identity Management Consultant www.microsoftIdM.com,ilmXframework.codeplex.com

Well I wouldn't say that everyone wants codeless... I will update when I get further news.

you can't even imagine how happy I'm now with decision made to stay with old classic inbound / outbound flow for all MAs... Microsoft products are good from version 3, indeed... this was ILM v2 :)

Trust me i would rather stay coded.. much simpler... codeless complexity as I call it... needs some work.. But clients are sold on it and want it as much as possible.. So it puts me in this middle position.. Any eta til the release of this?Joe Stepongzi - Identity Management Consultant www.microsoftIdM.com,ilmXframework.codeplex.com

A fix for this is now available from PSS. You can reference KB 2272389 but that isn't available, yet.

This FIM MA precedence issue has taken a slightly different twist for me at my FIM site ... can anyone tell me if they've seen this too, and if the same patch will address my issue? Scenario: domain attribute in the MV, with contributing MAs being both FIM (1) and AD (2). inbound (codeless) sync rule imports domain user (relationship criteria MV.accountName = CS.sAMAccountName; Create Resource in FIM = true; MV.domain set to constant value matching domain config in portal) account is projected onto MV first time and pending export set up for FIM portal account is created in FIM portal but without a value for the domain attribute ... even though present in the metaverse it is not in the FIM MA CS when running a preview on the FIM MA object (full sync) it shows the domain update from the AD MA as "skipped not precedent" ... even though there is no value in the FIM MA CS???? To solve the above scenario I too have started resorting to a combination of equal precedence and classic inbound rules extensions to ONLY write a value for this attribute to the MV if there isn't already one present. I absolutely HATED having to do this, as it is kind of the thin end of the wedge, and goes against all the most basic of precedent concepts built up over years of working with MIIS/ILM before FIM. Thanks

Attribute precedence is applied on the inbound AND on the outbound side. You haven't mentioned, what your current configuration of the attribute flow precedence for domain in your environment is... If FIM has a higher precedence than AD DS, domain will with the default precedence configuration never make it into FIM. This is because a MV value that was contributed by a MA with a lower precedence will never flow (EAF) to a MA with a higher precedence. Why is FIM a contributing MA in your environment for domain? The owner of this attribute is AD DS and if you take a look at How Do I Synchronize Users from Active Directory Domain Services to FIM, you will find a method for calculating it. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for getting back so quickly Markus. The above scenario is a simplification of a config which has 10 contributing MAs to the domain attribute ... the portal identifies the specific inbound sync rule I'm looking at as having precedence number #11 ... but given there are a number of inbound rules this doesn't correlate to what shows up in the sync engine (where it just tells me that the mapping type is "SR-Constant" for this MA with an "Order" of 4 ... the FIM MA itself shows as 2, but relatively speaking they are 2 and 1). I'm concerned about your statement "a MV value that was contributed by a MA with a lower precedence will never flow (EAF) to a MA with a higher precedence" ... I'm pretty sure this wasn't the way of the MIIS/ILM world where a value would be exported under such a condition in lieu of a value not being precedent in the higher order MA. The reason that there is a contributing value from the portal is that there are multiple domains involved. I skimmed over your article only yesterday - it doesn't cater for the multi-domain scenario from memory, but checking again now. There is a lot of history with this particular site involving the (attempted) sync of groups and group membership/ownership between AD/Notes/FIM ... and there are lots of work-arounds to cater for the fact that the Notes MA doesn't recognise certain CS object classes (e.g. the mail-in-database object) ...Bob Bradley, www.unifysolutions.net (FIMBob?)

You're welcome... Inbound and outbound precedence handling is not the same. Your description applies to inbound precedence. In case of the default precedence configuration, to contribute a value to the MV, a MA must have the same or a better precedence than the last contributor. Please see Paul's article on flow precedence in ILM for more details on this. The solution to calculate the domain value in the article works for multi-domain environments. In AD DS, domain is a computed attribute. This means, the value is not directly associated with an object. When the value is needed, the directory service has to look up the value. The implementation outlined in the article is similar - it uses the objectSid attribute value to calculate the domain value. From an inbound flow configuration perspective, domain should not be contributed by the FIM MA because AD DS is authoritative for the value. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks again Markus - there's nothing in your reply I don't agree with (in particular about AD DS being authoritative for domain!), but as I said before, my understanding of precedence is still adjusting from ILM/MIIS days (outbound precedence being new to FIM). I'll check out your link shortly - although in our scenario one of the "domains" isn't actually real (has a string value of "NOTES"). As I said this solution has evolved to work-around the limitations of a Notes MA ... In the meantime, and further to my last response, the issue we have is related to a problem we've been having with the EQUAL PRECEDENCE setting that was previously set for both domain and accountName - whereby the values of both attributes in the metaverse were changing unexpectedly as a result of what looked to be no more than sync activity on a connected MA. The intent was to initialize both domain and accountName in the metaverse for certain types of users that are NOT created initially in the portal, and have them provisioned to the portal after which time the portal would become authoritative for both attributes. While it is easy to imagine why you would want the portal to be authoritative for accountName from this point, there was also provisioning/deprovisioning designed around the domain attribute value changing in the metaverse as a result of a change in the portal. I can see how the solution could be reconfigured to remove the inbound flow from the FIM Portal for domain, on the basis that we can come up with another way of handling domain moves, but I don't see how this can work for accountName ... do you have a take on that? I have always preferred to have AD authoritative for that too, until along came the FIM Portal :).Bob Bradley, www.unifysolutions.net (FIMBob?)

I am currently devoid of an environment to test the behaviour outlined in this article by Paul Loonen: http://social.technet.microsoft.com/Forums/en-US/identitylifecyclemanager/thread/2c4f5c39-de0b-4fed-9cdd-057d0394085b ... however I guess I must have long been under a misconception … and fooling myself into believing something else. Specifically the scenario I am concerned with appears in the article with a couple of diagrams and text which states “In general, you will get into this situation when for a given MA you define both an IAF and an EAF for an attribute, so flowing a value from the CS into the MV and flowing it back into the same CS.”. If you search for this string you’ll find what I’m referring to. Rather, I would probably have defined it as “… attempting to export a value from the MV to a CS attribute of higher precedence on the assumption it can subsequently be imported back into the MV from the same CS”. What you and Paul are obviously saying here is that this is NOT ALLOWED … both of you citing “unwanted data loss is possible”. However, I can think of plenty of cases where I have actually WANTED this to happen … and I THOUGHT it used to happen with MIIS/ILM, but I am no doubt mistaken. The issue a few of us are now having with FIM is where system A in Paul’s diagram is actually FIM, and system B is say AD. An example of this is the sAMAccountName for an existing account projecting onto the metaverse accountName, but not being set up as a pending export to FIM unless equal precedence is set ... and where in my case I don’t want to have equal precedence set! The MIIS/ILM example I was thinking of which matches Paul’s diagram A where I DO want the initial export to A to occur (even though A is of higher precedence than B) is when you want to contribute a value to A when there’s a value in the MV and you have no better option available – e.g. you want the initial telephone number to come from HR (B) and go out to AD (A), but thereafter have A as more authoritative for telephone number. Of course I’ve always been able to do this in the past, but thinking about it now I’ve probably used provisioning code to achieve this … i.e. just before the “csentry.CommitNewConnector()” call in the provisioning rules extension model where you can effectively (it seems) override precedence by specifying something like csentry[“telephoneNumber”].Value = mventry[“telephoneNumber”].Value. What I am expecting now, based on your argument, is that if I don’t do this in ILM I’m probably going to get the same “skipped-not-precedent” status in the sync preview I’m now getting with the FIM MA. Of course with ANY OTHER FIM MA you can also do this in an outbound sync rule by checking the “initial flow only” checkbox. However you can’t do this for the FIM MA … and therein lies our dilemma. The question therefore remains … how do we achieve this outcome (of overriding precedence on initial flow only) with the FIM MA WITHOUT HAVING TO RESORT TO EQUAL PRECEDENCE? It occurs to me that what is going to be a very common requirement is NOT SUPPORTED FOR THE FIM MA. Is there actually another way to achieve this desired outcome? I'm thinking in terms of some "back door method" of assigning some initial values in the FIM portal when provisioning to the portal the first time ... ??? Thanks for your patience here.Bob Bradley, www.unifysolutions.net (FIMBob?)

I have yet to test the patch, but I have a big problem with this... What about when you create accounts in the FIM Store?? It then creates and AD account... So in a way... you will have two authoritative values.... What if you depict where you want the user to be? then you have to use someother attribute for this.. and have it flow back the domain that way???? Not buying it... There indeed was a change in precedence flow... but not from ILM to FIM... somewhere from MIISSP1 to ILM there was an alter.. because there were somethings I used to be able to do with this that you can't anymore.. I know this bug specifically fixed a couple issues.... forcing equal precedence... and changing even if the value is the same... Also it would sometimes create random deletes... without the allow null checkbox checked. Glenn has told me that the patch should fix both issues.. I really think this needs to be looked into a little further.. if I wasn't busy at the moment... I would be hammering it out........ ALso didn't read Paul's post yet... will check it out.. as soon as I hit submit.Joe Stepongzi - Identity Management Consultant ilmXframework.codeplex.com

I've had similar instances but it was limited to boolean values and multiple SR rules. Regardless of how precedence was set the last MA run in full sync mode seemed to update the MV. It was an interesting behaviour. I worked around it by defining classic rules (using a rules extension) because of the boolean bug that Jorge had logged where the "true" constant value sometimes changed to a 1 (detailed in this article here) Thanks B Was this specific issue ever resolved? I'm seeing this right now where I have two MAs contributing a series of boolean values via Sync Rules (using expressions so not direct), and the last MA to sync is precedent rather than according to the precedence order defined on the attribute.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Brian - I haven't had a chance to test the latest patch yet, so I don't know if it has been resolved, but THANKYOU for confirming that I wasn't going mad here ... indeed your observations are consistent with mine, and these make me incredibly nervous about using equal precedence!!!Bob Bradley, www.unifysolutions.net (FIMBob?)

Brian - I haven't had a chance to test the latest patch yet, so I don't know if it has been resolved, but THANKYOU for confirming that I wasn't going mad here ... indeed your observations are consistent with mine, and these make me incredibly nervous about using equal precedence!!! Bob Bradley, www.unifysolutions.net (FIMBob?) The above referenced QFE package resolved this issue and some other wierdness. I have a call with PSS tomorrow and I want to find out what other things are in there.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Can you let us know what they come back with? I had another instance of this issue myself last week. It's hard to sell the advantages of using declarative rules and then have to explain that its broken and you can't use it in most situations where you need to assign precedence. Thanks-

Frank, I'm curious what Brian will come back with. I can confirm as well that build 4.0.3561.2 fixes the above issue. Other stuff it fixes I know about: Attribute recall issue: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/941b44f2-de41-4ec3-9686-f78f1178ac69 Synchronization Service CPU usage: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/0456bce2-7f5f-45eb-aa0a-c1945d2b7065 And it adds support for SSPR following the password history password policy setting. http://setspn.blogspot.com/2010/11/fim-2010-sspr-enforces-password-history.html http://setspn.blogspot.com

Hi- Yes per my reply a few posts up this is all straightened out. I was also able to get a set of documents from PSS which outlined all of the issues resolved in 3561 and the builds leading up to it. Quite a few different things were in there.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Hi- Yes per my reply a few posts up this is all straightened out. Quite a good number of different things are fixed in these updates. My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com