I'm currently investigating AD migration strategies. In one of these strategies Id like to have user copiedfrom one AD domain to another AD domain (other forests). After the initial copy we could keep them synchronized using ILM until we can cleanup the old AD domain. I am aware that using the PCNS service, whenever a user change it's password we can push that change to the other forest.The actual question: what with the initial creation of the user accountobject? Am I correct that for this step we need a tool like ADMT which can pre-provision users including their password? Or can ILM handle this aswell?

I've done sync before between forests (Test &Prod)at a customer and there are two issues: 1) ILM / FIM can't do SIDHIstory 2) We can create OU's but ILM 2007 couldn't delete them (I wrote a process to flag the OU and then have the terminate module wipe out all flagged OUs)I didn't to PCNS but as long as it is one way, you should be ok.. Bidirectional is not supported.Otherwise, it's just one more source.EricEric

You can provsion accounts using ILM but you cannot migrate user's current passwords. There's no way (for good reasons) to read the current passwords in the source domain, even its supposed for migration purposes only :-)PCNS can synchronize passwords once a user changes its password in a source (this could be the old domain or the new one) Hope this hepls /Matthias

Thank you both to confirm what I was thinking. About the sidHistory: I'm aware what it does and why one should use it. Is there no way to use fim/ilm to fill in that specific attribute? Or am I completely dreaming here? Some more elobare explaining why fim cannot do sidHistory would be usefull.Is PCNS not supported bidrectional? So you really have to choose an authorative source for the password to come from (upon password changes ofcourse)Thomas

Sorry, I was not proposing that as an answer - pressed the wrong button :-)No, PCNSis not bidirectional - its send password chnages to ILM which proagates them to any directories for which an MA has been configured. If by bidirectional you mean, could a password change in either forest be propagated to the other, the this would create a problem because the way PCNS works is by intercepting the password change on the DC. So you try to configure DCs in separate forests to the the source and the destinatation, you would end up with an infinite loop of password changes (i.e. PW change on DC1 would be detected and sent (via ILM) to DC2, which would detect the password change and send it back to DC1, which would detect the password change and....Steve

You can't do "bi-directional" but you can limit PCNS to groups. So if you create a group in Forest A for "Forest B Users" and the reverse you can limit the changes in each direction from the "primary forest" for the user to the other forest.One other problem you'd have would be if there is no forest trust relationship between forests. Since I believe that PCNS uses Kerberos, you may require an ILM/MIIS server per forest.EricEric

Actually you can use ADMT to migrate existing user passwords even if the user account has already been synchronised by ILM. It’s quite easy as long as the samAccountName matches between domains (otherwise you’ll have to match the accounts in ADMT). I’ve done this many times before using the following procedure: 1. Install and configure ADMT, and the ADMT Password Export Service. • You’ll need to reboot a domain controller to install the Password Export Service. • See the follow article on configuring the Password Export Service: http://technet.microsoft.com/en-us/library/cc974435(WS.10).aspx 2. Ensure your ‘Password Export Server Service’ is started. 3. In the Active Directory Migration Tool console right click on the node ‘Active Directory Migration Tool’ and select ‘User Account Migration Wizard’. 4. On the Welcome screen press ‘Next’. 5. Select the source domain (and appropriate local Domain Controller if desired). 6. Select the target domain (and appropriate local Domain Controller if desired). 7. Press ‘Next’. 8. Ensure ‘Select users from domain’ is selected and press ‘Next’. 9. Press ‘Add’ and select the users you wish to migrate. 10. When all users are selected press ‘Next’. 11. Select the ‘Users’ container of the target domain and press ‘Next’. • This container is insignificant as existing objects in the target domain will be matched, and left in their present location within the target domain. 12. Ensure ‘Migrate passwords’ is selected, then for ‘Password migration source DC’ select your Password Export Server. Press ‘Next’. 13. For ‘Target Account State’ select ‘Target same as source’. Ensure all other check boxes are de-selected and press ‘Next’. 14. In the ‘User Options’ dialog ensure all check boxes are de-selected and press ‘Next’. 15. Enable ‘Exclude specific object properties from migration’ and move all User properties to the ‘Excluded Properties’ list. Press ‘Next’. 16. Select ‘Migrate and merge conflicting objects’ and ensure all other check boxes are de-selected. Press ‘Next’. 17. Press ‘Finish’. 18. The account migration will begin and display its status in a separate dialog. When complete click ‘View Log’ and exam the status of the log. 19. Logon to a domain controller in the target domain. 20. For each OU you just migrated passwords between remove the ‘User must change password at next logon’ setting by running the following command replacing <OU Distinguished Name> with the DN of the each OU: dsquery user <OU Distinguished Name> -limit 0 | dsmod user –mustchpwd no Cheers, Andrew