Well, we seem to be ok now. The repadmin /showmeta deal was one of the early things
we tried in hopes of narrowing it down, but the values of three of those attributes
kept incrementing and the Org DSA would be different virtually every time, so it was
hard to chase back. Operations started noticing isues around 1:30 Thursday afternoon,
and I got pulled in around 3:30 or so. After checking a few things and realizing that
it was a policy flip-flop issue I advised them to contact PSS - it was some time
before they actually did. After 4 hrs of working with PS over the phone, they
escalated and our TAM sourced a local engineer, but it was around 11:30 before he was
able to get there. He spent the night trying to isolate it - turned on some
additional auditing, etc. Early this morning he turned off FRS on the PDCE and saw
the GPT for the default domain GPO change on that DC anyhow - it was being changed by
something under SYSTEM, but couldn't be more specific. The problem seemed to
stabilize after that, however. (Note - it had stopped for well over an hour once late
in the evening but then resumed).
Anyhow, by 8:30 or so this AM we were pretty fried - fresh troops had arrived, things
were quiet, and MS had escalated to Dev as they were unsure of the culprit. I went
home and got a little sleep. I woke up a little while ago and checked in - apparently
things are OK. They restarted FRS and got the PDCE's SYSVOL back in sync, and all has
been holding. MS basically said 'we're not sure why it happened', 'every case is
different', etc. Not that I'm dissing them - they did a lot of work to chase it, and
we certainly could have been better prepared if we had been auding object access and
been able to figure out where it started. I haven't talked to them directly yet to
see what, if anything, happened with their escalation to dev (they were doing so to
see if they could determine what precisely was doing the changes in the SYSVOL on the
PDCE when FRS was disabled).
Anyhow, so much for the day off I was supposed to have today... If we learn any more
about root cause, I'll repost. At this point, we may never know. If nothing else, it
added some fuel to my oft-repeated request to get some outside expertise to come in
and help me define/implement improvements to our AD structure and monitoring - it's
easy to get isolated in your thinking when you don't get to move around and see how
things work in other environments. That's why this list is invaluable - thanks to all
of you !
Dave
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of joe
Sent: Fri 5/14/2004 11:23 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [ActiveDir] HELP ! - password policy changing on replication
When it flips to a bad value, check the originating DSA with repadmin
/showmeta, that should show you where the bad value came from which is
*probably* on a machine where a GPO INF file that hasn't been updated.
An alternative thing would be to do a CRC check of all files in all sysvol's
and look for the stuff that varies.
joe
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fugleberg, David A
Sent: Thursday, May 13, 2004 6:31 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] HELP ! - password policy changing on replication
Further info - I found a posting by Joe that describes a similar issue - by
looking at repadmin /showmeta on a DC where the policy is wrong, I can see
the version of the 'wrong' attributes (like MaxPwdAge) is very high (>60)
with today's date and recent time, while the others are at 1 with the
date/time of when we installed AD over 3 yrs ago. Clearly something is
causing this to change on a DC someplace. I hoed the "Originating DSA"
would tell me where the problem lies, but each time this flip-flops I see a
different DC in that field.
I need to know what to look for to figure out a) which DC is originating the
problem and b) where the problem is. I suspect something related to our
domain policy is corrupted on some DC, causing it to set itself to default
values at its policy refresh, and this is replicating. Then whe other DCs
refresh their policy properly, they get the correct settings. Can anybody
help ? We're working our way to the right folks at MS PSS at this point...
Dave
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Fugleberg, David A
Sent: Thursday, May 13, 2004 3:58 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] HELP ! - password policy changing on replication
We're experiencing a problem which I'm sure I've seen documented
before...just can't remember where.
Symptom is that people are having passwords expire prematurely - suddenly
they're prompted for id/password when trying to access a resource, and if
they log out/in they are told their password has expired. If, on the other
hand, they just wait a bit instead of logging out/in, things work in a few
minutes. It bounces back and forth every five minutes or so. Our Max
password age is 90. When the user is OK, the time until expiration (as we
calculate it based on PwdLastSet and Max Password Age) is what we expect.
When the user is having problems, it appears it expired at 42 days.
I recall something about password policy being set incorrectly so it
flip-flops between 90 and 42 days. Can anybody tell me what that was all
about ???
Dave
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
â²Ø~ˆm¶Ÿÿà rØyØ¢¸?™¨¥–+-†ÙŠËEm¶Ÿÿà rØyØ¢¸?–+-}ª¡¶bâ²Ör¯zm§ÿðÃ
šŠV«r¯yÊ&ý§-Š÷4™¨¥iËb½çb®Šà
