ADMT Intra Forest migration questions

Hi All, I am working on a domain migration. In the past I have used ADMT. I am familiar with the setup and use of ADMT from previous migrations, and am comfortable with the process of migrating groups, users, and computers from an old forest to a new forest.

The process works well, since I can migrate all groups and users in advance since ADMT copies them over. They still exist on the source domain. This allows me to migrate everything over at once, then I can work on smaller groups of computers at a time. For example, I can migrate over 1000 users and 200 groups, and the users can still actively work on their source domain. Once I migrate their computer from source to target domain, the next day they are logging in to the target. This I would do in groups of about 25 computers.

I am now working on an intra-forest migration from one domain to the other. I was not aware ADMT 'moves' accounts and groups rather than 'copies' them until my first test user on the environment. This was shocking to me, seeing the account deleted from source domain.

To specify the exact setup, the envinroment is as follows:


Target / New domain:

Source / Old domain:

There is a two way Tree Root transitive trust set up between the two.


Is there a way around this with intra forest migrations? I am looking for suggestions on how to go about the migration process now for thousands of users, since my original plan I have used in the past for inter forest migrations will not work in this scenario. Thanks in advance.
Who is Participating?
MaheshConnect With a Mentor ArchitectCommented:

Once you migrated (Moved) source user to target domain in same forest and you did not migrate his computer account, while logging on his computer account in source domain, you need to use targetdomain\migratedusername

If you use sourcedomain\username, it will give you error that user account does not exists

Now to address your original question:
By default ADMT moves accounts (users and groups) in intra-forest migration
For intraforest migration, computer accounts are treated differently than user and group accounts. To facilitate rollback, a new computer account is created in the target domain, and the source computer account remains enabled in the source domain after the migration.

User / group accounts should be moved along with SIDHistory attributes, hence even if you migrated / moved user, they will get new SID from target domain, can still access there resources (ex: profile on computer which is still in source domain) with target domain Identity because of SID History
Moving users will not destroy any permissions on file shares / ACL etc. and hence it will remain accessible for migrated users as long as you migrate SID

There would not be change in migration sequence with one change:
Only thing until you migrate computer, migrated user need to logon to source computer as targetdomain\username, SID History will take care of his original profile and share folder access etc.
Also you don't need to disable SID filtering and enable SID history for intra forest migration because all domains by default have transitive trust between each other as opposed to inter forest migration
SID filtering is not enabled across domains in same forest and SIDHistroy is enabled by default within domains in same forest
lastly migrate computers same way as you did in inter-forest migration

One guy has told in below blog that during intra-forest migration, actual source account get deleted from source and recreated in target with its SID copying as SIDHistory to avoid SID duplication because there can't be SID duplication in single forest no matter how may domains you have
That make sense because its may be limitation of AD that it cannot directly cut - paste accounts between domains in same forest though Microsoft did not tell that anywhere

I don't know how that blog is trustworthy, however what I feel that accounts gets migrated with cut - paste way and then only change that happening would be swapping original SID with new and move original SID to SID History attribute, otherwise all user properties \ attributes have to be copied and create entire new object in target domain which seems not realistic
In any case you need to migrate SID History to make things work
If you have MS Exchange server in forest, no changes are required from Exchange side because you moved account

One last caveat is that if you migrate account having member of domain admins or built-in groups, that membership is getting lost in target and if user has any permissions to resources in source domain, it will be lost, hence you need to make sure that before starting user migration, if there are any resources in source which have domain admins / built-in groups has permissions, replace them with domain local group in source domain and add source user to that domain local group, but obvious that you need to migrate that domain local group as well if its newly created before you start migrating users

Check ADMT guide for complete details

you have nothing to worry about you can move groups no issue you just need to be careful with the group type (Global or Domain local etc...) since it is in the same forest it doesnt' really matter the group is in which domain
CCtechAuthor Commented:
Akhater, Can you clarify this please?  

Using my topology above;

Target / New domain:

Source / Old domain:

There is a two way Tree Root transitive trust set up between the two.


TestUser AD account is located in and so is his computer.
Testuser logs in to his computer as sourcedomain\testuser.
We migrate TestUser AD account from to
The user's computer is still on source, when the user goes to log in to his computer as sourcedomain\testuser, you are saying is will still work even though his AD account no longer exists there?
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

AkhaterConnect With a Mentor Commented:
yes off course this is why they are in the same forest, the only thing you need to make sure is the group type since moving a user to another domain might put him outside the scope of the group

the easy way is to
1) change the groups to universal groups
2) move users etc....
3) move the groups etc...
4) change back groups to orignial scope
CCtechAuthor Commented:
Hi Mahesh, Thanks for this info; very useful. I understand ADMT is moving users in the intra forest migrations, I understand am familiar with SID history and all. I am curious if we can break the forest trust and reconfigure as an external trust. Is this a possibility? There are no dependencies on the target domain yet, it is currently an empty domain shell with only some DC's.
You are talking about single forest and breaking trust between domains in that forest?
How could you break the forest trust, that's not possible and totally not supported even if you delete $domain from directory partition
Also external trust is not possible in same forest as name express itself - "External" - which means domain outside your forest boundry, this is not your case

If you do not want to migrate users between same forest, establish new AD forest, but then you need to redesign your strategy and every single component in your strategy to reflect cross forest migration which you are familiar with

CCtechAuthor Commented:
Understood Manesh, I agree but am just trying to think outside of the box. We will proceed ADMT and just have to cut over users and computers at the same time. It will just be less graceful is all. Thanks.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.