|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Event ID 5719: No Windows NT or Windows 2000 Domain Controller is available for domain <domain>.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. Show quoteHide quote "MyndPhlyp" <nob***@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> Show quoteHide quote "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message Http://www.eventid.netnews:%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. > is a great place to lookup information on events IDs as users share their http://www.eventid.net/display.asp?eventid=10010&eventno=508&source=DCOM&phase=1> 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 > Show quoteHide quote > --- 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" <nob***@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 Show quoteHide quote "MyndPhlyp" <nob***@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" <nob***@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. Show quoteHide quote "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message tp://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382 --- 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" <nob***@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 > >> > >> > > AD http://www.eventid.net/display.asp?eventid=10010&eventno=508&source=DCOM&phase=1> >> DNS FAQ > >> > > Show quoteHide quote > >> --- 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" <nob***@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? > >> > > >> > > >> > >> > > > > > > 
Other interesting topics
Password Protecting/Hiding Files & Folders on Windows 2003 server???
security update repeats "indefinitely" controlling what computers a user can log on to User Config / Windows Settings / Scripts Not Shown in GPOE Novell/Active Directory Built-in Administrator acct. for Domain be password never expires? 5 Ways to Speed Up Your Computer's Performance windows security log doesn't have any entry W2K ESENT Event ID 454, error -515 every 5 minutes Best Practice: Patches that are not critical or security related |
|||||||||||||||||||||||
