0

The scenario:

A Windows 2003 Server, that is the only DC in the network (192.168.1.10/24), is configured to synchronise its time from another NTP-Server (Linux machine with radio clock, IP 192.168.1.12/24). All that works well as expected.

The DC also provides the endpoint for VPN-connections, hence it obtains a second IP (192.168.1.58/24) as long as a VPN-connection is establised.

The problem:

If the windows time service is restarted when a VPN-connection exists, it binds to the second IP address as shown in the event log:

source: w32time
event ID: 35
The time service is now synchronizing the system time with the time source
ntp.xxx.local (ntp.m|0x9|192.168.1.58:123->192.168.1.12:123).

After the VPN-connection is closed, time synchronisation via the 2nd (now released) IP address fails:

source: w32time
event ID: 38 (can't reach NTP-Server)
event ID: 47 (No attempt to contact a source will be made for 15 minutes.) 
and finally:
event ID: 29 (NtpClient has no source of accurate time.)

After a while, the time service comes up again. But a blackout period is not acceptable for a DC.

Question:

Is there any configuration (preferably set via group policies) that instructs windows time service to bind to a specific IP address? Or at least not to bind to the VPN-tunnel's IP address?

Note:

The problem persists if the time is synchronised from an internet NTP-server. So this is not an issue, and yes, I want to use the internal (reliable) NTP-server.

Improve this question
1
  • I cannot understand why this question was downvoted. Is the description so bad? Well, the situation occured in a production environment on the DC and has severe consequences there. It is so severe that I am in fact thinking about contacting Microsoft Support as suggested by user48838 - for that, I have to reproduce the behaviour in a laboratory environment which takes me some time. I am going to keep the community posted about the outcome.
    – WLanger
    Sep 15, 2011 at 17:17

2 Answers 2

Reset to default
1

I was having a similar problem and came across KB 292822, titled

Name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS

It lists a series of steps that you can take to resolve the problem by preventing the RAS from registering its IP addresses with DNS:

To resolve this issue, configure the Routing and Remote Access server to prevent it from registering the IP address of its PPP adapter in the DNS or the WINS database. To do this, follow these steps:

I won't paste in all of the steps here as it's kind of an extensive process.

My solution was actually to move RAS to a different machine, which solved the problem without having to make a ton of registry tweaks on a domain controller.

Improve this answer
0

If the built-in Windows Time client is not working correctly, which is what it sounds like based upon your description, you might consider a 3rd party Time Client instead. There are a good range of alternate options to consider.

Improve this answer
2
  • Answer not acceptable for a DC in a productive environment :-( First of all, the built-in Windows Time client works, it is just a configuration issue. Second, the time service functions as an NTP server in the domain. So we are not talking just about an NTP client issue here, but rather about a critical component of a production environment domain.
    – WLanger
    Aug 28, 2011 at 18:28
  • Then you may need to consider getting Microsoft Support involved if this is configuration issue is functionality related.
    – user48838
    Aug 28, 2011 at 18:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .