• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 358
  • Last Modified:

Domain name change due to organizational changes

I was wondering what type of task I have at hand.  I currently run on a single domain environment.  Our organization has changed its name and execs are asking for the domain name to also change.  Does anyone know of a good place for information to possibly running 2 domains side by side to assist in migrating people from tha old domain to the new?  And then I would like to sever the old domain completely and go back to a single domain.

Any help would be greatly appreciated!!!
0
MedProIS
Asked:
MedProIS
1 Solution
 
Donald StewartNetwork AdministratorCommented:
This should help you

Windows 2003 Domain Rename
0
 
Chris DentPowerShell DeveloperCommented:

If you're sticking with moving to a new domain the Active Directory Migration Tool is the most common option.

You'll find the tool here:

http://www.microsoft.com/downloads/details.aspx?familyid=6f86937b-533a-466d-a8e8-aff85ad3d212&displaylang=en

And the guide here:

http://www.microsoft.com/downloads/details.aspx?familyid=6D710919-1BA5-41CA-B2F3-C11BCB4857AF&displaylang=en

Whether you go for this, or dstewartjr's suggestion, make sure you give yourself ample time for testing.

Chris
0
 
MedProISAuthor Commented:
What happens to the end-users?  Am I going to have to script every PC to rejoin the new domain once I change it?  Will the servers automatically join the new one or will I have join them to?
0
Independent Software Vendors: 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!

 
jakethecatukCommented:
Not to difficult a task to complete.

Use this time to update your AD to the lastest version if you can (2008 R2 etc).
Create your new AD with new DNS.  Once created and running correctly, set up a trust relationship between the two domains.
Create new user accounts in your new domain to match your existing user accounts.
As you migrate your desktops over to your new domain, get your users to login using their new credentials created above.

Now for the fun bit - what applications are you running on your old domain?  If it's fileservices, you will need to give access to the server for your new domain users.  Exchange - you will need to add the new domain user to the account.  SQL - same sort of thing.

Once all the users and desktops have been migrated, start to plan the move of the servers.  Exchange will need to be a new install and then moving mailboxes.  SQL and fileserver, remove from old domain and add to the new domain.  Check permissions afterwards (there is a lot more to the server moves than this, but this will give you an idea of the steps involved).
0
 
Chris DentPowerShell DeveloperCommented:

For domain rename, you must reboot the systems towards the end, but otherwise no changes are required (obviously you should fully review the documentation for that).

In the case of ADMT, you can have it take care of shifting clients and servers between domains (except systems like Exchange and other Domain Controllers). ADMT will also rewrite security to an extent, reducing any client over-head in a migration.

Do you need to deal with Exchange or do you have any other complications?

Chris
0
 
MedProISAuthor Commented:
I will be dealing with an exchange 2010 server along with 2 sql servers.  Both are 2005.  I have 2 - 2008 AD servers and 1 - 2003 AD server.  Should I have all my servers upgraded to server 2008 before I do this also?
0
 
Chris DentPowerShell DeveloperCommented:

Hmm Exchange 2010 rules out Domain Rename (same applies for Exchange 2007). Or is that not in place yet?

Don't bother upgrading Domain Controllers if you go for a migration, I strongly urge you to rebuild those prior to making them DCs for the new domain. Obviously not all at once :)

SQL "should" be fine with the move, but it's something you'll need to test carefully.

Personally I'd go for the Migration, it allows you to progress at your own pace, testing things as you move along. But then, I've migrated thousands of users where I've only done a very small number of domain rename operations :)

The process is roughly:

1. Configure a new Domain in a new Forest
2. Configure Name Resolution (DNS) so all systems in each Forest can resolve names in the other
3. Create a Trust between each domain
4. Prepare the new Forest for Exchange. You'll need an Exchange server here as well.
5. Configure and test mail routing between the two domains. Forwarding on a per-account basis works. Will both domains be running Exchange 2010?
6. Configure ADMT (Disable SID Filtering on the Trust, configure Password Migration, etc)
7. Test migration of groups to the new domain (source can remain intact, doesn't commit you to changing over)
8. Test migration of a user account to the new domain (source can remain intact, doesn't commit you to changing over)
9. Test migration of a computer account (domain membership will be changed, so you're committed as far as that system is concerned)
10. Test migration of mailbox data. Depending on source and destination systems. See this for Exchange 2010: http://technet.microsoft.com/en-us/library/bb124797.aspx

That's it, the final stage is to shift everyone else over based on the results of your testing. It is possible to run these side-by-side for an extended period, it just depends on how happy you are working with all of this.

Chris
0
 
snusgubbenCommented:
Exchange 2010 do not support a domain rename using rendom.exe, so ADMT is your pick. Chris-Dent provided you the documentation you need to preform this task.
0
 
MedProISAuthor Commented:
ACtually we are running a 2003 Exchange box but I have spent the last week getting it ready for a mailbox migration this weekend.  It is on the old domain right now but has no mailboxes on it.  Should I hold off on that?  Should I use that on the new/second domain?
0
 
Chris DentPowerShell DeveloperCommented:

You could use Domain Rename if you have Exchange 2003 in your forest. It's only 2007 and 2010 that exclude Domain Rename.

If you have already run adprep for Exchange 2007 / 2010 it may well be too late to go back on that. I suspect you'd have to remove the Exchange organisation entirely, I bet that wouldn't be a popular move.

Otherwise, building it as a temporary (or permanent) Exchange server for the new domain would be beneficial. Exchange servers cannot be simply moved between forests, so you'll have to put up with a fair amount of rebuild work there.

Chris
0
 
MedProISAuthor Commented:
So if I already extended and prepped AD for my exchange 2010 server then I have no options?  Is it to late to rip out and place in the new domain?
0
 
Chris DentPowerShell DeveloperCommented:

Correct, the configuration changes that make it incompatible with Domain Rename have (as far as I'm aware) already been made (as part of the prepped part, the schema extensions shouldn't effect this).

You would have to remove the entire Exchange Organisation (2003 and all) to get back to a state where you can use it.

Chris
0
 
MedProISAuthor Commented:
Since my 2010 box is not in production yet can I rip that out, wipe it, and then use it for my second domain?  Then can I use ADMT for my other servers and clients?  Excluding the excahnge2003 and maybe an AD box that is.
0
 
Chris DentPowerShell DeveloperCommented:

Sure, that sounds like a fine idea :)

What will be the first DC for your new Forest? If you'd planned to use the Exchange box for that do remember that you won't be able (well, it's not supported) to promote / demote it once Exchange is installed.

Chris
0
 
MedProISAuthor Commented:
I have another new server that can be my "New" 2008 AD box.  Trust the domains together.  Then I will extend and prep that domain for the 2010 exchange box.  With the 2 exchagne boxes on separate domains will they still be able to connect with each other?  How would mailbox migration go with them being on separate domains?
0
 
Chris DentPowerShell DeveloperCommented:

> With the 2 exchagne boxes on separate domains will they still be able to connect with each other?  

They'll be able to connect as SMTP servers, but they're different directories (AD databases) so won't share configuration or address books.

The TechNet bit I popped in way up there has details of how Move-Mailbox might be used to get mailboxes between the forests.

http://technet.microsoft.com/en-us/library/bb124797.aspx

I guess this may be the most appropriate for you if the source is going to be Exchange 2003?

http://technet.microsoft.com/en-us/library/dd876952.aspx

You still have to tackle mail routing, how much of that you need to do depends on how fast you want to do the mail switch-over. Faster is simpler, but introduces greater risk because of more work at once. How many users / mailboxes do you have to deal with?

Chris
0
 
MedProISAuthor Commented:
I have about 500 mailboxes and I have about an 80gb .priv/.edb.  I think with the small number that I have I could do this over a long weekend.  Faster would be easier.  I heard that the max transfer rate between exchange servers is on average a little over 4gb per hour?
0
 
Chris DentPowerShell DeveloperCommented:

Something like that, yes. That seems pretty reasonable, especially if you've already dealt with shifting users and computers. You can give users from the new domain rights for mailboxes in the old (and vice versa). Decoupling the two tasks can help a lot.

Just make sure you take the Monday off as Holiday ;)

Chris
0
 
MedProISAuthor Commented:
Thanks so much for all of your input.  You have been EXTREMELY helpful in planning this organizational change.  Best Regards!!
0
 
Chris DentPowerShell DeveloperCommented:

You're welcome, best of luck getting through it :)

Chris
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Tackle projects and never again get stuck behind a technical roadblock.
Join Now