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?

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%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@homeright.now> wrote in message
news:%23ikDt8p5GHA.4644@TK2MSFTNGP04.phx.gbl...
> 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?
>
>

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@n0-spam-for-me-comcast.net> wrote in message
news:%23ucs4aq5GHA.1188@TK2MSFTNGP05.phx.gbl...
> 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%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@homeright.now> wrote in message
> news:%23ikDt8p5GHA.4644@TK2MSFTNGP04.phx.gbl...
> > 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?
> >
> >
>
>

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@homeright.now> wrote in message
news:4OqUg.9405$UG4.4846@newsread2.news.pas.earthlink.net...
> 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@n0-spam-for-me-comcast.net> wrote in message
> news:%23ucs4aq5GHA.1188@TK2MSFTNGP05.phx.gbl...
>> 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%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@homeright.now> wrote in message
>> news:%23ikDt8p5GHA.4644@TK2MSFTNGP04.phx.gbl...
>> > 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?
>> >
>> >
>>
>>
>
>

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@n0-spam-for-me-comcast.net> wrote in message
news:uAY1FT25GHA.756@TK2MSFTNGP05.phx.gbl...
> 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@homeright.now> wrote in message
> news:4OqUg.9405$UG4.4846@newsread2.news.pas.earthlink.net...
> > 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@n0-spam-for-me-comcast.net> wrote in message
> > news:%23ucs4aq5GHA.1188@TK2MSFTNGP05.phx.gbl...
> >> 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@homeright.now> wrote in message
> >> news:%23ikDt8p5GHA.4644@TK2MSFTNGP04.phx.gbl...
> >> > 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?
> >> >
> >> >
> >>
> >>
> >
> >
>
>