Time syncronisation in domain
-
-
@DustinB3403 said in Time syncronisation in domain:
You use a local DC as a time source on the domain.
This is from my system.
But it's not the master, it's just the one that the desktops look to. The DC always gets its time from somewhere else. It's impossible to be a source, it doesn't have that possibility. What you are showing isn't relevant. That other things look to the DC doesn't matter, where does the DC look? The DC always looks to another system via software or to hardware. In the end, the master is ALWAYS hardware. There is no other possibility.
-
@scottalanmiller And I said that the DC always looks to a global source, but the client systems get their time from the DC to be in sync with it.
You're arguing the semantics of what I've said, which is simply, DC's look for a universal source, all client systems look to the DC for their time source.
-
@scottalanmiller said in Time syncronisation in domain:
@DustinB3403 said in Time syncronisation in domain:
You use a local DC as a time source on the domain.
This is from my system.
But it's not the master, it's just the one that the desktops look to. The DC always gets its time from somewhere else. It's impossible to be a source, it doesn't have that possibility. What you are showing isn't relevant. That other things look to the DC doesn't matter, where does the DC look? The DC always looks to another system via software or to hardware. In the end, the master is ALWAYS hardware. There is no other possibility.
Right, but where does a DC run? It may be software, but it runs on hardware somewhere. And if that hardware offers no internet connection to the underlying software, then it [the hardware] effectively is the master time source until it obtains an internet connection.
-
@DustinB3403 said in Time syncronisation in domain:
@scottalanmiller And I said that the DC always looks to a global source, but the client systems get their time from the DC to be in sync with it.
You're arguing the semantics of what I've said, which is simply, DC's look for a universal source, all client systems look to the DC for their time source.
Well, okay, but here is a tip... anytime you complain about someone using semantics, that just means that something is wrong. Never act like arguing semantics is bad, if there are semantics to argue, then something was wrong.
In this case, what was wrong, is that I carefully asked what the master time source was because THAT is what we need to know. You argued semantics and brought in what you felt was a "close enough" misuse of the question to answer something useless. We don't care that the DC is seen as the time source to the clients, we NEED to know what the DC is using as its master time source.
So you can call it arguing semantics. But with my semantics we can solve the problem. Without them, we have no way to continue diagnosing the issue.
-
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@DustinB3403 said in Time syncronisation in domain:
You use a local DC as a time source on the domain.
This is from my system.
But it's not the master, it's just the one that the desktops look to. The DC always gets its time from somewhere else. It's impossible to be a source, it doesn't have that possibility. What you are showing isn't relevant. That other things look to the DC doesn't matter, where does the DC look? The DC always looks to another system via software or to hardware. In the end, the master is ALWAYS hardware. There is no other possibility.
Right, but where does a DC run? It may be software, but it runs on hardware somewhere. And if that hardware offers no internet connection to the underlying software, then it [the hardware] effectively is the master time source until it obtains an internet connection.
Exactly. That's what I'm asking to find out.
-
@scottalanmiller said in Time syncronisation in domain:
@DustinB3403 said in Time syncronisation in domain:
@scottalanmiller And I said that the DC always looks to a global source, but the client systems get their time from the DC to be in sync with it.
You're arguing the semantics of what I've said, which is simply, DC's look for a universal source, all client systems look to the DC for their time source.
Well, okay, but here is a tip... anytime you complain about someone using semantics, that just means that something is wrong. Never act like arguing semantics is bad, if there are semantics to argue, then something was wrong.
In this case, what was wrong, is that I carefully asked what the master time source was because THAT is what we need to know. You argued semantics and brought in what you felt was a "close enough" misuse of the question to answer something useless. We don't care that the DC is seen as the time source to the clients, we NEED to know what the DC is using as its master time source.
So you can call it arguing semantics. But with my semantics we can solve the problem. Without them, we have no way to continue diagnosing the issue.
But @scottalanmiller look at the fourth post in this topic.
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.
Only with the semantics of (not understanding what was already stated) could there be confusion.
Which is "Only the DC needs to go out to an international source, what source is it using?"
You're wrong here.
-
@DustinB3403 said in Time syncronisation in domain:
It clearly says only the DC would reach out to an international time source.
Incorrect. It has a hardware source, period. We need to know what it is. You are making a simple question into something confusing. There IS a source here, we need to know what it is.
-
@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.
-
@DustinB3403 said in Time syncronisation in domain:
It clearly says only the DC would reach out to an international time source.
He clearly states that he is NOT connected to the Internet. We only know what he does NOT do, we have no idea what he does, do.
-
@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?
