Hi, I am receiving an "unexpected-error" when exporting a previously disabled account to AD as a re-enabled account. Here's the scenario: User is returned to the delta view, which should move them back to the Active Accounts OU (from the Inactive Accounts OU). The export does move the user to the Acitve Accounts OU, however, the user is disabled, and the export reports "unexpected-error". A subsequent sync will change the user to enabled without any errors. The event viewer reports this error, that baffles me a bit: "BAIL: MMS(1848): tower.cpp(3855): 0x80004005 (Unspecified error) BAIL: MMS(1848): csobj.cpp(2112): 0x80004005 (Unspecified error) BAIL: MMS(1848): expcall.cpp(864): 0x80004005 (Unspecified error) ERR: MMS(1848): expbase.cpp(2902): PutAnchorWithDnInternal failed on CS object {CB0DE8C8-15F4-48CC-8A67-3214E4D3DE85} with 0x80004005 (pass 1 of 5) Forefront Identity Manager 4.0.3576.2" All my searches say a hotfix addressed this in ILM, but I'm unsure if that would be an appropriate approach for FIM. Any ideas or suggestions are appreciated. Thank you for any help. Sami

Sami - can you confirm that the disabled account you are seeing there is not one that has been re-provisioned? A straight rename (mod dn) has always worked OK for me, so I am thinking the "PutAnchorWithDnInternal" part of the exception is the clue here. It indicates to me that the FIM sync engine might be trying to overwrite the AD anchor (the AD guid) with something that was previously stored in FIM. I presume you are using declarative sync rules here? If so, what are you using as the relationship for the join? What are your attribute flows out to (and back in) from AD for the following atts: dn objectSID objectGUID Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Hi Bob, I am using declarative sync rules. For the join relationship, I'm comparing: objectSid=objectSid employeeID=employeeID accountName=sAMAccountName I have two outbound attribute flows to dn, one for Initial Flow Only, both with this custom expression: IIF(IsPresent(SQL_Connector_Flag),"CN="+Customer_ID+",OU=Sharepoint_Users,DC=DOMAIN,DC=org","CN="+Customer_ID+",OU=Inactive Accounts,DC=DOMAIN,DC=org") I have an inbound attribute flow of objectSid to objectSid. I just did another test and the objectSid is not changing when the account is re-enabled, so I'm assuming that means it wasn't re-provisioned. Does anything I have in the sync rule look suspicious? Thank you for your help and ideas. Sami

Out of curiousity, I set the attribute flow for userAccountControl to "Initial sync only". This obviously means the account didn't get re-enabled, but I also didn't get the error. The object's userAccountControl is definitely 514 before the attempt to change it to 512. I'm using this code to set the UAC value: IIF(IsPresent(SQL_Connector_Flag),512,514) Maybe that is the problem? (I've used this code before and it's been OK.) Thanks, Sami

The SR looks good, but are you trying to activate an account that may not have an initial password? You can't enable an account without at least setting an initial password - I usually check the pwdLastSet value to determine this.Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

I think the password is already set because I am able to manually set the account to enabled in ADUC when the user is in the state right before the Export that causes the error. However, you have maybe hit on something.... If I remove the attribute flow to set the password, the error doesn't appear. With the password attribute flow enabled, the preview doesn't show it being affected with any change, so I'm not sure if this is relevant or not. I'm still not sure what's going on, but will work on the password angle some more. Thank you again for your help. Sami

Cool - password flows should always be initial flow only, as you don't want these appearing in your metaverse in clear text, and if you do it the correct way it remains hidden.Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Thank you for the help. The Initial Flow only worked. The customer has a password flow requirement and isn't using PCNS, so I'm doing something different for password attributes. Thanks, Sami