Event ID 5719: No Windows NT or Windows 2000 Domain Controller is available for domain <domain>.

[MyndPhlyp]

Okay, I successfully shot myself in the foot a few days ago. Managed to lock
myself out of a Win2K Pro workstation by messing around with a Group
Security Policy on the Win2K DC. Panic set it and I eventually fell upon
this KB article:

http://support.microsoft.com/kb/826903

Without thinking [...could probably stop right there...] about stashing a
backup copy of the system32\config\security file I stomped on it with the
repair\security file and went on to attempt cleaning house. I deleted the
newly-created GSP from the DC, removed the workstation from AD, and changed
the workstation to rejoin the domain.

Checking the workstation's Event Log from the DC (fresh workstation boot and
without logging onto the workstation) I get the following error:

Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5719
User: N/A
Computer: MYWIN2KPRO
Description:
No Windows NT or Windows 2000 Domain Controller is available for domain
MYNET. The following error occurred:
There are currently no logon servers available to service the logon request.
Data:
0000: 5e 00 00 c0

Citrix and RAS are not part of the picture. (Yeah, I've run across several
of those KBs.) NetBT buffers is not the problem either. (Yeah, I've hit
several of those, too.)

At shutdown time for the workstation, I get a DCOM error:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10010
User: MYNET\Bonehead
Computer: MYWIN2KPRO
Description:
The server {563B0D4F-3080-4B80-B47A-7CA258999376} did not register with DCOM
within the required timeout.

Searching through the workstation's Registry,
563B0D4F-3080-4B80-B47A-7CA258999376 = AcctMgr.FormHandler CLSID.

I'm pretty much convinced I've successfully hosed the security settings on
the workstation. (Gee, ya think?) Short of nuking the village and starting
over, or considering a career in basket weaving and door-to-door sales, I'd
appreciate some constructive assistance in correcting this.

[Bonus follow-up question, with double the trivia points, regarding Event ID
565 appearing in the DC's logs for whoever successfully solves today's
trivia question.]

Help? Please? Anybody?

 

[Steven L Umbach]

To start with you way over complicated things. Apparently you messed with
the logon locally or deny logon locally user rights in a domain level Group
Policy. All you had to do, assuming you can logon to a domain controller, is
to modify those user rights in the same GPO and then reboot the domain
computer and you should have been able to logon. My bet is that you added a
group to deny logon locally such as users.

From where you are at now the first thing I would do is to make sure that
the computer is configured correctly as far as DNS in that it points only to
domain controllers as it's preferred and secondary DNS servers in tcp/ip
properties and NEVER list an ISP DNS server for ANY domain computer. The
link below explains more on AD DNS. Verify that your DNS is correctly
configured and then see what happens. You can also run the support tool
netdiag on any domain computer to check the health of many domain related
issues such as DNS, dc discovery, and secure channel. Http://www.eventid.net
is a great place to lookup information on events IDs as users share their
experiences as to what they found to be the problem and solution.

Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --- AD
DNS FAQ
http://www.eventid.net/display.asp?eventid=10010&eventno=508&source=DCOM&phase=1
--- Eventid.net on Event 10010
http://support.microsoft.com/default.aspx?scid=kb;EN-US;313222 --- last
resort use of secedit command to reset local security settings to default
defined levels and note use of the /areas switch. Do NOT attempt this on a
Windows 2003 Server as it will screw up services settings severely.

Okay, I successfully shot myself in the foot a few days ago. Managed to
lock
myself out of a Win2K Pro workstation by messing around with a Group
Security Policy on the Win2K DC. Panic set it and I eventually fell upon
this KB article:

http://support.microsoft.com/kb/826903

Without thinking [...could probably stop right there...] about stashing a
backup copy of the system32\config\security file I stomped on it with the
repair\security file and went on to attempt cleaning house. I deleted the
newly-created GSP from the DC, removed the workstation from AD, and
changed
the workstation to rejoin the domain.

Checking the workstation's Event Log from the DC (fresh workstation boot
and
without logging onto the workstation) I get the following error:

Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5719
User: N/A
Computer: MYWIN2KPRO
Description:
No Windows NT or Windows 2000 Domain Controller is available for domain
MYNET. The following error occurred:
There are currently no logon servers available to service the logon
request.
Data:
0000: 5e 00 00 c0

Citrix and RAS are not part of the picture. (Yeah, I've run across several
of those KBs.) NetBT buffers is not the problem either. (Yeah, I've hit
several of those, too.)

At shutdown time for the workstation, I get a DCOM error:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10010
User: MYNET\Bonehead
Computer: MYWIN2KPRO
Description:
The server {563B0D4F-3080-4B80-B47A-7CA258999376} did not register with
DCOM
within the required timeout.

Searching through the workstation's Registry,
563B0D4F-3080-4B80-B47A-7CA258999376 = AcctMgr.FormHandler CLSID.

I'm pretty much convinced I've successfully hosed the security settings on
the workstation. (Gee, ya think?) Short of nuking the village and starting
over, or considering a career in basket weaving and door-to-door sales,
I'd
appreciate some constructive assistance in correcting this.

[Bonus follow-up question, with double the trivia points, regarding Event
ID
565 appearing in the DC's logs for whoever successfully solves today's
trivia question.]

Help? Please? Anybody?

 

[MyndPhlyp]

Thanks for the input.

1) Life lesson learned too late. Panic was the order of the day. 20/20
hindsight is an asset realized a tad bit too late.

2) The workstation gets its networking information from DHCP that, in turn,
updates DNS. Reserved IP address. Yes, the DNS has Enable Forwarders and the
ISP's servers are listed. The only DNS known to the workstation is the local
one. The ISP's DNS has not been experiencing problems... at least over the
last few weeks. <g> The DNS and DHCP have been stable and reliable since...
er... forever with no changes over the years.

NETDIAG and DCDIAG show nothing out of line. Everything passes on both
tests.

I don't believe the problem to be at the server end though. The security
policy was the only thing (other than loosening a few selective DCOM
security settings) I messed with and that policy has since been removed.
(Should have done that before jumping on the workstation's security file.)

Thinking out loud, comparing the time stamp on the NETLOGON entry in the
System log with those in the Application log, it appears the event is
happening very close to the same moment Norton Internet Security's SNDSRVC
is firing up: they both appear in the same minute. (NIS fires up without a
problem, FWIW, and hasn't been the source of any problems for ages.) It
could be coincidence. I'll have to check the logs a few times to see if the
time stamps remain consistent.

I'm familiar with the AD DNS link. Went that route many years ago. IIRC, it
cleared up problems I was experiencing back then.

The eventid.net URL did not yield any new clues. An interesting read though.
(Noted again all the references to Citrix, Terminal Server, etc.) Seems
several have chosen to ignore or disable the DCOM message. I cannot take
that action; I believe this to be a symptom of why I cannot get access to
the server half of a client/server application that relies upon DCOM.
Google'ing for "563B0D4F-3080-4B80-B47A-7CA258999376" and other related
phrases/keywords yielded nothing useful so far.

I'll have to think a while before I venture into SECEDIT. I suspect stomping
on system32\config\security took out some entry modification(s) made along
the line either by software installs (e.g., NIS mentioned above). I've never
made any manual changes... at least that I can recall. Considering that I've
already shot my left foot, placing a bullet in the right foot might make the
limp less noticeable. <g>

To start with you way over complicated things. Apparently you messed with
the logon locally or deny logon locally user rights in a domain level Group
Policy. All you had to do, assuming you can logon to a domain controller, is
to modify those user rights in the same GPO and then reboot the domain
computer and you should have been able to logon. My bet is that you added a
group to deny logon locally such as users.

From where you are at now the first thing I would do is to make sure that
the computer is configured correctly as far as DNS in that it points only to
domain controllers as it's preferred and secondary DNS servers in tcp/ip
properties and NEVER list an ISP DNS server for ANY domain computer. The
link below explains more on AD DNS. Verify that your DNS is correctly
configured and then see what happens. You can also run the support tool
netdiag on any domain computer to check the health of many domain related
issues such as DNS, dc discovery, and secure channel. Http://www.eventid.net
is a great place to lookup information on events IDs as users share their
experiences as to what they found to be the problem and solution.

Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --- AD
DNS FAQ
http://www.eventid.net/display.asp?eventid=10010&eventno=508&source=DCOM&phase=1
--- Eventid.net on Event 10010
http://support.microsoft.com/default.aspx?scid=kb;EN-US;313222 --- last
resort use of secedit command to reset local security settings to default
defined levels and note use of the /areas switch. Do NOT attempt this on a
Windows 2003 Server as it will screw up services settings severely.

Okay, I successfully shot myself in the foot a few days ago. Managed to
lock
myself out of a Win2K Pro workstation by messing around with a Group
Security Policy on the Win2K DC. Panic set it and I eventually fell upon
this KB article:

http://support.microsoft.com/kb/826903

Without thinking [...could probably stop right there...] about stashing a
backup copy of the system32\config\security file I stomped on it with the
repair\security file and went on to attempt cleaning house. I deleted the
newly-created GSP from the DC, removed the workstation from AD, and
changed
the workstation to rejoin the domain.

Checking the workstation's Event Log from the DC (fresh workstation boot
and
without logging onto the workstation) I get the following error:

Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5719
User: N/A
Computer: MYWIN2KPRO
Description:
No Windows NT or Windows 2000 Domain Controller is available for domain
MYNET. The following error occurred:
There are currently no logon servers available to service the logon
request.
Data:
0000: 5e 00 00 c0

Citrix and RAS are not part of the picture. (Yeah, I've run across several
of those KBs.) NetBT buffers is not the problem either. (Yeah, I've hit
several of those, too.)

At shutdown time for the workstation, I get a DCOM error:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10010
User: MYNET\Bonehead
Computer: MYWIN2KPRO
Description:
The server {563B0D4F-3080-4B80-B47A-7CA258999376} did not register with
DCOM
within the required timeout.

Searching through the workstation's Registry,
563B0D4F-3080-4B80-B47A-7CA258999376 = AcctMgr.FormHandler CLSID.

I'm pretty much convinced I've successfully hosed the security settings on
the workstation. (Gee, ya think?) Short of nuking the village and starting
over, or considering a career in basket weaving and door-to-door sales,
I'd
appreciate some constructive assistance in correcting this.

[Bonus follow-up question, with double the trivia points, regarding Event
ID
565 appearing in the DC's logs for whoever successfully solves today's
trivia question.]

Help? Please? Anybody?

 

[Steven L Umbach]

If you have not done so I would run netdiag also on that Windows 2000
computer. In my experience what you have done with security policy should
not interfere with that computer being able to find a domain controller. The
other thing I would try is to verify that you can ping the domain controller
by FQDN and IP, try accessing the sysvol share from the client as in
\\dcname.domain\sysvol , and use nslookup as described in the KB article
below to verify that the domain controller _srv records can be resolved by
the workstation. If all that works it would be surprising that you still are
having errors indicating that a domain controller can not be located.

Steve

http://support.microsoft.com/default.aspx?scid=kb;[LN];816587

Thanks for the input.

1) Life lesson learned too late. Panic was the order of the day. 20/20
hindsight is an asset realized a tad bit too late.

2) The workstation gets its networking information from DHCP that, in
turn,
updates DNS. Reserved IP address. Yes, the DNS has Enable Forwarders and
the
ISP's servers are listed. The only DNS known to the workstation is the
local
one. The ISP's DNS has not been experiencing problems... at least over the
last few weeks. <g> The DNS and DHCP have been stable and reliable
since...
er... forever with no changes over the years.

NETDIAG and DCDIAG show nothing out of line. Everything passes on both
tests.

I don't believe the problem to be at the server end though. The security
policy was the only thing (other than loosening a few selective DCOM
security settings) I messed with and that policy has since been removed.
(Should have done that before jumping on the workstation's security file.)

Thinking out loud, comparing the time stamp on the NETLOGON entry in the
System log with those in the Application log, it appears the event is
happening very close to the same moment Norton Internet Security's SNDSRVC
is firing up: they both appear in the same minute. (NIS fires up without a
problem, FWIW, and hasn't been the source of any problems for ages.) It
could be coincidence. I'll have to check the logs a few times to see if
the
time stamps remain consistent.

I'm familiar with the AD DNS link. Went that route many years ago. IIRC,
it
cleared up problems I was experiencing back then.

The eventid.net URL did not yield any new clues. An interesting read
though.
(Noted again all the references to Citrix, Terminal Server, etc.) Seems
several have chosen to ignore or disable the DCOM message. I cannot take
that action; I believe this to be a symptom of why I cannot get access to
the server half of a client/server application that relies upon DCOM.
Google'ing for "563B0D4F-3080-4B80-B47A-7CA258999376" and other related
phrases/keywords yielded nothing useful so far.

I'll have to think a while before I venture into SECEDIT. I suspect
stomping
on system32\config\security took out some entry modification(s) made along
the line either by software installs (e.g., NIS mentioned above). I've
never
made any manual changes... at least that I can recall. Considering that
I've
already shot my left foot, placing a bullet in the right foot might make
the
limp less noticeable. <g>

To start with you way over complicated things. Apparently you messed with
the logon locally or deny logon locally user rights in a domain level Group
Policy. All you had to do, assuming you can logon to a domain controller, is
to modify those user rights in the same GPO and then reboot the domain
computer and you should have been able to logon. My bet is that you added a
group to deny logon locally such as users.

From where you are at now the first thing I would do is to make sure that
the computer is configured correctly as far as DNS in that it points only to
domain controllers as it's preferred and secondary DNS servers in tcp/ip
properties and NEVER list an ISP DNS server for ANY domain computer. The
link below explains more on AD DNS. Verify that your DNS is correctly
configured and then see what happens. You can also run the support tool
netdiag on any domain computer to check the health of many domain related
issues such as DNS, dc discovery, and secure channel. Http://www.eventid.net
is a great place to lookup information on events IDs as users share their
experiences as to what they found to be the problem and solution.

Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --- AD
DNS FAQ
http://www.eventid.net/display.asp?eventid=10010&eventno=508&source=DCOM&phase=1
--- Eventid.net on Event 10010
http://support.microsoft.com/default.aspx?scid=kb;EN-US;313222 --- last
resort use of secedit command to reset local security settings to default
defined levels and note use of the /areas switch. Do NOT attempt this on
a
Windows 2003 Server as it will screw up services settings severely.

Okay, I successfully shot myself in the foot a few days ago. Managed to
lock
myself out of a Win2K Pro workstation by messing around with a Group
Security Policy on the Win2K DC. Panic set it and I eventually fell
upon
this KB article:

http://support.microsoft.com/kb/826903

Without thinking [...could probably stop right there...] about stashing a
backup copy of the system32\config\security file I stomped on it with the
repair\security file and went on to attempt cleaning house. I deleted the
newly-created GSP from the DC, removed the workstation from AD, and
changed
the workstation to rejoin the domain.

Checking the workstation's Event Log from the DC (fresh workstation
boot
and
without logging onto the workstation) I get the following error:

Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5719
User: N/A
Computer: MYWIN2KPRO
Description:
No Windows NT or Windows 2000 Domain Controller is available for domain
MYNET. The following error occurred:
There are currently no logon servers available to service the logon
request.
Data:
0000: 5e 00 00 c0

Citrix and RAS are not part of the picture. (Yeah, I've run across several
of those KBs.) NetBT buffers is not the problem either. (Yeah, I've hit
several of those, too.)

At shutdown time for the workstation, I get a DCOM error:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10010
User: MYNET\Bonehead
Computer: MYWIN2KPRO
Description:
The server {563B0D4F-3080-4B80-B47A-7CA258999376} did not register with
DCOM
within the required timeout.

Searching through the workstation's Registry,
563B0D4F-3080-4B80-B47A-7CA258999376 = AcctMgr.FormHandler CLSID.

I'm pretty much convinced I've successfully hosed the security settings on
the workstation. (Gee, ya think?) Short of nuking the village and starting
over, or considering a career in basket weaving and door-to-door sales,
I'd
appreciate some constructive assistance in correcting this.

[Bonus follow-up question, with double the trivia points, regarding Event
ID
565 appearing in the DC's logs for whoever successfully solves today's
trivia question.]

Help? Please? Anybody?

 

[MyndPhlyp]

From the Win2K workstation, I can ping the DC by FQDN and IP, I can access
SYSVOL via \\DC.DOMAIN\SYSVOL and \\DC\SYSVOL and \\DOMAIN\SYSVOL, and
manual inspection of the DNS _srv records plus NSLOOKUP from the workstation
all show life is good.

If you have not done so I would run netdiag also on that Windows 2000
computer. In my experience what you have done with security policy should
not interfere with that computer being able to find a domain controller. The
other thing I would try is to verify that you can ping the domain controller
by FQDN and IP, try accessing the sysvol share from the client as in
\\dcname.domain\sysvol , and use nslookup as described in the KB article
below to verify that the domain controller _srv records can be resolved by
the workstation. If all that works it would be surprising that you still are
having errors indicating that a domain controller can not be located.

Steve

http://support.microsoft.com/default.aspx?scid=kb;[LN];816587

Thanks for the input.

1) Life lesson learned too late. Panic was the order of the day. 20/20
hindsight is an asset realized a tad bit too late.

2) The workstation gets its networking information from DHCP that, in
turn,
updates DNS. Reserved IP address. Yes, the DNS has Enable Forwarders and
the
ISP's servers are listed. The only DNS known to the workstation is the
local
one. The ISP's DNS has not been experiencing problems... at least over the
last few weeks. <g> The DNS and DHCP have been stable and reliable
since...
er... forever with no changes over the years.

NETDIAG and DCDIAG show nothing out of line. Everything passes on both
tests.

I don't believe the problem to be at the server end though. The security
policy was the only thing (other than loosening a few selective DCOM
security settings) I messed with and that policy has since been removed.
(Should have done that before jumping on the workstation's security file.)

Thinking out loud, comparing the time stamp on the NETLOGON entry in the
System log with those in the Application log, it appears the event is
happening very close to the same moment Norton Internet Security's SNDSRVC
is firing up: they both appear in the same minute. (NIS fires up without a
problem, FWIW, and hasn't been the source of any problems for ages.) It
could be coincidence. I'll have to check the logs a few times to see if
the
time stamps remain consistent.

I'm familiar with the AD DNS link. Went that route many years ago. IIRC,
it
cleared up problems I was experiencing back then.

The eventid.net URL did not yield any new clues. An interesting read
though.
(Noted again all the references to Citrix, Terminal Server, etc.) Seems
several have chosen to ignore or disable the DCOM message. I cannot take
that action; I believe this to be a symptom of why I cannot get access to
the server half of a client/server application that relies upon DCOM.
Google'ing for "563B0D4F-3080-4B80-B47A-7CA258999376" and other related
phrases/keywords yielded nothing useful so far.

I'll have to think a while before I venture into SECEDIT. I suspect
stomping
on system32\config\security took out some entry modification(s) made along
the line either by software installs (e.g., NIS mentioned above). I've
never
made any manual changes... at least that I can recall. Considering that
I've
already shot my left foot, placing a bullet in the right foot might make
the
limp less noticeable. <g>

To start with you way over complicated things. Apparently you messed with
the logon locally or deny logon locally user rights in a domain level Group
Policy. All you had to do, assuming you can logon to a domain

controller,
is

to modify those user rights in the same GPO and then reboot the domain
computer and you should have been able to logon. My bet is that you

added
a

group to deny logon locally such as users.

From where you are at now the first thing I would do is to make sure that
the computer is configured correctly as far as DNS in that it points

only
to

domain controllers as it's preferred and secondary DNS servers in tcp/ip
properties and NEVER list an ISP DNS server for ANY domain computer. The
link below explains more on AD DNS. Verify that your DNS is correctly
configured and then see what happens. You can also run the support tool
netdiag on any domain computer to check the health of many domain related
issues such as DNS, dc discovery, and secure channel. Http://www.eventid.net
is a great place to lookup information on events IDs as users share their
experiences as to what they found to be the problem and solution.

Steve

tp://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382 ---
AD

DNS FAQ

http://www.eventid.net/display.asp?eventid=10010&eventno=508&source=DCOM&phase=1

--- Eventid.net on Event 10010
http://support.microsoft.com/default.aspx?scid=kb;EN-US;313222 --- last
resort use of secedit command to reset local security settings to default
defined levels and note use of the /areas switch. Do NOT attempt this on
a
Windows 2003 Server as it will screw up services settings severely.

Okay, I successfully shot myself in the foot a few days ago. Managed to
lock
myself out of a Win2K Pro workstation by messing around with a Group
Security Policy on the Win2K DC. Panic set it and I eventually fell
upon
this KB article:

http://support.microsoft.com/kb/826903

Without thinking [...could probably stop right there...] about

stashing
a

backup copy of the system32\config\security file I stomped on it with the
repair\security file and went on to attempt cleaning house. I deleted the
newly-created GSP from the DC, removed the workstation from AD, and
changed
the workstation to rejoin the domain.

Checking the workstation's Event Log from the DC (fresh workstation
boot
and
without logging onto the workstation) I get the following error:

Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5719
User: N/A
Computer: MYWIN2KPRO
Description:
No Windows NT or Windows 2000 Domain Controller is available for domain
MYNET. The following error occurred:
There are currently no logon servers available to service the logon
request.
Data:
0000: 5e 00 00 c0

Citrix and RAS are not part of the picture. (Yeah, I've run across several
of those KBs.) NetBT buffers is not the problem either. (Yeah, I've hit
several of those, too.)

At shutdown time for the workstation, I get a DCOM error:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10010
User: MYNET\Bonehead
Computer: MYWIN2KPRO
Description:
The server {563B0D4F-3080-4B80-B47A-7CA258999376} did not register with
DCOM
within the required timeout.

Searching through the workstation's Registry,
563B0D4F-3080-4B80-B47A-7CA258999376 = AcctMgr.FormHandler CLSID.

I'm pretty much convinced I've successfully hosed the security

settings
on

the workstation. (Gee, ya think?) Short of nuking the village and starting
over, or considering a career in basket weaving and door-to-door sales,
I'd
appreciate some constructive assistance in correcting this.

[Bonus follow-up question, with double the trivia points, regarding Event
ID
565 appearing in the DC's logs for whoever successfully solves today's
trivia question.]

Help? Please? Anybody?