Time syncronisation in domain
-
@DustinB3403 said in Time syncronisation in domain:
You've made a conclusion here about the configuration of this system.
Have I? I thought the opposite. I'm only repeating what the OP stated clearly. I've made no conclusion at all. I was specifically arguing against your conclusion that I can't find any basis for. I'm not intended to conclude anything, only repeating the original statements.
-
@DustinB3403 said in Time syncronisation in domain:
Were as a more rational conclusion is that this system can access the DC, but doesn't have internet access.
That's what the OP said and what I repeated. We are now back to the first post. Okay, we are on the same page now. Now we can start back at the first step is diagnosing the problem....
To what does the DC look for its time source?
-
@DustinB3403 said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@DustinB3403 said in Time syncronisation in domain:
All clients in the network (this system included) go to the DC for their time.
Red herring, we aren't concerned about them, why do you keep mentioning them? This is misdirection. What they look to has no bearing on what the DC looks to.
The red herring is that only this system doesn't have internet access, this doesn't mean he doesn't network access (or more specifically) the ability to sync time from a DC.
You've made a conclusion here about the configuration of this system.
Were as a more rational conclusion is that this system can access the DC, but doesn't have internet access.
No, this sounds completely like an offline LAN. Very typical in some places.
You are incorrect.
back to the OP.
@meghal did you change some default setting in any way? Windows is designed, out of the box, to get time from the DC as part of the login authentication process.
I never set any GPO for time synchronization on my workstations that are joined to a domain.
-
I think you two are actually saying the same thing, but for different systems.
You agree it might be a time shift, but @DustinB3403 is asking about the client and @scottalanmiller is asking about the server.
Since the clients are looking to the server, and the server needs a time source, it would make sense to know what that was.
Would also be know if it truly was CLIENT or CLIENTS.
-
@JaredBusch said
I never set any GPO for time synchronization on my workstations that are joined to a domain.
Right, that is just automatic, correct?
-
@BRRABill said in Time syncronisation in domain:
@JaredBusch said
I never set any GPO for time synchronization on my workstations that are joined to a domain.
Right, that is just automatic, correct?
Correct, and as @scottalanmiller said, in post 3, if the desktop time is too far off in the first place, then it will not sync either. So you at least need to set it once if it is way off.
-
@BRRABill said in Time syncronisation in domain:
I think you two are actually saying the same thing, but for different systems.
You agree it might be a time shift, but @DustinB3403 is asking about the client and @scottalanmiller is asking about the server.
Since the clients are looking to the server, and the server needs a time source, it would make sense to know what that was.
Would also be know if it truly was CLIENT or CLIENTS.
But the client by default (as an Always) you set the time source for the client to be the DC. So even if the DC is of by 12 years, you're clients should be off as well.
Time will still be bad, but it's bad everywhere.
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
-
@JaredBusch said in Time syncronisation in domain:
I never set any GPO for time synchronization on my workstations that are joined to a domain.
Good point, that's a default. Nothing more should be needed as long as the DC is stable and accessible.
-
@BRRABill said in Time syncronisation in domain:
@JaredBusch said
I never set any GPO for time synchronization on my workstations that are joined to a domain.
Right, that is just automatic, correct?
Yes, normally.
-
@DustinB3403 said
But the client by default (as an Always) you set the time source for the client to be the DC. So even if the DC is of by 12 years, you're clients should be off as well.
Time will still be bad, but it's bad everywhere.
That's a good question. How would the client know the DC is off? Wouldn't it just update to the DC time?
But again, I think that goes back to Scott's question of ... what does the DC use for its time source.
-
@DustinB3403 said in Time syncronisation in domain:
But the client by default (as an Always) you set the time source for the client to be the DC. So even if the DC is of by 12 years, you're clients should be off as well.
Only if they were always off together. NTP and SNTP don't allow for large, rapid time drift. Which is why stability on the DC is critical.
-
@BRRABill said in Time syncronisation in domain:
That's a good question. How would the client know the DC is off? Wouldn't it just update to the DC time?
No, not if the drift is too rapid. It will see it as a stability issue and not sync.
-
@BRRABill said in Time syncronisation in domain:
But again, I think that goes back to Scott's question of ... what does the DC use for its time source.
Exactly. If the DC's source is too unstable, like using the software clock on VMware 4, you will expect it to drift too fast for clients to handle. VMware Server had a natural drift of over 100%, for example (meaning it could drift by one second, every second, when idle!)
-
@DustinB3403 said in Time syncronisation in domain:
@BRRABill said in Time syncronisation in domain:
I think you two are actually saying the same thing, but for different systems.
You agree it might be a time shift, but @DustinB3403 is asking about the client and @scottalanmiller is asking about the server.
Since the clients are looking to the server, and the server needs a time source, it would make sense to know what that was.
Would also be know if it truly was CLIENT or CLIENTS.
But the client by default (as an Always) you set the time source for the client to be the DC. So even if the DC is of by 12 years, you're clients should be off as well.
No you do not set the windows workstations to the DC. I just said that. It is an automatic backend setting. You do not set a NTP server in Windows normally when joined to a domain.
Time will still be bad, but it's bad everywhere.
If time is too far off, it will not sync.
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
-
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
-
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
-
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
-
@scottalanmiller said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
Does VMWare 5, 6 or 7 use the hardware clock and pass that information along to the VMs?
-
@Dashrender said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
Does VMWare 5, 6 or 7 use the hardware clock and pass that information along to the VMs?
I was under the impression that all Hypervisors did this now days.
-
@dafyre said in Time syncronisation in domain:
@Dashrender said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
Does VMWare 5, 6 or 7 use the hardware clock and pass that information along to the VMs?
I was under the impression that all Hypervisors did this now days.
Why would you not have been under this impression in the ESX 4 days? But clearly that wasn't the case as Scott mentioned above.
