Reasons to be cheerful
Doomsday Weekend 5: It's over, but that isn't the only good news
Sysadmin blog It’s easy to complain about a tough weekend. It’s not so easy to remember the little things that made it easier.
Not everything during a huge network overhaul is negative. I was thoroughly impressed with Exchange 2010. Teamviewer 5 was simply rolled out to replace Teamviewer 4 with no negative effects.
I am always pleasantly surprised by the "little things": downloadable components, or incremental updates, for a minor product you’ve been using for years. Doomsday Weekend was my first real chance to get to know the Microsoft Print Management Console. I had poked at it in the lab and I may even have set up a home printer using it. I had not, however, deployed it in a production environment. It is refreshingly useful, with the ability to load up both 32-bit and 64-bit drivers for your printers onto whatever print servers you have - In our case, the domain controllers (Server 2003 R2 x64).
One quirk: it wouldn’t let me load 32-bit drivers from a 64-bit machine. That the print servers were 64-bit seemed not to be a problem, but the if the system running the Print Management Console was 64-bit it would just not allow us to load a 32-bit driver. The solution was to load the print drivers onto the 64-bit print server from a 32-bit system. Not a big deal, but the lesson I took away from it was to ensure that you join one system of each planned architecture and operating system to your domain early, rather than getting halfway through the rollout and having to ask “wait a minute, have we got any 32-bit systems joined to the new domain yet?”
I have posted many times on Group Policy, but sitting down to redo your entire network’s policies in a single night can renew your appreciation for how far they have come. There are a lot of things that, five years ago, I would have been coding into logon scripts that now simply disappear with the right group policies. I love that Group Policy Preferences can push down little bits of registry configuration to each new user or computer.
And so I have just built my first reasonably sized network that didn’t require any logon scripts. It feels much cleaner.
I had almost forgotten secondary DNS zones. Certainly not new, but also not something smaller organizations use on a regular basis. This weekend I was creating an entirely new domain in a new forest. I had to keep systems from both networks alive and talking to each other throughout the process. There were systems on the new domain with the same name as systems still alive on the old domain. Trying to use NetBIOS resolution would have resulted in naming conflicts.
The simple trick of having the DNS servers on each of the two networks publish a secondary DNS zone mirrored from their counterparts on the other network. As long as you have proper routing tables, someserver.oldnetwork.local can now find someserver.newnetwork.local by name. When transitioning to a new subnet with a completely different addressing scheme, the last thing you want to do is to have servers talking to each other by IP address. You have sleep deprivation. Some computers are changing subnets as part of the move. Which computer is which IP on which subnet?
But ultimately, the applications and tools that helped get me through Doomsday Weekend were systems management tools. All the mistakes, the mix-ups, the PR gaffes, and the long hours have led me to one decision: next year I’m not buying a single new server. I’m spending the budget on management tools. ®
Sponsored: Global DDoS threat landscape report