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.

Mat
  • 1,536
  • 1
  • 17
  • 21
WLanger
  • 96
  • 1
  • 6
  • 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 '11 at 17:17

2 Answers2

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.

dsolimano
  • 1,290
  • 2
  • 14
  • 26
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.

user48838
  • 7,393
  • 2
  • 17
  • 14
  • 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 '11 at 18:28
  • Then you may need to consider getting Microsoft Support involved if this is configuration issue is functionality related. – user48838 Aug 28 '11 at 18:31