Hi all, This question relates to provisioning with just the Synchronisation Service. We do not use the portal. I've been happily provisioning users without Exchange functionality for a while now, but now that we're migrating to Exchange, I have had to do a bit of reading around mailbox provisioning. The articles I've been reading are: Jorge's quest for knowledge, and A Technet article. What I'm a little confused over is that without enabling the Exchange provisioning in the Extensions section, populating the unicodePwd and userAccountControl csentry values has the desired result of creating an enabled AD account with the specified password. When I enable the Exchange 2010 provisioning component though, the password appears to be ignored and as a result the userAccountControl comes back as a 514 instead of a 512 - which in turn creates an exported-change-not-reimported error, but I'm not so worried about that since it's not the root cause issue. If I reset the disabled account's password and enable it, it's fine from that point on. In the first article, Jorge supplies the mandatory attributes - which is exactly the information I was after, and implies that the methodology from the second article is optional, ie I should be able to code as I have done previously and it should still work. Does anyone have any further information as to whether or not this is correct or incorrect? I'm at a loss at this point in time as to whether I must adopt the methodology in the second article or whether there's something else I'm missing here. Cheers, Lain

I forgot to come back and close this. It turned out to be a problem of my own making. I had not revisited our AD delegation model post-Exchange installation, and one of our Desktop Support staff had indicated it was possible to send mail on behalf of another user, which I realised immediately was due to having the "All extended rights" option. I removed this option from the delegated group, which I had in turn forgotten I had made the FIM account a member of, which in turn meant the account no longer had the right to set passwords, which in turn meant account creations were working, but the password was not deemed complex and the account was set to disabled. Fun, fun, fun. Anyway, I decided to remove the FIM account from the delegated group used for account management and directly assign it the rights to those OUs only. That resolved the issue. So a simple solution for what ultimately turned out to be a simple problem. As per usual though (for me), I was trying to troubleshoot the complex end of the solution before validating the basics were taken care of. Cheers, Lain