I would tend to agree with what David is saying from what I have seen of lag sites as well.
Not many people, relatively, doing it, those that are are likely to be doing it in a rough shod way. I am not a huge fan of lag sites. I think they are ok, but for instance didn't think they deserved 3 or 4 different speakers talking about it at the DEC in DC a couple of years ago. I am far more interested in taking away the rights from people to do the stupid deletions in the first place like was mentioned previously. Seriously, I have done 0, count them, 0 restores of objects in production and have been involved in some rather seriously sized implementations, 5 years of lead AD tech for a Fortune 5 directory. The lax decision of accidental deletions happen is not a mentality I am like to subscribe to. If someone deleted something, my feeling is, they knew what they were doing and they were adequately aware of what they did. First off, don't delete right off. Disable, rename, and move. Second off, don't do admin through the GUI, too easy to click on an OU when deleting than a single user. Third off, don't let people have the power to delete things. Let them request deletes of automated systems that are designed to follow good rules so appear to be smarter than the admins. There were mentions of supportability, etc. I would not be surprised to hear MS say this is supported. Honestly, it isn't that whacky from a technical standpoint. However, if someone has gone the supportability review process I *HIGHLY* recommend they keep any and all docs with the names of the MS people involved locked up and saved. I have had it occur more than once over the years where I was told something was supported and fine and then several years later have them looking at me saying they would never have approved this or that. Some of the times I didn't have docs and was screwed as MS I have found is fond of saying "we don't have any documentation of that being said or being done", other times I had docs and then I see PSS trying to find reasons why they missed the issue or something else in the doc not being followed that they try to imply makes the whole thing moot. Unfortunately PSS will declare a lot of things as unsupportable even if they have no good answer themselves, for instance, scripted GPO deployment pre-GPMC. There were several years there that people were forced to come up with their own mechanisms for scripted GPO deployment before GPMC was released because the normal GUI just wouldn't cut it, they are all unsupported by MS. Unfortunately companies won't tend to find out until they contact MS about it or PSS stumbles upon it. Back to lag sites, you, of course, have the possibilities of directory corruption, etc where you lose the entire directory in one fell swoop. A lag site could be used here but an auth restore is probably not going to be what you need to save you, you need to rebuild everything. Personally over a lag site I would use a site with a bunch of virtual DCs that you are taking down together and backing up the disk images of and then if you need to roll back, you pick the day or 4,6,8,12 hour period and roll back to it once everything else has been taken offline and you build the rest of your environment back out from this "seed" environment. This gives you the additional benefit of having an environment you can take into a segregated lab and test stuff any time you need to. It just needs to be done right or you will have Brett snickering at you. As I mentioned in an earlier post, if you are afraid of deleted objects, I would recommend judicious use of searchflags&0x08 and admod with the -undel option. Couple that with a simple AD/AM directory that you don't let your loose cannon admins to have access to and you can pretty easily get things back. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Adner Sent: Friday, May 20, 2005 5:24 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD DR - replication lag site----Why? 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: ActiveDir@mail.activedir.org > 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: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org > 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: ActiveDir@mail.activedir.org > 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: 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/ > > 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/
