time synchronization across domain

[Roy Avery]

Our domain consists of four separate sites with a domain controller at each site. Our workstation
and DC times are synchronized with each other, although they are off of the true correct time by
several minutes. Should I set up each DC at each site to be a trusted source, and set each DC to
synch with the same time server on the internet? Or should I only use a single DC for the entire
domain?

How exactly do I go about doing this? I've searched on MS, but the amount of articles that come up
is enormous, and I find it a bit confusing. Are there any articles that provide a simple
explanation on how to do this?

Thank you.

 

[ptwilliams]

Everything synchronises hierarchically. You don't have to synchronise with
anything, and all machines will simply consider the time of the forest root
the correct time. If you want to synchronise with an external source, you
*only* configure the forest root controller to obtain this time. The DCs
will then synchronise with the forest root, or preferred bridgehead, etc. if
in a site, and the members with these. The PDCs in each domain will
synchronise with DCs in the parent domain and so forth.

To configure the forest root to obtain time from an external source, pick a
time server from the list here: http://support.microsoft.com/?id=262680 and
perform the following on the forest root from a command prompt:

C:\>net time /setsntp:<FQDN *OR* IP address>

For example,

C:\>net time /setsntp:ntp2a.mcc.ac.uk


--

Paul Williams
_________________________________________
http://www.msresource.net - Under construction, but coming soon...


Join us in our new forums!
http://forums.msresource.net
_________________________________________

 

[Roy Avery]

Is my forest root the same as the DC that holds the FSMO rolls?

Thanks.

Everything synchronises hierarchically. You don't have to synchronise with
anything, and all machines will simply consider the time of the forest root
the correct time. If you want to synchronise with an external source, you
*only* configure the forest root controller to obtain this time. The DCs
will then synchronise with the forest root, or preferred bridgehead, etc. if
in a site, and the members with these. The PDCs in each domain will
synchronise with DCs in the parent domain and so forth.

To configure the forest root to obtain time from an external source, pick a
time server from the list here: http://support.microsoft.com/?id=262680 and
perform the following on the forest root from a command prompt:

C:\>net time /setsntp:<FQDN *OR* IP address>

For example,

C:\>net time /setsntp:ntp2a.mcc.ac.uk


--

Paul Williams
_________________________________________
http://www.msresource.net - Under construction, but coming soon...


Join us in our new forums!
http://forums.msresource.net
_________________________________________

 

[ptwilliams]

Yes. It's the Server that holds the PDCe in the top-most domain of the
forest.


--

Paul Williams
_________________________________________
http://www.msresource.net - Under construction, but coming soon...


Join us in our new forums!
http://forums.msresource.net
_________________________________________

Is my forest root the same as the DC that holds the FSMO rolls?

Thanks.

 

[Herb Martin]

You forest ROOT Domain is the FIRST one you installed.

It usually holds the Schema Master and Domain naming
master one the FIRST DC you installed by you may have
moved it or the PDC Emulator.

The "normal" (designed) time synchronization is the following:

Root Forest Domain PDC Emulator is manually or
automatically synchronized to a known time source for the
admins -- atomic clock over the Internet, hardware radio,
or indirectly through your firewall but YOU, the Admin
choose this.

PDC Emulators for all other domains in the forest sync from
the Root Forest PDC emulator

Other DCs from each domain sync from their own PDC emulator

Servers and clients from each domain are manually set to sync
from a nearby server.

You can CHANGE this if it makes more sense to get each PDC
emulator or even each server or machine to sync from a known
time source but you must NOT let the time get too far out of sync
-- I believe it is 5 minutes but it might be 10 or some such.

Kerberos authentication -- and things like replication therefore --
fail if the time is not "close."

If your machines are more than 5 minutes out of sync I would be
very careful about "just correcting them" immediately but would
rather incrementally move them towards the correct time before
automating it.

Some of this is built into some of the MS time sync tools, to
avoid a sudden jump in the time greater than the tolerance.


--
Herb Martin

Is my forest root the same as the DC that holds the FSMO rolls?

Thanks.

 

[Roy Avery]

Thank you.

Yes. It's the Server that holds the PDCe in the top-most domain of the
forest.


--

Paul Williams
_________________________________________
http://www.msresource.net - Under construction, but coming soon...


Join us in our new forums!
http://forums.msresource.net
_________________________________________

 

[Jeremy@gilbarco]

Just to reiterate:
You should ONLY have the one machine pointing at an
external time source. All the other machines should be
left alone. If your time gets too far off you will not be
able to log in. Make sure that your time zones are set up
in the Time and Date applet, otherwise it can be really
frustrating to troubleshoot. Although your machines will
show the local time based on their timezones, they
communicate with each other using GMT.

 

[Roy Avery]

Unfortunately, the first one I installed had a hardware failure about a month ago. I was forced to
seize the FSMO rolls with another DC. I then removed all history of the original DC as being a DC
and dcpromo'd it back to a DC.

When typing "net time" at a command prompt on any workstation or DC, it lists the DC that is first
in alphabetical order. Why is this? By the way, the first in alphabetical order isn't the one I
used to seize the FSMO rolls. I went ahead and set the SNTP server on the first DC alphabetically.

Thanks again.

 

[Roy Avery]

All of our machines are in synch already. It's just that our time isn't in synch with the "real"
time. HR is complaining that people are leaving work early because the computer says it's time to
go.

 

[Herb Martin]

Unfortunately, the first one I installed had a hardware failure about a month ago. I was forced to
seize the FSMO rolls with another DC. I then removed all history of the original DC as being a DC
and dcpromo'd it back to a DC.

If you mean you DCPromo the original machine twice (or even
completely re-installed it) then fine. Never return the original
roll holder to your network after a seizure -- for longer than
it takes to DCPromo.

When typing "net time" at a command prompt on any workstation or DC, it lists the DC that is first
in alphabetical order. Why is this?

I don't know; mine doesn't do that. At least not on the DC
I am using.

"net time" is largely just a Client utility; don't read too much
into it's behavior.

By the way, the first in alphabetical order isn't the one I
used to seize the FSMO rolls. I went ahead and set the SNTP server on the

first DC alphabetically.

I would make sure to set the PDC Emulator (wherever you put it)
that way also. (Or equivalent.)

Contrary to what another poster said, you might also need to
do this to DCs or other servers located at other sites,
depending on your WANS and firewall setups.

 

[Herb Martin]

All of our machines are in synch already. It's just that our time isn't in synch with the "real"
time. HR is complaining that people are leaving work early because the computer says it's time to
go.

My point was to describe the default behavior,
and explain the care you need to take if you CHOOSE
to correct the time by a large amount.

You can decide if "correct time" is important to you,
but you must have CONSISTENT time (within a few
minutes.)

Personally, I cannot abide time settings that are more than
a minute off and generally prefer them to just be correct.

But that's me. <grin>

(There are however practical considerations when copy
and updating files across machines and trying to figure out
whether a file was "just changed" or not.)