The problem is that there is almost nothing more variable than the business environment and its needs. For example an organization restructuring may mean renaming some sub domains and/or changing their hierarchy, while a change of the company name will defiantly force a domain name change (a frightening prospect for many Windows administrators).
I was put in such a situation where a company that I am working with as an IT consultant had grown from a small design company of 20 employees with the name of Untilled Studios to became a successful group of companies employing 150+ person with the name of Think Arabia. For a while I ignored the problem but their needs have also developed and they started to need an internal SharePoint site with the name of the new organization and sub-sites for the different companies. It became obvious that a domain rename was needed.
I found that the procedure is very simple and can be easily done. Although there is nothing terrifying about it, I strongly suggest that you do as I did and try it in a test environment. I’ve installed the following virtual machines:
Two Domain controllers (DC0 and DC1): One domain controller can do, but I wanted to match the production environment as closely as I can.
One member server and/or one member workstation: Actually I created two of each to see the effect on member machines that were powered off during the procedure and member machines that were powered on. However, it turned out that all four machines I created acted in the same exact way regardless of whether they were on or off while I was renaming the domain
And the key to the procedure is one domain member machine that is not a domain controller to perform almost all steps from. This can be a Windows 7 machine with Remote Server Administration Tool (RSAT) installed, but I prefer to use Windows 2008 R2 server since the rendom utility gets installed automatically as part of “Active Directory Domain Services” role. But make sure not to promote the machine to a domain controller as this machine should not be a domain controller.
Step 0: Create a new DNS zone with the new domain. As new records will start being created in that zone as soon as we perform the rename.
Step 1: From the Control Station run the rendom /list command.
An xml file will be created that lists the current domain information, namely ForestDNSZones, DomainDNSZones and NetBios name.
Step 2: Edit this file to replace all mention of the old domain with the new domain name. In this case I’ve replaced all occurrences of untitled.local with thinkarabia.net and all occurrences UNTITLED with THINKARABIA.
You can verify the new configuration using the rendom /showforest command:
Step 3: Now that we feel more confident, it is time to upload the modified xml to our domain controllers using the command rendom /upload.
Step 4: Is to verify the radiance of the domain controllers using Run rendom /prepare.
Here is where I 1st faced an unexpected issue. In my first attempt, both of my test domain controllers were not prepared, but worked fine after turning off the Windows firewall. When I repeated the procedure, only one of the domain controllers gave an error while the other did not have any issues although the firewall was on. When I did it in production I turned the firewall off on all DC just in case, and it went fine on the first attempt.
Step 5: The grand moment has come when you do the transfer rendom /execute.
All your domain controllers will start to reboot at the same time!!!
Step 6: In order to continue you need to make your control server (the one we have been working with so far) aware of the domain name change. For that you will need to reboot it twice. Otherwise it will continue to use credentials from the old domain and will no longer be able perform changes on the new domain. By the way, all member servers and workstations will need to be rebooted twice to reflect the change, but not yet
Normally at first, all your machines will suggest logging in using the old domain name. No need for alarm, it is just remembering what user name you’ve used last time you have logged in. You simply need to switch user and login with the new domain name.
Step 7: Reflecting the domain name change on your Group Polices.
Group polices still reference the old domain names, and hence we need to fix it.
This is easily performed using the following two commands:
gpfixup /olddns: untitled.local /newdns:thinkarabia.ent
gpfixup /oldnb:UNTITLED /newnb:THINKARABIA
Step 8: Renaming the domain controllers themselves.
Unfortunately they do not get automatically renamed by rebooting twice; you will need to do it using the following commands:
netdom computername dc0.untitled.local /add:dc0.thinkarabia.net
netdom computername dc0.untitled.local /makeprimary:dc0.thinkarabia.net
Restart the domain controller, and repeat for the other domain controller.
Step 9: There is nothing else left to do on the control server except clean up using rendom /clean
And now you have a new name for your domain controller. But you need to reboot all your member machines twice for the change to take effect on all of them. It is a good idea to schedule the reboot before performing the procedure so that it happens automatically afterwards.
Note that this same procedure can be used to change the hierarchy of your sub domain in the forest. For example the sub domain it.servies.rj.com can be renamed to it.rj.com to reflect an organization restructuring.
This info was taken directly from here
No comments:
Post a Comment