Windows XP on domain not allowing domain admins to RDP in

Our company is still supporting Windows XP. They are part of a Active Directory based domain. Until Feb 2016 they were all accessible via RDP from the few trusted Domain Admins. Now about 4 - 6 sites out of 300 of them are failing to logon. When you first reboot them they can be accessed. After about a day they can't. The following was done so far.

Monitored perfmon for memory leaks. Could find any. (Remember it is only a handful of sites)

Updated the DNS addresses (Company wide changes were not implemented on some PC's thanks to group policy updates being killed by Microsoft with he AD DS migration from Windows Server 2003 to 2012.

Removed NetBIOS and made sure SMB was used instead. (That helped all clients)

Verified all patches were up to date. (most were and the rest were immediately updated manaually)

Verified no viruses were in effect

New features were added over time and the page swap file was out of range. Fixed that and made it static on another drive.  (All clients showed improvements).

Other minor fixes include defrag and cleanup.
LVL 1
hatcherb1234Network EngineerAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
jmac44Connect With a Mentor Commented:
...and the reason why it works (when rebooted) is because the DNS if flushed and registered again with the DC that handles DHCP and gets the IP address that was assigned but not previously updated by the target machine. That is my theory - please reread my post. One final comment Windows XP have been EOL since 4-8-14 it's quite possible these machines are compromised. Good luck.
0
 
jmac44Commented:
I've seen something similar to this in another post and their problem was DHCP wasn't dynamically updating DNS A and PTR records.
See below and disregard red underline that was a screen shot for something else.
dhcp.JPG
Edit:
Also be sure those workstations Advanced TCP/IP settings are registering their their connection's addresses in DNS in the the adapters properties.
0
 
hatcherb1234Network EngineerAuthor Commented:
The graphic provided does not look like a Windows XP Pro network properties. I can't relate to your answer.
0
Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

 
jmac44Commented:
Are you the system administrator for your network?
0
 
hatcherb1234Network EngineerAuthor Commented:
Yes. I also built the AD DS and defined all of the group policies,
0
 
hatcherb1234Network EngineerAuthor Commented:
One final note. Due to the company policy the DNS is external so the AD DS is forwarded outbound trust. But that has not been a problem.
0
 
jmac44Commented:
Ok. The graphic is of DHCP Properties. If your not familiar with it, it's because it's probably being  administered somewhere within the Forest of your domain by another administrator who is also the admin of DNS. I'm assuming that you did install DNS manager and it is being propagated by the a Domain Controller in your forest that contains the FSMO roles.

There's a couple things you can try, flush and register the dns on the workstations and/or un-join them from the domain and then re-join to re-establish trust. But I'm not confident that will work. You need to find out how often DHCP is leasing IP addresses and if they are dynamically updating the A and PTR records from the DHCP Properties dialog box in the graphic of the previous post.

It sounds like the DHCP lease is on a short timer and it's not getting updated to the target machine fast enough and so when someone remotes in the DHCP DC has a different IP than what the target machine has.
0
 
hatcherb1234Network EngineerAuthor Commented:
Ok. All that makes sense. However the clients in the field use a load shared tier zero DNS which handles the whole United States for our company. The AD DS uses the building's DNS that house the AD DS also.  The building's DNS is rooted back to the same tier zero DNS  arrangement. If all of the clients were acting up I would agree in general. The only reason I brought about the DNS is all of the clients were originally pointed towards old and now outdated DNS. We updated all clients since then 2 years ago and they all became more reliable in general such as working with WSUS. All were working until the 6 clients started acting up around February 2016. Systeminfo shows the same results as the working system. Gpresult shows the same results as the working systems. If we reboot the client they work fine for a day then stop working. I initially supected a memory leak of some sorts. Please reread what I originally wrote. :-)
0
 
hatcherb1234Network EngineerAuthor Commented:
Excellant support. Thank You
0
 
jmac44Commented:
Thanks, glad to help!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.