Slashdot Mirror
Dorm Storm?
The Ape With No Name writes: "I work as a network technician at a major Southern university and we are gearing up for what is lovingly called "Dorm Storm," aka the weekend the students return to their dorm rooms, ethernet connections and BearShare. We'll move in approx. 3500 students, install and configure 1500 or so network cards and troubleshoot hundreds of circuit, switch and routing problems over the course of the next two weeks (with less than 50 people or so). I was wondering if anybody out in the academic computing community had some advice, stories to relate, yarns to spin for the rest of Slashdot with regard to other universities and their networking for students. You might think you have had a hell of a time setting up machines for users, but this becomes a Sisyphean task when you face a wireless, IP only, Novell setup for a grumpy architecture student on a budget Win2K laptop - one after another after another!"
Use cards from the same vendor. Don't support any windows 3.x machines. Older macs are easy but take a variety of cards. Easy to support but hard to stock card inventory. Laptops are picky and we never got 1 card to work in every laptop. We kept a few of another brand just in case. Buy 15 extra dongles for every 100 pc cards. A trouble ticketing system is a must. A large percentage of your users will be able to get everything working on their own. Many will help neighbors. It is a great way to meet new people.
Napster and all those other peer to peer programs were really eating our bandwidth because of all the computers in the dorms. So now we reduce the available bandwidth for those ports/programs to almost nothing during the day. We then let them do whatever they want to (within certain limits) in the evening hours until a couple hours before the new business days.
Probably not the best solution but it's working out for us.
At the university where I work, we've been gearing up for the last few weeks. We have guides that answer the common questions for the users intelligent enough to read them. For the rest, we'll have every warm body helping with phones or going from room to room to help with setup.
;)
One of the most important bits: have a clear SLA. Be sure that you know and users know exactly what you do and don't support. At this point, inconsistency is a killer, because if one guy's willing to do more than the others, users will keep calling back until they get that one guy. If anything's changed since last spring, be sure that <em>everyone</em> knows exactly what was changed and why.
Give your specialists some cross training. Be sure that your mac guys can do basic windows troubleshooting, and vice versa. It seems like all the Mac questions hit at once. It must be a mac user group mind thing.
It's too late for this year, but automate as much as you can for next year. If you give your users access to your help database and you give them documentation, a few will check there. Set up web forms for network registration, account registration, etc.
Whenever your department doesn't do something, find out who does, and make sure that your info's correct. Students will call IT wanting to know how to register for classes online, or how to set up their telephone. That might be enrollment or the registrar or telecom or someone else. Be sure that you know, and that it's documented so that you're not sending users on wild goose chases. Otherwise, they'll call back (or worse, be referred back by another clueless department), and the second time around, they'll be pissed.
Most importantly, schedule breaks. We tend to push ourselves too hard during this time of the year. A lot of people just keep going "for another five minutes" until they pass out because they've been working for 6 hours straight without stopping for food or toilet breaks. If you've got someone who won't stop, force them to get coffee for everyone else. That'll get them away from the users for a minute, at least.
Forward, retransmit, or republish anything I say here. Just don't misquote me.
A self-install guide was my first thought too, but with an important addition. Most installation instructions I see, even most instructions of any sort, show all signs of being written by somebody who knows the procedure and writes it down. This usually yields a set of instructions that does not work, because the person who writes down the procedure knows what the instructions mean and also believes some steps are obvious and not worth mentioning. They might not even be conscious of them. E.g., "Set XYZ to ABC mode," rather than "In the XYZ section, click the radio button next to ABC mode and then click Okay."
A better procedure is to write instructions, give them to a complete novice, sit them in front of a computer, then shut up and watch. Write down every confusion they have, then rewrite the instructions, and repeat until you have instructions that you know work for a novice.
I went to school at Lehigh University in Pennsylvania, one of the earlier schools to have a mandate that all students should be "wired" (as they called it). When I arrived as a freshman in 1995, all non-Greek on-campus housing was wired with 10baseT LAN access and all libraries and academic buildings (save for the Architecture building, funny enough) had access to the same network. Remember, this is the first year that Windows 95 came out. Through the network, not only did you have access to the Internet, but you also had a complete suite of software available without any installation hassles, including Maple, Word, Excel, and various other programs required for all your classes. By my sophomore year, when I started working for the IT guys as a part-time student installer, every on-campus student could bring in their machine and plug it in. I spent a good deal of time running around to various buildings, installing ethernet cards and making sure people could print, login, stuff like that.
The number one most important thing for a large-scale mass install like this is excellent documentation. I'm not talking user manuals, but step-by-step, written for special-ed third grader instructions. The docs for this project were excellent. I may have helped out maybe 50 people tops in those first couple of move-in weeks. I think the figures I remember were something like 70% of people needed no help beyond the instructions. That's pretty good when you're dealing with 5000 students, 3500 of which had older computers that were setup on the network the previous year (those are more difficult because they still have all their settings in place for older configurations).
The second most important tip is to have well-written support software. The software that Lehigh had doing the dirty work of configuring network settings, initializing programs for network use, and setting up printers and connections was pretty solid. Everyone once and while you'd get some oddball Packard Bell that didn't like it, but for the most part, it was solid. Macs were even supported well (indeed first, because the school actually transitioned from all Macs to all PCs during this period). People running Linux were usually clued in on their own, so no help needed there. In contrast, other friends have reported stories to me of utter nightmare installs due to programs crashing, wiping out configuration settings, installing the wrong software, etc. at other universities. If you don't have solid software that you yourself are comfortable using, don't push it out onto thousands of incoming freshmen. Every tiny annoyance you see will become a full-blown logistical nightmare as you try and coordinate your support staff to fix it.
Finally, use e-mail effectively. Our student consultants were all setup with mailing lists that we could post problems and solutions (mostly solutions) for even the rarest of situations. We were all told to do this and told to watch for the information as well. Information flows a lot better when a bunch of geeks can read threads of problems and solutions than when you go over it during organizational meetings. For us, those usually were reserved for congratulatory pizza and the occasional mass wishlist.
Of course, all that is probably a little dated (we didn't have wireless LANs yet when I left), but as far as logistics goes, it's pretty much the same good advice.
Documentation. Solid software. Communication. If you've got that, you should be fine.
I admin for a private high school in Connecticut, and I get this problem every year. Kids already have a NIC, but it's not set up right. Or something else obscure doesn't work. Here are a few helpers to get you through the mad rush.
1. Hire help. Cheap help. Go to the local high schools, and offer $50 bucks and pizza for a day of installing NIC's. Get tech-savvy students(duh).
2. Insist that your job is *only* setting them up on the network. If it doesn't work on the first plug, move on and come back to that person later.
3. Use only one type of NIC. I use 3Com 3C-905B cards. Carry a driver diskette with you.
4. Never help anyone with a Compaq Presario. They are a nightmare. Corollary: If you get suckered into helping anyone with a Presario, never, ever, call Compaq Tech Support asking for a recovery disk.
5. Set up a help desk site with common problems and solutions. Easy with PHP or something.
6. If students are savvy enough to do their own stuff, by all means, let them. This means anyone running Linux, so just give them the NIC, and tell them to have fun.
7. Block outgoing P2P. It will save you lots of bandwidth.
8. Use 10-Mbit hubs or switches in your dorms. This will keep the rest of your network (100Mbit?) nice and tidy from P2P traffic.
9. Keep a close eye on possible haxors. You know how to identify them, the kids who bring their own Cisco routers to school. They're the ones who are going to bring down your gateways.
10. Breathe. Just take it easy, and remember, they're only computers.
Hope this helps.
Ted (Ted.Dziuba@LEGIT_MAIL_PLZ.cheshireacademy.org)
"Quoth the Penguin, pipe grep more"