Title: RE: [ActiveDir] AD DR - replication lag site----Why?

Thanks Rick,

I didn't think it to strong.  And took no offense.

As most of you know,  I am a "buy" guy.

When I reviewed AD back when, I new that we were in trouble if we had any accidents with administration.  We allow for delegated administration with-in our AD design, so the only way to protect the directory and have a way to rapidly recover the object was to use a solution like Quest Recovery Manager.  We have had quite a number of restores to fix issues.  Could manage doing a recovery site to recovery an OU deletion, or

Going to Exchange 200x we knew the idea of having a recovery forest was not going to work in our operation... think of the number of production servers you have to patch.  So we evaluated solutions that allowed object level restores on mailboxes as well.

When it comes to operations, I want fast and easily reproducable results.  That means object restores and mailbox restores should take less than an hour.  My old operations would take 8 hours to do a simple mailbox restore.  And we have had situations with mis-configured ADC's killing objects in AD.  So I am a big fan of technology that allows for rapid restore of information.

I think it is a sin that MS doesn't incorporate this with their AD and Exchange products.  You can get into a lot of trouble if you don't have these types of tool if you aren't experienced IMHO. 

Todd

 
 

-----Original Message-----
From: Rick Kingslan
To: [email protected]
Sent: 5/21/2005 12:17 PM
Subject: RE: [ActiveDir] AD DR - replication lag site----Why?

It was brought to my attention that I came off a bit strong (and that
might be mild...) in this message to Todd.  I've sent him a personal note
of apology, and I don't believe in tearing someone up in public and then
apologize in private.

 

Todd - I'm sorry for the way that I worded this message.  We have our
own ways of doing things, and that's what makes life interesting.  And,
there are a 100 ways of doing something, and I'm glad that we have the
ability to discuss these ways here, and debate them.  Sometimes with me,
however, personal bias goes a bit too far.

 

So, please accept my apologies.  I'm sorry for the 'tone' of my message.

Rick Kingslan  MCSE, MCSA, MCT, CISSP
Microsoft MVP:
Windows Server / Directory Services
Windows Server / Rights Management
Windows Security (Affiliate)
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
WebLog - www.msmvps.com/willhack4food

  _____ 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Rick Kingslan
Sent: Friday, May 20, 2005 3:49 PM
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]
<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 �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� : 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�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� :
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/

Reply via email to