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/

Reply via email to