Troubleshooting a DHCP Server

If you use DHCP servers to automatically configure the TCP/IP settings for workstations in your organization, a DHCP failure can lead to a major disruption in service. After all, if a workstation is not able to acquire an IP address, then it will have no way of accessing any of the resources on your private network or on the Internet. In this article, I will discuss some techniques that you can use to troubleshoot DHCP server failures.

Inappropriate Address Assignment

One very common DHCP related issue is the assignment of an unexpected IP address. For example, suppose that your DHCP server was configured with an IP address scope of 192.168.0.1 to 192.1680.50. You would expect network hosts to be assigned IP addresses in this range. Now, suppose that a workstation on your network appeared to be having problems communicating with network servers. You issue an IPCONFIG /ALL command to view the workstation’s IP address configuration. Instead of the expected address range, the workstation has been assigned an address beginning with 169.254.

So what happened? If a host on your network is unexpectedly assigned an address beginning with 169.254, you can rest assured that the address was not assigned by your DHCP server. What actually has happened, is that the workstation has failed to contact a DHCP server. When this occurs, the workstation will assign itself an IP address using a Windows feature known as Automatic Private IP Addressing (APIPA).

Microsoft built Automatic Private IP Addressing into Windows as a way of helping those who have very small networks. For example, if you were to create a small Windows network, you would not have to manually configure IP addresses even if there were no DHCP server on the network. APIPA would automatically assign a unique class B IP address to each machine on the network. This is great for small home networks but completely inappropriate for larger networks.

If a workstation resorts to using an APIPA assigned address, it is because its requests for an IP address have gone unanswered. There are several possible causes for this problem. Assuming that the other computers on the network are able to acquire an IP address from your DHCP server, you can rule out the DHCP server as the cause of the problem.

More than likely, the issue is related to the networking hardware installed in the workstation that is having the problem. For example, the Network Interface Card might be assigned an incorrect driver. Another possible cause of the problem is that the patch cable is not plugged into the Network Interface Card, or is not connected to a switch on the other end.

Of course, just because only one computer on the network is having trouble obtaining an IP address doesn’t completely rule out the server as the cause of the problem. If other workstations are successfully obtaining IP addresses, then you can be sure that the server is working properly. However, it could be that the server has run out of IP addresses that it can assign to clients. You can easily tell if this is the problem by comparing the size of the DHCP address scope to the number of devices on your network that request IP addresses from the DHCP server.

Common DHCP Server Problems

If multiple workstations are experiencing problems with leasing IP addresses, then the problem is most likely related to the DHCP server itself. If you suspect that the DHCP server is the cause of the problem, then you might start off by doing some ping tests to verify that the DHCP server is able to communicate across the network.

If the DHCP server is able to communicate with other computers on the network, then I recommend verifying that the DHCP server has an IP address that is compatible with the scope that the server is configured to assign addresses from. For example, if the DHCP server’s scope consists of addresses from 192.168.0.1 to 192.168.0.50, then the server will not actually be able to assign those addresses unless the server itself has been assigned a static address in the same subnet range, such as 192.168.0.0 or 192.168.0.51.

 If this still doesn’t solve the problem, then I recommend checking the basics. For example, you should make sure that the DHCP server is still authorized by the Active Directory to lease IP addresses. You should also check to verify that the scope is active, and that the necessary services are running on the DHCP server.

IP Address Conflicts

Another problem that I have seen on occasions involves IP address conflicts among dynamically configured addresses. When you create a DHCP scope, it is the DHCP server’s responsibility to make sure that addresses within the scope are only leased to one client at a time. If that’s the case, then how is it possible to have an IP address conflict for dynamically assigned addresses?

There are two situations that I’ve run into that can cause this problem. The first time that I ever ran into this problem, I was able to determine which PCs had been assigned at the duplicate addresses. When I checked the TCP/IP configuration on those machines, I found that one of the machine’s IP addresses had been manually configured. It’s kind of a long story, but that machine’s user was running an unauthorized application that required a static IP address. The user got tired of having to reconfigure the application every time they used it, so they took the address that had been dynamically assigned to them, and entered it as a static address.

The likelihood of this happening today is fairly slim. When a particular situation occurred, Windows 98 was the current operating system. Windows 98 lacks many of the security features that we take for granted today. A properly secured workstation running Windows XP or Windows Vista should be resistant to end user reconfigurations. Even so, I wanted to at least mention this issue because it gives you something to look for if you have trouble solving the problem.

A much more common cause of this problem is that multiple DHCP servers are in use, and those DHCP servers have overlapping scopes. If you only have a single DHCP server on your network, do not make the mistake of immediately dismissing this idea as a possible cause of your problem. In all likelihood, there is probably a rogue DHCP server that is conflicting with your primary DHCP server.

Windows 2000 Server and Windows Server 2003 are both designed in such a way to prevent rogue DHCP servers from causing problems. A DHCP server can only issue IP addresses after it has been authorized by the Active Directory. The problem is that this only applies to Windows-based DHCP servers. DHCP servers running other operating systems are free to lease IP addresses to clients without having to be authorized by the Active Directory.

So has a user really gone through the trouble of installing a rogue, Linux based DHCP server? Probably not. A much more likely explanation is that a wireless access point, or a router intended for cable or DSL Internet connections is causing your problem. Such devices almost always have DHCP server’s built in. These devices typically use a scope range of 192.168.0.x or 192.168.1.x. If this happens to be the same IP address scope that your primary DHCP server uses, then you may run into a situation in which both DHCP servers are issuing addresses from the same address pool.

Conclusion

In this article, I’ve explained that there are a number of potential causes for DHCP failures. In most cases, these failures are related to simple communications problems between the DHCP server and the workstations that are trying to lease addresses.

Troubleshooting Remote Desktop

Ever since the release of Windows XP, one of my favorite features as always been Remote Desktop. In case you're not familiar with Remote Desktop, it is a built-in Windows feature that allows you to connect to your computer remotely by using the RDP protocol. For example, if you are at home and you need to access something from your computer at the office, you could use a Remote Desktop session to remotely control your office PC from home. Remote Desktop is built on the same technology, and uses the same protocol as the Windows Terminal Services.

As handy as Remote Desktop is, it can sometimes be problematic. While the sessions are usually solid, there are a number of things that can go wrong during the connection and authentication process. In this article, I will explore some various troubleshooting techniques that you can use when things go wrong with Remote Desktop.

The Remote Computer Cannot be Found

Probably the most common Remote Desktop problem is that Remote Desktop has trouble locating the remote PC. There are a number of things that can cause this problem. Probably the simplest cause is misspelling the name of the remote computer. Therefore, if you're having trouble connecting to remote computer, just take a second and make sure that you've spelled the remote machine's name correctly.

If the remote computer's name is spelled correctly, the problem may be DNS related. Remote Desktop uses the RDP protocol, which piggybacks on top of the TCP/IP protocol. As you probably know, TCP/IP does not use computer names as a mechanism for identifying the systems. The only reason that it is possible to specify a computer name is because a DNS server resolves the computer name to an IP address.

If you find yourself having name resolution problems, there are a couple of different things that you can try. One option is to try using the remote system's fully qualified domain name as opposed to its NetBIOS name. This won't always help you to establish a connection, but in certain situations it will help.

Another option is to specify the remote machine’s IP address rather than its name. Generally speaking, using an IP address tends to be much less problematic than using a host name when connecting. Even IP addresses can be problematic, though.

The biggest factor that tends to make connecting with IP addresses problematic is the use of dynamic IP addresses. If you are using Remote Desktop to connect to a server, this probably won't be an issue, because most servers use static IP addresses. Workstations, on the other hand, almost always use dynamic IP addresses. Therefore, the IP address that your workstation is using today will probably be assigned to a different workstation tomorrow. If the machine that you are connecting to does use dynamic IP addresses, then you will practically have no choice but to specify a host name when connecting rather than specifying the machine's IP address.

Another factor that can make it difficult to connect to a host machine using remote desktop is firewalls. The Remote Desktop Protocol is designed to work across TCP port 3389. If you are attempting to connect to a remote machine that sits behind a firewall, then the firewall must allow traffic to flow through TCP port 3389. Of course blindly opening this port on your firewall can pose a huge security risk. You might choose instead to enable port forwarding so that inbound RDP traffic is forwarded to a specific IP address, rather than someone on the outside being able to attempt an RDP connection to any machine on your network.

On many networks, you won't have a choice but to use port forwarding for RDP traffic. The majority of networks use private IP addresses on their networks, and only the router uses a public IP address. The router uses Network Address Translation (NAT) to proxy traffic between the Internet and hosts on the private network. If you are trying to establish an RDP connection from across the Internet with a host that sits behind a NAT firewall, then you will have to configure the firewall to forward RDP traffic to the target host.

Of course this assumes that you are attempting to establish a connection directly from outside the perimeter network. If you are connecting to the private network using a VPN or a dial up connection, then you will have to worry about reconfiguring a NAT firewall, because your VPN or dial-up connection provides you with a connection to the private network. The remote access server that is used for establishing VPN or dial-up connections almost always sits behind a firewall, and you'll have to insure that this firewall allows RDP traffic to flow to the private network.

While I am on the subject of firewalls, I want to point out that Windows XP SP2 and Windows Vista both contain a built-in firewall. If you are attempting to establish a connection to a machine running one of these operating systems, you'll have to insure that the Windows firewall is configured to allow RDP traffic.

Authentication Problems

Establishing the initial connection is by far the most problematic aspect of Remote Desktop, but there are other problems that you may encounter. Many users are surprised to see that they can attach to a remote PC, and enter their credentials, but are stopped by the following error message:

The local policy of the system does not permit you to log on interactively.

Windows displays this error message if the user who's logging lacks the necessary permissions to log in using the Remote Desktop Protocol. You can correct the problem by adding the user account to the Remote Desktop Users group or to the local Administrators group.

Data Encryption

One of the most cryptic problems with Remote Desktop involves receiving the following error message:

Because of an error in data encryption, this session will end. Please try connecting to the remote computer again.

This error message is almost always related to using an outdated remote desktop (or terminal service) client. When Microsoft released Windows 2000, they created an add-on called the Administration Tool Pack. The Administration Tool Pack included a client component that could be used to establish a remote session. Although this client initially appears to be compatible with Windows XP, it isn’t. Using the Windows 2000 version of the Administration Tool Pack to establish a Remote Desktop session with Windows XP will usually trigger the error message that I mentioned above.

Windows XP comes with its own Remote Desktop client that you can use to establish a connection with other machines that are running Windows XP. If you prefer using the Administration Tool Pack though, then you can always upgrade to the Windows Server 2003 version, which you can download at: http://support.microsoft.com/kb/304718

Conclusion

Although Remote Desktop usually works fairly well, it can sometimes be difficult to establish an initial connection. In this article, I have discussed some of the most common causes of Remote Desktop problems and some possible work arounds.