User impact when migrating from the old AD domain into the new AD domain ?

Posted on 2015-02-08
Medium Priority
Last Modified: 2015-02-08

Before I'm going ahead with the plan to migrate the AD from one domain to another using ADMT, I just wanted to know and cover all of the bases and possibilities of what is going to happen from the user perspective ?

1. What happened to the AD domain selection or dropdown that the user usually select during the Workstation or Windows Server logon process? Does the user account will be the same  with the AD domain label difference ?

2. What happened to the user who is not logged off to the workstation, would they be able to log off and login as normal or their account / desktop will be broken ?

3. Do I have to manually exit the domain and then rejoin the new domain for the servers and the workstation ?

I need to know if the user will experience down time or anything that they need to be aware of the difference.

Note: There is no Exchange Server to worry about in this old domain.
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3

Assisted Solution

Scobber earned 400 total points
ID: 40596731
your computers should default to the domain they are joined to, however you can use domain2\username to force selection to the second domain. Also it is good practice to use the user principal name to login to workstations eg username@fqdn, additional upn's can be provisioned using AD Sites and services or AD domains and trusts

Author Comment

by:Senior IT System Engineer
ID: 40596772
ok, so in this case the user should not need to change their way of work with the new domain migration ?

what about the files of the users in the old file server when the old AD domain is decommissioned ?
LVL 37

Accepted Solution

Mahesh earned 1600 total points
ID: 40597048
I guess this is the continuation question to last question

To answer your questions:

1 When you migrate users, after migration I guess you need to select all migrated users in target domain, and go to there properties and change UPN to reflect to new domain UPN from account tab, because users will migrate there own UPN as well to new domain
For Ex: Source domain is contoso.com and user is user1 @contoso.com
after you migrate user to target.com, still it will show user1@contoso.com which you need to change to user1@target.com
From Vista onwards domain is not showing by default at logon, you need to type target\user 1st time which will get cached then for next logons
Migrated user will carry all attributes including SID History which is useful in maintaining co-existence such as accessing file server in source from parent

2 & 3: There no question of user logoff and logon, ADMT will migrate machine from source to target along with user profiles
What this will do, ADMT will push agent on workstation, translate user profiles, shares, registry permissions from source to corresponding target user and finally disjoin machine from source and join it to target domain and reboot the same.
Post reboot target user will get old profile as it is back, so practically end user will not see any difference except target\user during logon.
The process is same for workstations and servers

Domain migration use concept called SID History.
while migrating users and groups you will migrate there SID as SID History to target users and groups, more even due to this SID History, source accounts groups membership in source domain is also automatically get translated \ carry forwarded to target domain provide that groups are already migrated
After that you disable SID filtering and enable SID History over domain trust
As a fact during co-existence migrated users can access their data on old domain file servers via associated SID History, When target user tries to access his data in old domain, file server looks for his old domain SID as SID History and grant same access to target user as source user
Like I said in earlier post. please setup lab to test all scenarios, because its may not possible to explain each and every term with this communication media
U.S. Department of Agriculture and Acronis Access

With the new era of mobile computing, smartphones and tablets, wireless communications and cloud services, the USDA sought to take advantage of a mobilized workforce and the blurring lines between personal and corporate computing resources.


Author Comment

by:Senior IT System Engineer
ID: 40597336
Thakns Mahesh for the complete reply. I assumethat the reboot on the workstation can be scheduled or is it automatically rebooted at random ?

So in this case do I need to do anything on the file server to resume user access to their files after the server is installed with the ADMT agent and then disjointed and rejoined on the new domain ?
LVL 37

Expert Comment

ID: 40597683
No, you can't schedule reboot of workstations, after agent operation is finished, machine will be rebooted after predefined delay (minimum 1 Minute) to maximum 10 minutes I guess.
Post reboot machine will be part of target domain

Before migrating file server:
U should migrate all source groups with SID History
Then migrate all users with SID History and "Fix group membership option", this will ensure that target user will have same group membership as source
After that you will migrate all computer objects
After that you will migrate file server just like normal computer and you should be fine. Due to SID History file server access will be retained during co-existence
Post migration file server source domain ACL will either replaced \ merged with target domain ACL depending upon what options you choose

If you are migrating file server after all users and computers migration gets finished, you can migrate file server with replace mode
If you are migrating file server in between before completing all user and computer migration, you should migrate file server with Merge mode so that post file server migration remaining source users will retain there access to file server which is now part of target domain.

Author Comment

by:Senior IT System Engineer
ID: 40597689
Cool, many thank you mahesh for the detailed explanation, i trully appreciate your time to reply to my thread.
LVL 37

Expert Comment

ID: 40597692
Its my pleasure


Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
I was prompted to write this article after the recent World-Wide Ransomware outbreak. For years now, System Administrators around the world have used the excuse of "Waiting a Bit" before applying Security Patch Updates. This type of reasoning to me …
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…
Suggested Courses

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question