Objective – Domain Name Change from .com to .local
A domain contains a group of computers that can be accessed and administered with a common set of rules. For example, a company may require all local computers to be networked within the same domain so that each computer can be seen from other computers within the domain or located from a central server. Domains give the administrator a single point of control for all computers and user on their network.
Great care and thought should be put into naming your domain. There are certain mechanics within a network that may cause problems with certain naming conventions. For example, the choice to name your domain with a .com, .edu, .net, or .local can play a pivotal role in how websites are displayed, the time it takes to load or even the ability to share resources inside of your network.
Our case study is looking at a .com private internal, non-internet routed network. a “non-internet” routed network simply means the domain server is not servicing internet requests for information based on the domain name. Domain names are the backbone of the internet. DNS or Domain Name Server/Service is the mechanism in which we, people, understand and navigate the internet. There are public servers that keep track of IP addresses and their associated domain names. For Example www.google.com resolves to an IP address of 184.108.40.206 as its web address. Google also has public DNS server (the servers that keep track of names and addresses) at 220.127.116.11 and 18.104.22.168. If your computer doesn't have this information, the only way you could traverse the internet is if you knew the IP address of your intended site.
In most cases small to medium business do not host their own webservers and as such do not need to route web traffic to and from their office. Most publicly accessible web pages end in a .com, .net, .edu, .org, .gov and there are others. The problem being, if you choose one of these suffix’s for your business internal domain you may have problems resolving internet addresses VS internal addresses. The reason being is that in a domain, you have a DNS server keeping track of names to IP addresses. If your server’s name is LightingSVR, your domain is Lightingcorp and your suffix is .com the actual computer name known to DNS is lightningSVR.lightingcorp.com. There is nothing wrong with this it will work just fine. The issue becomes when you have a website for your business that is www.lightingcorp.com.
From inside your network the first place your computer will go is to its local DNS server and will attempt to connect to that server to find its web page. Now if that server has Web Services turned on your will end up getting the webpage to that server. If it doesn’t then you must wait for a timeout before DNS realizes that no such place exists and goes out to the internet to find the page requested.
In this example, if our internal domain suffix was a .local AND we were hosting an internal website the address would be lightingcorp.local. Which would only be accessible form inside of the network. However, the ability to have a lightingcorp.com webpage address hosted outside of the network would be fine and no issues would be found.
Potential problems could be, exceedingly long load times for external webpages with the same name, internal network resources not working properly or at all, or even a complete lack of network connectivity in your local network.
“ With proper expectation, a road map and a complete understanding of process we were able to minimize down time and minimize revenue loss. ”
The idea of changing a domain name can be quite a daunting task. We are talking about recreating the entire system you have been using. New PC names, new profiles, new share names, computer reboots, down time and possibly, issues. Thankfully, the need to change a domain name was not ignored by Microsoft. They have included a tool to do just this. Its not a one and done thing, it will take time, but it simplifies the process.
Before beginning the procedure it’s important to set the proper expectations, have a road map, and fully understand the procedure. Expectations for a Domain re-name looked quite daunting for any business owner. The road map helps to give clear and simple understanding of the work going to be performed. Understanding the procedure give the technician and the client confidence in what work is going to happen.
Down time – Renaming a domain is not just changing out a suffix, its basically creating and entirely new network. Each PC will need to be changed, rebooted multiple times and loss of network resources until the name change is complete.
No network Resources – everything runs on DNS on names. Changing your domain suffix will break all of your shares, Group Policy objects will need to be reconfigured, and possibly even some database system that rely on FQDN could cease to function
Having a well thought out plan of action or road map is a key to success in any endeavor. Where do you start? Why? When will you finish? In what order should I go? Are all good questions when planning the work. Thankfully, there is an established plan for a domain rename. Step one is to rename your DNS (domain) servers. Step two is to get your network resources back up, renaming/re-joining the server to the domain. Step three is to rename/re-join your workstations to the domain. Lastly clean up GP for any global shares/resources.
Understanding of the procedure
What are we doing? What aspects of system is this impacting? What services and roles are affected by this? Both the technician and the client should be on the same page. While the technical person may not fully understand the difference between GP, DNS and DHCP, just the ability for both parties to communicate gives the project confidence that it will be completed with minimal issues.
This project went off flawlessly. Which I assure you is not the norm. As per the expectations, no user needed network resources, no users were even onsite. This gave us unfettered access to the network, servers, and PC’s. Reboots happened when they needed to. Network resources were offline for as long as was needed. Everything went very smooth.
The project started with Renaming our DNS servers. With no user needing to log on, reboots happened in a timely fashion. This initial step is usually where problems happen. If expectations are not clear users can be impacted as their ability to log on to the domain is lost. Making sure you have local administrator logons is key for the next step of getting network resources back up and running.
Getting the servers and resources back key to having the network running. Again, expectation play a key role. With the expectation that no resources would be available, renames and reboots were able to be done as needed. In fact, several are needed for this procedure. Each of the servers took their new names, updated their files, and joined the new domain without issue. Once the resource system is in place moving to the workstations is next.
Workstations are the most time-consuming part of this operation. With the expectation set, and no users onsite, each station was able to be renamed and rebooted without interfering with operations. Each workstation required two reboots to be renamed to the new domain.
This project of domain renaming can be costly for a company. Lost time, lost revenue are real considerations when doing major system work. With proper expectation, a road map and a complete understanding of process we were able to minimize down time and minimize revenue loss. The project was completed a full day earlier than expected.
Some projects are easy, others can be difficult. Expect the unexpected and be flexible. The problems encountered were nothing we could have anticipated. Some projects are smooth and others you learn a lot.