Hello all - I have run into an issue I have not seen before. When provisioning new users to AD with FIM, I am (for now) setting the password to a static string value that meets the domains complexity requirements using an Outbound Sync Rule (initial flow only). I am also setting userAccountControl to 512 (both in initial flow and persistent flow). When exporting the new user to AD, the user is created, but i get an error trying to set the userAccountControl to 512. Using the account used by the MA, I connect to AD and try to manually enable the account but get an error about the password not meeting the requirements. I can, with the account used by the MA, open ADUC and manually set the password to the desired static value used in my Outbound Sync Rule. Then I can manually enable the account and all is well. So, it does NOT appear to be a rights issue with the account. I have forced the MA to use a specific DC and I get nothing in either the FIM sync event logs or on the DC itself (which for the record is the PDC). Anyone have any thoughts?Keith

I've seen that exact same issue before. In all my cases it was Kerberos issue. One was related to cross-forest kerberos ticket issues (forests had an external trust) The second was due to a firewall blocking UDP 464. The third was not having access to the DNS server to lookup the SRV record for the Kerberos KDC. Hosts files here used to locate the remote domain Similar to your case, it worked fine using ADUC. Not knowing your topology, these may not apply, but thing to consider anyways. -Frank

Thanks Frank! I ran across a posting somewhere that referred to Kerberos issues (probably yours). Single forest (multiple domain though). FIM sync is in the domain of the users, and so is the account used to by the MA. So it doesn't appear to be a Kerberos issue. Getting ready to do a network capture though to hopefully see what is going on a little better.Keith

in AD you cannot enable user "useraccountcontrol=512" if the password is null, the result is this error message, "The server is unwilling to process the request", it seems that you set the password to null during creation. I don't know if this is related too double check time synchronization for active directory

Time sync looks good. The whole environment looks to be very clean and stable. I belive this is my issue: http://support.microsoft.com/kb/976424. From the KB: "For example, you cannot set the user password by using the Microsoft Identity Lifecycle Manager during user provisioning." Looking at the attribute version numbers on the krbtgt account indicates there was an authoritative restore done on (at least) that account. I am trying to get confirmation of this from my client, and will then be deploying the hotfix. I will report back when I have more information.Keith

The hotfix above has resolved my issue. So, it was a Kerberos issue, just not a very common one. Thanks to Frank for getting me started on the Kerberos path! KeithKeith