Luke,
First My Suggestion:
I am still verifying with experts whether Norton Ghost does take an image of
the disk, w/o the proper AD backup methods. If it does, you're in a very
dangerous situation. At some point replication could go from bad to worse.
I think the unlucky case if they start replicating again, is actually just
at some point in the future for you.
My suggestion would be to migrate this Exchange server to your other server,
or backup the Exchange server, rebuild the AD replica DC from scratch, and
then restore the Exchange server. I'm not sure how feasible these
suggestions are b/c I'm not well an Exchange guru, just an AD
replication/backup/restore guru. However, I'm SURE that you will have AD
problems in the future if this DC remains on.
You _may_ be able to mitigate the likelyhood that the two systems start
replicating again, by pausing the netlogon service on the ghost restored DC.
This will ?hopefully? stop it from taking changes.
You asked, "What is the worst case?":
I'm glad you asked ... this is complicated, so I hope I can explain it
clearly. The potential problem relates to how we track replication
meta-data, and perform replication. Basically, a "first DC" tracks whether
it has seen a given replicated change from a 2nd DC by storing the
InvocationID (really a GUID) and a USN pair. The USN is a serial 64 bit
number and ever single transacted change has a USN stamped with it to
represent that change. If you imagine the USN always increasing for each
new change on a DC, you can see how every change in your AD forest, has an
InvocationID (i.e. a DC) and USN that represents that change.
Lets use some specific examples to make it clear, say the "highest USN" is
537 when the ghost image is taken of the 2nd DC, meaning their are changes
('changes' can be add users, password changes, new exch mailboxes, etc)
associated with USNs 1 through 536. After the ghost image is taken, changes
continue to trickle in, and each change replicates off to the first DC of
course. Each time replication happens, the first DC saves the "highest USN"
of the 2nd DC through the end of the changes it replicated from the 2nd DC.
Say USN 673 is the last "highest USN" of the last change the first DC
replicated from the 2nd DC right before the ghost image was restored.
Now, trouble ... when you now restore that ghost image, you take the 2nd DC
back in time, and the DC will have the USN 537 from the ghost image, while
the first DC will think it's seen the 2nd DC's changes through USN 673. New
changes by the 2nd DC will now get USNs 537, 538, 539, etc through 672, and
eventually beyond 672 as well. The first DC however will never get the 2nd
set of changes made at USNs 537-672, b/c it thinks it's seen all changes
before 673. So to start with you won't have the same data on the two DCs,
and this will never fix itself. Now things get really bad (as if that
wasn't bad enough
... imagine that change USN 675 on the 2nd DC (which
will get replicated b/c it's after 673), depends on (like is a child object
of) a change that was made slightly earlier at USN 671. The first DC will
ask for changes 673 and up, and when it sees change 675 it will freak out,
b/c it claims to be above a child that couldn't possibly be there when the
first DC hasn't and won't replicate change 671. Other weird things can
happen to things like DN references (like a group's member attribute) that
reference objects that don't exist on one DC, etc.
I'm not sure if that made sense, but believe me; the basic data consistency
AD has tried to ensure is shot, and other apps that run on AD (like
Exchange) can start to misbehave. Cleaning up these inconsistencies could
be very very difficult, as you've taken AD very far outside it's normal
operating parameters. Microsoft PSS doesn't even have tools that I know of
to deal with this kind of thing.
Back to my first suggestion:
For this reason, it's vitally important to stop taking changes on this 2nd
DC, the ghost restored DC. WELL, of course this is all a mute point if Nort
on Ghost performs a regular AD backup somehow, then you wouldn't be
afflicted by the above horror. But I think this is unlikely to be the case,
but I'll repost again one way or the other, when I get a response from some
authoritative Norton/Symantec people.
Thanks,
Brett Shirley
AD Replication and AD Backup/Restore, SDE (that means Programmer)
This posting is provided "AS IS" with no warranties, and confers no rights.
Luke said:
Brett,
I formated a floppy using norton ghost wizard and the ghost program
was copied onto the floppy. i booted the DC from the floppy, loaded
the ghost program and do the ghost. After that i booted the DC back
into w2k.
After the crash the image was dumped back and it booted up fine with
the exception of not replicating and having a de-synchorisation of the
accounts with another DC. Looks like i got lucky this time. Just out
of curiousity, what could be the wrost thing that could happen if i
was unlucky?
I cannot shut down this DC as it is also an exchange server, and this
is the only mail server that we have, and thus i am not able to wipe
the DC out.
Will the Netdom command help in having the accounts synchronised? and
wil it have any negative effects on the network? What i want is just
to have the least disruption to the network.
thanx.
Luke
"Brett Shirley [MSFT]" <
[email protected]> wrote in message
Luke,
Could you please describe how you got the "Ghosted image"? AD doesn't
support any sort of disk or file imaging that doesn't go through the
official backup/restore APIs. I believe, but am not really that sure, that
Norton Ghost does this. If you've done this, it is very very bad, and if
we're lucky, the only thing it's done is not replicate. Please stop trying
to get them to replicate, it's a good idea to shutdown this DC down or
unplug it from the network for now.
Is this the only DC for this domain? Is it plausible to wipe this DC and
bring it back online as a new replica DC?
Thanks,
Brett Shirley
SDE, AD Replication & AD Backup/Restore
Disclaimer: ( DmitriG posts alot, so I defer to his disclaimer ... )
I've CC'd Sorin, b/c from a quick web search, I saw he was trying to ghost a
DC too.
http://www.freelists.org/archives/windows2000/12-2002/msg00418.html
Hi Jason,
thanx for the reply. Checked my dns and the entries are correct.
I have tried forcing a replication but it fails with the message
target prinicpal name is incorrect and doing a repadmin /showreps
shows that the last successful replication is before the crash happen.
the error msg that i see from doing repadmin is "access is denied."
i was wondering if i need to do a netdom command between teh 2 DCs to
have their accounts synchronised, but i am not experienced enough to
know if there will be any side effects that this will have on the
otehr servers and clients taht are in the network.
Thanx.
I'd check the DNS records again. Make sure the A records have the right
IP
addresses. What I was wondering was if the Ghosted image was too old.
If
the error messages reported are the most up to date then DNS
configuration
looks to be the problem. Another approach to get information would be
to
force replication using Active Directory Sites and Services snap-in or
using
repadmin.exe. Then use repadmin /showreps to show the status of your
replication attempts. It will report last success times and last
failure
times as well as an error code. You may find information on the error
code
on support.microsoft.com or by posting it again here. If DNS is
configured
correctly the error message may give a clue as to the problem.
Hi Jason,
the ghosted image is about 3 weeks old.
message
How old is the Ghosted image?
Anybody got any ideas to this or have experienced this before?
So if step 1 fails, here are steps 1a through 1h