Time syncronisation in domain
-
@meghal said in Time syncronisation in domain:
one more thing my this network is not connected with internet.
This is the TOTAL information given about his time sources. We only know that he is not talking to the Internet. Nothing more. If you feel that there is more, you need to provide a quote because these are the only words relative to his time source that I see anywhere.
-
@meghal said in Time syncronisation in domain:
I have applied a GP on my windows 2008 server but the client machine time are not syncronise with server. what could be the reason?? i have implemented NTP policy both for server and client through Gp. one more thing my this network is not connected with internet.
Okay... what we know:
- Clients are NOT synchronized with the server
- Server does NOT have access to an Internet time source
- OP would like to fix the issue that the clients are not synchronizing to the server.
It clearly says only the DC would reach out to an international time source. There is nothing to have confused here. All clients in the network (this system included) go to the DC for their time.
What Dustin says about the same data:
- Clients ARE reaching on the server.
- Server IS getting time from some unmentioned international time source (where did the idea of something international even come from?)
I feel like you have the exact opposite reading of the OP that I do. Everything you say is clear is literally the opposite of what I see.
-
Have I missed OP posts that have been deleted or something?
-
@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.
-
@DustinB3403 said in Time syncronisation in domain:
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.
And that's a red herring why? Since we want to know how that specific machine is getting its time. And as I've made painfully clear, how the clients talk to the DC isn't important at this stage, why keep mentioning that?
-
@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.
