Hi, I'm in the process of planning for a domain migration (Domain.local & domain.com) All the users within domain.local need to logon to the domain.com domain. They currently have a two way forest trust relationship and are using linked mailboxes within Exchange 2007 whereby there is already a disabled AD account within domain.com. I have installed the ADMT 3.2 and need to test the migration of accounts and computers, but had a couple of questions on the process. Can you perform a security, distributions groups and computers migration before the go live date? I presume this will replicate the components into the new domain and not cause a conflict? (How is the SID referenced on the domain if shares have groups from both trusts?)What is the best practice to migrate the user accounts as they already exist? At present a disabled user account is in the domain for the linked mailboxes. Will a migration using ADMT a conflict with these or can these user accounts be used to logon to the new domain?Can the passwords also be migrated?Is there any simple method to safely change all the linked mailboxes into normal accounts? (From articles read, it is a case of disconnecting the mailboxes and reconnecting them to the new AD account, but I'm unsure if this will cause any issues withing a profiles on the users outlook settings. The primary objective is to minimize disruption to the user profiles, from experience this is main issue when rebuilding machines. I was hoping for the ADMT to transition the local profile into the new domain so the login process would be seamless but haven't much experience with ADMT. I've read through some documentation, but had these initial questions. Thanks for any advice.

1. Yes. Just don't use them if you don't want to. 2. If the disabled target accounts were created so that ADMT will see a conflict, you can use Migrate and merge conflicting objects. Read more about this in the ADMT Migration Guide. 3. Yes, but you'll have to check how well this works when you're using Migrate and merge conflicting objects. 4. Your concerns are valid. http://technet.microsoft.com/en-us/library/bb201694.aspEd Crowley MVP "There are seldom good technological solutions to behavioral problems."

1. Yes. Just don't use them if you don't want to. 2. If the disabled target accounts were created so that ADMT will see a conflict, you can use Migrate and merge conflicting objects. Read more about this in the ADMT Migration Guide. 3. Yes, but you'll have to check how well this works when you're using Migrate and merge conflicting objects. 4. Your concerns are valid. http://technet.microsoft.com/en-us/library/bb201694.aspEd Crowley MVP "There are seldom good technological solutions to behavioral problems."

1. Yes. Just don't use them if you don't want to. 2. If the disabled target accounts were created so that ADMT will see a conflict, you can use Migrate and merge conflicting objects. Read more about this in the ADMT Migration Guide. 3. Yes, but you'll have to check how well this works when you're using Migrate and merge conflicting objects. 4. Your concerns are valid. http://technet.microsoft.com/en-us/library/bb201694.aspEd Crowley MVP "There are seldom good technological solutions to behavioral problems."

Is there any simple method to safely change all the linked mailboxes into normal accounts? (From articles read, it is a case of disconnecting the mailboxes and reconnecting them to the new AD account, but I'm unsure if this will cause any issues withing a profiles on the users outlook settings. You can follow this document to covert the linked mailbox: How to Convert a Mailbox to a Linked Mailbox http://technet.microsoft.com/en-us/library/bb201694(EXCHG.80).aspx When you convert linked mailbox to user mailbox, the connection between between account and mailbox is removed. Thanks, EvanEvan Liu TechNet Community Support

Is there any simple method to safely change all the linked mailboxes into normal accounts? (From articles read, it is a case of disconnecting the mailboxes and reconnecting them to the new AD account, but I'm unsure if this will cause any issues withing a profiles on the users outlook settings. You can follow this document to covert the linked mailbox: How to Convert a Mailbox to a Linked Mailbox http://technet.microsoft.com/en-us/library/bb201694(EXCHG.80).aspx When you convert linked mailbox to user mailbox, the connection between between account and mailbox is removed. Thanks, EvanEvan Liu TechNet Community Support

Need a bit more information, are you planning to knife cut your migration over a weekend or you plan do do coexistence for some times? If you're planning on doing coexistence for sometime than you need to consider implementing some GALsync and or cross forest freebusy. 1. Yes security groups, and DLs migrate before users, otherwise say usersA gets migrated he doesn't belong to any DLs in the target forest now. Now you can say bring over his associated group memberships during his user migration, but it's typically better to just get the groups over first. Computer translation\migration you perform at the same time, you do this after you migrate the user. How is the share referenced...? Via sid history. 2. Merge 3. Convert the MB using shell 4. Yes it's transparent, you dont need to create any new outlook profile, once you run the profile translation\computer migration the user can log into the new forest seamlessly and they will have their original profile. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Need a bit more information, are you planning to knife cut your migration over a weekend or you plan do do coexistence for some times? If you're planning on doing coexistence for sometime than you need to consider implementing some GALsync and or cross forest freebusy. 1. Yes security groups, and DLs migrate before users, otherwise say usersA gets migrated he doesn't belong to any DLs in the target forest now. Now you can say bring over his associated group memberships during his user migration, but it's typically better to just get the groups over first. Computer translation\migration you perform at the same time, you do this after you migrate the user. How is the share referenced...? Via sid history. 2. Merge 3. Convert the MB using shell 4. Yes it's transparent, you dont need to create any new outlook profile, once you run the profile translation\computer migration the user can log into the new forest seamlessly and they will have their original profile. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Many Thanks for the reply's! (Can always count on Ed for help! Nearly on the 30k mark, Cheers!) I will run through some further testing with the ADMT to confirm the issues. Thanks James: Ideally it would be a straight forward cut but I can foresee disruptions so will do it in chunks to help debug issues. We need to migrate approx 50users which isn't huge but will still keep me busy! Migrate 100% of the groups and DLs (now)Migrate user accounts and merge them with current disabled accounts (as suggested)Migrate a number of mailboxes (Change linked to standard) (Weekend)Knife cut a quantity of computer accounts and test (Start of Week)Repeat Migrate a number of mailboxes (Change linked to standard) (Evening)Repeat Knife cut a quantity of computer accounts (Working Hours)Ideally this will take place over the weekend and then the problems will arrise Monday morning. (They always do)Ideally we will use SID history, I can't see an advantage of not enabling this (unless my understanding it unclear) I have found a good guide here: http://blog.thesysadmins.co.uk/admt-series-3-sid-history.html

Sounds like a plan.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Sounds like a plan.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Thanks for the advice. I thought I would update to confirm that I successfully migrated 50PCs using the ADMT tools and am more confident with its use. To answer my own questions: Yes. I performed the groups & user migration in advance including password replication. The only issue was with users that had changed their password after this took place. (possible solution would be to set password to not allow change or carryout nearer the migration date) You can migrate the "Security Translation" in advance, however best practice was to carry this out immediately before the "Computer" migration and swapover. ADMT migration of domain.local user accounts to domain.com does not affect any functioning to the user account and login.Passwords were migrated successfully. There was some tweaking to get this working. As the ADMT system kept erroring when trying to connect to the source domain. I used the following command to import the key from source to target (ran this on the target ADMT system.admt key /option:import /sourcedomain:sourcedomain.local /keyfile:key.pesMigrated users were still able to connect to Exchange "linked" mailboxes even through the mailboxes had not been changed to standard exchange accounts. This made it easier to convert the mailboxes as this could be carried out out-of-hours. There were not any issues disconnecting accounts and reconnecting them to domain.com users. Problems/Issues Experienced: DNS Errors: The main issue we had was related to DNS and resolving computer names. The ADMT would fail simply because it could not resolve the IP address of the machine. There was a conditional forwarder put in place to request the IP from the domain.local DNS, however client systems didn't seem to be registering their IP/name in this domain. A problem related to this was that the DHCP was moved from domain.local to domain.com before the migration (the primary DNS was still set to domain.local) but this caused problems. I would suggest that the DCHP was left installed on the old domain until after the migrations are complete to avoid.Admin Rights: Another issue was related to local admin rights, some of the systems didn't have any domain admin permissions on the local machines, this had to be manually added using the "users" account. (Poor configuration from previous support)Default domain: I specified the default domain to use "domain.com" using GPO. Therefore once the machine had been migrated it would pick up the new GPOs and change this. This didn't work correctly and "domain.local" was listed first on the windows logon drop down box. As a work around I had to inform users to select "domain.com" and disabled the "domain.local" user account to prevent login.