Using my non-scientific personal observations, of the last 50 or so customers I've been to I believe only 3 had lag sites. Of those 3, none had done what I'd call a good job of setting it up (they had basically just created a separate site with a longer replication interval). Of the other ~47, perhaps half knew of lag sites and were either interested in the concept or had plans to implement them. How many actually will I can't say. These are all Premier customers.
So, based on my personal experience, I'm more inclined to agree with Todd. I think, however, that over the next couple years lag sites will become the norm as virtualization becomes commonplace and best practices are better documented and understood. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan > Sent: Friday, May 20, 2005 15:49 > To: [email protected] > Subject: RE: [ActiveDir] AD DR - replication lag site----Why? > > Todd, > > With all due respect, I think there are more people doing > this than you think. You aren�t using a Lag Site, so it�s > �whacky�. Your opinion, so you�re entitled to it. > > PSS blessed our implementation, BTW. If you�d like, I�ll be > happy to provide you with contacts for the ROSS tech (out of > Los Colinas) that did our recent AD Health check in advance > of our Win2k3/E2k3 upgrade. He stated that this was becoming > a cheap, scalable solution to providing DR � and a few large > organizations were using them at warm/hot sites because they > also meet criteria for DR as addressed and required for Sarbanes. > > And, I don�t question the fact that a poor site design can > cause problems. But, humbly, I submit that I know what I�m > doing. Learn from what I do � or learn not. That�s up to > you. I know that you have a liking for Quest � which is > fine. I use some of their tools � just not Recovery Manager. > However, in a DR situation when your DCs are being rebuilt > from scratch � Recovery Manager is not a very valuable tool > when there are no objects to �undelete�. > > As for Guido � I hope he chimes in as well. He seems to be > one of the few that you trust � regardless of those that have > supported you in the past. Hopefully then � we can put this > behind us. Me, I�ll keep doing what has been successful for > me for two years, thank you. > > -rtk > > > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Myrick, Todd (NIH/CC/DNA) > Sent: Friday, May 20, 2005 11:59 AM > To: [email protected]; [email protected] > Subject: RE: [ActiveDir] AD DR - replication lag site----Why? > > > > 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] 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] > 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 �tage - salle 238. > 43, Bd du 11 Novembre 1918. > 69622 Villeurbanne Cedex. > > > > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Ruston, Neil Envoy� : 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] 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�vious sentence ? Waou! > That's very celver !! > > Am I right ? > > Regards, > > Yann > > > > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Dan > Holme Envoy� : > 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] 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 > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > 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 > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
