While this might seem obvious to a seasoned professional, I found myself walking through the process with a couple of clients the other day. I would like to make a couple of assumptions, first. One, there is a domain controller online and others in the network are able to log onto the domain. Two, the user’s physical network from the wall jack to the rest of the network is functional. Three, they have access to a local computer account so they can at least log in using a local account and troubleshoot.
To summarize, I asked them to identify what are some possible issues that might cause the process to fail, and then added my own:
- Not on the network – yes, check the link light, make sure the network adapter is plugged in, check to make sure the wireless adapter (if using wireless) is properly configured. If we don’t have a link light, then either we have a back network cable from the computer to the wall, or we might not have the proper drivers installed on the computer for the network adapter. We can usually verify the drivers by checking Device Manager and seeing if it is recognizing the network adapter, and we can also check by taking the computer to a known good cable and network location to see if we can get a link light there.
- Not configured with a proper TCP/IP address – this is a pretty common one, so how do we check the IP address on the computer? Easy, we open a command prompt and run ipconfig to see the IP address, subnet mask, and default gateway address. In most cases, when the computer is not configured with a static address and does not receive a DHCP provided address, then we will get a 169.254.x.x address. If we are not getting a DHCP address, it is usually because either the DHCP server is down, out of addresses, or we are not connecting to the same network. One way to test problems with the DHCP server is to simply eliminate it from the equation by using a static address instead.
- DNS is not configured properly – this should only be a problem when configuring static addressing. If it is a DHCP provided address and the DNS is wrong, then we should be seeing problems with a large number of computers. So, again, back to ipconfig. If we run ipconfig /all, it will tell us how we have DNS configured. We can verify the DNS address by checking the DNS settings on other computers to make sure that they are the same. We can also test DNS by simply using ping to ping a domain controller (or two or more) by name and seeing if it resolves properly and is able to receive responses. If DNS does not resolve, we should take the next step and make sure that we can get there by pinging the TCP/IP address of the domain controller. It will do no good for us if we can’t get there at all.
- Not able to resolve to find a domain controller – we use SRV records to find our domain controllers. We can check to make sure the domain controllers are listed in DNS. If they are not listed, as in the below snapshots, then we can go to our domain controllers and run net stop netlogon and then run net start netlogon. This process will cause the domain controller to dynamically update its information in DNS.
- Windows Firewall settings not allowing connections – this is a strange, but possible issue with Windows Firewall, at least when it comes to our troubleshooting steps. Windows Firewall often will block ICMP packets, which are used by ping. So, when we ping a server from a client computer, or a client computer from a server, it is possible that we won’t get a response even though both of them are up and running. Sometimes, it makes sense to disable the Windows Firewall when troubleshooting to make sure it is not the cause of the problem.
- Not able to see shares on the domain controller – we can easily test the ability to access the SYSVOL share, for example, by running net view \domaincontrollername from a client computer.
The solution to many problems may simply be to join the client computer to a workgroup and then to re-join it to the domain. So, we would click on the Workgroup radio button, then enter a name and click OK. We would then have to restart the computer. Once back into the computer again, we would go back in and click on the Domain radio button, put in the domain name, fill in the security information and join the domain again after another restart. So, two reboots, and you should be OK.
We can simply go into this screen, delete the .com part of the domain name, click OK, enter the credentials, and restart the computer just once.
Client computers reset their computer password with the domain every 30 days. The client computer drives this. Even if the client computer is offline for more than 30 days, it will still be able to connect to the domain and then initiate the computer password change. There is a bit of a fallacy in the industry where people believe that the password reset is driven by the domain controllers and that if the passwords are reset when the computer is offline, then the computer will not be able to connect to the domain and update its password. It doesn’t work that way. It is all client driven. If over 30 days have passed, the client will connect and reset its password with the domain when it is back on the network. It doesn’t matter if it has been longer than 30 days, it will still reset with the domain when it connects to the network.