Solved

AD Domain Migration - Trust Relationships and Policy Inheritance

Posted on 2012-03-20
9
614 Views
Last Modified: 2012-03-31
Hi,

My company has decided in its infinite wisdom that we will migrate to a new AD domain, i.e. move from existingdomain.com to newdomain.com, 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 newdomain.com, 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 :-)
0
Comment
Question by:chudless69
  • 4
  • 3
  • 2
9 Comments
 
LVL 38

Expert Comment

by:Adam Brown
ID: 37743295
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.
0
 

Author Comment

by:chudless69
ID: 37743502
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.
0
 
LVL 38

Expert Comment

by:Adam Brown
ID: 37743546
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.
0
 

Author Comment

by:chudless69
ID: 37743570
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.
0
 
LVL 38

Expert Comment

by:Adam Brown
ID: 37743605
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.
0
 

Author Comment

by:chudless69
ID: 37743637
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) :-)
0
 

Assisted Solution

by:dennisgroup
dennisgroup earned 500 total points
ID: 37762062
chudless69,

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.
0
 

Author Comment

by:chudless69
ID: 37762272
Dennisgroup,

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.
0
 

Accepted Solution

by:
dennisgroup earned 500 total points
ID: 37762937
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.
0

Join & Write a Comment

Restoring deleted objects in Active Directory has been a standard feature in Active Directory for many years, yet some admins may not know what is available.
Is your Office 365 signature not working the way you want it to? Are signature updates taking up too much of your time? Let's run through the most common problems that an IT administrator can encounter when dealing with Office 365 email signatures.
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

762 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

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now