WLAN Success During Back-to-School Deluge

I oversee a large wireless network at Syracuse University, and the start of the fall semester is one of our busiest times. This year my colleagues and I onboarded about 10,000 wireless devices in just a few days, with only a few hiccups. We created a recipe for success out of preparation, a great team and some useful tools, but we also hit a couple of snags.

The campus network consists of almost 4,000 access points. We’re a mostly Cisco wireless environment, with a dash of Meraki thrown in at a few remote locations. At the start of the semester, the majority of the wireless activity happens in the areas where students are moving into campus.

We have 13 dorms, 125 apartments, and somewhere shy of 8,000 beds. We run a number of secure WLANs, a guest SSID and a “helper” WLAN. The helper WLAN dead-ends into CloudPath’s XpressConnect tool for configuring devices and transitioning them to our general-purpose secure network.

Students (and their parents) have differing levels of savvy and patience with accessing a business-grade secure network as they move in, so our network team spends a few frantic days bringing it all together.

I attribute the relative ease of the process to two factors. First, we placed tech support teams in the lobbies of the student residences. We also set up multiple temporary help desks for students who needed assistance. (We typically have one central held desk.)

Second, we tried to steer everyone through the XpressConnect tool for proper supplicant configuration This puts all client devices that use it into a known, good configuration state and offers a common support model.

[802.11ac is an opportunity for WLAN vendors to dislodge competitors. If you’re thinking of brining in new blood, check out “802.11ac: Time To Change Vendors?.”]

On the problem front, we discovered a Windows 8 issue where XpressConnect would seemingly configure the device, but couldn’t get it onto the secure WLAN. A WLAN driver update or WLAN and chipset driver refresh usually did the trick, but it required more work than either the student or the support team would have preferred.

We also discovered a Java-related obstacle on a small percentage of MacBook’s that required manual configuration of supplicant settings. One of our Apple-savvy staffers solved this problem with some command line wizardry.

The team also had to be patient when addressing student complaints about our “slow” WLAN, even though it’s a well-designed 11n environment. The culprit here was that a number of students were using the rate-limited, Bluesocket-based guest WLAN rather than our full-speed secure network.

We do flood incoming students with how-to literature for campus technology services to avoid this kind of problem, but we realize this is also a period of information-overload for most students, so it’s not an appropriate time to tell them to RTFM.

One change I made this year was to add language to the guest portal to direct students from the rate-limited guest network to the fast, secure WLAN.

We Know BYOD

If you work in higher education you’ve been in a BYOD environment long before the term became trendy. Any and every device type, OS, version and health posture rolls into dorms and student apartments, including smartphones, laptops, video game consoles and printers.

Given this plethora of devices, we sometimes ran into problems. As with many schools, we don’t have a great WLAN answer for hundreds of personally owned, low-end wireless printers, so we provided students with USB cables and guidance on proper non-wireless use.

AppleTV and its ilk posed similar challenges. Apple ignores problems with its Bonjour protocol, and while Cisco (to its credit) tries to provide capabilities that allow for Apple’s toys to play well on the network, this is another area where, along with gaming consoles, we steered users to our under-used wired dorm networks. Some students bring their own wireless routers, which are prohibited by campus policy because of security and interference concerns. Cisco’s Prime Infrastructure 1.3 is not the best rogue-finding tool (past version of Cisco WNMS have been better), but we were able to slog our way through the system to eliminate a handful of offending devices.

We also take a low-tech approach to keeping forbidden devices off the network in the first place; we added “please don’t” wording on rogues to our XpressConnect utility page to get the message across as users self-configured their devices. We also periodically remind users of allowable dos and don’ts through our IT twitter account. Looking forward, we’re hoping for better experiences for wireless management (a long-running beef with Cisco) and the ability to attach more of the non-computing wireless devices to the WLAN, but at the moment we’re mostly at the mercy of the industry.

All in all, I’m generally pleased with the process. Our WLAN is rapidly growing as measured by infrastructure device counts and the number of gadgets each student uses (easily three-plus on average), yet our reported problems are very low despite wireless being the preferred access method. As any IT pro can relate, users still complain about the network being slow. The fact is, most of our problems are single-client issues, not a network fault. Other conditions also arise that “feel” like systemic wireless problems, such as a misbehaving DNS environment.

At Interop New York in October, I’ll be talking about the many things that can make good wireless seem bad and what you can do about it. You can get more information about that session here. In the meantime, here’s wishing all network admins in K-12 and higher education a good school year.