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: ActiveDir@mail.activedir.org 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: ActiveDir@mail.activedir.org 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 À : 'ActiveDir@mail.activedir.org' 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: ActiveDir@mail.activedir.org 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 À : ActiveDir@mail.activedir.org 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]; ActiveDir@mail.activedir.org 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/