My 2 cents... Implementation of lag sites is a solution that was recommended to us by our MS Advisory Support Engineer. From what we have been told, MS is writing a whitepaper on implementing lag sites. Not sure when that would be officially released.
Arden On 5/20/05, Myrick, Todd (NIH/CC/DNA) <[EMAIL PROTECTED]> wrote: > I disagree that Lag sites are popular, maybe with you and at AD conferences > as a session. I tend to avoid those sessions. > > To all those considering this as a viable solution, why not run it by MSC or > PSS and see what they say. We get something called a supportability review > before we implement anything to whacky at my organization. > > There are so many things that can go wrong with a improper site design and > object reanimation that I just say avoid doing it. > > I am waiting for Guido to chime in on this. > > Todd > > _____ > > From: Dan Holme [mailto:[EMAIL PROTECTED] > Sent: Thu 5/19/2005 10:16 AM > To: [email protected] > Subject: RE: [ActiveDir] AD DR - replication lag site----Why? > > > > Two more notes on this issue: > > 1) THIRD PARTY AD RESTORE TOOLS. Sounds like it's clear, now, WHY lag sites > are so popular. Yes, there are third party products (particularly Quest > Recovery Manager) that work quite well if you have a budget for that. > Here's my take as to why my IT budget shouldn't be spent on those tools (and > *should* be spent on OTHER tools by some of those same companies). > > a) Deleted objects can be avoided with proper delegation. It's so > important that you properly delegate and properly use accounts with > administrative logon (i.e. with 'secondary logon' only) that this trumps > just about everything. At most of my clients, NOBODY (from a practical > perspective) can delete users or groups. We have a process we call > graveyarding, whereby an account is tagged (using a variety of methods) and, > with a SCRIPT, moved to an OU where they stay for 90 days before being > deleted (again, only by the SCRIPT). The only other accounts that can > delete users and groups are the super-high admins (e.g. Domain Admins > equivalents). This is only a piece of the picture, but it is an important > piece. > > b) Deleted objects can be restored for FREE using ADRESTORE from > Sysinternals. Granted, this tool brings back only the object (SID, GUID, > DN, CN) but that's all that really matters, right? The best (FREE) > approaches we take at clients include *regularly* logging group memberships > in a custom database (to compare to last-knowns and watch for issues easily > and free-ly). So when we restore a group we can repopulate membership > quickly, anyway. So with good processes, it's FREE and easy to restore > objects in most situations. > > c) Windows Server 2003 SP1 adds a feature that makes reanimating > Groups MUCH easier when you have deleted groups & users. No more "auth > restore two times" necessary. (Haven't seen it? Do an auth restore on a > group on an SP1 DC and find the LDIF file it creates!!) > > d) that leaves only really nasty deletions (e.g. an entire OU), > which, given a & b, will probably never happen. And when they do, an auth > restore on a lag site takes a very short time. > > e) therefore, I save my IT budget and use the $ on tools to aid > provisioning, auditing & monitoring, again to avoid problems in the first > place. > > 2) PREVENTING AUTHENTICATION ON LAG SITE. As I mentioned, the method I've > heard of, and that we're testing, is to stop the NetLogon service on the lag > DCs. There are several ways to avoid it restarting when/if the DC is > rebooted. The article referenced in the ORIGINAL post suggested modifying > which SRV records are registered. This should work, I'd guess, and is more > elegant. The trick is that SRV records are not registered. The A records > still are, so DCs should be able to find each other and replicate > successfully, but clients won't 'see' the DCs as a viable authentication > option. I've not tried that approach but it sounded really good. > > 3) OK, three notes. LAG SITES can be done with DCs in a site with a long > replication interval, or by changing the replication WINDOW (schedule). > It's a good idea to have TWO lag sites on alternating frequencies, to avoid > a situation where something awful happens just before a lag site happens to > replicate. Someone detailed this earlier, and it's a good note! > > Dan > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] On Behalf Of Myrick, Todd > (NIH/CC/DNA) > > Sent: Thursday, May 19, 2005 6:34 AM > To: [email protected] > Subject: RE: [ActiveDir] AD DR - replication lag site----Why? > > Is it cheaper and more efficient to go the replication lag site route than > buy a proper backup and object level restore solution? > > I mean not to toot a vendor's horn, but Quest recovery manager turns the > process of restoring objects into a 15 minute click click operation. I > would hate to think of the number of steps you all must do to reanimate the > object in a directory using the "Recovery Site". > > >From a operations standpoint, there is no substitute for a proper backup > solution and object level restore utility for AD. > > Thanks, > > Todd Myrick > > -----Original Message----- > From: TIROA YANN [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] > Sent: Thursday, May 19, 2005 4:20 AM > To: [email protected] > Subject: RE: [ActiveDir] AD DR - replication lag site > > Neil, > > I now understand... I'm a new man by now thanks to the mysterious lag site > that have been revealed to me :-)) > > Thanks a lot for your explanations. > > Cordialement, > > Yann TIROA > > Centre de Ressources Informatique. > Campus Scientifique de la DOUA. > Bât. Gabriel Lippmann - 2 ème Ã(c)tage - salle 238. > 43, Bd du 11 Novembre 1918. > 69622 Villeurbanne Cedex. > > > > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] De la part de Ruston, Neil > EnvoyÃ(c) : jeudi 19 mai 2005 10:09 > À : '[email protected]' > Objet : RE: [ActiveDir] AD DR - replication lag site > > If the deletion occurs on DC1, then a DC (DC2) in the lag site will not > receive the deletion immediately. You therefore have a window of opportunity > > in which the deletion may be 'undone'. > > The deleted object may be auth restored on DC2 and thus replicated / > reanimated on DC1 (and any other DC which has received the deletion). > > [My terminology may not be acceptable to some - I have deliberately > explained this in simplistic terms :)] > > neil > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] On Behalf Of TIROA YANN > Sent: 19 May 2005 08:54 > To: [email protected] > Subject: RE: [ActiveDir] AD DR - replication lag site > > > Hello, > > I must apologize, but i'm a little bit confused. You said "With a lag site, > you ONLY have to do an authoritative restore (NTDSUTIL)". > > Do you mean if i delete my OU in DC in site A, all i have to do is do an > autoritative restore, not on site A, BUT on DC on lag site, reboot, and > dforce replication to site A ? And the non-autoritative restore will be in > fact the data on the lag site, that explain your prÃ(c)vious sentence ? Waou! > That's very celver !! > > Am I right ? > > Regards, > > Yann > > > > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] De la part de Dan Holme EnvoyÃ(c) > : > jeudi 19 mai 2005 08:51 À : [email protected] Objet : RE: > [ActiveDir] AD DR - replication lag site > > The major issue is the SPEED of recovery. With a lag site, you ONLY have to > > do an authoritative restore (NTDSUTIL). > > Without a lag site, you must first restore the AD from backup tape ('normal' > > restore), which can take quite some time!!!! Then, and only then, can you do > > the auth restore. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] On Behalf Of TIROA YANN > Sent: Wednesday, May 18, 2005 11:46 PM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: [ActiveDir] AD DR - replication lag site > > Hello, > > Thanks for this interesting tips, but i didn't really understand the "behind > > the techno" of a lag site in case of just a deletion of an entire OU with > many objects. > > For example,if I have AD 2003 domain with 2 sites: > Site A has 2 DCs > Site B has one DC and is the lag site > Between 2 sites, i scheduled repl to appear every 1 week. > > In the situation of an OU deletion, i go to the DC i have made the deletion, > > and do an autoritative restore in dsmode and after rebbot, wait for > replication to take place in order to repopulate all my domain with my OU > restored. So what will the lag site help me in this situation ? > > I can understand that a lag site will help me if all my DCs in site A > crashed. So i would take all informations from the lag site to be restored > in site A such as "copy" my domain from the lag site by doing a dcpromo > /adv, and go my freshly installed DCs on site A, and restored my whole > domain. > However, I think i will have more updated information by restoring from my > yerterday backup than from the lag site... > > So, could you help me better understand the behind the techno of a lag site, > > i thing i misunderstand something important ;-( > > Thank you for your feedback. > > Have a nice day :-) > > Regards, > > Yann > > List info : http://www.activedir.org/List.aspx > <http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx > <http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > <http://www.mail-archive.com/activedir%40mail.activedir.org/> > List info : http://www.activedir.org/List.aspx > <http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx > <http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > <http://www.mail-archive.com/activedir%40mail.activedir.org/> > > ============================================================================ > > == > This message is for the sole use of the intended recipient. If you received > this message in error please delete it and notify us. If this message was > misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not > waive any confidentiality or privilege. CS retains and monitors electronic > communications sent through its network. Instructions transmitted over this > system are not binding on CS until they are confirmed by us. Message > transmission is not guaranteed to be secure. > ============================================================================ > > == > > List info : http://www.activedir.org/List.aspx > <http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx > <http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > <http://www.mail-archive.com/activedir%40mail.activedir.org/> > List info : http://www.activedir.org/List.aspx > <http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx > <http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > <http://www.mail-archive.com/activedir%40mail.activedir.org/> > List info : http://www.activedir.org/List.aspx > <http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx > <http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > <http://www.mail-archive.com/activedir%40mail.activedir.org/> > List info : http://www.activedir.org/List.aspx > <http://www.activedir.org/List.aspx> > List FAQ : http://www.activedir.org/ListFAQ.aspx > <http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > <http://www.mail-archive.com/activedir%40mail.activedir.org/> > > >
