Today I was doing some work for a client at a local college. The client has offices on campus, logs into the campus network, and uses the campus network resources, but the client owns all their own computers in their campus office. This can lead to some butting of heads between the client’s IT staff and the campus IT staff, especially when it comes to getting the client’s computers configured to use campus resources.
I understand the campus IT staff doesn’t want to give out settings and configurations for network resources, but whenever you call their help desk, they won’t tell you any information over the phone, and they say someone from their staff will be out to look at it within two business days. It’s very frustrating supporting the client’s machines at this location.
That being said, here’s the specifics on this problem, and what I did to fix it.
Three wireless networks were configured when the campus IT guy setup the new laptops on the college’s domain. Lets call them Guest Network, Staff Network and Remote Network (for access at a totally different campus). All three wireless networks were configured as Preferred Networks in my Windows XP SP2’s Wireless Network Connection properties. The order in which they were defined were:
1) Guest Network
2) Staff Network
3) Remote Network
Guest Network had Open Network Authentication with Data Encyption disabled.
Both Staff Network and Remote Network were setup as WPA Network Authentication with TKIP Data Encryption.
When I logged onto the Windows domain wirelessly, the new laptops were connecting to the Guest Network by default. I went into the Wireless Network Connection properties and reordered my Preferred Networks so that Staff Network was on top, above Guest Network, but I still wasn’t able to associate to the Staff Network, even after a reboot.
I fired up NetStumbler to see what was going on, and the Guest Network was the only network visable. It appeared that the campus staff was subscribing to the security by obscurity principle of keeping the Staff wireless network hidden by not broadcasting its SSID. KB811427 explains that
“When your Microsoft Windows XP Service Pack 1 or Service Pack 2 (SP1 or SP2)-based Wireless Zero Configuration (WZC) client computer is in the proximity of two wireless access points, and one of the access points is broadcasting its Service Set Identifier (SSID) but the other is not, your computer always connects to the access point that is broadcasting its SSID. This occurs regardless of the preference order of the networks that are configured on the Preferred Networks list.
Additionally, when your computer is connected to an access point that is not broadcasting its SSID, and another access point that is broadcasting its SSID is enabled nearby, your computer automatically connects to the access point that is broadcasting its SSID.”
I ended up having to right click on my Wireless NIC – Properties – Wireless Networks Tab. Then I highlighted Staff Network, my preferred network with the non-broadcast SSID, and selected Properties. From the Association tab I had to select “Connect even if this network is not broadcasting“.
After making this change, I disconnected from the Guest Network and was able to associate with the Staff Network despite it’s hidden SSID. Finally, I selected the Connection tab and chose Connect when this network is in range. I rebooted the machines and verified I was able to access resources on the Staff Network.
If these steps don’t fix your connection problems, check out:
KB907405 – You cannot reconnect to a wireless network that uses a hidden SSID after you manually disconnect from that network on a Windows XP Service Pack 2-based computer
KB917021 – Enhances the Windows XP support for Wi-Fi Protected Access 2 (WPA2) options in Wireless Group Policy (WGP), and to help prevent the Windows wireless client from advertising the wireless networks in its preferred networks list.