|
Merely
increasing the tombstone lifetime is by no means sufficient if only a percentage
of representative DCs are restored ... even in a virtual environment. More
potential AD scenarios than not exist that would result in a directory comprised
of DCs that believe themselves (and one another) to be
more consistent (up to date) than they actually are. AD's propagation
dampening, which functions by means of a DC's unique invocation ID (a GUID) and
a per partition up-to-dateness vector, is the primary cause. Such
inconsistencies are mitigated internally by AD when gracefully restoring the
directory or when adding/removing/re-adding app. NCs (specifically, the
invocation ID is regenerated amongst other mods.). They are not,
however, currently dealt with if the directory itself is unaware of
the restoration. Temporal issues are caused when only a percentage of
the DCs are restored using diff. disks or the like (SAN volume shadows
etc.). Restoring the entire distributed service (where feasible) or, at
the least, restoring a piece and cleaning out all non-restored DCs prior to
replication, removes such concerns. Adjusting the tombstone lifetime alone
will not
suffice.
-- http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alain Lissoir Sent: Monday, March 21, 2005 11:51 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory Lab Recommendations And of course, I meant in VM lab environment ... obviously!
:-) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alain Lissoir Sent: Monday, March 21, 2005 8:41 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory Lab Recommendations Yep ! I concur with Aric's statement. Changing the tombtone
is definively worthed in an AD environment. I've been through these issues
myself ... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard, Aric Sent: Monday, March 21, 2005 8:29 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory Lab Recommendations I think the strict
replication consistency will allow you to get around this situation. http://support.microsoft.com/default.aspx?scid=kb;en-us;317097
Regardless, you run the chance of generating lingering objects if all the DCs
are not fully synced at the point of shutdown for the 60 day plus duration.
You might consider increasing the tombstone lifetime to a value large
enough to ensure that your DCs will be in use enough to replicate tombstones
before they are garbage collected. AD is not designed to be in a “mostly
powered off” state, so these two issues are something you will always battle
with in an environment that is powered on
infrequently. Regards, Aric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jorge de Almeida
Pinto Hi
Dean, Just
curious... For my studying, testing, playing, etc. I have several VM
environments (VM WRK) set up that I use from time to time. Lets say I built that
environment (at least 2 DCs) in December 2004. When I start the VMs now all DCs
start to complain, which is logical to me, about that each DC has not replicated
for more than the Tombstone Lifetime Value (60 days). Using the "Allow
Replication With Divergent and Corrupt Partner" registry on the DC I get those
DCs replicating again. Not that much work for a test environment. I was
wondering if you have some thoughts on this Cheers, Jorge From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Dean
Wells ... forgot to mention
that any number of rollbacks within the available timeframe takes (in our
configuration) only minutes (the most costly demand on the time to
return-to-ready state is the OS's bootstrap). -- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Dean
Wells I've seen a slew of
production and lab scenario requests over the past year or so, many of which
I've offered non-technology specific recommendations for ... more recently I've
focused my efforts on a non-Microsoft solution that I developed for
MSEtechnology, used for some time in the Remote Learning
arena, named ECbox (originally defined as "Electronic Classroom in a Box"
though more recently internally-colloquially known as "Enterprise Computing
in a Box"). The solution was
designed from its inception to provide a means of snapshotting a distributed
environment whose services impose a potential requirement to roll-back the
entire distributed implementation to an earlier point in time (lock, stock and,
hopefully not too-smoking, barrel). As I mentioned, the ECbox is used
extensively for remote learning but MSEtechnology has also deployed it as a
platform around which our own internal technology services are housed.
Simply put, the ECbox
is a solution built upon VMware ESX Server containing server (and administrative
client-side mods.) designed specifically to tailor ESX's feature set to the
demands of collective groups of dependent computers (e.g. a distributed
database such as Active Directory). For the sake of example, MSEtechnology
is able to roll its entire Directory, Web and Messaging service (though our
requirements are comparatively small, the scale is something of an irrelevant
factor in rollback capability and time) back to a multitude of daily earlier
points in time (MSEtechnology's current capacity/requirement allows for a couple
of weeks). Hope this proves
useful. Regards. Dean -- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Bernard,
Aric How about MSVS 2005,
MSVPC 2004, or VMWare (pick your flavor) with undo disks? From my experience
this a lot faster and typically cheaper than using a disk imaging utility and a
slew of physical machines. Regards, Aric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of
[EMAIL PROTECTED]
|
