Help! AD can't find itself!

  • Thread starter Thread starter CG
  • Start date Start date
C

CG

I was attempting to set up a DFS with fault-tolerant replication
between my two AD servers. I set up a test DFS root and DFS root
replica. I then tried to tear it down and build up a DFS root
for-real. It wouldn't work, so I tried to fix that problem. I thought
my jet database was corrupt, so I removed it per an article I found on
eventid.net... After that the domain couldn't find itself! I'm new at
AD. I do know that my DNS SRV records are intact on both servers. I
also know that there is network connectivity between the two AD
servers. I don't know where to look and what to do to repair this
problem.

Please Help!

netdiag /test:DsGetDc

.........

Computer Name: WEB1
DNS Host Name: web1.webs.local
System info : Windows 2000 Server (Build 2195)
Processor : x86 Family 15 Model 2 Stepping 7, GenuineIntel
List of installed hotfixes :
KB823182
KB823559
KB824105
KB825119
KB826232
KB828035
KB828741
KB828749
KB830352
KB835732
KB837001
KB839643
KB839645
KB840315
KB841872
KB841873
KB842526
Q147222
Q828026


Netcard queries test . . . . . . . : Passed



Per interface results:

Adapter : Intel Pro 1000 MT Gigabit Ethernet Adapter - onboard

Netcard queries test . . . : Passed


Global results:


Domain membership test . . . . . . : Failed
[WARNING] Ths system volume has not been completely replicated to
the local
machine. This machine is not working properly as a DC.


NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_{83E0CBBE-37E4-415A-8C8B-4E3C876E18DC}
1 NetBt transport currently configured.


DC discovery test. . . . . . . . . : Failed
[FATAL] Cannot find DC in domain 'WEBS'.
[ERROR_NO_SUCH_DOMAIN]


The command completed successfully
 
In
CG said:
I was attempting to set up a DFS with fault-tolerant replication
between my two AD servers. I set up a test DFS root and DFS root
replica. I then tried to tear it down and build up a DFS root
for-real. It wouldn't work, so I tried to fix that problem. I thought
my jet database was corrupt, so I removed it per an article I found on
eventid.net... After that the domain couldn't find itself! I'm new at
AD. I do know that my DNS SRV records are intact on both servers. I
also know that there is network connectivity between the two AD
servers. I don't know where to look and what to do to repair this
problem.

Please Help!

netdiag /test:DsGetDc

........

Computer Name: WEB1
DNS Host Name: web1.webs.local
System info : Windows 2000 Server (Build 2195)
Processor : x86 Family 15 Model 2 Stepping 7, GenuineIntel
List of installed hotfixes :
KB823182
KB823559
KB824105
KB825119
KB826232
KB828035
KB828741
KB828749
KB830352
KB835732
KB837001
KB839643
KB839645
KB840315
KB841872
KB841873
KB842526
Q147222
Q828026


Netcard queries test . . . . . . . : Passed



Per interface results:

Adapter : Intel Pro 1000 MT Gigabit Ethernet Adapter - onboard

Netcard queries test . . . : Passed


Global results:


Domain membership test . . . . . . : Failed
[WARNING] Ths system volume has not been completely replicated to
the local
machine. This machine is not working properly as a DC.


NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_{83E0CBBE-37E4-415A-8C8B-4E3C876E18DC}
1 NetBt transport currently configured.


DC discovery test. . . . . . . . . : Failed
[FATAL] Cannot find DC in domain 'WEBS'.
[ERROR_NO_SUCH_DOMAIN]


The command completed successfully
Click to expand...

What made you think your jet database was corrupted?
What exactly did you do?
What article did you follow?

For starters, in addition to the above, can you also post:

1. Unedited ipconfig /all
2. DNS zone name
3. AD DNS domain name.
4. All relevant Event ID errors #s.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

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

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Ace Fekay said:
In
CG said:
I was attempting to set up a DFS with fault-tolerant replication
between my two AD servers. I set up a test DFS root and DFS root
replica. I then tried to tear it down and build up a DFS root
for-real. It wouldn't work, so I tried to fix that problem. I thought
my jet database was corrupt, so I removed it per an article I found on
eventid.net... After that the domain couldn't find itself! I'm new at
AD. I do know that my DNS SRV records are intact on both servers. I
also know that there is network connectivity between the two AD
servers. I don't know where to look and what to do to repair this
problem.

Please Help!

netdiag /test:DsGetDc

........

Computer Name: WEB1
DNS Host Name: web1.webs.local
System info : Windows 2000 Server (Build 2195)
Processor : x86 Family 15 Model 2 Stepping 7, GenuineIntel
List of installed hotfixes :
KB823182
KB823559
KB824105
KB825119
KB826232
KB828035
KB828741
KB828749
KB830352
KB835732
KB837001
KB839643
KB839645
KB840315
KB841872
KB841873
KB842526
Q147222
Q828026


Netcard queries test . . . . . . . : Passed



Per interface results:

Adapter : Intel Pro 1000 MT Gigabit Ethernet Adapter - onboard

Netcard queries test . . . : Passed


Global results:


Domain membership test . . . . . . : Failed
[WARNING] Ths system volume has not been completely replicated to
the local
machine. This machine is not working properly as a DC.


NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_{83E0CBBE-37E4-415A-8C8B-4E3C876E18DC}
1 NetBt transport currently configured.


DC discovery test. . . . . . . . . : Failed
[FATAL] Cannot find DC in domain 'WEBS'.
[ERROR_NO_SUCH_DOMAIN]


The command completed successfully
Click to expand...

What made you think your jet database was corrupted?
Click to expand...

The description of the problem in the errorlog seemed to match the
symptoms I observed. Hindsight says that taking hasty action was poor
judgement. It seemed harmless at the time. I deserve a lump of coal in
my stocking this Christmas. I'm hoping that I don't get what I
deserve. I am thankful for this forum, and hopeful for a solution.
What exactly did you do?
Click to expand...

First, after removing the DFS roots and replicas. I attempted to
remove the host directory d:\dfstest-repl directory that I was using
for testing. It had a "DFS Don't remove" folder in there. Like a
three-year-old, I decided to do what I was told not to. I stopped FRS
and removed the directory. If I thought I had problems before, I
really had problems now. DFS began to complain with NtFRS:13539
errors. I thought to myself "Gee, didn't I REMOVE the DFS root? Why is
it still trying to replicate." The next error log message was
NtFrs:13555. The errorlog text was extensive. After reading the
description of the error,I found a solution that seemed to fit. I
tried [1] first: stopping and starting ntfrs. That didn't work. I
tried [4] which deleted the c:\winnt\ntfrs\jet directory. That was the
last action I did besides watch the various errors trickle in, quickly
overwhelming this novice of AD. I've attempted to research each
subsequent event that was generated. There doesn't seem to be a
cut-and-dry precedent for this problem. The only other action I've
taken is to run netdiag /fix, hoping that the root of the problem
might have been a trivial DNS error.
What article did you follow?
Click to expand...

Solution [1] and [4] in the description found in eventviewer for
NtFrs:13555.
For starters, in addition to the above, can you also post:

1. Unedited ipconfig /all
Click to expand...

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : addweb1
Primary DNS Suffix . . . . . . . : webs.add123.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : webs.add123.com
add123.com

Ethernet adapter Intel Pro 1000 MT Gigabit Ethernet Adapter - onboard:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) 82540EM Based
Network Conne
ction
Physical Address. . . . . . . . . : 00-C0-9F-16-F5-66
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.168.4
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.168.1
DNS Servers . . . . . . . . . . . : 192.168.168.4
192.168.168.30
2. DNS zone name
webs.add123.com

3. AD DNS domain name.
webs.add123.com

4. All relevant Event ID errors #s.
Click to expand...

NtFrs:13539
NtFrs:13555
NtFrs:13552
NtFrs:13516
NtFrs:13530
NtFrs:13553
NtFrs:13565
NtFrs:13508
NtFrs:13562

Symptomatic errors:
Userenv:1000
SceSrv:1003
NetLogon:5719
BROWSER:8021

Let me know if you need more.
 
In CG <[email protected]> made a post then I commented below


Well, I won't be the one to put coal in your stockings! You'll have to do
that! :-)

Your configuration is fine. Just wanted to eliminate any DNS/AD issues that
can may also have been contributing to the problem.

You've done alot, don't know where to start. Have you tried to setup a new
root and start over?

Take a look at these articles and see if they help out.

http://www.eventid.net/display.asp?eventid=13539&eventno=355&source=NtFrs&phase=1

Overview of DFS in Windows 2000
http://support.microsoft.com/?id=812487

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

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

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Ace is correct, the core of your problem is FRS. If you absolutely need to
have this DC available and authenticating clients before you resolve your
FRS related problem you may edit the registry value below:

\HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Netlogon\Parameters\Sysvolready

Change the currently 0 value to 1 and then restart the Netlogon service.

This will tell the DC to advertise as a DC despite the SYSVOL not being
properly shared out. It will then provide authentication services and other
DC -specific services, but will likely not provide group policy to clients
until the FRS issue is resolved. Clients will fail over to other DCs for
that and most likely never notice a difference, depending on network
topology.

The above is a workaround though until you can get FRS working. What are
your FRS error events?
--
Tim Springston
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"Ace Fekay [MVP]"
 
In
Tim Springston said:
Ace is correct, the core of your problem is FRS. If you absolutely
need to have this DC available and authenticating clients before you
resolve your FRS related problem you may edit the registry value
below:

\HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Netlogon\Parameters\Sysvolready

Change the currently 0 value to 1 and then restart the Netlogon
service.

This will tell the DC to advertise as a DC despite the SYSVOL not
being properly shared out. It will then provide authentication
services and other DC -specific services, but will likely not provide
group policy to clients until the FRS issue is resolved. Clients
will fail over to other DCs for that and most likely never notice a
difference, depending on network topology.

The above is a workaround though until you can get FRS working. What
are your FRS error events?
Click to expand...

I forgot all about that key! I hope it helps GC to get this going.
Ace
 
Ace Fekay said:
In

I forgot all about that key! I hope it helps GC to get this going.
Ace
Click to expand...

Thankfully, I'm not having a problem authenticating windows client
users. Authenticating web users is the primary function for this AD
domain, which is still working. We have no group policies on this
domain, so that's not a problem either. Being such a novice, you may
have to spell things out for me just to get me started. I checked
those two articles. Here's what eventid.net said:

|From a newsgroup post: "Make sure the permissions on the
|destination server are granted for Server\SYSTEM
|(full control). You have to make sure that the
|Frs-Staging (usually on another drive) has also permissions
|to be created. For the replica in the registry, use AD
|users and computers and configure mmc to display users
|groups and computers as containers, then navigate your
|server until you find the NTFRS Subscriptions. You should
|be able to remove the DFS from there."

Where does one set the location for "Frs-Staging" ... Mine just
magically appeared. :) It looks like permissions are set properly,
though.

I dug through AD Users and Computers (displayed as containers) and
could find nothing that looked like an NTFRS Subscription. Could you
describe what am I looking for precisely?

Here are the NtFRS errors that I'm seeing:

NtFrs:13539
NtFrs:13555
NtFrs:13552
NtFrs:13516
NtFrs:13530
NtFrs:13553
NtFrs:13565
NtFrs:13508
NtFrs:13562

Also, I don't see SYSVOL$ when I run "net share" on either server in
the AD pair. Is it possible (advisable?) to set up a proper SYSVOL$
share manually?

Can I check to see if the information in c:\winnt\sysvol is complete
and uncorrupted? Would it be possible (advisable?) to manually
transfer the data from server A to server B? Would that jump-start the
process?

I can't demote either AD server without forcing dcpromo.exe. Even if I
demoted and each server, I wouldn't be able to re-promote them, since
AD can't be found at all. There's always the complete-restore, but I'd
rather not open that can of worms until I have to. That means extended
downtime, and that's something I'd rather not have to deal with. That,
and an ugly hurricane bearing down on our fair city. :)

CG
 
In
CG said:
"Ace Fekay [MVP]"


Thankfully, I'm not having a problem authenticating windows client
users. Authenticating web users is the primary function for this AD
domain, which is still working. We have no group policies on this
domain, so that's not a problem either. Being such a novice, you may
have to spell things out for me just to get me started. I checked
those two articles. Here's what eventid.net said:


Where does one set the location for "Frs-Staging" ... Mine just
magically appeared. :) It looks like permissions are set properly,
though.

I dug through AD Users and Computers (displayed as containers) and
could find nothing that looked like an NTFRS Subscription. Could you
describe what am I looking for precisely?

Here are the NtFRS errors that I'm seeing:

NtFrs:13539
NtFrs:13555
NtFrs:13552
NtFrs:13516
NtFrs:13530
NtFrs:13553
NtFrs:13565
NtFrs:13508
NtFrs:13562

Also, I don't see SYSVOL$ when I run "net share" on either server in
the AD pair. Is it possible (advisable?) to set up a proper SYSVOL$
share manually?

Can I check to see if the information in c:\winnt\sysvol is complete
and uncorrupted? Would it be possible (advisable?) to manually
transfer the data from server A to server B? Would that jump-start the
process?

I can't demote either AD server without forcing dcpromo.exe. Even if I
demoted and each server, I wouldn't be able to re-promote them, since
AD can't be found at all. There's always the complete-restore, but I'd
rather not open that can of worms until I have to. That means extended
downtime, and that's something I'd rather not have to deal with. That,
and an ugly hurricane bearing down on our fair city. :)

CG
Click to expand...

To view the NTFRS subscriptions in ADUC, you need to goto View, and set it
to Advanced View.

Was Tim's post helpful? If the FRS staging area appeared, that's a good
sign, so are Event id 13553 and 13565.

CG, did you check out eventid.net for those other event log #s? Here's one
that caught my eye for 13552:
http://www.eventid.net/display.asp?eventid=13552&eventno=571&source=NtFrs&phase=1



Ace
 
Ace Fekay said:
To view the NTFRS subscriptions in ADUC, you need to goto View, and set it
to Advanced View.

Was Tim's post helpful? If the FRS staging area appeared, that's a good
sign, so are Event id 13553 and 13565.

CG, did you check out eventid.net for those other event log #s? Here's one
that caught my eye for 13552:
http://www.eventid.net/display.asp?eventid=13552&eventno=571&source=NtFrs&phase=1



Ace
Click to expand...


Advanced View. <smacks forehead>. Found it, removed the broken DFS
roots. (Why were they left there? Bug? You'd think that by removing
them in DFS Control panel that it would do a complete removal.)

Next: Changed that registry key to get GC advertised as ready. Sure
enough, after replacing the files from
NtFrs_PreExisting___See_EventLog, the SYSVOL share was advertised. I
made the same change on its AD partner. I had to do some domain role
changing to make the less-sick server pull the weight of the domain
until all the files were replicated and everything stabilized.

I created a new DFS root, and file replication is as it should be.

Hindsight says: to avoid this problem, I should have found and removed
the broken DFS entries in AD Users and Computers. I should not have
removed my ntfrs/jet directory.

Question about the change I made to the registry
(\HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Netlogon\Parameters\Sysvolready)

Is that a flag field that will get turned on and off by the state of
AD?
So that means that I shouldn't have to change it back now that things
are normal, right?

Thanks for all of your assistance!
 
In
CG said:
"Ace Fekay [MVP]"



Advanced View. <smacks forehead>. Found it, removed the broken DFS
roots. (Why were they left there? Bug? You'd think that by removing
them in DFS Control panel that it would do a complete removal.)

Next: Changed that registry key to get GC advertised as ready. Sure
enough, after replacing the files from
NtFrs_PreExisting___See_EventLog, the SYSVOL share was advertised. I
made the same change on its AD partner. I had to do some domain role
changing to make the less-sick server pull the weight of the domain
until all the files were replicated and everything stabilized.

I created a new DFS root, and file replication is as it should be.

Hindsight says: to avoid this problem, I should have found and removed
the broken DFS entries in AD Users and Computers. I should not have
removed my ntfrs/jet directory.

Question about the change I made to the registry
(\HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Netlogon\Parameters\Sysvolready)

Is that a flag field that will get turned on and off by the state of
AD?
So that means that I shouldn't have to change it back now that things
are normal, right?

Thanks for all of your assistance!
Click to expand...

Yep, just leave the reg entry alone for now.

And don't hit yourself too hard in the head!
Cheers!

:-)

Ace
 
Back
Top