We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


VERY URGENT: Remote offices can't find Domain Controllers at headquarters.

Medium Priority
Last Modified: 2013-11-21

I have a client with the following details:

2 DC 2003 at the headquarters.
Several remote offices with XP workstations and NT4 File & Print servers (Remote offices at different subnets from the headquarters).

Every service and workstation is working correctly at the headquarters, they can contact the DCs, DNS and WINS, but none of the remote office machines can authenticate at  the domain controllers from the headquarters, as a consequence, no services provided by the NT4 servers are available, and XP machines are login on with cached credentials only.

All tcp-ip communications to the DCs, DNS, and Wins servers at the headquarters are available, any machine from the remote offices is able to ping these servers at the headquarters.

This network made an upgrade from NT4 domain to 2003 on the last weekend, I can't confirm the remote offices were able to log on to the upgraded 2003 DCs at the headquarters after the upgrade, or if they have been login on with cached credentials since.

Someone tells me that they did manage to log on to the File & Print NT4 servers from the remote offices since the upgrade before these problems, but since It wasn't me, I'm not absolutely sure that is true. If that was true, and since NT4 doens't keep the credentials in cache as far as I know, this would confirm that they were previously able to contact the 2003 DCs at the headquarters.

I can't be sure the customer hasn't done any changes to the routers also.

Any thoughts?
Watch Question

Make sure you permit ports 88 and 445 on your routers.

Do you have DCs on those branch offices?

I'm not at all sure why you can't authenticate, but I suggest that you have a look at the DNS setup. Make sure that the one of the following scenarios are applicable

     - All PC's have only the domain controllers as DNS servers,
     - You set up the NT servers as slave DNS servers and point each subnet to its local NT server. I'd guess this would be the better implementation as there would be less traffic across the WAN link.

Check the service pack level of the NT servers. I'm not sure if NT servers cannot participate in a 2003 domain at all or if it needs a specific service pack. Check it out, it may point you into a direction.

Lastly, if you don't mind sacrificing your domain functional level and you can actually (see previous) join an NT server to the domain, why don't you make them BDCs and use domain replication to have the logon occur locally? Then you'd have some rdundancy as well.

Good Luck



Hi, there are no DCs at the remote offices, except for one which still has a NT4 BDC, but the machines at this site are experiencing exactly the same problems as the others, which makes sense to me because of some info I read recently, according to it, XP machines after an upgrade, will only log on in active directory, they will never use NT DCs again... So this could be seen as a confirmation that this XP machines were able to log on to the 2003 AD after de upgrade, but now, although they can't contact the AD, they will not use the local NT4 BDC in according to taht info.

I also learned that all the remote offices enter the headquarters through the same router... That could defintly be a point of failure.

Regarding communications, I could ping servers at the headquarters from the remote offices, I can Even VNC and Remote Desktop to worktations at remote offices from the headquarters...

I don't know routers, but maybe this one is affecting traffic regarding authentication somehow?



All PCs, have only the DCs at the headquarters as their DNS and WINS servers, all NT4 machines have SP6, but notice that they are only member servers, the XP machines at the remote offices authenticate only at the headquarters, and they also are not able to do it.
Menshen, IF your users at headquarters can authenticate AND your remote users don't AND all remote traffic comes through the central router THEN in my opinion this one is affecting authentication traffic.

If you can't access the router you can make a fool proof of this, using a laptop test that you can logon at the headquarters and then test that you can't logon at the remote office, or viceversa.

If the router is a Cisco device i can help you too, let me know.


Some more details...

The following errors are from a XP machine on monday, after the user logged on for the first time on the upgraded domain:

Event ID 3224

Source: Netlogon

Changing machine account password for account COMPUTER failed with the following error:
There are currently no logon servers available to service the logon request.

Event ID 28

Source W32Time

The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are accessible. NtpClient has no source of accurate time.

This could indicate that the machines from the remote offices are having trouble locating the 2003 DCs since the upgrade was done, but this is not happening with the machines at the headquarters.

Previously this was an NT4 domain with two DCs at the headquarters. The WINS servers were the DCs, and there was no DNS.
During the upgrade I configured DNS at the DNS and maintained the WINS servers, so the only new info the heardquarter and remote machines had, was a new DNS server.

Check to make sure that they are pointing to the proper gateway.


Also... There is still a live NT4 BDC at the headquarters from the domain before the upgrade was done (this was left up because it is also a proxy server), so if for some reason the remote XP machines were not able to log on to the 2003 DCs, they woudl have this one available... Honestly I feel a bit lost.


fnbgppl ... They are
Event ID 3224 Source: Netlogon

"The security database on the server does not have a computer account for this workstation trust relationship" - I received this error on a number of servers and Windows XP machines. This problem occurred when I upgraded a NT4 PDC to a 2K server. Somehow, the security records on the PDC and BDC had got out of sync. My solution was to remove the offending PC from the domain, remove its account from both the 2K server (acting as a PDC) and from the BDC. I waited 15 minutes for all the updates to filter through and then rejoined the domain.

Try to remove/rejoin a workstation in a remote office, logon and check for errors


wpadron, I asked one of the technicians from the client to delete one of the accounts, and recreate it a few hours ago, I know now he didn't wait enought time to ensure that operation was replicated between DCs before creating it again. I will have to retry it tomorrow morning.

Have you tried the deleting a computer account and then running a network ID wizard for that machine?


Important... very important detail I noticed. I was bothered by the fact that only machines on other subnets didn't find the server, so I did a test, I installed a 2003 machine and joined it to the domain on the headquarters, and then took it to another subnet and it coulnd't authenticate of find log on servers... This from a machine that was done after the upgrade, and that can log on perfectly once it is returned to the headquarters...

So definitly the problem is from the fact that the machine is on another subnet. And this only became a problem after the upgrade, these same machines on the NT4 were able to log on without problems, and without even a DNS at the remote offices.

So...What do these machines need to contact a 2003 domain controller on another subnet? They have the correct gateway, they have the correct DNS, which is the DC at the headquarters... They even have WINS configured, which is also the DC...
Just a quick question.

Your Machines, do they have any static IP settings.

Any custom entries in the C:\WINDOWS\system32\drivers\etc\hosts file pointing to your DC's?

Also do you have any static WINS entries pointing to DC's.

On your Machines in the remote offices, can they Ping and tracert your 2003 DC's can you run an nslookup on a server and return the name server?

another thing you can try is the following command
nltest sc_query:%Your Domain name%
from one of your workstations, this will test the secure channel between your machine and your domain.

Also, I assume your domain is running in Mixed AD mode and not Native AD mode.


They all have static IP addresses, something that obviously does not please me, I plan to implement DHCP soon.
They have static entries point to the DNS, and WINS servers, which in this case are the DCs at the headquarters.

I can Ping the DCs servers from the machines at the remote offices, I'll have to confirm nslookup queries and your next command in the morning.

The domain is still in mixed mode.

can you ping your workstations from your DC, if so, then you might be able to use a utility called Rclient (Part of the MS windows Resource Kit)

Usage run from a  command line, rsetup \\PCNAME

this will remotely install the remote client service on the workstation. You can then use rclient \\pcname to connect to a command line console on the target machine.

This will then allow you to run diagnostic commands on the remote machine as if you were logged onto it locally. From there you can run your nltest and nslookup commands.

I strongly suspect that your static IP settings are causing the problem, especially WINS.


davidsummers, I'll be looking into it in less than an hour, but I'm not sure WINS is the problem, because the 2003 machine that was done after de upgrade, will use DNS to find domain controllers.

We could consider that the NT4 Servers would still use WINS, and that the XP workstations at the remote sites would also use it they never logged on to the AD, but that specific 2003 machine would use DNS I think.


Additional important Info, I've been given incorrect info by the IT team from the customer, the remote machines, aren't even aware of the upgrade, I can see at the remote XP machines, that their host names are still without the complete extension such as:


they are still only PC, and the event viewer confirms netlogon errors immediatly after the upgrade to 2003.

So machines on the same subnet are working perfectly on the AD, remote machines are still looking for the NT4 domain. I believe NT4 domain clients from remote offices use WINS to find a DC, and they are still using the WINS address of the old PDC, which is now a the PDC emulator, and WINS. So the IP address to the WINS server is the same, but this is now a 2003 wins ant not NT4


I can confirm that remote machines are able to contact the new DNS and the new WINS server and use it for resolving names.
The domain name is correctly present in the WINS database. Still the the remote machines tell they cannot find the domain.

I did from a remote machine a ping to both of the DC servers:

ping dc01
ping dc02.localdomain.com

I got positive responses to both, I checked my cache with nbtstat -c which shows me now an entry for dc01, I believe this confirms to me that the remote machines can contact and use WINS and DNS, but still they are somehow unable to find the domain...


I was informed that both that ports 88 and 445 are open on the routers, and that no changes were made recently, so tey always allowed remote machines to contact the NT4 servers athe the headquarters to log on.

I have no sites or subnets defined on AD, since I believe this is only needed if you have DCs at the remote offices, and since they don't exist they are not needed


PINPOINTED!!!! It was the god damn router!

I installed a 2003 router and everything worked perfectly!

Now I need to find the correct info to my customer regarding ports and protocols that must be open on the routers to allow 2003 logon traffic. (even though e kept telling me everything was open...)

He has a Cisco7200vxr centrally and cisco 2600 at the remote offices.

Anyone know what needs to be open exactly?
Windows 2000 connectivity through firewalls ... or damn routers ;) http://support.microsoft.com/?kbid=280132

If you need help configuring the router let me know.

Good luck

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Here you Go:


Computer Login and Authentication

A computer logon to a domain controller uses the following:

• Microsoft-DS traffic (445/tcp, 445/udp)

• Kerberos authentication protocol (88/tcp, 88/udp)

• LDAP ping (389/udp)

• DNS (53/tcp, 53/udp)



Thanks fo the help guys, the points go to wpadron for getting me the info first.

P.S. the problem was in fact with the MTU size of the packets on the router... NT4 accepted authentication even after the router fragmented the packets, 2003 R2 was more sensitive to the change.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.