Error 1311 There are currently no logon servers available to service the logon request
We have 10 laptops running Windows XP Service pack 2 that are configured on a mixed mode windows domain. Those laptops are also used in the field where the auditos take an 8-port switch, go onsite and switch to a peer to peer mode with static IP addresses. All laptops use a local (i.e. non-domain) username and password to log in. That username is Auditor. All laptops also use the same shared folder called "clitemp" that it is confiugured to have Full control for administrators and the user Auditor (who is a local administrator) Below are the scripts used for connection that each laptop has with unique local IP addresses for each laptop of course:
1) Script to connect to the Field network with the 8-port switch or when they are at work on the domain:
@echo off
c:
if exist \winnt\system32 cd \winnt\system32
if not exist \winnt\system32 cd \windows\system32
@echo Setting IP address and Subnet
netsh interface ip set address name = "Local Area Connection" source = static addr = 192.168.1.68 mask = 255.255.255.0
@echo Setting Gateway
netsh interface ip set address name = "Local Area Connection" gateway = 192.168.1.1 gwmetric = 1
@echo Setting Primary and Secondary DNS servers
netsh interface ip set dns name = "Local Area Connection" source = static addr = 192.168.1.2
netsh interface ip add dns name = "Local Area Connection" addr = 205.171.3.65
@echo IP Adress Changed to FIELD and WORK network
pause
exit
2) Script to display computer name. The auditor who is going to act as the server when in the field runs that and it basically gives the name to the people to use to map a drive
' VBScript.
' Display Computer Name
Set WshNetwork = WScript.CreateObject("WScr
WScript.Echo "Computer Name = " & WshNetwork.ComputerName & ""
3) This script asks for the name of the computer that the auditor acting as the server gives and maps the share Clients as drive W: using the credentials of the machine that is acting as the server.
@Echo off
set /p pcname=Please enter name of the PC (eg. JohnD-Laptop) to connect:
Echo Disconnecting any old W: drive if it exists...
net use W: /d /yes
Echo Attempting to connect to W: Drive...
net use W: \\%pcname%\clitemp <password for user auditor> /user:%pcname%\auditor
pause
exit
No firewalls are setup on the laptops, but on occasion we still get the 1311 error message. All laptops log on locally so the domain authentication should not be an issue. All laptops use the same local account to log on locally and the map drive script explicitly connects using the account that is on the PC that is acting as the server so cached credentials should exist, but even if they are not, the fact that the map drive command explicitly provides the credentials, should allow for connection.
The only other thing I noted when this occurs is that the user whose machine can't map the drive, cannot see the server by name. They can ping by IP address, but even if I try to have them enter the IP address to map the drive while also using the credentials, the error 1311 occurs again.
Any suggestions on the matter would be appreciated. I did the research on the error and there should be no authentication issues since the authentication is explicitly given ont he script.
1) Script to connect to the Field network with the 8-port switch or when they are at work on the domain:
@echo off
c:
if exist \winnt\system32 cd \winnt\system32
if not exist \winnt\system32 cd \windows\system32
@echo Setting IP address and Subnet
netsh interface ip set address name = "Local Area Connection" source = static addr = 192.168.1.68 mask = 255.255.255.0
@echo Setting Gateway
netsh interface ip set address name = "Local Area Connection" gateway = 192.168.1.1 gwmetric = 1
@echo Setting Primary and Secondary DNS servers
netsh interface ip set dns name = "Local Area Connection" source = static addr = 192.168.1.2
netsh interface ip add dns name = "Local Area Connection" addr = 205.171.3.65
@echo IP Adress Changed to FIELD and WORK network
pause
exit
2) Script to display computer name. The auditor who is going to act as the server when in the field runs that and it basically gives the name to the people to use to map a drive
' VBScript.
' Display Computer Name
Set WshNetwork = WScript.CreateObject("WScr
WScript.Echo "Computer Name = " & WshNetwork.ComputerName & ""
3) This script asks for the name of the computer that the auditor acting as the server gives and maps the share Clients as drive W: using the credentials of the machine that is acting as the server.
@Echo off
set /p pcname=Please enter name of the PC (eg. JohnD-Laptop) to connect:
Echo Disconnecting any old W: drive if it exists...
net use W: /d /yes
Echo Attempting to connect to W: Drive...
net use W: \\%pcname%\clitemp <password for user auditor> /user:%pcname%\auditor
pause
exit
No firewalls are setup on the laptops, but on occasion we still get the 1311 error message. All laptops log on locally so the domain authentication should not be an issue. All laptops use the same local account to log on locally and the map drive script explicitly connects using the account that is on the PC that is acting as the server so cached credentials should exist, but even if they are not, the fact that the map drive command explicitly provides the credentials, should allow for connection.
The only other thing I noted when this occurs is that the user whose machine can't map the drive, cannot see the server by name. They can ping by IP address, but even if I try to have them enter the IP address to map the drive while also using the credentials, the error 1311 occurs again.
Any suggestions on the matter would be appreciated. I did the research on the error and there should be no authentication issues since the authentication is explicitly given ont he script.
Actually, since they are all logged in with the same name and password, you shouldn't have to even specify the user or password in the script.
ASKER
Kenneniah, understand that. but we tried the regular net use with no credentials and also with the /user: switch that did not contain computer name. As I stated, we also tried using the ip address as well to map with no effect.
Yeah, strange things happen when Windows can't find a "server" through DNS or NetBIOS, especially authentication issues. Therefore the question becomes why can't they see each other using NetBIOS name. When this is ocurring what happens if you run "nbtstat -A ipaddress" ?
ASKER
For that, I'll have to wait when it happens again when they are in the field.
Is it just the laptops connected to the switch, as I see you are setting a gateway and DNS servers, Is the 192.168.1.2 an actual DNS server?
ASKER
Kenneniah,
It is, but not when in the field. It is the domain controller when they are at the office. Basically they use the same ip scheme when either in the field or in the office.
It is, but not when in the field. It is the domain controller when they are at the office. Basically they use the same ip scheme when either in the field or in the office.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Kenneniah,
It is to switch between DHCP and static. Even when they are in the fileld they can exit their own little field network, connect to the client's network and use the internet. They can then switch back.
I believe however that the fact that the DNS is set as the domain controller may cause some issues with authentication. As such I will accept all your suggestions as solution to the issue.
If all goes well, in a few months they will have Terminal services access through VPN and all this excessive scripting stuff will be a non issue.
It is to switch between DHCP and static. Even when they are in the fileld they can exit their own little field network, connect to the client's network and use the internet. They can then switch back.
I believe however that the fact that the DNS is set as the domain controller may cause some issues with authentication. As such I will accept all your suggestions as solution to the issue.
If all goes well, in a few months they will have Terminal services access through VPN and all this excessive scripting stuff will be a non issue.
ASKER
I am fairly certain that your suggestions will resolve the issue or at least will explain the inconsistencies. I thank you for your response.
Since the username and password is the same on all computers, you don't need the %pcname%\ in /user:%pcname%\auditor
Due to that %pcname%, if Windows is unable to locate that computer by netbios name it won't be able to authenticate.