There are no logon servers available to service the logon request

  • Thread starter Thread starter Mark
  • Start date Start date
M

Mark

Right

I have a work laptop that connects to a domain.

When I am at home and connect to the domain over the VPN I can access the
fileshare on my laptop.

When I bring the laptop home and connect to my home network I cannot access
the fileshare - I get the error message above.
I can see the machine in the Network Neighbourhood - I just cannot see any
of the fileshares or connect to them in anyway.
(This happens regardless of whether I shutdown the laptop at work or I leave
it running when I bring it home).

The strangest thing is this used to work (ie. I could do the above and see
the fileshare and access it no problems at all). Now it does not.

What do I need to investigate to fix this.

Many thanks for any help in advance.
 
You may try this command when you are home network: net use \\computername
/user:username Or this search result may give more details. Please post back
with the result.

workgroup networking faqs
There are currently no logon servers available to service the logon
request - \\Computername is not accessible ...
www.howtonetworking.com/workgroupnet.htm

--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
 
Unfortunitely I get this error message :
"System error 1311 has occurred.

There are currently no logon servers available to service the logon
request."
 
Unfortunitely I get this error message :
"System error 1311 has occurred.

There are currently no logon servers available to service the logon
request."
Click to expand...

There are two possible cause:

1) VPN does not normally send / resolve the computer's name, VPN
normally sends only traffic via the IP addresses.

2) Anti-virus softwares that block the NetBIOS name resolution
protocol. Several anti-virus (especially Norton) blocks the NetBIOS
name resolution as part of the Internet worm blocking module.

Locate the PC's IP address and then try to access this via the IP
address (\\192.168.1.1) instead of the name (\\Computer.)
 
I dont believe this is the problem...

I can connect from the Home PC to the Work Laptop File Share when the Home
PC is connected to the Work Network via VPN (the Laptop is still at work
connected to the Work Network - an NT Domain)

I cannot connect to the Work Laptop File Share from the Home PC when the
Laptop is at home and only connected to the Home Network (although it is
still logged into the Domain using cached credentials)

Note when the Work Laptop is at Home connected to the Home Network I can
still Remote Desktop to it and I can still see it in the Network
Neighbourhood.

Note that there is a user on the Work Laptop with the same User ID and
Password as exists on my Home PC. Every User is an Administrator.
 
Mark,

I've been working on this problem for several months now. I first saw it in
June and have had absolutely no luck with responses on the forum. What
Service Pack are you running?

-Harrier
 
Service Pack 3 - Fully Up to Date...



harrier said:
Mark,

I've been working on this problem for several months now. I first saw it in
June and have had absolutely no luck with responses on the forum. What
Service Pack are you running?

-Harrier
Click to expand...
 
SP3 is the problem. I rolled back two laptops to SP2 today and the problem
"mysteriously" went away. The other SP3 laptop I completely rebuilt the
networking stack and was able to get the issues to go away up until I added
the laptop back to the domain. Once the domain membership was established
the issues resurfaced. As long as the domain controller is online there is
no issue with SP3. If the domain controller is not online you see the
issues. I don't know if this is a change in behavior with SP3 or an SP3
defect. Hopefully an MS engineer investigates and responds accordingly.

-harrier
 
I feared as much...

No doubt this is a microsoft security improvement...

I would have hoped they would be able to tell us what registry settings need
changing to allow for this scenario - assuming it can be done via registry
settings and isnt some code change thats reduced completely normal and
required functionality (you should see the number of posts with this problem
- not only here but across the web).

Just another example of microsoft assuming something and completely arsing
it up...
 
I am experiencing the exact same issue on a batch script utilizing the
following net use DOS command structure:

FOR /F "tokens=1* delims=," %%G IN (web_server_list.txt) DO (
ECHO OFF
NET USE * /d /yes
ECHO ON
NET USE M: "\\%%G\%web_drv_shr_nm%" %passwd% /USER:%usrnm%@%web_domain_nm%
)

During the iteration through the servers listed in the web_server_list.txt,
I receive the 'System error 1311 has occurred' error for the first attempted
server in the listing, but have no issues AFTER the 1st attempt.

Can someone at Microsoft explain why this occurs and how this is consistent
with any RFC that speaks to authentication to mapped drives using domain
servers. It appears that during the 1st attempt by Microsoft code underlying
NET USE they are "assuming" cached credentials to a domain that is "primary"
to a laptop or PC is a faulty assumption and would not necessarily be
recommended in any RFC on this subject.

If I plan to use a second domain server to service the NET USE request, why
doesn't the NET USE sequence of supporting methods that Microsoft has
programmed into their OS directly follow the instructions to authenticate
with the provided (secondary) domain and not assume I'm requesting to utilize
local cached credentials to the primary server I first logged in with?
 
Back
Top