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

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.


"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uAY1FT25GHA.756@xxxxxxxxxxxxxxxxxxxxxxx
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;%5bLN%5d;816587

"MyndPhlyp" <nobody@xxxxxxxxxxxxx> wrote in message
news:4OqUg.9405$UG4.4846@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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>



"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23ucs4aq5GHA.1188@xxxxxxxxxxxxxxxxxxxxxxx
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.

"MyndPhlyp" <nobody@xxxxxxxxxxxxx> wrote in message
news:%23ikDt8p5GHA.4644@xxxxxxxxxxxxxxxxxxxxxxx
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?










.

Relevant Pages

  • Re: Event ID 5719: No Windows NT or Windows 2000 Domain Controller is available for domain .
    ... In my experience what you have done with security policy should ... The workstation gets its networking information from DHCP that, ... updates DNS. ... I don't believe the problem to be at the server end though. ...
    (microsoft.public.win2000.security)
  • RE: block internet at two workstations
    ... If you have 10 workstation on the LAN you don't need DNS locally. ... Ok how do you expect to do name resolution on the LAN with DNS removed? ... > prospectus based upon the core principle concepts of security. ... ALL INCLUSIVE curriculum utilizes lectures, ...
    (Security-Basics)
  • RE: 2 users 1 workstation
    ... XP workstation to the SBS2003 domain, after you click Finish, you receive ... this issue can occur if the DNS forward lookup zone ... In the Domain Controller Security policy on the server, ...
    (microsoft.public.windows.server.sbs)
  • Re: slow logging into AD
    ... Make sure DNS are correct defined at the particular workstation. ... point to the Domain Controller running an AD integrated dns zone. ... and when I now log into the domain from my win server ...
    (microsoft.public.windows.server.active_directory)
  • Re: slow logging into AD
    ... Much thanks, that did it, although I had to put the IP address of my gateway ... > Make sure DNS are correct defined at the particular workstation. ... > point to the Domain Controller running an AD integrated dns zone. ...
    (microsoft.public.windows.server.active_directory)