2

In the school I work in we have a large number (500+) of Windows 7 laptops on a Meru Wireless system and Server 2008 R2 Servers. We have an appalingly large failure rate where a student or staff member tries to logon (to the laptop joined to the domain) and is met by "There are currently no logon servers available to service the logon request". I've seen this question and this one and while removing and re-joining to the domain works, it's highly time consuming, irritating, and we (I) have more important things to concentrate on. The only MS KB article I can find is regarding a read-only domain controller (which ours isn't) and I'm at my wits end.

Ultimately, is there a definitve cause and answer to this or am I stuck removing and re-joining the laptops?

3
  • By any chance, do you have a GP to wait for network when logging in to process scripts? If you do, I may have an idea.... Feb 18, 2011 at 1:42
  • @Holocryptic, yes, drive mappings and such.
    – tombull89
    Feb 18, 2011 at 8:41
  • I know this is an old thread, but Tombull did you ever find a solution to this? Our school board is dealing with the same issue.
    – user116506
    Apr 5, 2012 at 0:43

3 Answers 3

3

I'm making some assumptions. Tell me if I'm wrong. I'm assuming these clients are obtaining IP addresses from DHCP and are only receiving, as DHCP options, the addresses of DNS servers running on Active Directory domain controller computers. If they aren't then I'd start by making these assumptions true first.

In my opinion you'd do well to use a sniffer to examine the traffic between the client computer and the domain controller(s) to determine what's actually happening behind the scenes. That should give you an idea of where to begin to focus your efforts.

By the user logon stage of the boot process you should be seeing the client making DNS requests to locate DC's, followed by LDAP and SMB/CIFS requests to determine site membership, apply machine group policy, etc.

In the case of an all wireless network I'd wonder if you're seeing sufficient packet loss as to make DNS unreliable, which will cause the rest of the logon process to fail. If you haven't isolated the wireless network from the equation yet I'd recommend attaching an affected computer to a wired network, booting it up from a powered-off state, allowing it to pull DHCP (and, ideally, watching either in your DHCP server's management interface or a sniffer to see that it actually pulls an IP address), and see if it acts differently. If it does then that's a sign that your wireless network may be the culprit.

It's not magic. Watch the packets on the wire-- they're trying to tell you what's going on.

5
  • correct. The laptops I am having a problem with are on one VLAN (student VLAN) while the other (Staff VLAN) is fine. Starting an affected machine up while connected over ethernet works without any problems. Half term next week so I'll fire up wireshark (correct me if that's the wrong one to use) and see what I can counjure up.
    – tombull89
    Feb 17, 2011 at 16:08
  • I would also try taking a computer that was having a problem and immediately connect it to the wired network. It should grab and a dynamic IP and pull GPO settings when trying to authenticate then. EDIT: response to tombull89- yeah sound like your Meru Network.
    – Chadddada
    Feb 17, 2011 at 16:09
  • @Chadddada: That's exactly what I'm suggesting in paragraph 4. Eliminate the wireless network from consideration. Feb 17, 2011 at 16:13
  • @tombull89: Wireshark will definitely do what you want, as will Microsoft's Network Monitor. Getting a good sniff of this traffic may be difficult since you can't run the sniffer on the client (since it hasn't logged-on yet). You'll be stuck either sniffing at a "choke point" between the client and the DCs or sniffing on every DC. Personally, I'd look for a place where I could capture all the traffic coming from the client (like the place where the AP the client will be using connects to the network) and use switch port mirroring to sniff there. Feb 17, 2011 at 16:15
  • seeing as we've got just the two DC's I think it's a viable option to run Wireshark on them. Many thanks for your suggestions.
    – tombull89
    Feb 17, 2011 at 16:31
1

Just to be clear, are they trying to log into the laptops as a local user or a AD user? Whichever the case have them enter that domain before the username they are trying.

1)Click User Another Account 2)Username: domain\username Password:XXXX

I am guessing they are doing this correctly but just to be sure.

Another thing to check is making sure the adapter has the DC/preferred DNS entered. I have seen it where people can not connect to the network over wireless or make sure that they are on the local network when trying and not connected to some other wireless.

2
  • Edited my question, but yes, it's on the domian. We don't have "use another account" just the username and password boxes (unless another use has gone on "switch user").
    – tombull89
    Feb 17, 2011 at 16:02
  • You can still log on to a local account with the username and password boxes. Type: ".\(local username)" to log on using the username of a local account. Mar 9, 2014 at 17:04
1

I'm going to throw this out there, based on your response to my comment. I have a Win 7 workstation that I was doing some troubleshooting on, dealing with my webfilter. I had set the GP to wait for network access for processing the scripts, instead of having async processing. I noticed after setting this, that when I locked my computer and left it for a while that the network did not stay running, but then reconnected after unlocking.

That said, with you having trouble with wireless access, in my experience with wireless connectivity on laptops, is that the wireless ethernet does not activate and either search for signal or connect until after the login. My guess (and this is only a guess at this point) is that because you have a GP set to wait for network, it is preventing the login because the laptop won't connect until after login, but you can't login because it's waiting for network to process the login. A bit of a vicious circle. You mention that with ethernet it does connect right away.

To test, take a couple laptops that exhibit the problem (it sounds like in your case it's all of them), move them to a new OU and disable GP inheritance. Test the login process then. If it works, re-enable the wait for network GP, reboot, and test again.

You can also see if there's a way to give all profiles that log in to the lapop access to the wireless LAN so it can use it for login. But I'm kinda grasping for straws on this last suggestion.

HTH

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .