Hi, group provisioning from MVExtension .dll worked fine for me for years, it was sufficient to rename csentry.DN to rename group in AD (change distinguishedName). now with FIM declarative provisioning and 2 DN flows set up in outbound sync rules (one for initial flow and one for persistent) instead of changing connector space object's DN MIIS wants to add 'dn' attribute to the group. so export goes fine with no errors but DN is not changed in AD. what's wrong here and why 'dn' attribute is going to be added instead of renaming CSObject.DN? (role1 was renamed to role2)

Please post your SR configuration - the DN flows are good enough. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

the only difference from basic groups provisioning scenario is that FIM objects that maps to AD are not groups, but custom created objects 'roles'. 'UPN' is just an indexed string calculated by FIM workflows.

We would need to see how the UPN attribute is getting updated in the MV to troubleshoot this. Does the displayName attribute in the source MA flow to the MV UPN attribute? According to what you have shown here for screenshots, the displayName changing would have to be related to changing the UPN since UPN is what determines the target dn value in target MA.

ok, provisioning stage: after export to AD and delta import / delta sync there's an error 'export change not reimported' Same error with DN not reimported happens with role name change and further DN and display name changes. AD MA has only import rules setup

Glenn, any ideas?

Prior to the export to ADDS (1) and after the import from it (2), you should take a look at the object's tower: Delta Unconfirmed Export Delta Pending Import During the staging process, the synchronization engine compares the values and if they don't match, exported-change-not-reimported is thrown. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Prior to the export to ADDS (1) and after the import from it (2), you should take a look at the object's tower: Delta Unconfirmed Export Delta Pending Import During the staging process, the synchronization engine compares the values and if they don't match, exported-change-not-reimported is thrown. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation Markus, I know how sync engine compares the values and why export-change-not-reimported is thrown. The problem itself if you scroll up to my original messages is with DN flows to AD MA. If I have only initial flow defined in FIM sync rules like UPN->dn there's a normal pending export picture: export goes fine and no errors occured during delta import but if I would turn on persistent UPN->dn flow in FIM sync rules like on the screenshot above the picture changes to this: FIM adds one more attribute flow for DN as a regular attribute on new object provisioning. This I suppose should not happen and this in turn gives that export-change-not-reimported exception Question is: why FIM adds DN attribute flow as a regular attribute flow to new objects provisioning details? This is also the reason why object in AD is not renamed (DN is not changed for CS object) but FIM tries to flow DN as a regular attribute (with a new value)

If you have a regular and an initial attribute flow defined, both configurations are processed. In FIM (ILM), object level operations are performed prior to attribute level operations. An initial attribute flow belongs to the object level operations. When provisioning creates a new connector, you have the option to initialize the attributes of the newly created object. This is what the initial attribute flow configuration is good for. As a second step, the attribute level operations are applied - in this case the regular attribute flows. If you have for an attribute regular and initial attribute flow defined, you typically need some logic in your regular flow to determine whether the flow is processed on a newly provisioned object. This is why Glenn asked for the UPN calculation logic. The weird thing - if I'm not missing something - in your case is, that it shouldn't matter since both flows are using UPN as a source. So, what you see in the screenshots is so far correct, you should see a regular attribute flow for dn. The question is now, why you get the warning during the staging operation. Looking at the tower might help to shed some light on this. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Markus, lets leave export-change-not-reimporeted for now. Can you explain this: role was renamed from r1 to rx1, UPN value recalculated, but DN for AD CS object is not changed? in classic MV rules I would expect DN to change in the highlited part.

Again :o), just using the UI is not sufficient to track down issues like this. Also, the warning might be related to your issue... Before running the export that has the updated DN, you should take a look at the Delta Unconfirmed Export of the affected object. Is there a dn update sittinig? You should also configure your export run profile to create a log file during export. That way, you can see what the ADDS MA has exported to ADDS. After the import, you should take a look at the Delta Pending Import and also at the hologram. This will tell you what happened from the perspective of FIM. This script might help to make the process a bit easier. It is possible, that your issue is related to ADDS and not to FIM - I have seen cases like this before. This means, it is possible that FIM has tried to move the object but AD has not completed the operation for some reason. Don't quote me on this because I might be confusing myself; however, for some reason, I'm under the impression that you should see a Rename instead of an Update - but I might be wrong. I will repro this scenario as soon as time permits; however, this can take a moment. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for reply. I will try to get more logs on export. but once again :) if I would switch to MV Extension .dll code from sync rules and will rename ADMA csentry.DN during mventry provisioning there will be RENAME operation pending export to AD. with fim sync rules there's an UPDATE operation instead of rename plus dn flow as a regular attribute. and as an old MV extension code works fine its not an AD issue :) will get export logs and see what's inside. again, thank's for reply. this issue is getting me mad... and I'm very short on support hours left for this year and will not open a case with MS right now :(

Correct, I would expect a pending rename as well. To eliminate a UI bug in the mix, it is better to take a look at what is actually staged on the object. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

well... its not a UI bug. here's export log for new object creation - nothing interesting except additional dn flow. I think I will recreate MA now to see whether is a bug in MA config <delta operation="add" dn="CN=Prg-testapp2.r1,OU=test_app2,OU=Business Applications,OU=RG Resources,DC=mydomain"> <primary-objectclass>group</primary-objectclass> - <objectclass> <oc-value>group</oc-value> </objectclass> - <dn-attr name="managedBy" multivalued="false"> - <dn-value> <dn>CN=utest,OU=Accounts,OU=office, mydomain </dn> <anchor encoding="base64">rUcwij6ehkyh/HlYqdU5QQ==</anchor> </dn-value> </dn-attr> - <attr name="displayName" type="string" multivalued="false"> <value>r1</value> </attr> - <attr name="dn" type="string" multivalued="false"> <value>CN=Prg-testapp2.r1,OU=test_app2,OU=Business Applications,OU=RG Resources,DC= mydomain </value> </attr> - <attr name="groupType" type="integer" multivalued="false"> <value>0xffffffff80000002</value> </attr> - <attr name="sAMAccountName" type="string" multivalued="false"> <value>Prg-testapp2.r1</value> </attr> </delta>

ok, here's new object export log: <mmsml xmlns="http://www.microsoft.com/mms/mmsml/v2" step-type="export"> <directory-entries> <delta operation="add" dn="CN=Prg-testapp2.test,OU=test_app2,OU=Business Applications,OU=RG Resources,DC=123,DC=com"> <primary-objectclass>group</primary-objectclass> <objectclass> <oc-value>group</oc-value> </objectclass> <dn-attr name="managedBy" multivalued="false"> <dn-value> <dn>CN=utest,OU=Accounts,OU=Office,DC=123,DC=com</dn> <anchor encoding="base64">rUcwij6ehkyh/HlYqdU5QQ==</anchor> </dn-value> </dn-attr> <attr name="displayName" type="string" multivalued="false"> <value>test</value> </attr> <attr name="dn" type="string" multivalued="false"> <value>CN=Prg-testapp2.test,OU=test_app2,OU=Business Applications,OU=RG Resources,DC=123,DC=com</value> </attr> <attr name="sAMAccountName" type="string" multivalued="false"> <value>Prg-testapp2.test</value> </attr> </delta> </directory-entries> </mmsml> after that here's delta import log (dn attribute is not in the list, so I have export-change-not-reimported error): <mmsml xmlns="http://www.microsoft.com/mms/mmsml/v2" step-type="delta-import"> <directory-entries> <delta operation="replace" dn="CN=Prg-testapp2.test,OU=test_app2,OU=Business Applications,OU=RG Resources,DC=123,DC=com"> <anchor encoding="base64">jgfzrBHBgkSjRw11gfqklw==</anchor> <parent-anchor encoding="base64">LORXk5246UCEkwoHqaaoMw==</parent-anchor> <primary-objectclass>group</primary-objectclass> <objectclass> <oc-value>top</oc-value> <oc-value>group</oc-value> </objectclass> <dn-attr name="managedBy" multivalued="false"> <dn-value> <dn>CN=utest,OU=Accounts,OU=Office,DC=123,DC=com</dn> <anchor encoding="base64">rUcwij6ehkyh/HlYqdU5QQ==</anchor> </dn-value> </dn-attr> <attr name="cn" type="string" multivalued="false"> <value>Prg-testapp2.test</value> </attr> <attr name="displayName" type="string" multivalued="false"> <value>test</value> </attr> <attr name="groupType" type="integer" multivalued="false"> <value>0xffffffff80000002</value> </attr> <attr name="name" type="string" multivalued="false"> <value>Prg-testapp2.test</value> </attr> <attr name="objectGUID" type="binary" multivalued="false"> <value encoding="base64">jgfzrBHBgkSjRw11gfqklw==</value> </attr> <attr name="objectSid" type="binary" multivalued="false"> <value encoding="base64">AQUAAAAAAAUVAAAAwARtAX4/m0TUCpFeyw4BAA==</value> </attr> <attr name="sAMAccountName" type="string" multivalued="false"> <value>Prg-testapp2.test</value> </attr> </delta> </directory-entries> </mmsml> then after delta sync MIIS wants to add that dn attribute to AD group, here's export log: <mmsml xmlns="http://www.microsoft.com/mms/mmsml/v2" step-type="export"> <directory-entries> <delta operation="update" dn="CN=Prg-testapp2.test,OU=test_app2,OU=Business Applications,OU=RG Resources,DC=123,DC=com"> <anchor encoding="base64">jgfzrBHBgkSjRw11gfqklw==</anchor> <attr name="dn" operation="add" type="string" multivalued="false"> <value>CN=Prg-testapp2.test,OU=test_app2,OU=Business Applications,OU=RG Resources,DC=123,DC=com</value> </attr> </delta> </directory-entries> </mmsml> after this export nothing is changed in AD and delta import shows no modifications. this should never happen... but it does exist. even with another MA created from scratch. its not a UI bug, not an AD bug, not a MA misconfiguration, not a permission issue... what else?

I can't repro the behavior you get. In my simple test environment, I have implemented a dn logic that is based on the availability of the objectGuid. To track the GUID value, I have a custom attribute (adGuid) in the metaverse. Here is the synchronization rule I am using: Here is the outcome: As you can see, the object has been successfully renamed. What I don't see yet is what the difference between your configuration and mine is. The best suggestion I have for your right now, is to repro my configuration - which is very simple. All, you need is one user in the portal that is provisioned to ADDS. After a confirming import of the newly provisioned user, the user should be renamed. In addition to the outbound synchronization rule above, you would need a simple ISR: If you can get this scenario to work as expected, we would have to go back to your configuration and determine what the differences are. Cheers, Markus

Markus, believe it or not, but custom expression flow to DN instead of UPN works fine :) see this: so after first export to AD and delta import to get ObjectSid and delta sync I have this: but changing my flow to UPN=>DN gives me back my error. Can you try to change your IIF condition to something like UPN=>DN where UPN flows from FIM to MV. just a string value, calculated by FIM

What happens when you use the trim function with your attribute: Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Markus, I have no idea how you guessed it, but it worked. Trim(UPN)=>DN works fine, no more additional DN flows and operation is RENAME now. I will leave it as a workaround for now, but I do suspect it is kinda bug or my misunderstanding of FIM declarative provisioning concepts. Thank you, guys

Groovy - I'm glad to see that it works. Since the string values seem to be same in the tower, but the re-import warning is thrown, I was hoping that this is due to a whitespace issue... Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

well... I just double checked the UPN values in MV - there're no whitespaces... tried other scenarios and here's what I found: FIM does the DN renaming job well only if function is present in =>DN flow. I mean "CN=",displayname,"string value" works fine as FIM concatenates these strings. But when I put 'mv string'=>dn I get that above mentioned behavior. no matter if MV value is calculated or not. this is really strange, but it happens with Microsoft all the time :) so we're kinda ready for such things

same problem... To MS: why can not bind MV string to DN in AD MA? any technical reason? why in portal bind correctly work (using Trim function)?

I have already answered your question here. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Adding on to an old thread, but I found this while searching for an issue I was just having. My outbound sync rule (which only included logic to rewrite the dn) was being "Applied" to the users under their provisioning tab, but my DN's were *not* getting renamed and fixed. They were never getting to the export stage of AD. My problem was that my DN logic was built using a custom attribute (collisionString) I had added to help with name collisions in the same OU container (Two John Doe's), and this value was null for *most* users. I changed my expression to a custom one that checks for existence of that value first, and it started working. No effect but "Applied": "CN="+lastName+"\, "+firstName+" "+collisionString+",OU=myou,DC=my,DC=domain" -> dn Takes effect and "Applied": IIF(IsPresent(collisionString),"CN="+lastName+"\, "+firstName+" "+collisionString+",OU=myou,DC=my,DC=domain","CN="+lastName+"\, "+firstName+",OU=myou,DC=my,DC=domain") -> dn Matt