Idan,
If any bullets fly your way, I promise to put myself in front of their path,
because I am "The One"... "The Toddler" I have mad powers yo... (At least in
this Matrix).
I think your post was not problematic in the least, and offered good
information without blatant self promotion.
There are two keys to using a mailing list for marketing, just like in the
movie The Matrix, in the Kitchen of the Oracle, there was a sign in Latin,
and it translates to "Know thy self". It is obvious from your post that you
know yourself and the value your companies product has to solving this
person's problem. Also in The Matrix, on the way out of the door of the
kitchen there was another sign in Latin that said. "Only in Moderation".
The Oracle offers Neo a cookie to console him because she tells him he isn't
the one. (This one ain't to bright is he? Was her actual words....AMEN).
The thing is Neo does eventual embrace his natural gifts once he gets over
the fear of rejection, and doesn't eat all her cookies (Unlike the guy who
is eating the steak).
So I applaud you for taking the necessary risk, and to reward you some what,
I forwarded this thread to my manager for review because we have the same
problem here. If we are interested we will contact you.
I encourage you to continue to contribute to the knowledge this community is
building as payment for your free marketing. And remind you "Only in
Moderation." I am "The One" here who promotes Vendors products a lot,
because I am not a Vendor, I am a customer, and the Institution I work for
wants to make sure that everyone has an opportunity to develop and promote
their products. That institution is the U.S. Government.
Also please take an opportunity to go to www.bindview.com and look over
their security products. They are looking pretty nice, and I owe them for
the phone call they gave me when I said that I was mad at them. I am no
longer mad at them because of the way they treated me, and encourage you all
to click on the link above. Also I promise never to express my feelings
publicly about a problem I have with a vendor as well. It isn't very
professional of me, and I applaud the way Bindview people handled the
situation by validating my feelings, and empathizing with my position.
So if anyone needs to get flamed here it is me.
Night all.
Remember: Good artist copy, great artist steal.
The ideas expressed in this message were from the book "The Philosophy of
the Matrix". I encourage you to pick it up and read it, along with the book
Seinfeld and Philosophy, Robbie Allen's AD cookbook, and Chris Wolf's
Troubleshooting Microsoft Technology book that just came out.
The Toddler
-+SMT+-
-----Original Message-----
From: Dummy account for mailing lists [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 03, 2003 8:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs
Hi guys,
At the risk of getting a bit flamed, let me wade into this. :-)
I work for the vendor that makes this software (P-Synch from M-Tech), and
I think a bit of clarification would be helpful:
* The problem we address with the facility than supports writing a
new password to multiple DCs is slow replication of the transition
of the intruder lockout attribute on AD user objects from the locked
to the unlocked state. The following scenario is the one and only
situation in which we would suggest to a customer to write password
updates to more than one DC at a time:
- There is a large, distributed AD domain (one production example is
400 DCs spread over 70 countries).
- Users throughout the distributed domain access either a central
help desk or a central password-reset web application to reset
forgotten passwords, and in particular to clear intruder lockouts.
- The central server or help desk facility by default sets paswords
and clears lockouts on a central DC (typically not the FSMO).
- Users must subsequently and immediately access resources from
DCs other than the one where the password reset / intruder unlock
happened.
- The AD domain runs Windows 2000 (slow replication of intruder
unlocks was supposedly fixed for 2003, but I haven't verified
yet).
* If any of these is false for your organization - don't write
password updates / intruder unlocks to multiple DCs. There *will* be
extra replication traffic, and you should not introduce that without
good reason. Our product certainly doesn't write to multiple DCs
by default -- you have to explicitly configure it to do that.
* If every one of these conditions is true for you, then depending on
where your users are, your network infrastructure, bandwidth, latency,
replication schedule, etc., you may be getting complaints from the IT
support organization that an intruder unlock made by the central help
desk or web GUI can take hours to effectively reach every resource
the user needs to access.
This is pretty awful user service, and short of Windows 2003, Microsoft
tells us that there is no automated fix planned for this.
* If you're still reading, you're either just curious or you have this
problem in your organization. With our software (http://psynch.com/),
you can make password updates, combined with clearing intruder
lockouts, on a few select DCs at a time. We have site-aware logic,
plus some manually-defined rules to figure out which DCs to touch
for a given user at run-time. In practice, we'll touch from 2 to 5.
We don't, and you should never, reset a user's password on every DC
in the domain. A handful of DCs, judiciously selected based on the
user's current IP address, the IP of the user's home directory
hosting server, and DCs near resources like mail and web servers the
user is likely to sign into are more than enough.
* When we reset passwords / clear lockouts for a user on multiple DCs,
that user gets "back in business" immediately, rather than waiting
for AD replication of the cleared intruder lockout attribute. This
is a big deal to affected users, and to global IT support groups.
* Faster user service comes at the cost of some extra replication
packets. There is no free lunch, unfortunately.
* Total replication traffic is not very large, and the FSMO is not
slammed. This is because DCs are smart enough to not replicate
attribute changes where the final value is the same as the initial
value. We only know the latter from empirical evidence, but we do
have this in production at some very large global enterprises, and
they are quite happy with this (admittedly aggressive) strategy.
So the bottom line from this long message is:
* Never write to multiple DCs unless you have a compelling reason to.
* Such reasons do exist, but are not the norm.
* The impact of doing this is quite manageable, but should be
considered carefully.
I hope this helps!
Cheers,
-- Idan
On Fri, 1 Aug 2003, Rick Kingslan wrote:
> Yep - I won't disagree on the PDCE needing to be in good health and quite
> ready for some reasonable update traffic - local or cross-site.
>
> 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 8:50 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs
>
> I'm starting to see where you're coming from - in the end, its still a bad
> idea, at least from a replication standpoint.
>
> At the very least, you'll get n-1 DC's worth of updates to the PDCE - as I
> said, I'd hate to be the PDCE in that envrionment....
>
> --------------------------------------------------------------
> Roger D. Seielstad - MTS MCSE MS-MVP
> Sr. Systems Administrator
> Inovis Inc.
>
>
> > -----Original Message-----
> > From: Rick Kingslan [mailto:[EMAIL PROTECTED]
> > 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/
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/
