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!"
It's because here on slashdot, people know: Offer free tech support once, and you're forever branded as the tech support guy, and you do tech support for free. If they need help, they go to you cause you're free.
sig?
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.
Being the designated computer geek will *NOT* get you laid. It will *NOT* win you friends. All it will get is people calling you any time of the day or night, particularly the week where all the arts students with the crappy old computers and rotting floppies ask you whether you can recover their Word 6.0 document for them . . .
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
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.
If any of you guys have Cisco switchs then you can use Vlan Management Policy Server. It allows you to assign students to vlans based on mac addresses. I designed a system built around this switching feature. When a student plugs into a dorm port, the first packet they send triggers the switch to look up their mac address in a central database. Barring an entry they are dumped into a fallback VLAN where I position a DHCP, DNS, HTTP multihomed server. The DHCP assigns them a non-routable IP address to communicate with one side of the box. I then instruct them(through check-in documentation) to open their browser. I wrote a tricked out named.conf, that no matter what domain they request, it always returns the IP of my server. Thus, they will connect to my server and I can collect information, including their Mac address from the arp cache...they fill out the form and their data is dumped into a database, a perl script is called to add their mac address and vlan assignment to the VMPS database(a flat text file) and fire out a SNMP packet out the public interface to tell the VMPS switch to grab the VMPS file and refresh it's tables. Viola! Totally automatic...we were having trouble keeping up with the volume of activations, so I had to think of something(there are 3 of us for 3500 ports, and 2 are student aides).
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.
on the upside, Compaq now has its recovery disks and other stuff available for download. at least for the battered old Deskpro I use as a firewall. :)
my old sig used to be funny, but then slashcode ate it and now it's not funny anymore
While I was in the tech support department of a large university we had the same thing happen, but the culprit was an Apple AirPort base station that apparently got hit by a power surge and went rouge. My box happened to go through a lease renewal after that, and somehow the network sleuths tracked me down as the culprit. It took some fast talking to calm them down and help them find the rouge box.
TAMU will be introducing 10,000 students to the dorms next week. All dorm rooms have two ethernet ports. When a student plugs in, they are taken to a registration page (regardless of their destination) where they can register their machine and assign a DNS hostname. They are then free to use the network.
p 3 for somewhat up-to-date information (we will not be supporting the PH nameserver for more than afew weeks, hopefully).
One IP address per student is allowed. They can change their hostname at will. All configurations are done via DHCP, so any machine that can speak TCP/IP and DHCP are welcome on the ResNet.
http://cis.tamu.edu/help/resnet_registration.ph
We do it that way. Once someone applies for and receives his account information, we send them to their floor's RA who has a couple of instruction packet to lend out. The packet walks them through installing basic Windows networking services, then they login with a generic "newuser" account, which automatically upgrades their Novell client to a modern version. We then use Novell's Application Launcher to install Netscape and McAfee virus protection--one click install for each. Netscape settings are downloaded from the login script; DHCP provides IP configuration; and we give them basic email account configuration instructions.
We leave it up to the user to get their network card installed. Some of them have their friends do it, some do it themselves, and others pay us during our off-time. For those who either can't figure out the packet, or have problems with the procedure, we schedule a time to visit and get things working for them. We update our instructions periodically as we discover common problems and solutions to those issues. I suppose the toughest part--anywhere--is the fact that we're dealing with all sorts of different computer models. Some certainly present interesting quirks.
We're a fairly small school, and not everybody has computers, so it goes pretty well. There's only a couple of us to handle it all. Word gets around and users help each other out quite a bit. We keep as much as we can centralized and generic, and automate settings and such through login scripts and such.
We avoid a lot of issues but not officially supporting them, like file sharing and network gaming. People do it, and we don't have any reason to stop it, but they have to help each other out. We don't let them call up and get our help for things like that. "Research only" is the official policy.
"I say consider this day seized!" -Hobbes
"Tomorrow we'll seize the day and throttle it!" -Calvin
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.
At the lovely University of Pennsylvania, it's a total breeze. We have so many freshman that want to get an on campus job that they don't realize how badly they're being ripped off. So they sign up to be "Information Technology Advisors" and there are about 15 per dorm. One sits with a laptop at the front desk and people ask him for help. The other 14 sit in the computer lab on our bulletin board waiting for jobs to show up. We do a couple thousand cases in a week.
They show up a week early for school for "training" where someone shows them how to download ethernet drivers onto a floppy from a website. And click on windows control panels to enable DHCP. Anything more complicated gets refered up to more experienced (And more paid) personel.
I assume this is the way most schools do things. It's kindof cut and dried, cheap, and effective.
There are no trails. There are no trees out here.
I'm campus contact for College Ave campus of Rutgers U. We've had pretty massive host growth. User education is the KEY to reducing workload on your techs and admin. Three words will set you free:
LITERATURE LITERATURE LITERATURE. Make up pamphlets about the following subjects, distribute them to EVERY ROOM and email them to students and parents over the summer preceeding the semester on the following subjects:
-How to get and install a network card
-How to register for an IP address online
-How to set up IP in various OS's (Win9x, win2k, Mac OS 7, Mac OS X, command line linux)
-What rules you'll have to abide by concerning bandwidth caps, providing access and illegal activities
After you get everyone online youll have users screaming about configuring stupid crap like outlook and AOL. Create online documentation about these and make people aware of them.
Mind you Rutgers doesn't use DHCP, so that registering stuff might sound a little non-kosher to you small network DHCP guys :). We've tried, DHCP just isnt an option across ATM, more than two dozen routers and a few hundred VLANs.
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"