I remember looking at these when they first came out and thinking it would be useful for sysadmins/coders who work in odd areas, but the form factor is pretty much useless on a plane/train, inside a rack, or anywhere else you don't have a full desk to set it on. And the fact that it was an 8.5lb laptop in the days of their competition getting down into the 5-6lb class. Coupled with the high (even for IBM) pricetag, it didn't do so well.
I've read through a number of peering agreements over the last year, and this is one of the most onerous and one-sided that I've seen. Mandating minimum connection speeds that are out of the realm of all but probably the 20-30 largest carriers in the world, minimum of 8 POPs with 4 of them in distinct regions peering with TWC, must have at least 500 downstream AS's, and must be advertising 2000+
Definitely taking the stance of they have everything to gain from this relationship and any benefit to the peer is only if it benefits TWC more. The Google's and Facebooks of the world have fair and reasonable policies that most large enterprise customers can easily meet to benefit from peering. Maybe this is why peeringdb doesn't list many locations or peers for TWC. Glad Charter is buying them. Hopefully peering policies like this go away soon. For those interested, Charter's policy is here for those interested in how far apart they are from each other:
I've been a Debian user since sometime in 1996, was a RH user from 3.0.3 until around the 6.X days, and was a Slackware user before that (back in the pre-kernel 1.0 days when a distro was 50+ floppies for a full install)
Your goals here are make it quick and easy to get stuff out of the box, configured, and back out the door as quickly and efficiently as possible.
Things I'd do to start:
If doing racks, consider shelves so you can slide equipment in and out quickly. Some racks will let you do shelves that mount to the sides rather than taking up 1U for a shelf, these may let you get more density in the rack and need fewer racks.
If doing shelves, don't stack equipment, try to put it like books on end, makes it a lot easier to get one piece out without moving a bunch of others.
Plenty of power cords/outlets where you need it, make sure if everything isn't a C13 that you account for this. Newer switches are starting to use C15s or C19s for larger equipment. Make sure you have a large enough UPS to handle startup current for all these devices. Constantly turning up/down equipment is hell on your power feeds, good clean UPS power is important.
Patch cables wired in and velcro'ed off to the rack where you need them, and run extras. That way if you have a suspected bad cable or a broken end you aren't worrying about replacing it right away to get the equipment out the door.
Terminal servers are a godsend in an environment like that. Configure them so you know that TS1, port 1 is the top (or bottom) device in the rack. Keep them in order or you'll be tearing your hair out why the wrong device just rebooted.
As someone else mentioned, USB barcode scanners if you have to do any kind of inventory tracking is a GREAT tool to have.
Separate but adjacent boxing/unboxing room with a sturdy table. And a sturdy cart to move equipment back and forth between them. You want to keep all the cardboard and styrofoam out of the equipment config area.
Has anybody suggested asking the current political candidates their views on SOPA? If you live in the US, and your Congressperson is listed as a Co-sponsor of the bill, or listed as an opponent of the bill, have you contacted them to voice your opinion? Votes are all that matters to politicians. A few hundred calls/emails to their office telling them that this is a flawed bill, and it WILL result in your vote going to their opponent can quickly change their minds on what matters to them.
That's the current list of SOPA co-sponsors.
Backup configs, make sure you save them frequently when things are working.
Get a good network management/monitoring package which uses SNMP to monitor the equipment.
Take as many classes and training sessions as you can.
Purchase vendor support for equipment. Cisco TAC is invaluable when the excrement hits the oscillating device. When the network is down, and the boss comes into the server room to ask when it's back up, it's much more comforting to hear that the vendor is helping you investigate the issue than to hear you have no idea what the problem is or when it might be fixed.
Build a lab to test/learn new protocols/ways of doing things. Have a couple servers in there, as well as the same type or smaller versions within the same family. If you're running Cisco 3945 routers in production, a lab with 1720s running 10 year old code doesn't help you troubleshoot production issues or test code upgrades.
A good podcast which covers CCNA/CCNP level topics with examples:
How to backup your devices:
Netdisco, good tool for network discovery and host tracking
Join and read network mailing lists. NANOG, Cisco-NSP, Juniper-NSP are a good place to start. http://puck.nether.net/mailman/listinfo/ to subscribe to several of those.
Beyond that, good luck. Speaking as someone who has been doing systems/network administration for close to 15 years, you will learn something new every day. If you don't, you're not trying hard enough.