Discussion:
AD replication issue!!!
(too old to reply)
kj [SBS MVP]
2010-02-19 17:16:42 UTC
Permalink
SBS2000 eh?

How old was the system state you restored and when was the last time you
verified that replication completed between the two DC's?

Also, when you 'rebuilt' the SBS server did you join the existing domain or
create a new one?

Suggest using the SBS scpecific groups which I'm adding for you.
Help!!!
We have an SBS 2000 server and another win2k3 domain controller in our
environment. The two were replicating and have been for many years
now.
Last week our SBS server crashed and I had to rebuild it. The last
step was to restore the system state - which restores AD among other
things.
As soon as the machine came back up, I started testing to see if it
was actually fully functional again. Right away I noticed that I
could not access ANY shares - not even administrative shares using
the server name (\\server\share). I could only access them by
specifying the ip address of the SBS like this \\ip_address\share.
I then noticed that when I went into the active dir users and
computers app, it was now connecting automatically to the other
domain controller's AD database - NOT the one on this SBS machine -
which is supposed to be the "primary" DC. I was able to select
"Connect to a domain controller" and had to manually enter the SBS
machine name as it was not listed in the window at the bottom to
select from - jsut the win2k3 DC was in there... After I entered the
SBS machine name I was able to connect to it's AD.
I then realized that replication was not happening between the two
machines anymore. I am seeing ID 13508 in the File Replication
Service event log. ("THe file replication service is having trouble
enabling replicating from TRUE5 to TRUE3" etc... please note that
TRUE5 is the win2k3 DC and TRUE3 is the SBS machine.) As well, If I
go to Active Dir Sites and Services and try to force a replication, I
am getting "Replication Access was denied". I am also seeing id's
1126 and 1655 in the "Directory Access" event log. 1126 is an "unable
to communicate with global catalog" error. 1655 is "an attempt to
communicate with the global catalog failed - reason ...replication
access was denied"
Where should I start to troubleshoot AD replication errors?? I really
believe the root of the issue is somehow related specifically to
screwed up permissions on the SBS machine that for some reason got
screwed up during the recovery process.
I have never really had to worry about an AD issues before - just set
it up and it works fine... so I am a complete newbie to this.
This issue is leading to many other issues - for example I am unable
to setup new users with exchange mailboxes and have them access them
etc... Exchange doesn';t even see my SBS machine as a domain
controller - it only shows the other win2K3 dc!
Help!!!!
PS.. I recreated the SYSVOL and NETLOGON shares that were missing -
not sure if I should have or not...
Thanks, Brad
--
/kj
Ace Fekay [MVP-DS, MCT]
2010-02-19 17:46:50 UTC
Permalink
Post by kj [SBS MVP]
SBS2000 eh?
How old was the system state you restored and when was the last time you
verified that replication completed between the two DC's?
Also, when you 'rebuilt' the SBS server did you join the existing domain
or create a new one?
Suggest using the SBS scpecific groups which I'm adding for you.
Help!!!
We have an SBS 2000 server and another win2k3 domain controller in our
environment. The two were replicating and have been for many years
now.
Last week our SBS server crashed and I had to rebuild it. The last
step was to restore the system state - which restores AD among other
things.
As soon as the machine came back up, I started testing to see if it
was actually fully functional again. Right away I noticed that I
could not access ANY shares - not even administrative shares using
the server name (\\server\share). I could only access them by
specifying the ip address of the SBS like this \\ip_address\share.
I then noticed that when I went into the active dir users and
computers app, it was now connecting automatically to the other
domain controller's AD database - NOT the one on this SBS machine -
which is supposed to be the "primary" DC. I was able to select
"Connect to a domain controller" and had to manually enter the SBS
machine name as it was not listed in the window at the bottom to
select from - jsut the win2k3 DC was in there... After I entered the
SBS machine name I was able to connect to it's AD.
I then realized that replication was not happening between the two
machines anymore. I am seeing ID 13508 in the File Replication
Service event log. ("THe file replication service is having trouble
enabling replicating from TRUE5 to TRUE3" etc... please note that
TRUE5 is the win2k3 DC and TRUE3 is the SBS machine.) As well, If I
go to Active Dir Sites and Services and try to force a replication, I
am getting "Replication Access was denied". I am also seeing id's
1126 and 1655 in the "Directory Access" event log. 1126 is an "unable
to communicate with global catalog" error. 1655 is "an attempt to
communicate with the global catalog failed - reason ...replication
access was denied"
Where should I start to troubleshoot AD replication errors?? I really
believe the root of the issue is somehow related specifically to
screwed up permissions on the SBS machine that for some reason got
screwed up during the recovery process.
I have never really had to worry about an AD issues before - just set
it up and it works fine... so I am a complete newbie to this.
This issue is leading to many other issues - for example I am unable
to setup new users with exchange mailboxes and have them access them
etc... Exchange doesn';t even see my SBS machine as a domain
controller - it only shows the other win2K3 dc!
Help!!!!
PS.. I recreated the SYSVOL and NETLOGON shares that were missing -
not sure if I should have or not...
Thanks, Brad
--
/kj
How old is the backup that was used to restore the DC?
Did you use a backup, or an image restoration?

This sounds like an NTFRS Journal Wrap issue. See if the following will
help.

http://eventid.net/display.asp?eventid=13508&eventno=349&source=NtFrs&phase=1

Using the BurFlags registry key to reinitialize File Replication Service
replica sets
http://support.microsoft.com/kb/290762



Here are my notes on Journal Wraps from past troubleshooting steps ... I
hope you find them helpful.

===========================
Journal Wrap - What does it mean?

Troubleshooting journal_wrap errors on Sysvol and DFS replica sets
http://support.microsoft.com/?id=292438

In a generalized summary, a Journal Wrap indicates it's trying to replicate
to another DC and the DC with the error's FRS service may have been shut off
for some reason. The Wrap error is based on the USN log or known as the USN
Journal. Everything and anything that gets replicated has a USN, or Update
Serial Number. Each DC has it's own, and other DCs keep track of them so
they know whether they have the other DCs' latest changes and are up to date
on their own end. So generally, the USN Journal keeps track of changes made
to any NTFR drive, whether for DFS, DC replication of SYSVOL, etc. If
changes are made while the FRS service is shut down, it may get to a point
where the last time something was changed, and when the FRS service is
started, the last USN it's aware of no longer exists (because that much time
has passed by).

---

For your convenience, the steps are:

1. Expand "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters"
2. Change value for "Enable Journal Wrap Automatic Restore" from 0 to 1. If
the DWORD Value does not exist, create a new one with the exact spelling as
above, including spaces but without the quotes.
3. Stop the NTFRS Service (open a command prompt and type "net stop ntfrs")
4. Start the NTFRS Service (net start ntfrs)
5. Monitor the File Replication Service Event Logs for events:
• 13553 – The DC is performing the recovery process
• 13554 – The DC is ready to pull the replica from another DC.
• 13516 - At this point go to step 6. (the problem is resolved if you
receive this event)
6. Using a command prompt type: "net share" and look for the Netlogon and
Sysvol Shares to appear. The Journal Wrap error is only fixed after the
Domain Controller receives the new SYSVOL replica from a peer Domain
Controller. This may take a period of time depending on where your peer DC
is located and on bandwidth.
7. Change value for "Enable Journal Wrap Automatic Restore" from 1 to 0.


===========================
Now if it continues after these steps, then you would need to run an
Authoratative Restore, that is if you have a recent backup. Do you have a
backup? If not, and nothing else is running on it, and you have other DCs, I
would force demote it, then re-promote it back into a DC. If this is SBS,
this part won't work, and you need to fix it, period.

Using the BurFlags registry key to reinitialize File Replication
http://support.microsoft.com/kb/290762

How to rebuild the SYSVOL tree and its content in a domain.
If you set Burflags to D4 on a single domain controller and set Burflags to
D2 on all other domain controllers in that domain, you can rebuild the
SYSVOL ... I've also seen folks copy over the Sysvol folder, then set the
Burflag options as mentioned, it worked.
http://support.microsoft.com/kb/315457

How to Troubleshoot the File Replication Service
Check FRS event logs on both computers.
If Event ID 13508 is present, there may be a problem with the RPC service on
either computer
http://support.microsoft.com/kb/272279

Troubleshooting journal_wrap errors on Sysvol and DFS replica sets
http://support.microsoft.com/?id=292438

How to disable the requirement that a global catalog server be available to
validate user logons
http://support.microsoft.com/kb/241789
===========================
--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE &
MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

If you feel this is an urgent issue and require immediate assistance, please
contact Microsoft PSS directly. Please check http://support.microsoft.com
for regional support phone numbers.
Brad Pears
2010-02-19 17:53:16 UTC
Permalink
Hi there...

Ya, SBS 2000 - it's an old puppy that we are hoping to replace with SBS 2008
this year - funds permitting... In the meantime I need to keep this old
feller truckin along...

I should have elaborated a little more... When I said "rebuilt"... all I did
was to replace the power supply and two disks in the raid array that had
failed, then reconfigured the raid array, installed Win2K (standard) SP4
from the SBS cd's THEN restored drive c:\ and drive e:\ contents as well as
system state from our most recent backup exec backup sets. What I restored
was from a backup taken the night that it went down - but several hours
before.

So, I didn't have to join it to a domain - the restore should have set all
that back up again...

Incidentally, if I do a DCPROMO on teh SBS box, it thinks that it already is
a domain controller - so it knows some things - just not enough!!!

As well, AD does still show both servers in the "Domain Controllers"
container and the AD Sites and Services still shows both servers there as
well.

Brad
Post by kj [SBS MVP]
SBS2000 eh?
How old was the system state you restored and when was the last time you
verified that replication completed between the two DC's?
Also, when you 'rebuilt' the SBS server did you join the existing domain
or create a new one?
Suggest using the SBS scpecific groups which I'm adding for you.
Help!!!
We have an SBS 2000 server and another win2k3 domain controller in our
environment. The two were replicating and have been for many years
now.
Last week our SBS server crashed and I had to rebuild it. The last
step was to restore the system state - which restores AD among other
things.
As soon as the machine came back up, I started testing to see if it
was actually fully functional again. Right away I noticed that I
could not access ANY shares - not even administrative shares using
the server name (\\server\share). I could only access them by
specifying the ip address of the SBS like this \\ip_address\share.
I then noticed that when I went into the active dir users and
computers app, it was now connecting automatically to the other
domain controller's AD database - NOT the one on this SBS machine -
which is supposed to be the "primary" DC. I was able to select
"Connect to a domain controller" and had to manually enter the SBS
machine name as it was not listed in the window at the bottom to
select from - jsut the win2k3 DC was in there... After I entered the
SBS machine name I was able to connect to it's AD.
I then realized that replication was not happening between the two
machines anymore. I am seeing ID 13508 in the File Replication
Service event log. ("THe file replication service is having trouble
enabling replicating from TRUE5 to TRUE3" etc... please note that
TRUE5 is the win2k3 DC and TRUE3 is the SBS machine.) As well, If I
go to Active Dir Sites and Services and try to force a replication, I
am getting "Replication Access was denied". I am also seeing id's
1126 and 1655 in the "Directory Access" event log. 1126 is an "unable
to communicate with global catalog" error. 1655 is "an attempt to
communicate with the global catalog failed - reason ...replication
access was denied"
Where should I start to troubleshoot AD replication errors?? I really
believe the root of the issue is somehow related specifically to
screwed up permissions on the SBS machine that for some reason got
screwed up during the recovery process.
I have never really had to worry about an AD issues before - just set
it up and it works fine... so I am a complete newbie to this.
This issue is leading to many other issues - for example I am unable
to setup new users with exchange mailboxes and have them access them
etc... Exchange doesn';t even see my SBS machine as a domain
controller - it only shows the other win2K3 dc!
Help!!!!
PS.. I recreated the SYSVOL and NETLOGON shares that were missing -
not sure if I should have or not...
Thanks, Brad
--
/kj
kj [SBS MVP]
2010-02-19 18:10:57 UTC
Permalink
Probably best to start with basic DCdiag, netdiag, etc especially ensuring
that each DC can resolve the other by name and number.
Post by Brad Pears
Hi there...
Ya, SBS 2000 - it's an old puppy that we are hoping to replace with
SBS 2008 this year - funds permitting... In the meantime I need to
keep this old feller truckin along...
I should have elaborated a little more... When I said "rebuilt"...
all I did was to replace the power supply and two disks in the raid
array that had failed, then reconfigured the raid array, installed
Win2K (standard) SP4 from the SBS cd's THEN restored drive c:\ and
drive e:\ contents as well as system state from our most recent
backup exec backup sets. What I restored was from a backup taken the
night that it went down - but several hours before.
So, I didn't have to join it to a domain - the restore should have
set all that back up again...
Incidentally, if I do a DCPROMO on teh SBS box, it thinks that it
already is a domain controller - so it knows some things - just not
enough!!!
As well, AD does still show both servers in the "Domain Controllers"
container and the AD Sites and Services still shows both servers
there as well.
Brad
Post by kj [SBS MVP]
SBS2000 eh?
How old was the system state you restored and when was the last time
you verified that replication completed between the two DC's?
Also, when you 'rebuilt' the SBS server did you join the existing
domain or create a new one?
Suggest using the SBS scpecific groups which I'm adding for you.
Help!!!
We have an SBS 2000 server and another win2k3 domain controller in
our environment. The two were replicating and have been for many
years now.
Last week our SBS server crashed and I had to rebuild it. The last
step was to restore the system state - which restores AD among other
things.
As soon as the machine came back up, I started testing to see if it
was actually fully functional again. Right away I noticed that I
could not access ANY shares - not even administrative shares using
the server name (\\server\share). I could only access them by
specifying the ip address of the SBS like this \\ip_address\share.
I then noticed that when I went into the active dir users and
computers app, it was now connecting automatically to the other
domain controller's AD database - NOT the one on this SBS machine -
which is supposed to be the "primary" DC. I was able to select
"Connect to a domain controller" and had to manually enter the SBS
machine name as it was not listed in the window at the bottom to
select from - jsut the win2k3 DC was in there... After I entered the
SBS machine name I was able to connect to it's AD.
I then realized that replication was not happening between the two
machines anymore. I am seeing ID 13508 in the File Replication
Service event log. ("THe file replication service is having trouble
enabling replicating from TRUE5 to TRUE3" etc... please note that
TRUE5 is the win2k3 DC and TRUE3 is the SBS machine.) As well, If I
go to Active Dir Sites and Services and try to force a replication,
I am getting "Replication Access was denied". I am also seeing id's
1126 and 1655 in the "Directory Access" event log. 1126 is an
"unable to communicate with global catalog" error. 1655 is "an
attempt to communicate with the global catalog failed - reason
...replication access was denied"
Where should I start to troubleshoot AD replication errors?? I
really believe the root of the issue is somehow related
specifically to screwed up permissions on the SBS machine that for
some reason got screwed up during the recovery process.
I have never really had to worry about an AD issues before - just
set it up and it works fine... so I am a complete newbie to this.
This issue is leading to many other issues - for example I am unable
to setup new users with exchange mailboxes and have them access them
etc... Exchange doesn';t even see my SBS machine as a domain
controller - it only shows the other win2K3 dc!
Help!!!!
PS.. I recreated the SYSVOL and NETLOGON shares that were missing -
not sure if I should have or not...
Thanks, Brad
--
/kj
--
/kj
Brad Pears
2010-02-19 18:42:43 UTC
Permalink
OK, I'll do that... Where do I find these tools? Are they part of the
win2000 support tools?

I did check the DNS entries on both DC's and indeed there are proper PTR and
A records there for each machine in both forward and reverse lookup zones.
Everything else in there looks ok, but again, I have not ventured into this
very far so can't say that it is 100% correct - what I see makes sense to me
though...

Thanks, Brad
Post by kj [SBS MVP]
Probably best to start with basic DCdiag, netdiag, etc especially ensuring
that each DC can resolve the other by name and number.
Post by Brad Pears
Hi there...
Ya, SBS 2000 - it's an old puppy that we are hoping to replace with
SBS 2008 this year - funds permitting... In the meantime I need to
keep this old feller truckin along...
I should have elaborated a little more... When I said "rebuilt"...
all I did was to replace the power supply and two disks in the raid
array that had failed, then reconfigured the raid array, installed
Win2K (standard) SP4 from the SBS cd's THEN restored drive c:\ and
drive e:\ contents as well as system state from our most recent
backup exec backup sets. What I restored was from a backup taken the
night that it went down - but several hours before.
So, I didn't have to join it to a domain - the restore should have
set all that back up again...
Incidentally, if I do a DCPROMO on teh SBS box, it thinks that it
already is a domain controller - so it knows some things - just not
enough!!!
As well, AD does still show both servers in the "Domain Controllers"
container and the AD Sites and Services still shows both servers
there as well.
Brad
Post by kj [SBS MVP]
SBS2000 eh?
How old was the system state you restored and when was the last time
you verified that replication completed between the two DC's?
Also, when you 'rebuilt' the SBS server did you join the existing
domain or create a new one?
Suggest using the SBS scpecific groups which I'm adding for you.
Help!!!
We have an SBS 2000 server and another win2k3 domain controller in
our environment. The two were replicating and have been for many
years now.
Last week our SBS server crashed and I had to rebuild it. The last
step was to restore the system state - which restores AD among other
things.
As soon as the machine came back up, I started testing to see if it
was actually fully functional again. Right away I noticed that I
could not access ANY shares - not even administrative shares using
the server name (\\server\share). I could only access them by
specifying the ip address of the SBS like this \\ip_address\share.
I then noticed that when I went into the active dir users and
computers app, it was now connecting automatically to the other
domain controller's AD database - NOT the one on this SBS machine -
which is supposed to be the "primary" DC. I was able to select
"Connect to a domain controller" and had to manually enter the SBS
machine name as it was not listed in the window at the bottom to
select from - jsut the win2k3 DC was in there... After I entered the
SBS machine name I was able to connect to it's AD.
I then realized that replication was not happening between the two
machines anymore. I am seeing ID 13508 in the File Replication
Service event log. ("THe file replication service is having trouble
enabling replicating from TRUE5 to TRUE3" etc... please note that
TRUE5 is the win2k3 DC and TRUE3 is the SBS machine.) As well, If I
go to Active Dir Sites and Services and try to force a replication,
I am getting "Replication Access was denied". I am also seeing id's
1126 and 1655 in the "Directory Access" event log. 1126 is an
"unable to communicate with global catalog" error. 1655 is "an
attempt to communicate with the global catalog failed - reason
...replication access was denied"
Where should I start to troubleshoot AD replication errors?? I
really believe the root of the issue is somehow related
specifically to screwed up permissions on the SBS machine that for
some reason got screwed up during the recovery process.
I have never really had to worry about an AD issues before - just
set it up and it works fine... so I am a complete newbie to this.
This issue is leading to many other issues - for example I am unable
to setup new users with exchange mailboxes and have them access them
etc... Exchange doesn';t even see my SBS machine as a domain
controller - it only shows the other win2K3 dc!
Help!!!!
PS.. I recreated the SYSVOL and NETLOGON shares that were missing -
not sure if I should have or not...
Thanks, Brad
--
/kj
--
/kj
kj [SBS MVP]
2010-02-19 19:29:10 UTC
Permalink
Yep part of the support tools but you might want to get the update
version(s) from MS downloads;

http://www.microsoft.com/downloads/details.aspx?FamilyID=23870A87-8422-408C-9375-2D9AAF939FA3&displaylang=en&displaylang=en

Did you have any errors on restore, system state in particular?
Post by Brad Pears
OK, I'll do that... Where do I find these tools? Are they part of the
win2000 support tools?
I did check the DNS entries on both DC's and indeed there are proper
PTR and A records there for each machine in both forward and reverse
lookup zones. Everything else in there looks ok, but again, I have
not ventured into this very far so can't say that it is 100% correct
- what I see makes sense to me though...
Thanks, Brad
Post by kj [SBS MVP]
Probably best to start with basic DCdiag, netdiag, etc especially
ensuring that each DC can resolve the other by name and number.
Post by Brad Pears
Hi there...
Ya, SBS 2000 - it's an old puppy that we are hoping to replace with
SBS 2008 this year - funds permitting... In the meantime I need to
keep this old feller truckin along...
I should have elaborated a little more... When I said "rebuilt"...
all I did was to replace the power supply and two disks in the raid
array that had failed, then reconfigured the raid array, installed
Win2K (standard) SP4 from the SBS cd's THEN restored drive c:\ and
drive e:\ contents as well as system state from our most recent
backup exec backup sets. What I restored was from a backup taken the
night that it went down - but several hours before.
So, I didn't have to join it to a domain - the restore should have
set all that back up again...
Incidentally, if I do a DCPROMO on teh SBS box, it thinks that it
already is a domain controller - so it knows some things - just not
enough!!!
As well, AD does still show both servers in the "Domain Controllers"
container and the AD Sites and Services still shows both servers
there as well.
Brad
Post by kj [SBS MVP]
SBS2000 eh?
How old was the system state you restored and when was the last
time you verified that replication completed between the two DC's?
Also, when you 'rebuilt' the SBS server did you join the existing
domain or create a new one?
Suggest using the SBS scpecific groups which I'm adding for you.
Help!!!
We have an SBS 2000 server and another win2k3 domain controller in
our environment. The two were replicating and have been for many
years now.
Last week our SBS server crashed and I had to rebuild it. The last
step was to restore the system state - which restores AD among
other things.
As soon as the machine came back up, I started testing to see if
it was actually fully functional again. Right away I noticed that
I could not access ANY shares - not even administrative shares
using the server name (\\server\share). I could only access them
by specifying the ip address of the SBS like this
\\ip_address\share. I then noticed that when I went into the active
dir users and
computers app, it was now connecting automatically to the other
domain controller's AD database - NOT the one on this SBS machine
- which is supposed to be the "primary" DC. I was able to select
"Connect to a domain controller" and had to manually enter the SBS
machine name as it was not listed in the window at the bottom to
select from - jsut the win2k3 DC was in there... After I entered
the SBS machine name I was able to connect to it's AD.
I then realized that replication was not happening between the two
machines anymore. I am seeing ID 13508 in the File Replication
Service event log. ("THe file replication service is having
trouble enabling replicating from TRUE5 to TRUE3" etc... please
note that TRUE5 is the win2k3 DC and TRUE3 is the SBS machine.)
As well, If I go to Active Dir Sites and Services and try to
force a replication, I am getting "Replication Access was
denied". I am also seeing id's 1126 and 1655 in the "Directory
Access" event log. 1126 is an "unable to communicate with global
catalog" error. 1655 is "an attempt to communicate with the
global catalog failed - reason ...replication access was denied"
Where should I start to troubleshoot AD replication errors?? I
really believe the root of the issue is somehow related
specifically to screwed up permissions on the SBS machine that for
some reason got screwed up during the recovery process.
I have never really had to worry about an AD issues before - just
set it up and it works fine... so I am a complete newbie to this.
This issue is leading to many other issues - for example I am
unable to setup new users with exchange mailboxes and have them
access them etc... Exchange doesn';t even see my SBS machine as a
domain controller - it only shows the other win2K3 dc!
Help!!!!
PS.. I recreated the SYSVOL and NETLOGON shares that were missing
- not sure if I should have or not...
Thanks, Brad
--
/kj
--
/kj
--
/kj
kj [SBS MVP]
2010-02-19 22:08:41 UTC
Permalink
You did boot into DSRM mode and did a non-authoritative restore, right?

Please attach the dcdiag from your SBS server which should tell us more...
but I don't think your system state restored correctly or the correct
procedure was followed.

I'd advise against an authoritative restore at this point.
Thanks, I found them on the SBS cd and installed them...
System state appeared to restore just fine during my "rebuilding "
process (well - it didn't report any errors at least...) I'll have to
look into doing an authoritative restore now that I have the DC
running... I do have another fairly recent backup of the system
state that I could try to restore from...
I ran dcdiag from the system tools and geting some interesting
entries in the log regarding replication errors... It says that
replication access was denied (saw that in the logs) and that "the
machine account for the destination TRUE3 (our sbs server) is not
configured properly. Check the userAccountControl field. Kerberos
error. The machine account is not present or does not match on the
destination, source or KDC servers."
Also, I get an error when testing MachineAccount. It says "TRUE3 is
not a server trust account"
Then I ran dcdiag /v on TRUE5 which is our windows 2003 server - it
showed even more intersting errors... I've attached the dcdiag log
from that here... There is a lot of stuff in there - some really
interesting things...
Can you make any heads or tails from that??
Thanks, Brad
Post by kj [SBS MVP]
Yep part of the support tools but you might want to get the update
version(s) from MS downloads;
http://www.microsoft.com/downloads/details.aspx?FamilyID=23870A87-8422-408C-9375-2D9AAF939FA3&displaylang=en&displaylang=en
Did you have any errors on restore, system state in particular?
Post by Brad Pears
OK, I'll do that... Where do I find these tools? Are they part of
the win2000 support tools?
I did check the DNS entries on both DC's and indeed there are proper
PTR and A records there for each machine in both forward and reverse
lookup zones. Everything else in there looks ok, but again, I have
not ventured into this very far so can't say that it is 100% correct
- what I see makes sense to me though...
Thanks, Brad
Post by kj [SBS MVP]
Probably best to start with basic DCdiag, netdiag, etc especially
ensuring that each DC can resolve the other by name and number.
Post by Brad Pears
Hi there...
Ya, SBS 2000 - it's an old puppy that we are hoping to replace
with SBS 2008 this year - funds permitting... In the meantime I
need to keep this old feller truckin along...
I should have elaborated a little more... When I said "rebuilt"...
all I did was to replace the power supply and two disks in the
raid array that had failed, then reconfigured the raid array,
installed Win2K (standard) SP4 from the SBS cd's THEN restored
drive c:\ and drive e:\ contents as well as system state from our
most recent backup exec backup sets. What I restored was from a
backup taken the night that it went down - but several hours
before. So, I didn't have to join it to a domain - the restore should
have
set all that back up again...
Incidentally, if I do a DCPROMO on teh SBS box, it thinks that it
already is a domain controller - so it knows some things - just
not enough!!!
As well, AD does still show both servers in the "Domain
Controllers" container and the AD Sites and Services still shows
both servers there as well.
Brad
Post by kj [SBS MVP]
SBS2000 eh?
How old was the system state you restored and when was the last
time you verified that replication completed between the two
DC's? Also, when you 'rebuilt' the SBS server did you join the
existing
domain or create a new one?
Suggest using the SBS scpecific groups which I'm adding for you.
Help!!!
We have an SBS 2000 server and another win2k3 domain controller
in our environment. The two were replicating and have been for
many years now.
Last week our SBS server crashed and I had to rebuild it. The
last step was to restore the system state - which restores AD
among other things.
As soon as the machine came back up, I started testing to see if
it was actually fully functional again. Right away I noticed
that I could not access ANY shares - not even administrative
shares using the server name (\\server\share). I could only
access them by specifying the ip address of the SBS like this
\\ip_address\share. I then noticed that when I went into the
active dir users and
computers app, it was now connecting automatically to the other
domain controller's AD database - NOT the one on this SBS
machine - which is supposed to be the "primary" DC. I was able
to select "Connect to a domain controller" and had to manually
enter the SBS machine name as it was not listed in the window
at the bottom to select from - jsut the win2k3 DC was in
there... After I entered the SBS machine name I was able to
connect to it's AD. I then realized that replication was not
happening between the
two machines anymore. I am seeing ID 13508 in the File
Replication Service event log. ("THe file replication service
is having trouble enabling replicating from TRUE5 to TRUE3"
etc... please note that TRUE5 is the win2k3 DC and TRUE3 is the
SBS machine.) As well, If I go to Active Dir Sites and Services and
try to
force a replication, I am getting "Replication Access was
denied". I am also seeing id's 1126 and 1655 in the "Directory
Access" event log. 1126 is an "unable to communicate with global
catalog" error. 1655 is "an attempt to communicate with the
global catalog failed - reason ...replication access was denied"
Where should I start to troubleshoot AD replication errors?? I
really believe the root of the issue is somehow related
specifically to screwed up permissions on the SBS machine that
for some reason got screwed up during the recovery process.
I have never really had to worry about an AD issues before -
just set it up and it works fine... so I am a complete newbie
to this. This issue is leading to many other issues - for example I
am
unable to setup new users with exchange mailboxes and have them
access them etc... Exchange doesn';t even see my SBS machine as
a domain controller - it only shows the other win2K3 dc!
Help!!!!
PS.. I recreated the SYSVOL and NETLOGON shares that were
missing - not sure if I should have or not...
Thanks, Brad
--
/kj
--
/kj
--
/kj
--
/kj
Ace Fekay [MVP-DS, MCT]
2010-02-20 03:02:24 UTC
Permalink
No I did not - because I was restoring the SBS machine from scratch (had
to replace some hardware) so the server was not a DC when I did the SBS
restore. I did a fresh install of win2k server using the SBS cd's, then
brought that installation up to SP4. I did NOT join it to the domain -
left it in the wrokgroup. At that point I restored the c: contents and the
system state from our backup exec backups taken the night it crashed and
then rebooted. Once it was started up I had to restore my exchange
databases etc... This was the disaster recovery procedures for SBS 2000
that I followed from Backup Exec tecch support. It wasn't until I had to
add a new user the next day that I realized there were serious problems...
I've attached the SBS dcdiag.log file here as well...
Brad
To properly bring the machine back up to the previous state after restoring
the whole C, D, etc, drives, a system state restore in your scenario must be
done as a non-authoratative restore using DSRM.

Ace
Brad Pears
2010-02-22 19:46:36 UTC
Permalink
Ok, so it sounds like maybe a non-authoritative restore at this point in
time is what I should be trying... THere are so many things that are so
screwed up with my SBS I don't really think that I have much of a choice...

The latest issue I am having today is that a new user that I added after the
restore of the SBS, who was been able to log into the domain since I set him
up, and was able to as recently as Saturday, can now no longer log on at all
to do anything - so the heat is on me.

I am just starting to look into this issue...
.
Post by Ace Fekay [MVP-DS, MCT]
No I did not - because I was restoring the SBS machine from scratch (had
to replace some hardware) so the server was not a DC when I did the SBS
restore. I did a fresh install of win2k server using the SBS cd's, then
brought that installation up to SP4. I did NOT join it to the domain -
left it in the wrokgroup. At that point I restored the c: contents and
the system state from our backup exec backups taken the night it crashed
and then rebooted. Once it was started up I had to restore my exchange
databases etc... This was the disaster recovery procedures for SBS 2000
that I followed from Backup Exec tecch support. It wasn't until I had to
add a new user the next day that I realized there were serious problems...
I've attached the SBS dcdiag.log file here as well...
Brad
To properly bring the machine back up to the previous state after
restoring the whole C, D, etc, drives, a system state restore in your
scenario must be done as a non-authoratative restore using DSRM.
Ace
kj [SBS MVP]
2010-02-22 20:30:27 UTC
Permalink
Yep. Do a non-authoritative resrote in DSRM asap. It's only going to get
expotentially worse until you do.

Restart the server and do the dcdiag on both DC's with verification that
bidirectional replicational is working before making *any* changes to AD
objects.
Post by Brad Pears
Ok, so it sounds like maybe a non-authoritative restore at this point
in time is what I should be trying... THere are so many things that
are so screwed up with my SBS I don't really think that I have much
of a choice...
The latest issue I am having today is that a new user that I added
after the restore of the SBS, who was been able to log into the
domain since I set him up, and was able to as recently as Saturday,
can now no longer log on at all to do anything - so the heat is on me.
I am just starting to look into this issue...
.
Post by Ace Fekay [MVP-DS, MCT]
No I did not - because I was restoring the SBS machine from scratch
(had to replace some hardware) so the server was not a DC when I
did the SBS restore. I did a fresh install of win2k server using
the SBS cd's, then brought that installation up to SP4. I did NOT
join it to the domain - left it in the wrokgroup. At that point I
restored the c: contents and the system state from our backup exec
backups taken the night it crashed and then rebooted. Once it was
started up I had to restore my exchange databases etc... This was
the disaster recovery procedures for SBS 2000 that I followed from
Backup Exec tecch support. It wasn't until I had to add a new user
the next day that I realized there were serious problems...
I've attached the SBS dcdiag.log file here as well...
Brad
To properly bring the machine back up to the previous state after
restoring the whole C, D, etc, drives, a system state restore in your
scenario must be done as a non-authoratative restore using DSRM.
Ace
--
/kj
Ace Fekay [MVP-DS, MCT]
2010-02-22 22:32:26 UTC
Permalink
Post by kj [SBS MVP]
Yep. Do a non-authoritative resrote in DSRM asap. It's only going to get
expotentially worse until you do.
Restart the server and do the dcdiag on both DC's with verification that
bidirectional replicational is working before making *any* changes to AD
objects.
Let's hope Brad does it ASAP. Brad, let us know how you make out.

Ace
Brad Pears
2010-02-23 02:09:15 UTC
Permalink
I am going to attempt this tomorrow (Tuesday) morning. I will jsut do a
system state restore - not a drive c: restore - as nothing there should be
an issue - it's all an AD issue...

Once I have completed the restore, if everything worked, will my other
win2k3 domain controller replicate it's existing AD structure back to the
SBS machine or will the SBS replicate it's restored structure out to the
other dc?? At this point it really doesn;t matter what happens really - the
structure has not changed at all other than the new users I added last week
won't exist in the restored AD structure - but they do exisit currently in
the backup DC's structure only. Might this cause an issue?? Should I remove
them from the other DC's structure before doing the restore??

I'm guessing leave it alone??

One other question I have.... if the restore doesn;t wind up working, can
I make my win2k dc the PDC, RID master etc... so that I can just have the
one DC in the domain? That would allow me to set up a win2K machine with
Exchange only on it and then later set up another win2k3 backup DC thus
getting rid of SBS altogether... Is that what one would call "seizing the
FSMO roles"??? Not sure f this can actually be done when it comes to SBS
2000

Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Yep. Do a non-authoritative resrote in DSRM asap. It's only going to get
expotentially worse until you do.
Restart the server and do the dcdiag on both DC's with verification that
bidirectional replicational is working before making *any* changes to AD
objects.
Let's hope Brad does it ASAP. Brad, let us know how you make out.
Ace
kj [SBS MVP]
2010-02-23 03:23:05 UTC
Permalink
Post by Brad Pears
I am going to attempt this tomorrow (Tuesday) morning. I will jsut do
a system state restore - not a drive c: restore - as nothing there
should be an issue - it's all an AD issue...
Once I have completed the restore, if everything worked, will my other
win2k3 domain controller replicate it's existing AD structure back to
the SBS machine or will the SBS replicate it's restored structure out
to the other dc??
The SBS server will initially be like it was at System State backup time.
The other DC will replicate all it's changes and bring the SBS server up to
date. Then the SBS server can be used to make changes to the domain again.

At this point it really doesn;t matter what
Post by Brad Pears
happens really - the structure has not changed at all other than the
new users I added last week won't exist in the restored AD structure
- but they do exisit currently in the backup DC's structure only.
Well, there are still things changing in the domain. Computer accounts are
changing passwords, users may be changing passwords, .... some of it matters
and some of it might not, but changes are a happening.
Post by Brad Pears
Might this cause an issue?? Should I remove them from the other DC's
structure before doing the restore??
No. Do nothing to the other DC. Just do a non authoritative restore to the
SBS server. Check with dcdiag and validate replication.
Post by Brad Pears
I'm guessing leave it alone??
One other question I have.... if the restore doesn;t wind up
working, can I make my win2k dc the PDC, RID master etc... so that I
can just have the one DC in the domain? That would allow me to set up
a win2K machine with Exchange only on it and then later set up
another win2k3 backup DC thus getting rid of SBS altogether... Is
that what one would call "seizing the FSMO roles"??? Not sure f this
can actually be done when it comes to SBS 2000
You really don't wanto to have to do that with SBS. Just do the non
authoritative restore and you should be good.
Post by Brad Pears
Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Yep. Do a non-authoritative resrote in DSRM asap. It's only going
to get expotentially worse until you do.
Restart the server and do the dcdiag on both DC's with verification
that bidirectional replicational is working before making *any*
changes to AD objects.
Let's hope Brad does it ASAP. Brad, let us know how you make out.
Ace
--
/kj
Brad Pears
2010-02-23 17:24:18 UTC
Permalink
OK, so do the non-authoritative restore and then after the reboot, run
dcdiag on the SBS machine to check that everything is replicating properly?

Thanks, Brad
Post by kj [SBS MVP]
Post by Brad Pears
I am going to attempt this tomorrow (Tuesday) morning. I will jsut do
a system state restore - not a drive c: restore - as nothing there
should be an issue - it's all an AD issue...
Once I have completed the restore, if everything worked, will my other
win2k3 domain controller replicate it's existing AD structure back to
the SBS machine or will the SBS replicate it's restored structure out
to the other dc??
The SBS server will initially be like it was at System State backup time.
The other DC will replicate all it's changes and bring the SBS server up
to date. Then the SBS server can be used to make changes to the domain
again.
At this point it really doesn;t matter what
Post by Brad Pears
happens really - the structure has not changed at all other than the
new users I added last week won't exist in the restored AD structure
- but they do exisit currently in the backup DC's structure only.
Well, there are still things changing in the domain. Computer accounts are
changing passwords, users may be changing passwords, .... some of it
matters and some of it might not, but changes are a happening.
Post by Brad Pears
Might this cause an issue?? Should I remove them from the other DC's
structure before doing the restore??
No. Do nothing to the other DC. Just do a non authoritative restore to the
SBS server. Check with dcdiag and validate replication.
Post by Brad Pears
I'm guessing leave it alone??
One other question I have.... if the restore doesn;t wind up
working, can I make my win2k dc the PDC, RID master etc... so that I
can just have the one DC in the domain? That would allow me to set up
a win2K machine with Exchange only on it and then later set up
another win2k3 backup DC thus getting rid of SBS altogether... Is
that what one would call "seizing the FSMO roles"??? Not sure f this
can actually be done when it comes to SBS 2000
You really don't wanto to have to do that with SBS. Just do the non
authoritative restore and you should be good.
Post by Brad Pears
Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Yep. Do a non-authoritative resrote in DSRM asap. It's only going
to get expotentially worse until you do.
Restart the server and do the dcdiag on both DC's with verification
that bidirectional replicational is working before making *any*
changes to AD objects.
Let's hope Brad does it ASAP. Brad, let us know how you make out.
Ace
--
/kj
kj [SBS MVP]
2010-02-23 17:34:54 UTC
Permalink
Post by Brad Pears
OK, so do the non-authoritative restore and then after the reboot, run
dcdiag on the SBS machine to check that everything is replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
Post by Brad Pears
Thanks, Brad
Post by kj [SBS MVP]
Post by Brad Pears
I am going to attempt this tomorrow (Tuesday) morning. I will jsut
do a system state restore - not a drive c: restore - as nothing
there should be an issue - it's all an AD issue...
Once I have completed the restore, if everything worked, will my
other win2k3 domain controller replicate it's existing AD structure
back to the SBS machine or will the SBS replicate it's restored
structure out to the other dc??
The SBS server will initially be like it was at System State backup
time. The other DC will replicate all it's changes and bring the SBS
server up to date. Then the SBS server can be used to make changes
to the domain again.
At this point it really doesn;t matter what
Post by Brad Pears
happens really - the structure has not changed at all other than the
new users I added last week won't exist in the restored AD structure
- but they do exisit currently in the backup DC's structure only.
Well, there are still things changing in the domain. Computer
accounts are changing passwords, users may be changing passwords,
.... some of it matters and some of it might not, but changes are a
happening.
Post by Brad Pears
Might this cause an issue?? Should I remove them from the other
DC's structure before doing the restore??
No. Do nothing to the other DC. Just do a non authoritative restore
to the SBS server. Check with dcdiag and validate replication.
Post by Brad Pears
I'm guessing leave it alone??
One other question I have.... if the restore doesn;t wind up
working, can I make my win2k dc the PDC, RID master etc... so that
I can just have the one DC in the domain? That would allow me to
set up a win2K machine with Exchange only on it and then later set
up another win2k3 backup DC thus getting rid of SBS altogether... Is
that what one would call "seizing the FSMO roles"??? Not sure f
this can actually be done when it comes to SBS 2000
You really don't wanto to have to do that with SBS. Just do the non
authoritative restore and you should be good.
Post by Brad Pears
Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Yep. Do a non-authoritative resrote in DSRM asap. It's only going
to get expotentially worse until you do.
Restart the server and do the dcdiag on both DC's with
verification that bidirectional replicational is working before
making *any* changes to AD objects.
Let's hope Brad does it ASAP. Brad, let us know how you make out.
Ace
--
/kj
--
/kj
Ace Fekay [MVP-DS, MCT]
2010-02-23 17:39:48 UTC
Permalink
Post by kj [SBS MVP]
Post by Brad Pears
OK, so do the non-authoritative restore and then after the reboot, run
dcdiag on the SBS machine to check that everything is replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
I agree. Run dcdiag /v (for verbose info).

Ace
Brad Pears
2010-02-23 18:19:59 UTC
Permalink
great - thanks guys... I have never had a problem with a domain controller
before - EVER, so this is all new to me!!!! unfortunately this is when you
wind up learning the most!!!!

Thanks Brad

PS... I'll keep you guys posted on how it goes...
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Post by Brad Pears
OK, so do the non-authoritative restore and then after the reboot, run
dcdiag on the SBS machine to check that everything is replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
I agree. Run dcdiag /v (for verbose info).
Ace
Brad Pears
2010-02-23 19:41:35 UTC
Permalink
WHen I currently run dcdiag on either of my domain controllers, it tells me
that a recent replication attempt failed from TRUE3 to TRUE5 (true3 is the
sbs, true5 is hte other dc) and indicates that the target principal name is
incorrect...

Where do I check what the principal name is and what exactly is it supposed
to be???

Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Post by Brad Pears
OK, so do the non-authoritative restore and then after the reboot, run
dcdiag on the SBS machine to check that everything is replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
I agree. Run dcdiag /v (for verbose info).
Ace
kj [SBS MVP]
2010-02-23 20:16:26 UTC
Permalink
Post by Brad Pears
WHen I currently run dcdiag on either of my domain controllers, it
tells me that a recent replication attempt failed from TRUE3 to TRUE5
(true3 is the sbs, true5 is hte other dc) and indicates that the
target principal name is incorrect...
Where do I check what the principal name is and what exactly is it
supposed to be???
One of the reasons replication is not working. Do your restore *then* check!
Post by Brad Pears
Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Post by Brad Pears
OK, so do the non-authoritative restore and then after the reboot,
run dcdiag on the SBS machine to check that everything is
replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
I agree. Run dcdiag /v (for verbose info).
Ace
--
/kj
Brad Pears
2010-02-23 20:56:45 UTC
Permalink
LOL, got ya... doing that in 5 minutes.... will keep you posted...

Brad
Post by kj [SBS MVP]
Post by Brad Pears
WHen I currently run dcdiag on either of my domain controllers, it
tells me that a recent replication attempt failed from TRUE3 to TRUE5
(true3 is the sbs, true5 is hte other dc) and indicates that the
target principal name is incorrect...
Where do I check what the principal name is and what exactly is it
supposed to be???
One of the reasons replication is not working. Do your restore *then* check!
Post by Brad Pears
Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Post by Brad Pears
OK, so do the non-authoritative restore and then after the reboot,
run dcdiag on the SBS machine to check that everything is
replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
I agree. Run dcdiag /v (for verbose info).
Ace
--
/kj
Brad Pears
2010-02-23 23:21:29 UTC
Permalink
bad news, I did the restore , rebooted, logged in and did the dcdiag... the
first dcdiag showed good results... and then it went south. FRS shows
replication errors (unable to replicate) in teh event log, the ne4xt dcdiag
shows errors replicating, incorrect principal name etc... etc...

dcdiag on my other domain controller shows the same types of errors... I
wonder if that directory is toast. Maybe I should attempt a restore of it's
system state. I do have a recent backup of it's system state from jsut prior
to my SBS crash...

If I try that, should restore it, see what happens, and if that doesn;t
clear things up - then restore my SBS system state again do you think??

The other option is to dig in there and try to fix things... but I will need
a lot of help doing that...

Brad
Post by kj [SBS MVP]
Post by Brad Pears
WHen I currently run dcdiag on either of my domain controllers, it
tells me that a recent replication attempt failed from TRUE3 to TRUE5
(true3 is the sbs, true5 is hte other dc) and indicates that the
target principal name is incorrect...
Where do I check what the principal name is and what exactly is it
supposed to be???
One of the reasons replication is not working. Do your restore *then* check!
Post by Brad Pears
Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Post by Brad Pears
OK, so do the non-authoritative restore and then after the reboot,
run dcdiag on the SBS machine to check that everything is
replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
I agree. Run dcdiag /v (for verbose info).
Ace
--
/kj
kj [SBS MVP]
2010-02-24 01:04:01 UTC
Permalink
Post the dcdiags from the SBS and the other DC. Make no changes to the other
DC.

Assuming that no errors occured on the DSRM non autroitative restore, right?
Post by Brad Pears
bad news, I did the restore , rebooted, logged in and did the
dcdiag... the first dcdiag showed good results... and then it went
south. FRS shows replication errors (unable to replicate) in teh
event log, the ne4xt dcdiag shows errors replicating, incorrect
principal name etc... etc...
dcdiag on my other domain controller shows the same types of
errors... I wonder if that directory is toast. Maybe I should
attempt a restore of it's system state. I do have a recent backup of
it's system state from jsut prior to my SBS crash...
If I try that, should restore it, see what happens, and if that
doesn;t clear things up - then restore my SBS system state again do
you think??
The other option is to dig in there and try to fix things... but I
will need a lot of help doing that...
Brad
Post by kj [SBS MVP]
Post by Brad Pears
WHen I currently run dcdiag on either of my domain controllers, it
tells me that a recent replication attempt failed from TRUE3 to
TRUE5 (true3 is the sbs, true5 is hte other dc) and indicates that
the target principal name is incorrect...
Where do I check what the principal name is and what exactly is it
supposed to be???
One of the reasons replication is not working. Do your restore *then* check!
Post by Brad Pears
Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Post by Brad Pears
OK, so do the non-authoritative restore and then after the
reboot, run dcdiag on the SBS machine to check that everything is
replicating properly?
Yep, but not a bad idea to run dcdiag on both DC's.
I agree. Run dcdiag /v (for verbose info).
Ace
--
/kj
--
/kj
Ace Fekay [MVP-DS, MCT]
2010-02-24 01:21:01 UTC
Permalink
Post by kj [SBS MVP]
Post the dcdiags from the SBS and the other DC. Make no changes to the
other DC.
Assuming that no errors occured on the DSRM non autroitative restore, right?
I agree, that would be helpful to know.

I suggest for Brad to check the event logs too, if there were any errors
regarding the non-authoratative restore. Also, it would be helpful to see
all event log errors in any of the logs regarding AD (FRS, etc). Post the
EventID# and Source names.

I think it's time as well to see:

1. ipconfig /all from both DCs, too, please.
2. repadmin.exe /showrepl dc* /verbose /all /intersite (on both DCs)
3. ntfrsutl ds your_dc_name (on both DCs)

Ace
Brad Pears
2010-02-24 03:38:31 UTC
Permalink
Hey guys, I wound up doing a non authoritative restore of my other DC and
that screwed things up even more - to the point where NO ONE could even log
onto the domain. OUCH!!! SO then I figured I'd better do an authoritative
restore of my SBS to try to get it back and guess what.... It is now up and
running! My other DC is in safe mode (DFRS) as we speak (I was gonna attempt
another restore to it but decided against that once my SBS was up again.)
I'm kind of scared to boot it back up normally in case it causes havoc on
the network again and somehow replicates something that screwws it all up
again. It shoudn;t really becasue of the authoritative restore but I'm
nervous as heck!

Here's what I am thinking... Right now my sbs 2000 machine is the only DC
running and everything seems to be working wiothout digging really deep -
cuz I am getting tired... been more than 12 hours now. I am thinking I want
to demote the other DC, clean it up and then either re-promote it OR promote
another one of my win2k3 servers to be a DC instead. I bet if I do this,
replication may just work...

Can you give me some instructions and/or suggestions on what I need to do
with that other DC to eliminate it as a dc, then clean it up and then
re-prmote etc...??

What do you think?

Thanks fellas...

Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by kj [SBS MVP]
Post the dcdiags from the SBS and the other DC. Make no changes to the
other DC.
Assuming that no errors occured on the DSRM non autroitative restore, right?
I agree, that would be helpful to know.
I suggest for Brad to check the event logs too, if there were any errors
regarding the non-authoratative restore. Also, it would be helpful to see
all event log errors in any of the logs regarding AD (FRS, etc). Post the
EventID# and Source names.
1. ipconfig /all from both DCs, too, please.
2. repadmin.exe /showrepl dc* /verbose /all /intersite (on both DCs)
3. ntfrsutl ds your_dc_name (on both DCs)
Ace
Ace Fekay [MVP-DS, MCT]
2010-02-24 06:28:08 UTC
Permalink
Post by Brad Pears
Hey guys, I wound up doing a non authoritative restore of my other DC and
that screwed things up even more - to the point where NO ONE could even
log onto the domain. OUCH!!! SO then I figured I'd better do an
authoritative restore of my SBS to try to get it back and guess what....
It is now up and running! My other DC is in safe mode (DFRS) as we speak
(I was gonna attempt another restore to it but decided against that once
my SBS was up again.) I'm kind of scared to boot it back up normally in
case it causes havoc on the network again and somehow replicates something
that screwws it all up again. It shoudn;t really becasue of the
authoritative restore but I'm nervous as heck!
Here's what I am thinking... Right now my sbs 2000 machine is the only DC
running and everything seems to be working wiothout digging really deep -
cuz I am getting tired... been more than 12 hours now. I am thinking I
want to demote the other DC, clean it up and then either re-promote it OR
promote another one of my win2k3 servers to be a DC instead. I bet if I do
this, replication may just work...
Can you give me some instructions and/or suggestions on what I need to do
with that other DC to eliminate it as a dc, then clean it up and then
re-prmote etc...??
What do you think?
Thanks fellas...
Brad
Hmm, you got lucky!

On the other DC, run:
dcpromo /forcedemote
Then delete it's reference in Sites and Services

Just in case there are any references to the that DC, run a MetaData
Cleanup:

How to remove data in Active Directory after an unsuccessful domain
controller demotion Windows 2000 and 2003
http://support.microsoft.com/kb/216498

Ace
Phillip Windell
2010-02-24 16:29:50 UTC
Permalink
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Hey guys, I wound up doing a non authoritative restore of my other DC and
that screwed things up even more - to the point where NO ONE could even
Hmm, you got lucky!
dcpromo /forcedemote
Then delete it's reference in Sites and Services
Just in case there are any references to the that DC, run a MetaData
How to remove data in Active Directory after an unsuccessful domain
controller demotion Windows 2000 and 2003
http://support.microsoft.com/kb/216498
Kinda proves the point that:

1. a second DC with SBS is about worthless.
2. Good backups are the primary means of DR with SBS
3. Fatal flaw in the SBS concept of only one DC in that if there was a
hardware failure and identical hardware couldn't be found to replace
it,...your only good means of DR would be nearly worthless.
4. As soon as someone learns enough about SBS to deal with it effectively
then they have kinda outgrown either SBS or they have outgrown their job at
a place so small that they run SBS.
--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Brad Pears
2010-02-24 18:29:04 UTC
Permalink
Thanks Ace!

A couple questions...

1) Can I run the "demote" command in DFRS mode or do I have to boot it back
up regularly and then run it? I am very scared to start that puppy back up
in regular mode and have it connected to the network for fear of what might
happen once it connects. The AD I restored (authoritatively) last night
should be the newst version of AD so it shouldn't atttempt a replication the
other way but I am still a little worried...

2) Can I delete the other DC I am demoting from AD Sites and Services BEFORE
I "demote" it or do I need to wait until after I have tried the demotion? I
realize the the demotion will attempt to remove it from AD but I am worried
about what it might do to my AD now that I have AD back up and running. I am
thinking I could just manually remove it from AD using the "AD cleanup" link
you supplied and run the demote on the other server with it not connected
at all to the network.

Thoughts?

Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Hey guys, I wound up doing a non authoritative restore of my other DC and
that screwed things up even more - to the point where NO ONE could even
log onto the domain. OUCH!!! SO then I figured I'd better do an
authoritative restore of my SBS to try to get it back and guess what....
It is now up and running! My other DC is in safe mode (DFRS) as we speak
(I was gonna attempt another restore to it but decided against that once
my SBS was up again.) I'm kind of scared to boot it back up normally in
case it causes havoc on the network again and somehow replicates
something that screwws it all up again. It shoudn;t really becasue of
the authoritative restore but I'm nervous as heck!
Here's what I am thinking... Right now my sbs 2000 machine is the only DC
running and everything seems to be working wiothout digging really deep -
cuz I am getting tired... been more than 12 hours now. I am thinking I
want to demote the other DC, clean it up and then either re-promote it OR
promote another one of my win2k3 servers to be a DC instead. I bet if I
do this, replication may just work...
Can you give me some instructions and/or suggestions on what I need to do
with that other DC to eliminate it as a dc, then clean it up and then
re-prmote etc...??
What do you think?
Thanks fellas...
Brad
Hmm, you got lucky!
dcpromo /forcedemote
Then delete it's reference in Sites and Services
Just in case there are any references to the that DC, run a MetaData
How to remove data in Active Directory after an unsuccessful domain
controller demotion Windows 2000 and 2003
http://support.microsoft.com/kb/216498
Ace
Ace Fekay [MVP-DS, MCT]
2010-02-24 18:40:41 UTC
Permalink
Post by Brad Pears
Thanks Ace!
A couple questions...
1) Can I run the "demote" command in DFRS mode or do I have to boot it
back up regularly and then run it? I am very scared to start that puppy
back up in regular mode and have it connected to the network for fear of
what might happen once it connects. The AD I restored (authoritatively)
last night should be the newst version of AD so it shouldn't atttempt a
replication the other way but I am still a little worried...
You have to have it up in normal mode to demote it. The /forcedemote switch
forces it out of AD, therefore it needs the other DC (SBS) up and running.
It won;t cause any problems other than what you already have!
Post by Brad Pears
2) Can I delete the other DC I am demoting from AD Sites and Services
BEFORE I "demote" it or do I need to wait until after I have tried the
demotion? I realize the the demotion will attempt to remove it from AD but
I am worried about what it might do to my AD now that I have AD back up
and running. I am thinking I could just manually remove it from AD using
the "AD cleanup" link you supplied and run the demote on the other server
with it not connected at all to the network.
Remove it after the demotion. That is a post-task.

Then run the metadata cleanup procedure to make sure it's reference no
longer exists in the AD database. It's a rather simple procedure if you
follow the steps verbatim. If you miss a step, then it will cause confusion.
Post by Brad Pears
Thoughts?
Brad
Brad, hang in there, you are almost there. Don't read into it what's not
there. Just follow the process I've recommended, and you should be ok.

Ace
Brad Pears
2010-02-24 21:07:41 UTC
Permalink
Thanks Ace... I am going to give it a go now... I really appreciate your
help!
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Thanks Ace!
A couple questions...
1) Can I run the "demote" command in DFRS mode or do I have to boot it
back up regularly and then run it? I am very scared to start that puppy
back up in regular mode and have it connected to the network for fear of
what might happen once it connects. The AD I restored (authoritatively)
last night should be the newst version of AD so it shouldn't atttempt a
replication the other way but I am still a little worried...
You have to have it up in normal mode to demote it. The /forcedemote
switch forces it out of AD, therefore it needs the other DC (SBS) up and
running. It won;t cause any problems other than what you already have!
Post by Brad Pears
2) Can I delete the other DC I am demoting from AD Sites and Services
BEFORE I "demote" it or do I need to wait until after I have tried the
demotion? I realize the the demotion will attempt to remove it from AD
but I am worried about what it might do to my AD now that I have AD back
up and running. I am thinking I could just manually remove it from AD
using the "AD cleanup" link you supplied and run the demote on the other
server with it not connected at all to the network.
Remove it after the demotion. That is a post-task.
Then run the metadata cleanup procedure to make sure it's reference no
longer exists in the AD database. It's a rather simple procedure if you
follow the steps verbatim. If you miss a step, then it will cause confusion.
Post by Brad Pears
Thoughts?
Brad
Brad, hang in there, you are almost there. Don't read into it what's not
there. Just follow the process I've recommended, and you should be ok.
Ace
Ace Fekay [MVP-DS, MCT]
2010-02-24 21:13:29 UTC
Permalink
Post by Brad Pears
Thanks Ace... I am going to give it a go now... I really appreciate your
help!
You are welcome! Don't forget KJ and anyone else that was helping, too.

Ace
Brad Pears
2010-02-24 21:41:18 UTC
Permalink
Yes absolutely, thanks to everyone for helping me out... I know it was an
effort by several folks!!! You guys have likely all been in the same boat
as me at one time or another so this you can't google!! It's nice to be
able to talk with someone who has actually been there!!

Thanks to all for you efforts in helping me get this resolved...

Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Thanks Ace... I am going to give it a go now... I really appreciate your
help!
You are welcome! Don't forget KJ and anyone else that was helping, too.
Ace
Ace Fekay [MVP-DS, MCT]
2010-02-24 22:43:20 UTC
Permalink
Post by Brad Pears
Yes absolutely, thanks to everyone for helping me out... I know it was an
effort by several folks!!! You guys have likely all been in the same boat
as me at one time or another so this you can't google!! It's nice to be
able to talk with someone who has actually been there!!
Thanks to all for you efforts in helping me get this resolved...
I knew all of this because I slept at a Holiday Inn last night. :-)

You are welcome.

Ace
kj [SBS MVP]
2010-02-24 22:51:45 UTC
Permalink
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Yes absolutely, thanks to everyone for helping me out... I know it
was an effort by several folks!!! You guys have likely all been in
the same boat as me at one time or another so this you can't
google!! It's nice to be able to talk with someone who has actually
been there!! Thanks to all for you efforts in helping me get this
resolved...
I knew all of this because I slept at a Holiday Inn last night. :-)
...and being a very *patient* and dedicated professional. Kudos Ace.
Post by Ace Fekay [MVP-DS, MCT]
You are welcome.
Ace
--
/kj
Ace Fekay [MVP-DS, MCT]
2010-02-25 00:19:22 UTC
Permalink
Post by kj [SBS MVP]
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Yes absolutely, thanks to everyone for helping me out... I know it
was an effort by several folks!!! You guys have likely all been in
the same boat as me at one time or another so this you can't
google!! It's nice to be able to talk with someone who has actually
been there!! Thanks to all for you efforts in helping me get this
resolved...
I knew all of this because I slept at a Holiday Inn last night. :-)
...and being a very *patient* and dedicated professional. Kudos Ace.
Post by Ace Fekay [MVP-DS, MCT]
You are welcome.
Ace
--
/kj
Thanks, KJ!! :-)

Ace
Brad Pears
2010-02-24 21:56:38 UTC
Permalink
HOLY CRAP!!!!

I restarted my other domain controller, and guess what??? Everything seems
to be working!! Both dc's are replicating and I'm not getting a bunch of
errors in either of the event logs!!! Things are looking pretty clean...

I'll leave it like this for bit and we'll see what happens...

Thanks again for all your help!!!!
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Thanks Ace... I am going to give it a go now... I really appreciate your
help!
You are welcome! Don't forget KJ and anyone else that was helping, too.
Ace
Ace Fekay [MVP-DS, MCT]
2010-02-24 22:42:35 UTC
Permalink
Post by Brad Pears
HOLY CRAP!!!!
I restarted my other domain controller, and guess what??? Everything
seems to be working!! Both dc's are replicating and I'm not getting a
bunch of errors in either of the event logs!!! Things are looking pretty
clean...
I'll leave it like this for bit and we'll see what happens...
Thanks again for all your help!!!!
A restart did it?? Hmm, interesting. Maybe a simple netlogon restart could
have done the trick? Well, keep tabs on it, and let us know what happens.

Ace
Brad Pears
2010-02-24 22:59:27 UTC
Permalink
funny you should say that... the sysvol and netlogon shares were not
present on the other win2k3 dc - and the scripts and policies folders were
missing. I had made a copy of them previously and placed them on the c:
drive as a backup, so I copied them back to where they belong, stopped frs,
changed burflags to "d4", (changed burflags to d2 on my sbs) and then
restarted frs on teh other DC. Now I have the sysvol and netlogon shares but
it has also created duplicates of the sysvol and netlogon directories - and
given them different names. As well, these duplicate directories have
replicated over to the SBS machine... What is the best way to clean all of
this up?? The good ness is that the shares are functional and the proper
dirs (scripts and policies) are present. Do I need to worry about getting
rid of the other duplicate scripts and policies folders that it created??
Should I just deleted them from one of the machines - which should remove
them through replication on the other right???

Thanks, Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
HOLY CRAP!!!!
I restarted my other domain controller, and guess what??? Everything
seems to be working!! Both dc's are replicating and I'm not getting a
bunch of errors in either of the event logs!!! Things are looking pretty
clean...
I'll leave it like this for bit and we'll see what happens...
Thanks again for all your help!!!!
A restart did it?? Hmm, interesting. Maybe a simple netlogon restart could
have done the trick? Well, keep tabs on it, and let us know what happens.
Ace
Ace Fekay [MVP-DS, MCT]
2010-02-25 00:23:18 UTC
Permalink
Post by Brad Pears
funny you should say that... the sysvol and netlogon shares were not
present on the other win2k3 dc - and the scripts and policies folders were
drive as a backup, so I copied them back to where they belong, stopped
frs, changed burflags to "d4", (changed burflags to d2 on my sbs) and then
restarted frs on teh other DC. Now I have the sysvol and netlogon shares
but it has also created duplicates of the sysvol and netlogon
directories - and given them different names. As well, these duplicate
directories have replicated over to the SBS machine... What is the best
way to clean all of this up?? The good ness is that the shares are
functional and the proper dirs (scripts and policies) are present. Do I
need to worry about getting rid of the other duplicate scripts and
policies folders that it created?? Should I just deleted them from one of
the machines - which should remove them through replication on the other
right???
Thanks, Brad
Ok, let's slow down a bit. What article did you follow to change the
burflags, exactly when did you do this, and what prompted you to do this?
Are you asking and receiving help elsewhere? After the non-auth restore of
the non-SBS? Let's not complicate things, or it may result into a deeper
hole you're digging.

Remember I asked for event logs and other info? Let's try this again. Please
post:

1. ipconfig /all from both DCs, too, please.
2. repadmin.exe /showrepl dc* /verbose /all /intersite (on both DCs)
3. ntfrsutl ds your_dc_name (on both DCs)

AND DON'T make any more changes!!

Ace
Phillip Windell
2010-02-25 15:02:15 UTC
Permalink
Post by Brad Pears
funny you should say that... the sysvol and netlogon shares were not
present on the other win2k3 dc - and the scripts and policies folders
were missing. I had made a copy of them previously and placed them on the
c: drive as a backup, so I copied them back to where they belong, stopped
frs, changed burflags to "d4", (changed burflags to d2 on my sbs) and
then restarted frs on teh other DC. Now I have the sysvol and netlogon
shares but it has also created duplicates of the sysvol and netlogon
directories - and given them different names. As well, these duplicate
directories have replicated over to the SBS machine... What is the best
way to clean all of this up?? The good ness is that the shares are
functional and the proper dirs (scripts and policies) are present. Do I
need to worry about getting rid of the other duplicate scripts and
policies folders that it created?? Should I just deleted them from one of
the machines - which should remove them through replication on the other
right???
Man!

Just get rid of this other DC and FORGET it!
DCPromo it down to a member Server and leave it.

SBS was never meant to have a second DC in the first place!
Run the SBS by itself. Make System State backup,..a lot,...all the
time,...keep multiple copies of them.

If you want 2 DCs,...get rid of SBS!!!,...and build a normal system with
nomral DCs and normal Servers,........or AT LEAST DCPromo the one down to a
member wait about a day to verify that the SBS is healthy,...then DCPromo
the second server back to a fresh clean new DC.
--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Leonid S. Knyshov // SBS Expert
2010-02-25 15:13:11 UTC
Permalink
Post by Phillip Windell
Man!
Just get rid of this other DC and FORGET it!
DCPromo it down to a member Server and leave it.
SBS was never meant to have a second DC in the first place!
Run the SBS by itself. Make System State backup,..a lot,...all the
time,...keep multiple copies of them.
If you want 2 DCs,...get rid of SBS!!!,...and build a normal system with
nomral DCs and normal Servers,........or AT LEAST DCPromo the one down to a
member wait about a day to verify that the SBS is healthy,...then DCPromo
the second server back to a fresh clean new DC.
Frustrating as it may be, SBS works perfectly fine with additional DCs
as long as it hogs all the roles. I have a multi-site install that has
worked for about 7 years now with an extra DC at each building. It is a
good idea to have a second DC in an SBS environment, if it's in the
budget. :)
--
Leonid S. Knyshov
Crashproof Solutions
510-282-1008
Twitter: @wiseleo
http://crashproofsolutions.com
Microsoft Small Business Specialist
Please vote "helpful" if I helped you :)
Ace Fekay [MVP-DS, MCT]
2010-02-25 15:33:52 UTC
Permalink
"Leonid S. Knyshov // SBS Expert"
Post by Phillip Windell
Man!
Just get rid of this other DC and FORGET it!
DCPromo it down to a member Server and leave it.
SBS was never meant to have a second DC in the first place!
Run the SBS by itself. Make System State backup,..a lot,...all the
time,...keep multiple copies of them.
If you want 2 DCs,...get rid of SBS!!!,...and build a normal system with
nomral DCs and normal Servers,........or AT LEAST DCPromo the one down to a
member wait about a day to verify that the SBS is healthy,...then DCPromo
the second server back to a fresh clean new DC.
Frustrating as it may be, SBS works perfectly fine with additional DCs as
long as it hogs all the roles. I have a multi-site install that has worked
for about 7 years now with an extra DC at each building. It is a good idea
to have a second DC in an SBS environment, if it's in the budget. :)
--
Leonid S. Knyshov
Crashproof Solutions
510-282-1008
http://crashproofsolutions.com
Microsoft Small Business Specialist
Please vote "helpful" if I helped you :)
Whether to continue with an extra DC or not, and I have one SBS installation
with two DCs, I was hoping Brad had forcedemoted the other DC out, cleaned
it up, and re-promoted it instead of going further with resetting the
burflag to force replication. When it comes to troubleshooting AD
replication, I like to use the least path of resistance. I look at playing
with (using the term loosely), the burflag and other registry changes as
additional tasks that are not necessarily required, especially with what
Brad's been through with this ordeal, if you have the option to simply yank
a DC out of the infrastructure with a forcedemotion or metadata cleanup,
which takes much, much less time. I look at having to that as the last
resort, where as a demotion and re-promotion could have taken care of it
cleanly and much quicker without losing any apps on the other DC or anything
else. Of course he would just have to re-enable it as a GC after
re-promoting it. A friend of mine once said that if he had to take
additional steps to try to fix something that had a 50-50 shot at working,
and taking twice as long, and longer if it didn't work, that it would cut
into his drinking time. Hmm, good point!

So I hope whatever Brad's in the middle of now is not going to cut into his
drinking time. :-)

Ace
Phillip Windell
2010-02-25 15:35:21 UTC
Permalink
"Leonid S. Knyshov // SBS Expert"
Post by Phillip Windell
If you want 2 DCs,...get rid of SBS!!!,...and build a normal system with
nomral DCs and normal Servers,........or AT LEAST DCPromo the one down to a
member wait about a day to verify that the SBS is healthy,...then DCPromo
the second server back to a fresh clean new DC.
Frustrating as it may be, SBS works perfectly fine with additional DCs as
long as it hogs all the roles. I have a multi-site install that has worked
for about 7 years now with an extra DC at each building. It is a good idea
to have a second DC in an SBS environment, if it's in the budget. :)
Yes, true. That is why my last statement gave that as the last option (the
one that begins with "..at least..").

Sorry to look like I was yelling (I don't think I was),...but this thread
has strung out so looonnngggg that the thread has become painful and
frustrating to watch even if I haven't been the main one posting in it.
--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Ace Fekay [MVP-DS, MCT]
2010-02-25 15:41:39 UTC
Permalink
Post by Ace Fekay [MVP-DS, MCT]
"Leonid S. Knyshov // SBS Expert"
Post by Phillip Windell
If you want 2 DCs,...get rid of SBS!!!,...and build a normal system with
nomral DCs and normal Servers,........or AT LEAST DCPromo the one down to a
member wait about a day to verify that the SBS is healthy,...then DCPromo
the second server back to a fresh clean new DC.
Frustrating as it may be, SBS works perfectly fine with additional DCs as
long as it hogs all the roles. I have a multi-site install that has
worked for about 7 years now with an extra DC at each building. It is a
good idea to have a second DC in an SBS environment, if it's in the
budget. :)
Yes, true. That is why my last statement gave that as the last option (the
one that begins with "..at least..").
Sorry to look like I was yelling (I don't think I was),...but this thread
has strung out so looonnngggg that the thread has become painful and
frustrating to watch even if I haven't been the main one posting in it.
--
Phillip Windell
Yes, it has grown. I'm trying to keep what's occured in memory to avoid
having to go back through it to find something. And I don't think you were
yelling. You were just trying to make a point. :-)

Ace
Brad Pears
2010-02-25 17:37:16 UTC
Permalink
PS... I should mention that everything appears to be working just fine with
both DC's right now... Still demoting it today though...

Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by Ace Fekay [MVP-DS, MCT]
"Leonid S. Knyshov // SBS Expert"
Post by Leonid S. Knyshov // SBS Expert
Post by Phillip Windell
If you want 2 DCs,...get rid of SBS!!!,...and build a normal system with
nomral DCs and normal Servers,........or AT LEAST DCPromo the one down to a
member wait about a day to verify that the SBS is healthy,...then DCPromo
the second server back to a fresh clean new DC.
Frustrating as it may be, SBS works perfectly fine with additional DCs
as long as it hogs all the roles. I have a multi-site install that has
worked for about 7 years now with an extra DC at each building. It is a
good idea to have a second DC in an SBS environment, if it's in the
budget. :)
Yes, true. That is why my last statement gave that as the last option
(the one that begins with "..at least..").
Sorry to look like I was yelling (I don't think I was),...but this thread
has strung out so looonnngggg that the thread has become painful and
frustrating to watch even if I haven't been the main one posting in it.
--
Phillip Windell
Yes, it has grown. I'm trying to keep what's occured in memory to avoid
having to go back through it to find something. And I don't think you were
yelling. You were just trying to make a point. :-)
Ace
Brad Pears
2010-02-24 21:13:51 UTC
Permalink
Ace, the FRS service is stopped on my SBS (I did this) Does this need to be
started before I "demote" the other DC??

Brad
Post by Ace Fekay [MVP-DS, MCT]
Post by Brad Pears
Hey guys, I wound up doing a non authoritative restore of my other DC and
that screwed things up even more - to the point where NO ONE could even
log onto the domain. OUCH!!! SO then I figured I'd better do an
authoritative restore of my SBS to try to get it back and guess what....
It is now up and running! My other DC is in safe mode (DFRS) as we speak
(I was gonna attempt another restore to it but decided against that once
my SBS was up again.) I'm kind of scared to boot it back up normally in
case it causes havoc on the network again and somehow replicates
something that screwws it all up again. It shoudn;t really becasue of
the authoritative restore but I'm nervous as heck!
Here's what I am thinking... Right now my sbs 2000 machine is the only DC
running and everything seems to be working wiothout digging really deep -
cuz I am getting tired... been more than 12 hours now. I am thinking I
want to demote the other DC, clean it up and then either re-promote it OR
promote another one of my win2k3 servers to be a DC instead. I bet if I
do this, replication may just work...
Can you give me some instructions and/or suggestions on what I need to do
with that other DC to eliminate it as a dc, then clean it up and then
re-prmote etc...??
What do you think?
Thanks fellas...
Brad
Hmm, you got lucky!
dcpromo /forcedemote
Then delete it's reference in Sites and Services
Just in case there are any references to the that DC, run a MetaData
How to remove data in Active Directory after an unsuccessful domain
controller demotion Windows 2000 and 2003
http://support.microsoft.com/kb/216498
Ace
Continue reading on narkive:
Loading...