Passwords, ok but what is the use case on SIDs? When you migrate data, is it unmanged and messy, you cant programmatically fix it/repoint it?
There are even ways around that, SetACL can migrate sids and you can even do it programmatically yourself if you have to. jlc From: [email protected] [mailto:[email protected]] On Behalf Of Jeremiah Rumball Sent: Monday, March 30, 2015 7:29 PM To: [email protected] Subject: [NTSysADM] ADMT and a Copied DC Hi all, I'm reviewing a possible solution to a problem we are facing and would like to get some of your input. We have a client, I'll refer to them as the "source," that we will be migrating to our "destination." The source is a child of a parent company, though from an AD standpoint it was not setup this way. The same, single domain for both parent and child employees. The domain belongs to the parent. The current issue is how to migrate just the child company AD objects to the AD destination we've built. They will be moving to a new forest but would like to maintain SIDs, passwords, etc. for all AD user accounts/groups. The first solution that came up was ADMT via a trust to the source domain. However, the parent company will not allow this. Option 2 is to get a copy of a DC from the source (VM), spool it up in the destination environment and then implement the trust/ADMT process "locally". I've got some concern about this process but would love to get some feedback from anyone who has ever run into this (or something similar) before. Thanks! Jeremiah
