In message <> "Rudolf Meier"
<> wrote:
>Hi
>
>> We're currently planning an office move, as part of this process we're
>> expecting our AD and DFS-R file servers to be offline for an unknown
>> period of time.
>>
>> My understanding from an AD and DNS point of view is that I need to
>> bring everything up within the tombstone lifetime, so we'll ensure that
>> this is done to avoid complications.
>
>You have to make a replication of deleted AD objects within this tombstone
>lifetime. So this means, that every AD object you will delete on the other
>servers, will be recreated after the servers (that were offline) get online
>again.
>
>By the way, the default tombstone time is at least 180 days since 2003 SP1
>(but only if the AD was created on a sp1 server). Article about this:
>http://www.petri.co.il/changing_the_...windows_ad.htm
>
>Maybe it's not a bad time to change this to those 180 days anyway...
I'm fairly sure we're already at 180 days, but I will double check just
in case. Even 60 days should be sufficient, but you never know.
>> Are there any limitations on the DFS-R side of things that may cause
>> problems if one or more servers are unavailable for an extended period
>> of time?
>
>That's a good question. I don't know how it works with file-tombstones, but
>since R2 came out after SP1, I could imagine, that it's also at least 180
>day... but, you could delete the server from the replication set and later
>add it again. The system would then check all files and it should quickly
>resynchronize the files...
I'm a little paranoid about doing that, with over 2TB of data split
across a couple million files, it takes over a week to resynchronize.
Worse, it's likely that there will be changes to multiple servers during
the transition -- We can live with the changes being out of sync and
unavailable to users on the opposite side, but I don't want to have to
manually sync up changes before going live again unless entirely needed
(although if this does happen, I have an rsync-type package that will do
the trick for me, but it too may take days)
>> The expected outage is anywhere from 1-6 weeks, although we're aiming to
>> have the last of our servers moved in just under 3 weeks from the first
>> move.
>
>Maybe a good idea would be not to make too many changes to important parts
>of AD during this time. Like this it should be possible to reduce the
>problems...
We're not expecting any significant changes, although users may rotate
passwords or other things like that. I'm bumping up password expiry by
6 months too, just to reduce the odds that anyone will be forced to
change their password, if anyone does, they'll have to deal with having
different passwords on different resources for a short time.
Definitely no schema updates, OU/group changes, and likely not even the
creation or deletion of accounts or computers, just to help ensure
things don't explode.