AD Domain Migration - Trust Relationships and Policy Inheritance


My company has decided in its infinite wisdom that we will migrate to a new AD domain, i.e. move from to, to put us in line with our re-named email domain from an old company to the new owners which is already live.

Ordinarily I would not have an issue in doing this but they have said they want a completely new domain as the existing one is considered 'dirty', problematic and full of multiple historical issues.

It would have been simply establishing a trust and migrating all the boxes which I've done before. However with this scenario, I am to avoid at all costs the 'cross polination' of any existing errors from the old to new domain which is now giving me a headache.

My main question is this:

If I create a new domain, called, build the DCs, File & Print, etc etc, establish the new DCs as FSMO holders, create group policy and so on, but then establish a trust relationship between the 2 domains, would the new domain inherit any of the hidden AD issues or is the trust relationship simply 'what is says on the tin'?

By that I mean it will readily allow me to migrate users, groups, files & permissions, apps and even Exchange without inheriting the issues as effectively it's a different domain with different AD installation and policy?

I also assume that it would make life easier for the email server move (Exchange 2010)?

Sorry, almost forgot - both domains are 2008.

Hope that makes sense, please ask for clarification if it does not.

Thanks in advance :-)
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Adam BrownSr Solutions ArchitectCommented:
Usually a migration won't cause the problems of the old domain to come into the new domain. Cross Forest replication isn't really as intense as Intra-domain replication, so most of the faulty AD stuff in the old domain wouldn't be migrated. However, you should know that if the old domain is actually corrupt or unhealthy, you're going to run into a number of significant problems migrating things over. Depending on the level of corruption or issues that exist in the old domain, you might not even be able to build a trust between forests.

That said, if you use ADMT to migrate between forests, you'll have a lot of extra information written to the new forest. It'll allow you to keep all your existing file permissions and whatnot, but it will cause some stuff from the old domain to remain in the new one indefinitely. In particular, this relates to SID Translation required during user migration.

Exchange migration between forests is not difficult without a trust in place, as you can export all mailboxes from the old domain and import them to the new domain with relative ease using Powershell (The command to do so is about 2-3 lines long). This only requires a few more steps than moving the mailboxes around with a trust in place. The most difficult part of the process is getting workstations set up with Outlook and the Exchange management tools to get it done with.
chudless69Author Commented:
So, as I don't have issues with users, groups, SIDS, etc (it's more a fact of occasional unexplainable 'goings on' from the legacy install and lifespan of the AD, and multiple people tweaking and playing along the way) then I am unlikely to inherit issues? When you say that the ADMT has extra info written to the forest that is primarily security based, not things such as group policy, deep settings and so?

With Exchange, I am not looking forward to that....primarily because of the Outlook configs. What do you mean by 'and the Exchagne management tools to get it done with'?

Would you recommend going with the trust on the 2 domains, or have the new domain kept separate from the old one? That does bring additional work and headaches such as the File Server scenario but I guess the ADMT would solve that (or maybe a tool such as Robocopy?). Removing from the old domain and adding to the new domain is simple enough, as long as it doesn't have a shed load of legacy problems that can be passed to the new domain I guess.
Adam BrownSr Solutions ArchitectCommented:
You're probably better off doing what your superiors want unless you can fully explain to them the situation, so do a lot of research on ADMT and let them know how it works, also to make sure it only does what you want it to. I haven't actually used it in a Migration before, so I can't give you all the details you'll need on that.

As for the Exchange Management tools thing, Exchange 2010 allows you to export mailboxes to a PST file and import them from a PST using powershell. However, this requires the use of a client machine that has Outlook 2010 64bit installed on it and the Exchange Management Console and Shell installed. The actual process is very easy, you just need to use an account that has the appropriate permissions to do so.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

chudless69Author Commented:
Oh I see, didn't realise what you meant - we just done that on the Exchange as we changed our mail domain and had to do it exactly as you stated.

On the bad domain part, understood but the superiors don't understand per se so I'm just seeking information so I can present them with the actual way we shall do it....I'm simply wary of inheriting existing issues.
Adam BrownSr Solutions ArchitectCommented:
Yeah. Having to deal with the boss who tells you to do something that isn't feasible or realistic is something we all have to do at some point. Best thing to do is research as much as possible and do your best to explain what the advantages and disadvantages of their plan are before presenting an alternative.
chudless69Author Commented:
Thanks for the advice. This is part of the research, seeking feedback from the experts on potential issues with the trust domain angle.

Any other comments and input are most welcome (and hoped for) :-)

I know exactly where you're coming from with this as I've been thru it myself.  A year and a half ago I did a cross-forest migration from a 2-domain forest to a single domain forest.  The original forest (forest A) was completely messed up due to some work that had been done prior to my inheriting the network.  The new forest (forest B) was my creation and was built correctly from the ground up.  I too had concerns of corruption or other issues following the setup as I migrated to the new forest/domain, but in the end, all the parts that were messed up were left behind with forest A and never touched the structure and hierarchies I created on forest B.  I did have permission issues while the trusts between the two forests were in place, but once the migrations were complete and the trusts severed, all problems simply disappeared.  I did have an additional challenge of having to maintain a shared e-mail domain during the migration which had its own complications since this was all done simultaneously, but I was able to get it to work properly and the actually process of the migrations were quite smooth.

I was able to get the migration done with nothing other than ADMT.  Due to my situation with Exchange (Exchange 2003 to Exchange 2007 with a shared e-mail domain), I did not use EXMERGE during the process, I simply used ADMT to migrate the users and the mailboxes from forest A to forest B.

One thing to be sure of is that your new domain has a solid and properly configured AD.  Utilize OUs and make sure your groups are setup properly for applying permissions and security settings.  If you've only got a single domain on the target side of the migration, you won't need any Universal groups (you will need some during the migration though in order to have permissions between the forests), just Domain Local and Global groups.  Make sure you label things clearly on the new domain and throughout AD and you shouldn't have any trouble later on.

The best thing about building a new domain when you know what you're doing is that you know it has been done correctly because you were the one to configure it.  You also have all the documentation since you have been creating it as you go (or at least you should be) instead of inheriting a mess of a system from someone else.

Hope this helps you out.  Let me know if you have any questions or if there's any other information you're looking for on this.
chudless69Author Commented:

Many thanks for that response. The migration route via a trust with my new domain is the path I'm looking at favorably, mainly as it is the 'easier' route.

What permission issues did you have between the 2 forests?

I have an Exchange 2010 environment so with the Trust I can can simply add the minimum Exchange CAS server on the new domain and do a remote move on the mailboxes which is so much easier.

I agree totally about building the new domain; if you are to manage it for the considerable future it does make it a damn site easier if you know where you stand from scratch.
I don't recall the specific permission issues I faced considering this was all done a year and a half ago, but the overall issue was due to the fact that I was migrating my users from a child domain in forest A to a single domain in forest B.  The child domain had previously been the parent domain.  The parent-child domain status had gotten reversed prior to my inheriting the system due to an improperly conducted replacement of the previous child domain.  (If it sounds messy, that's because it was)  I actually ended up exporting a list of all the groups and OUs from AD on the old domain and literally went thru them with a red pen to clarify what was actually needed on the new domain and restructured my entire AD setup on paper before actually building it on the new domain.

Our Exchange 2007 server on the new domain is a single server and holds all roles for the Exchange environment (sounds similar to your Exchange 2010 setup).  I think what I did was a remote move of the mailboxes as you mentioned.  I ended up using command line in the Exchange Power Shell to move the mailboxes.  I actually created an entire spreadsheet with the proper command line information for each user prior to the migration so I could simply copy and paste each time I was migrating a user and thus avoided any typos during the process.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.