AD Domain Migration - Trust Relationships and Policy Inheritance
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 :-)
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 :-)
ASKER
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.
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.
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.
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.
ASKER
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.
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.
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.
ASKER
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) :-)
Any other comments and input are most welcome (and hoped for) :-)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.