Dorm Storm? 628
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!"
my school (Score:1, Informative)
Re:Only on Slashdot... (Score:3, Informative)
Did just this thing for 3 years (Score:5, Informative)
It's worse than that (Score:3, Informative)
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 . . .
bearshare/napster/etc (Score:5, Informative)
Probably not the best solution but it's working out for us.
Automatic Registration (Score:3, Informative)
DHCP (Score:1, Informative)
Preparation (Score:1, Informative)
how we do it (Score:5, Informative)
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.
Re:Similar Problems (Score:3, Informative)
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. :)
Personal Experience with the dorms at UTK (Score:2, Informative)
When I went to pick my computer up I watched them stick the cards in and use a drivers disk they wouldn't give us. They had LOTS and LOTS of computers to install because of this. They were working on computers for a good two weeks and regularly throughout the year when someone would get a new computer. Hopefully they are smart enough to provide a drivers disk with the NICs they sale this time around.
A month or so later, I had fun downloading a redhat iso from the local sunsite. It took me longer to burn it then to download it... =)
Re:Rogue DHCP Server (Score:3, Informative)
Re:Ugh. (Score:1, Informative)
A few thoughts on ResNets (Score:2, Informative)
1) Provide easy to follow instructions. Both online and in paper form. Distripute the paper ones to the dorms, and bookmakr the online instruction in all the public user rooms.
2) Only support the Operating systems you have the experise for. If you only know Windows 98 and Windows 2000, only provide support for those. Don't try and support an OS you don't really know. In the end the students will be happier wil no support than really bad support that might break there computer.
3) If the hardware is the problem, tell them. Don't try and sugar coat the problem.
4) Invest in some quality networking hardware, and develop a network management system. We use Cabletron's SFS switchs. In addition we have written a complete network management system that tracks MAC-to-user relationships, as well as what IP a user currently has, and where on the network they are. Despite the complexity of this system it allows for very powerful network management. We have been able to write a number of automated proccess this monitor the network and turn off ports if the user is causing a problem. This can be anything from using too much bandwidth, to trying to hack our servers, to trying to steal an IP.
5) Finnaly, DHCP. Make all of ResNet DHCP and make sure it is all behind 1 router port. This allows you to easily block things completely from ResNet. One of things we did a few years ago to prevent open-relay mail servers is to just block port 25 to resnet.
Just a few of the things we have done to make our lives, and the lives of our customer service people a little easier.
Consider Texas A&M University (Score:3, Informative)
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
Re:UWM? (Score:2, Informative)
When you get to Sandburg you'll need to stop by the main desk and ask for a Network Use Agreement (NUA). Read and fill out that agreement and drop it off at the main desk, along with your $25 network access fee. That fee is one-time only, and covers installation, 10mbps network access, and a patch cable to get connected. Any other hardware is your responsibility.
You'll basically need to set up your box (Mac, Windows, or Linux) with an Ethernet card, TCP/IP and DHCP. If you're not familiar with the setup, you can bring your machine to our office and we'll set it up for you as part of the fee. When you get your computer up to your room, plug it in and start it up. When you get to a desktop start a browser. You'll see the registration page at this point. Fill out the registration page with your UWM email and password, your student ID number, and your receipt number from the NUA (if you registered within a few days).
Once you submit the form you'll have to reboot (yes, even on Linux) and then you should have Internet access. If at any point you run into a problem you can't resolve, you can call us at x4606 or stop down at our office in the Commons and we'll help you any way we can.
--
MIT Student Consultants (Score:1, Informative)
at uc berkeley (Score:2, Informative)
Re:Self Install Guide (Score:3, Informative)
We [bbcnet.edu] 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.
Re:Self Install Guide (Score:5, Informative)
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.
Re:Similar Problems (Score:2, Informative)
Hah! You thought those were bad?! Back when I was getting students on the campus networ (between '97-'99) the worst proprietary brand you could come across was BY FAR those damn Packard Bells. I still have nightmares about the wacky shit they would try to do when they would boot with new hardware in them. The day we found out about them going out of business, everyone at ResNet breathed a sigh of release.
At UPenn (Score:3, Informative)
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.
Provide Information (Score:1, Informative)
The biggest help I think is to provide the needed information in the form of flyers and on the School Website before the week actually begins. People who know how to setup there own computers will look there before they get to school usually so they have the needed info to connect.
If someone calls for info and not asistance give them the info or make a prerecorded message that provides all the necessary information.
And you can do what one school did, in which any computer with a working dhcp client could connect and get access to the schools local website only. Once on it they were instructed to fill out an online request form which registered their mac address to dorm room number and student. Then all they had to do was reboot or restart the dchp client to get full access.
But the biggest thing is mostly to provide the information so anyone with experience can do it by themselves without having to call and jump through hoops to get what they need. I don't know how many times I had problems getting simple information from help desks because they insisted on knowing the OS and all they supported was Win95/98 and wouldn't touch NT/2000 at all when I wasn't asking that.
Rutgers University (Score:3, Informative)
I'm campus contact for College Ave campus of Rutgers U. We've had pretty massive host growth [rutgers.edu]. 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.
My Experience (Score:5, Informative)
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.
Use this as an example (Score:2, Informative)
Similar Problems (Score:4, Informative)
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"
Allow only sane computers (Score:2, Informative)
In the pamphlet or something point out that computers should have at least
- 32 megs of RAM
- 100 megs of free hard drive
- cd drive
Also, the computer should be operational before you start with the NIC, else they'll first ask you to fix all other kinds of things.
Fruit flies like a banana, what do the other flies like?
Know the feeling (Score:2, Informative)
1. As stated before... hand out pamplets with instructions. They should only call for help as a last resort.
2. We had webforms to register your machine and recieve an IP. Our campus ran on a generic DHCP where IP's were handed to specific MAC address'. And each student could only have 2 IP's. This was all done on the web.
3. We made minimum requirements for machines we would support. Must be faster than P133's.
4. We would only officially support Win95 and higher. If you were using linux or any other, you were on your own and should know how to do it yourself. But there were a few of us that were linux savvy and willing to help.
There were quite a few other things we did that helped out. Installathons at individual dorms at certain times.
I know the exhaustion of having to deal with these problems. We were a team of 10-12 people that covered our entire campus.
Good luck... and boy and I glad I graduated and don't do that anymore.