I believe we learn as much from our mistakes as we do from our conscious learning efforts, if not more. We sometimes end up learning a lot more in the process that ensues to right our wrongs and mistakes. This post is about one of those times.
When I initially configured the domain in my network I chose emeneye.co.uk as the domain name. I say “chose” but I didn’t really give it much thought at the time, which turned into a learning opportunity for me as I went about renaming the domain name.
To provide brief background information, the Active Directory domain in my Lab is part of a broader hands-on learning project which includes improving my working knowledge of Active Directory and Windows server administration. When it came to designing the OU structure I thought it best to use an educational setting as the domain environment to guide my design decisions. My IT support experience has largely been in an educational environment so I thought it best to stick to what I know best. With that in mind, the .co.uk in the domain name didn’t seem suitable. So the task at hand was to change the name to emeneye.ac.uk.
My goal was to:
- Rename the domain as emeneye.ac.uk
- Ensure the DHCP and DNS servers are working as intended
- Make sure the MDT 2012 deployment environment on the server was working as intended, i.e. able to deploy the custom images to my Windows client PC’s
- Make sure client computers are able to join the domain and users are able to log onto the domain
The first thing I done was to take a snapshot of the virtual machine so I had something to fall back on if things didn’t work out.
The OU structure in the domain wasn’t really complex so it wasn’t critical to preserve it but I was curious to explore my options for retaining it.
I thought there must be a way to export the whole OU structure and, sure enough, a quick search on Google came up with LDIFDE. This is the run command I used:
ldifde -f c:\ExportOU.ldf -s winserverdc.emeneye.co.uk -d "dc=emeneye,dc=co,dc=uk" -p subtree -r "(objectcategory=organizationalUnit)" -l "cn,objectclass,ou"
The command produced the following.LDF file
With the .LDF file backed up safely I proceeded to demoting the domain controller using dcpromo.
I chose “Delete the domain because this server is the last domain controller in the domain” on the dcpromo wizard, which I knew would destroy the domain altogether.
I also deleted all application directory partitions and also deleted the DNS delegations pointing to the server. I figured it would be best to install the DNS server again when I promote the server to a domain controller later on.
Next was to remove the Active Directory Domain Services role, followed by removing the DNS server role
I quickly checked the IP settings on the server before reinstalling the Active Directory Domain Services role. I found the DNS server address was missing with only the broadband router’s IP address left. I want the DNS server to be installed on the same server as the one being promoted to a domain controller so I entered the IP address of the server in the DNS server field.
I ran dcpromo but this time to promote the server to a domain controller once again and it was at this point I entered the new domain name emeneye.ac.uk. The wizard also installed the DNS server role as per our requirement.
I forgot to take a screenshot when entering the new domain name so here’s one of the Active Directory Users and Computers console which shows the new domain
With the domain set up I had a quick look at the Server Manager where I had to authorize the DHCP server. I also double checked the DHCP scope and settings to make sure client computers receive the right default gateway and DNS server addresses. I had to manually add the DNS server address to the scope options as shown below:
The DHCP server started servicing clients soon after restarting the service.
I also had to start the Windows Deployment Services from within Server Manager.
I then turned my attention to the Deployment Workbench and found the Deployment Share was nowhere to be seen. All i needed to do was to open it again from within Deployment Wokbench by right-clicking on Deployment Shares, selecting Open Deployment Share and browsing to where the share was located on the hard drive. This operation completed successfully as shown below:
I then Edited the customsettings.ini file associated with the Deployment Share to reflect the new domain name. Without this, of course, joining client computers to the domain as part of the deployment process would fail.
Lastly I proceeded to restore the OU structure using LDIFDE to import the OU structure using the .LDF file created earlier on. I had to make some modifications to the .LDF file as detailed below before running the import command.
- Open .LDF file using Notepad
- Delete the first five lines pertaining to the Domain OU
- Replace all occurrences of the old domain name with the new domain name
This is the command I used to import the OU structure
ldifde -i -f "C:\ExportOU.ldf" -s winserverdc
Thankfully the import was successful. Here’s a before and after screenshot of the Active Directory Users and Computers console:
I’m too tired to go into detail on how I tested the new domain to make sure everything was working. And with that I conclude my post.