Time Sync Problem on AD 2003 domain

OK. I might have it resolved.

This is what I did, for all of those in the future who might face this until
they finally want to quit IT and become a burger flipper:

I went into GPO editor, into the default domain policy and looked at the
computer configuration\administrative templates\system\Windows Time Service
settings

"Enable Windows NTP Client" was enabled
"Configure WIndows NTP Client" was enabled with the following configuration:
NTPserver: 10.4.34.48
Type: NT5DS
CrossSiteSyncFlags 2
ResolvePeerBackoffMinutes 15
ResolvePeerBackoffMaxTimes 7
SpecialPollInterval 3600
EventLogFlags 0

I changed this to "Not Configured"

"Enable Windows NTP Server" was disabled

I changed it to Enabled

then I gpupdate /force 'd

and w32tm /monitor 'ed on the PDCE (silc055)

and it successfully synched with 208.66.175.36.

Then, fearing that I also messed up the clients on the domain - since this
was the default policy - I went out to silc041 - the Win2K non-DC server -
and executed a gpupdate /force, and a "w32tm -v -once"

The server synched with the PDC.

So, it seems to be working.

I haven't worked much with AD yet. I don't understand why those changes don't
seem to have affected all of the clients as well as the server, and why the
server was affected even though it's registry settings were set to force an
update with an external time source. And - forgive me here, I know I have
read this in one of the docs I've read but have read so many at this point I
dont remember - Is the default action for domain members to try to sync with
the PDCE? If so, why were those GPO settings set to those values - was it
probably just a mistake by the previous guy?

I appreciate any insight you can give...

I was trying to look back in our thread to see if GPOs were mentioned that
were altered for the time service. I couldn't find it anywhere. Sorry I
didn't think about a GPO causing it. I guess I assumed none were involved.
That would definitely be the cause of the machines not accepting the time
commands. Well, actually they would, but as soon as the GPO refresh ran (5
min for DCs), they will revert back to the GPO settings.

Was it a mistake from the previous guy? Probably yes. Reason I say that is
because the Default Domain Policy GPO time settings are all set to "Default"
by default. Apparently he was trying to do something, and apparently didn't
know how the time service works. Another reason I say that is because we
NEVER set OR CHANGE anything in the Default Domain Policy. It has key
settings for the domain to properly function as well as password policies,
etc. If it gets corrupted for whatever reason, such as loading it up with
settings, it's a bit difficult, yet possible, to restore. We recommend to
create a separate GPO for custom settings. If they get corrupted, you can
easily delete and start over, but not so with the Default Domain Policy.

Also we recommend to create and organize an OU structure that matches your
company LOB and locations (if any). Something like the following. This way
you can create and target GPOs specifically. We usually frown on this at the
domain level, except maybe something that has to be domain wide, like the
time settings, but why? By default it works out of the box.

Domain
......Philly OU
...............Accounting
...............Sales
...............Marketing
...............Desktop
...............Users
...............Laptops
......Seattle OU
...............Accounting
...............Sales
...............Marketing
...............Desktops
...............Users
...............Laptops

As I said, by default, all clients and member servers and other DCs will
sync with the PDC Emulator - out-of-the-box. Clients get their time source
from the DC that logged them on. That DC will get it's time synched from the
PDC Emulator in its domain. If its in a child, that PDC Emulator will get
its time synched from the PDC Emulator in the forest root, which should be
configured to an external time source.

So the only thing you really have to configure is the external time source
on the forest root PDC Emulator, then open UDP 123, and when done, go have a
cup of coffee.

OK,
So that was an exceedingly bad idea.

I got a call early this morning saying many people were having trouble
logging on to the AD domain. They initially got a message stating their
profile was corrupted. After rebooting a couple of times most could get on,
but on 5 users, it replaced their profile and established a profile "logon.
000" We had to copy as much information as possible from their original
profile to the new profile, and remap network drives to get them back up.

Besides the gropu policy changes listed in the previous post, one other thing
I did -last night from home - is I ran scans on a group of about 70 PCs and
compared their local time to the PDCE time. If it was off, I executed a "net
time /setsntp:10.4.34.48 " (the PDCE) with a net stop and start w32time, on
the local machine. This occurred on maybe a dozen or so. On some, I also
executed a "w32tm /resync"

When the problem arose, I put the group policy settings back to where they
were (that was before I knew the policy was trashed). Of course this had no
effect on the user problems, and now my PDCE can't sync with the external
time source again.

Somewhere in all of this, between the GP change and the time commands
executed remotely on the local machine, is something that caused corrupted
profiles - some recoverable, some not. Does anyone see what did it? Looking
at one of the users that were unrecoverable, their application log records
the following errors chronologically:

first Userenv 1508 Detail is "The process cannot access the file because it
is being used by another process for C:\documents and settings\'logon'\ntuser.
dat"
1502
1515
1511

Another strange thing is that not every PC on the domain was affected - tho
many were. Some folk logged in and had no trouble.

The ip addresses of the 5 heavily affected users did not match IPs of those I
executed the groups of commands on - but we're DHCP so there is a small (very)
chance that all of them could have got new IP's between last night and this
morning (very very small).

Also when I execute a net time /sntpquery on them, they are not pointed to
the PDCE - which my commands would have done, but are pointed to the default
time.microsoft site.

(BTW, is it correct that the time server settings are on a machine level and
not on a
I am afraid to change anything for fear of blowing up the world again. Any
insight anyone could provide will be appreciated!!!

See my previous post on the disaster that ensued.

I definitely like the idea of not modifying the default domain. Does it have
a return to 'default' setting on these? In light of the problems this morning,
is it safe for me to change this or might I get a bunch of users mad at me
again?

I just thought of something else I did yesterday:

I scavenged WINS and DNS. I don't see how it could apply but I mention it to
be thorough.

I'm actually in the middle of teaching a class today. I will have to think
about and compile a response to your previous post. There is quite a bit
going on between the GPOs, (whatever was inthe default GPO), time, reg
changes, etc. Quite a managerie of issues.

If you feel you need immediate attention, and the problem is causing
production issues with your user base, I HIGHLY suggest to call Microsoft
PSS to help resolve it. They will remote in and assist you to resolve all
issues. When you put in the ticket, just list everything in the one ticket
so there is only one charge. If you bought an SA, you should have 5 free
support calls with your SA, then it only goes against one of them.

I restored the group policy settings to the settings that worked last night -
following the procedure I outlined above, and I'm back to eventID 12.

The server once again insists on trying to synchronize with itself. It seems
insistent on ignoring commands and reg settings instructing it to sync to an
outside source.

Honestly there are changes in the Default Domain GPO that are apparently
causing it, based on what you've described. I believe you need to find a way
to reverse all the time settings. I don't know what else is in the default
policy other than time settings that were changed that would cause a company
wide issue, but I would truly consider trying to get that Default Domain GPO
back to stock (default). Since there were Time service reg changes made
too, it may complicate things. I don't think time settings would cause
profiles to go ballistic. Is there a redirect setting? If you run an RSOP,
what else is in it?

Also, have you considered contacting Microsoft?

Good Idea, I ran it and got a warning on the computer profile. When I viewed
error information, I got a warning on Security. "Security Polices were
proagated with warning 0xd. The data was invalid. Then said to query
"troubleshooting 1202 events" on microsoft. We do have 1202 events. That was
the issue I was going to hit after fixing the time events.

Could this be causing corrupted polices whenever there is a change to the
default GPO that gets propogated to the users?

Also, when I look at the time-providers on the RSOP, they are set to "enabled
- Enabled - Disabled" and when I look at the "configure windows ntp client
properties" it shows the settings that the other guy had in there rather than
the default settings that I had tried to restore (eg NtpServer was still set
to 10.4.34.48 - the PDCE - rather than time.microsoft.com)

Backup the Default Domain and Default Domain Controller GPOs.

Back up a Group Policy object using GPMC: Group PolicyJan 21, 2005 ... To
backup a single GPO, right-click the GPO, and then click Back Up. To backup
all GPOs in the domain, right-click Group Policy Objects and ...

Create another GPO with all those settings you see in the RSOP

Then run the dcgpofix tool to reset the two GPOs to default.
Download details: Windows 2000 Default Policy Restore ToolMay 21, 2004 ...
Recreatedefpol.exe is a tool developed to restore the Default ... where
either the Default Domain Policy, the Default Domain ... Others who
downloaded Windows 2000 Default Group Policy Restore Tool also downloaded:
....
http://www.microsoft.com/downloads/d...displaylang=en

Then start playing with GPO you created instead of the Default Domain GPO.
Make sure the settings apply. When done, then change it, and make sure those
settings apply. If they do, then you can disable it in your GPO, reapply,
then change it to default.

I started another thread for restoring the default domain policy (since the
timesync title doesn't fit that issue) and was looking at just this approach!

Once I have the default back to default, I can return to the time issue if
it's still an issue.

Obviously I'm missing something here.

I created another domain-level policy (called Standard Policy) and modified
it to our normal domain settings - things like 5 passwords remembered instead
of 24. and clicked enforce.

Then I ran dcgpofix and returned default doman, and default domain controller
polices to default.

Then I created a domain controller level policy (called standard dc) with the
domain controller policy cnanges.

but when I look at a GPResults, I can see that the only place the 'Standard"
policy has an effect, is where the Default Domain policy is "not configured"

This suggests that in order to avoid modifying the true Default Domain Policy
(and DC policy I presume), you must create a 'Standard' policy that is
identical to the Default policy, then make changes as desired, then set the
true default to 'unenforced'.

Is this true, or is there a wayto tell it that the 'Standard' policy has
precedence over the 'default domain' policy.

Ok, I found the spot where you promote the policies. As long as it takes the
defaults, and overlays the modifieds (now at the top of the list) I think I'm
ok.

The process resolved the time issues, and resolved the SceCLI errors (or at
least it appears that way thus far)

When I did a GPR with a test user I had established, some things disappeared
from the report that I had thought were default.

local polices/audit policy - audit account management - success/failure ---
is this not default?

System services - Windows Firewall/Internet Conneciton Sharing --- pretty
sure this is not part of the default set

Software Restriction Policies (several associated sections with this one)---
Not part of the default policy?

Administrative Templates - System - Display Shutdown Event Tracker ---Not
part of default policy?

Actually there are several sections in Administrative Templates, and User
Configuration that dropped off. ---- I assume nothing in either of these two
templates are part of the default policy?

My goal was to add as little as possible initially. I will go back and add
changes for the non-default settings after things have run a few days and
(hopefully) I am not seeing further issues.

No, not exactly. I think you are looking at an elephant through a
microscope. Just leave the password and other account settings to the
Default Domain Policy. That's what it's for. If you try to mirror it with
another policy, you will have duplicates resulting in two account policies.
If you want to add additional settings at the domain level, create a GPO and
adjust that for your custom stuff that is not in the Default Domain Policy
by default. Leave the Default settings in the Default policies, and that
goes for both the Default Domain and Default Domain Controller policies.
Hence why they call it "default." I mean you can mess with which one applies
first, but I don't suggest, recommend or even like to mess with the default
policies. It's something all the course teaches, what is recommended by
Microsoft engineers, and it just works. Besides, I constantly hear of issues
when messing with them, such as your posts.

Instead of going through them one by one for you, what I would do to answer
your questions, is use the GPMC to run a report on the Default Domain GPO,
that is if your Default Domain Policy is truly default (you've ran
dcgpofix). Read and compare what is in the report to the list of settings
you posted above.