I must say I've enjoyed this thread immensely - I think it's generated more discussion than any other innocent queries I've posted to the list :) In our case, Joe, it's a hub-and-spoke branch-office kind of model, single domain. As Roger said, I'd hate to be the PDCE back here at headquarters - if the same change happened at all 50+ remote DCs at the same time, they'd all hit the PDCE with an RPC update at (roughly) the same time. That fact alone is enough to discourage it, as far as I'm concerned.
Since we're rolling out SP4 right now, I think I'll pass on that feature. Thanks for all the comments ! Dave -----Original Message----- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 9:48 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs That nicely sums up what I've been trying to say - it would be a discrete change done on each DC, rather than one change done on multiple DC's. -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -----Original Message----- > From: Joe [mailto:[EMAIL PROTECTED] > Sent: Friday, August 01, 2003 10:29 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs > > > Good explanation but I want to modify a bit. Note I am not > talking about > downlevel replication at all, that is simple, it replicates > out from the > PDC once the BDC receives the UAS_CHANGE packet, have a nice day. :o) > > Note that the mastering DC will still send the changes out as normal > replication. The straight out of band shot to the PDC will > occur (unless > specified flag is set or the PDC is out of contact) which will then > start its replication but then the mastering DC will replicate to its > direct partners as well. > > So say you have a single site with say 10 DC's with DC1 as PDC this is > what I would expect would happen. You make change on DC10. It > sends the > change to DC1 immediately as a normal change (i.e. like it was change > requested from any client for instance) and then you now have 8 DC's > with the old password and 2 with the new password. The PDC having the > change with the latest time stamp or if everything was really > fast, the > time stamp being the same as on the other DC. Now it is a race, they > both send out the change notifications and the partners will start the > pull. These changes will replicate around and depending on > how the ring > is set up (are DC10 and DC1 direct partners for instance or three hops > from each other) varying amounts of replication will occur until the > changes collide and have to go through conflict resolution. If the PDC > has the later change, it wins. If they are at the same time you go > through the rest of the resolution process probably falling > to whomever > has lowest GUID wins. > > Now expand to two sites (very simple spanning tree if you can > even call > it that). The mastering DC is in site 2 and the PDC is in > site 1. Change > occurs on the masterering DC, it fires it to the PDC. The master then > replicates it around site 2 and the PDC replicates it around > site 1 both > following normal site replication rules. The changes hit the > bridgeheads > and both changes get passed both ways. Now the bridgeheads > need to look > at the change and say, hmm is this newer? If so, apply it, otherwise > toss it. If changes at the same time, go through the rest of the > conflict process. Most likely the PDC change will overwrite the change > of the local mastering DC in site 2. So Site 2 will have gone through > replication for the changes from mastering DC and then for the change > that went to the PDC. Obviously this can be modified by > timing and cross > site replication schedules and how fast the changes made it to a > bridgehead. For instance if the change was mastered on a bridgehead in > site 2 and the rep schedule was in progress already the change from > mastering DC could get to site 1 and start replicating there > as well as > in site 2 prior to the PDC change sweeping through and overwriting due > to last change. > > Now expand to more than two sites. If you have a hub and spoke changes > mastered on site 2 will most likely get no farther than site 1 (hub) > assuming they even get out of site 2. If you have a spanning tree with > multiple site hops along the tree between the mastering > DC/Site and the > PDC/PDC Site then the changes will meet somewhere in the > middle and you > have even more wasted replication. > > Now start making these changes on multiple domain controllers in the > same site, how does that affect things. First off every > change gets back > to the PDC so if you have 10 DC's you hit with a change, 10 > changes hit > the PDC via direct calls. Now things start replicating and last change > wins in all of the conflict resolution and there would be conflict > resolution until the changes all converged to the last > written change. > > Expand to multiple sites... Oy. You figure it out. :oP You have 50 > DC's you make the change on in 50 sites and the PDC gets hit with 50 > direct changes and in the meanwhile has probably started > replicating the > change from the first couple of change calls (depending on > how fast all > the initiating changes went through) and you get to figure > out where all > of the DC's would have collisions with each other (most likely on > bridgeheads) and various amounts of changes will get so far until you > get convergence to, most likely again, the last change the > PDC saw which > would then replicate out over top of all the other changes that had > replicated around including over top of the DC's that had the change > mastered on it. > > Does that make sense? This is based on reading and things I have seen > through the years. If not or this is wrong, please speak up. I would > really like to hear if Stuart Kwan agrees or if Trulli > watches this list > it would be good to hear from Dave again as well. > > > > Thanks. > > joe > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan > Sent: Friday, August 01, 2003 9:20 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs > > > Roger, > > If each DC is connected to a given DC, and the topology is > laid out even > remotely properly, the max hops that a replication are going > to take is > 3. The connected partners are going to replicate, and then > the event is > going to be done. There is not going to any need to replicate changes > to a DC that already has seen it - as the USNs should certainly > accommodate, and prevent. > > Consider this from Q225511: > ------------ > By default, machine account password and user password > changes are sent > immediately to the PDC FSMO. In a mixed-mode domain, if a Microsoft > Windows NT 4.0 domain controller receives the request, the client is > sent to the PDC FSMO role owner (which must be a Windows 2000-based > computer) to make the password change. This change is then > replicated to > other Windows 2000 domain controllers using Active Directory > replication, and to down-level domain controllers through the > down-level > replication process. If a Windows 2000 domain controller receives the > request (either in mixed or native mode), the password change is made > locally, sent immediately to the PDC FSMO role owner using > the Netlogon > service in the form of a Remote Procedure Call (RPC), and the password > change is then replicated to its partners using the Active Directory > replication process. Down-level domain controllers replicate > the change > directly from the PDC FSMO role owner. > > If the AvoidPdcOnWan value is set to TRUE and the PDC FSMO is > located at > another site, the password change is not sent immediately to the PDC. > However, it is notified of the change through normal Active Directory > replication, which in turn replicates it to down-level domain > controllers (if the domain is in mixed mode). If the PDC FSMO > is at the > same site, the AvoidPdcOnWan value is disregarded and the password > change is immediately communicated to the PDC. > > ----------- > > The default clearly states that the local DC receives the change, and > then the PDC-E is immediately notified via RPC - Not normal > replication. > Then, the PDC-E changes the rest of the DC's via the normal > replication > cycle. This will, in effect, reduce the overall impact of > replication to > some degree, but again, to directly connected partners (max of three > hops). > > Now, if AvoidPdcOnWan is modified to be TRUE, then normal > replication is > the mechanism of change, but from the site DC if the PDCE is > not in the > same site. But, it's still going to be a max of three hop replication > to directly connected partners. > > In now way am I saying that each DC doesn't need the update - they do. > I just suggest that it would not necessarily be a storm of > updates. In > a 10 DC structure, the local is going to be changed. The > PDCE is going > to be notified and is going to change itself with a call via RPC from > the changed local DC - not replication. The PDCE is then > going to send > change notification to it's directly connected partners, > which could be > done, theoretically, in two replication notices from the > PDCE, with two > other DCs being responsible for two partners. Each of the > others would > only have one. In 3 hops maximum, you would have all 10 DC changed - 2 > of those almost immediately and not participating in > replication at all. > > Rick Kingslan MCSE, MCSA, MCT > Microsoft MVP - Active Directory > Associate Expert > Expert Zone - www.microsoft.com/windowsxp/expertzone > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Roger Seielstad > Sent: Friday, August 01, 2003 6:04 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs > > I guess I'm trying to figure out why replication would be limited to > just the connected partners. Wouldn't the change on each DC cause the > USN to be incremented for that DC's replica? In that case, every other > DC would see it as a change which needs to be acquired during > replication? > > I guess there would be some consolidation at the site bridgeheads, but > even then, there should still be 1 change per DC being > replicated to N-1 > domain controllers. > > -------------------------------------------------------------- > Roger D. Seielstad - MTS MCSE MS-MVP > Sr. Systems Administrator > Inovis Inc. > > > > -----Original Message----- > > From: Rick Kingslan [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 31, 2003 10:10 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] Simultaneous password change on > multiple DCs > > > > > > Roger, > > > > Apparently, I need to clarify what I meant. In relation to the > > product that was proposed, the normal password replication would be > > minimized to immediate connected partners - so, IMHO, this > wouldn't be > > > a storm but a bit of a burst (squall???) > > > > Rick Kingslan MCSE, MCSA, MCT > > Microsoft MVP - Active Directory > > Associate Expert > > Expert Zone - www.microsoft.com/windowsxp/expertzone > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger > > Seielstad > > Sent: Thursday, July 31, 2003 5:59 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [ActiveDir] Simultaneous password change on > multiple DCs > > > > Actually, why would it be minimized? The password change is > happening > > on every domain controller, and as suck looks like a > discreet change > > to the PDCE - meaning its gonna kill the PDCE. > > > > -------------------------------------------------------------- > > Roger D. Seielstad - MTS MCSE MS-MVP > > Sr. Systems Administrator > > Inovis Inc. > > > > > > > -----Original Message----- > > > From: Rick Kingslan [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, July 30, 2003 10:12 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] Simultaneous password change on > > multiple DCs > > > > > > > > > Gil, > > > > > > > Making the same change on multiple DCs is bone-headed > > > As anyone who has had to clean up or troubleshoot the > appearance of > > > CNF: > > > objects can attest to.... > > > > > > And, yes - I concur that the password changes are all > > propagated via > > > the PDCE and the replication traffic would be minimized because of > > > such. > > > > > > Rick Kingslan MCSE, MCSA, MCT > > > Microsoft MVP - Active Directory > > > Associate Expert > > > Expert Zone - www.microsoft.com/windowsxp/expertzone > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Gil > > > Kirkpatrick > > > Sent: Wednesday, July 30, 2003 8:43 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [ActiveDir] Simultaneous password change on > > multiple DCs > > > > > > Making the same change on multiple DCs is bone-headed, but I don't > > > think it will generate much additional replication traffic. > > Aren't the > > > password changes forwarded to the PDC FSMO role owner for > > the domain > > > and then replicated from there? If that's true, then the redundant > > > changes coming into the PDCE should be dropped (generally, > > changing an > > > attribute to its current value has no effect). So the additional > > > password changes will each generate a message to the PDCE, but > > > otherwise not much else. > > > > > > Or am I missing something? > > > > > > -gil > > > > > > > > > -----Original Message----- > > > From: Roger Seielstad [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, July 30, 2003 1:22 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [ActiveDir] Simultaneous password change on > > multiple DCs > > > > > > > > > That strikes me as a way to cause replication storms in a flash, > > > depending on how the application is written. Say you have > > 10 DC's, and > > > this app changes the password on all 10 dc's. That's at least 81 > > > different replication messages, since each DC will > > recongnize that as > > > a different change. > > > > > > Seems to me to be both overkill and unnecessary. > > > > > > -------------------------------------------------------------- > > > Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator > > > Inovis Inc. > > > > > > > > > > -----Original Message----- > > > > From: Fugleberg, David A [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, July 30, 2003 3:23 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: [ActiveDir] Simultaneous password change on > multiple DCs > > > > > > > > > > > > We're looking at a product to manage passwords - it > > enforces common > > > > password policy and keeps passwords in sync across multiple > > > > platforms (mainframe, AD, NDS, Unix, etc.), as well as provides > > > > self-service password change/reset via a browser interface. > > > > > > > > One of its features on AD is that it's nominally > > site-aware - it can > > > > determine a browser's location based on IP address and > > change the AD > > > > password on a DC in that site. So far, so good. Now the tricky > > > > part - it can also be configured to ALWAYS change the > password on > > > > one or more DCs that you specify on the config, in > > addition to the > > > > one it selects. > > > > The idea is to specify DCs near resources at headquarters that > > > > people access from branch offices. This is supposed to > > ensure that > > > > people can access the resources immediately rather than > > waiting for > > > > the new password to replicate. > > > > > > > > Net result is that the same password change is applied > > directly at > > > > multiple DCs in different sites at the same time. > > > > My question is, what is the impact on the DCs and replication > > > > traffic ? What are the caveats of such a scenario ? > > > > > > > > One other thing - the helpdesk can use the web interface > > to assist > > > > callers who choose not to use self-service. In that case, the > > > > helpdesk can see a list of all DCs and select the > > > > one(s) they wish to send the change to. This can be > > disabled, but > > > > is the default if you enable 'site-awareness'. > > > > This bothers me a bit, since there's nothing to prevent a > > helpdesk > > > > person from selecting 'em all. Your thoughts ? > > > > > > > > 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/ > > > > > > > > > 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/ > > > 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/ > 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/
