Ultimately, you’re connected to resources by IP address, not machine name. When working at home the other day, I found that stale DNS entries can make this connection mechanism yield interesting results when connecting to your desktop PC via TS Gateway. Although the set of circumstances that led to this error is unusual, it’s worth seeing what happened.
Like many people at Microsoft, I use the MSIT deployment of TS Gateway (click here for details of the setup) to get the corporate network from outside the office. I use it regularly and it always “just works”. It’s great—one of my favorite features of Terminal Services.
One day when working from home, I logged into the application and desktop portal, typed in the name of my desktop computer, and connected to my desktop… with one major glitch:
That isn’t good. The bar at the top showed my computer’s name, so why couldn’t I log on? I clicked OK, and was presented with an additional dialog box prompting me for my credentials. This dialog box isn’t normally presented when I’m logging on via TS Gateway.
This is new, I thought, but maybe something’s changed on the back end since two days ago. I typed in my PIN. This got me right back to the original error message.
Things got really weird when I clicked Switch User. Staring at the screen shown below, I wondered, “Why is someone logged into my computer?”
Clicking Other User and attempting to log in using my password got me nowhere either. When I did that the computer complained that I was not a member of the Remote Desktop Users Group and disconnected me when I clicked OK.
Since I was able to reproduce this repeatedly, and could connect to TS RemoteApps via the portal so my credentials were plainly being accepted, I called for help. One person observed that it didn’t look like I was connecting to my desktop at all, even though the display bar showing the remote computer’s name displayed the right name. MSIT looked up the records for my desktop computer, and sure enough, DNS had two IP addresses listed for my computer. One of those IP addresses was no longer associated with my computer, so the connection was being sent to the wrong endpoint.
Now, we were on the right track. Here’s how we determined the problem and resolved it:
1. MSIT ran nslookup –q=any mydesktopname to get the IP addresses listed for my desktop computer and found that my computer had two records. (You don’t have to be an admin to run nslookup.)
2. Once back in the office, I ran ipconfig /all to get my desktop computer’s current IP address. (You don’t have to be an admin to run this, either.)
3. We got in touch with the data center owners to ask them to remove the IP address that wasn’t the one my desktop computer was using.
Why did DNS have two entries for my desktop computer? This can happen when a computer is improperly disconnected from the network, since that will prevent the old entry from being deleted, but the computer gets a new one when it starts on the network. (One cause of stale DNS entries is rebuilding computers while still attached to the network. If doing a planned rebuild, you can avoid this problem by leaving the domain before rebuilding.) The DNS server had a 50-50 chance of sending my incoming request to the right IP address, and lost the gamble. The fix was to delete the old DNS record from the database.
There are two key points here. First, duplicate entries in DNS can cause a routing system based on IP address to fail. The second one is information that helped us troubleshoot this problem:
1. I could connect to TS RemoteApps, but not to my personal desktop. This indicated that the problem did not lie in my credentials.
2. When I clicked Switch User, someone who would never be attached to my desktop was apparently logged in. This indicated either a major security hole or that I was not looking at my own desktop.
3. To support #2, when I presented my credentials I saw an error message telling me that I was not a member of the Remote Desktop Users group, even though I’d previously been able to connect to my desktop computer.
4. Nslookup and ipconfig filled in the missing details.