Faced with deploying up to 1,000 wireless access points across 160 buildings on two separate campuses, McGill University network chief Gary Bernstein immediately recognized the management challenge:

"With a thousand access points, you can't use sneaker power to manage [them]," says Bernstein, whose Montreal educational institution is among the trailblazers rolling out large-scale wireless LANs (WLAN) (see part 1 of our series).

Many of these pioneers by necessity have built their own management tools and figured out management techniques by trial and error. However, today they can take advantage of a growing number of third-party management products. They also are starting to evaluate a new approach to large-scale WLAN deployment: the so-called wireless switch, the first of which are starting to ship.

But none of these tools can or will replace the need to first think big about WLAN management. Experts say to control a big WLAN and minimize operational problems, you have to think through the issues from top to bottom.

Enterprise WLANs are almost invisible to a traditional network management system, even as they add hundreds or thousands of end devices that need to be managed. As Bernstein notes, hiring a platoon of support technicians to hike around a sprawling deployment and fiddle with access points is not practical.

Nearly all of the biggest WLAN sites are using a blend of homegrown tools and third-party applications.

Many WLAN hardware vendors create SNMP management information bases (MIB) on their access points. MIBs are chunks of code that use SNMP to pass data about the device's behavior and health to network management applications, where the data can be analyzed. MIBs written by vendors can pass back sketchy information about highly detailed data. And getting to the data, getting it out and getting it stored is a pain.

"Today, I have to go out and poll 560 access points," says Brad Noblet, director of technical services at Dartmouth College in Hanover, N.H. "That's time-consuming and bandwidth-consuming."

Cisco's internal IT group, overseeing about 3,000 access points in the company's global wireless network, has used some Cisco management tools, but they rely mainly on a set of applications they wrote themselves.

"I will use those tools if they offer me something [I need]," says David Castaneda, member of the technical staff with Cisco's Infrastructure IT group. "If they don't, I will build what I need."

What they built was their own wireless network provisioning tools, which typically run at night under the direction of Cisco-written scripts. Triggered by the scripts, the programs update the software on every access point in the network. That update is simplified because Cisco decided that the exact same software load, or image, would run on each device. The payoff is a network that almost seems to run itself, according to Castaneda.

"Our wireless LAN is very non-labor intensive," he says. "We wanted an 'install-and-forget' scenario, and that is what we built."

Many routine chores on distributed access points still have to be done one at a time. Network managers have turned to do-it-yourself automation to make this feasible for networks such as the one emerging at McGill. One example is changing the service set identifier (SSID)on each access point. The SSID is attached to wireless packets and acts as a kind of password to join a specific WLAN.

"If you want to change the SSID on all your access points, typically you still have to do this manually," says Pascal Beauregard, project manager for McGill's WLAN.

McGill created a set of Perl scripts that runs nightly to apply changes to the SSID and to collect device data using SNMP.

Designing for simplified management was a key element in Microsoft's installation of a huge WLAN at its Redmond, Wash., campus. From the outset, the company's internal IT group made sure it had remote control of the console port on each of the 2,500 access points deployed there (See Part 1). Then, operations staff built three databases with information on device addresses, radio channel assignments, locations and settings, and a bundle of scripts.

Installing an access point is now so simple it's handled by a building's facilities engineering staff, instead of the IT group. After the device is installed, a network administrator clicks on a script, which pulls out the needed data and configures the device.

"The script brings all this together and configures one access point or a whole subnet of access points with one button-click," says Don Berry, senior network engineer with Microsoft's Operations and Technology Group.

A growing number of third-party applications are taking a similar approach.

St. Vincent's Hospital in Birmingham, Ala., manages 170 access points with Mobile Manager from WaveLink Wireless and Cisco WLAN management utilities. Until recently, such tools typically have focused on remotely managing individual access points.

By contrast, WaveLink lets St. Vincent's corral access points into groups based on criteria such as location, business department or function. Users assigned to a department, such as the outpatient clinics, inherit the access rights of that department. Network managers also can send software upgrades or configuration changes by group, instead of individually.