NT 4.0 on ESX 3.5

[shcis]

Strange thing happened and was hoping to get some advise.

On esx host had the incorrect date and NTPclient not running. The guest VM which was NT 4.0 (a BDC) was rebooted and took the incorrect date of the host.

Here is where it gets tricky multiple Windows 2003 servers physical on another domain (NOT the domain of the BDC NT 4.0 server) got the incorrect date and then sync correctly with AD.

I don't understand why the NT.40 VM on domain A could impact physical W2K3 machines on Domain B?

Much appreciate any thoughts?

[shcis]

Forgot to mention, it only started after I updated VMTools on the NT4.0 VM.

Thanks

[kjb007]

Do you have trusts between the domains? That would be the first thing to check.

-KjB

[Lightbulb]

That is a little weird. The 2003 AD systems should not give a hoot what the NT4.0 systems thinks. They should get their time from the on of their DCs.

Check the following registry key on one of the windows 2003 systems that was affected:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current Version\DateTime\Servers

Maybe someone configured an external time source. Check the settings of the DC that holds the PDC emulator FSMO role also.

[shcis]

Thanks all the response.

Yes there is a trust between both domains.

The Windows 2003 physical machines do have

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current Version\DateTime\Servers

set to time.windows.com and time.*.gov

Forgive me, but I still can't connect the dots. The W2K3 servers do have access to the external.

Also, the NT 4.0 server does not have any time.ini or w32time.ini files it should not be acting as a time server.

Any ideas?

Thanks!

[kjb007]

If you have trusts between the domains, and the win2k3 domain has users from the NT 4.0 domain, it would explain the authrorization to perform the change. So, there would be access to make such a change. If the time change broke everything, an updated time should fix everything as well.

-KjB

[shcis]

I wish it was that easy.

The NT 4.0 server /domain does not have any users. It only exist because we have a backend vms that uses that domain.

Also, it date only change after I updated the vm tools on the nt 4.0 and rebooted.

Thanks again!

[Lightbulb]

Bit of a stumper. I asked about the REG settings in case a previous tech had made some ill advised changes. I really do not see how this could happen given the info that has been presented. I got nothing

[shcis]

Thanks!

It is almost as if the NT 4.0 vm broadcast itself as a NTP server. Is there anything from a VMware point that could cause the VM to broadcast?

I can't find any settings on the guest OS (NT 4.0) to suggest it was set as a Time server.

The ESX host Time Configuration was set for the wrong date and time and NTP client was stopped and the Time server was the loop back ip address.

[Lightbulb]

That is not really how NTP works. On a lighter note if you can figure out how to do it progrmatically you could raise holy Hell, until the FBI stopped you that is.

[shcis]

LOL....Thanks!

[kjb007 · Accepted solution]

Check here as well: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters on your servers to see what the Type value is set to. By default, it is set to domain heirarchy (nt5ds), which would cause it to sync with the domain. If your NT 4.0 vm is sync'ing with the tools, then correct the time on your ESX host. The make sure the BIOS time of ESX is set correctly as well.

As pointed out, NTP does not work on broadcast, it is a query type system. For some reason, and the trusts are a factor here as well, the windows hosts sync'd with their domain heirarchy, which included your NT 4.0 domain.

The loopback time for NTP on a host is the default config, if there is no other NTP provider configured.

-KjB

[shcis]

Thanks!

The physical W2K3 server type were set to NTP. I compared one that did change to the wrong date with another that did not and both registries for time were identical.

I did change the ESX host to the correct time and all is well. Thanks for all your help!!!