Real World Computing
Code in the head
The newly set up Scripting Centre has a wealth of genuinely useful material, and a new layout, along with hundreds of script examples and some superb walkthroughs. Start with the basics, and you'll soon be hooked and working out what to script next. The Scripting Centre is at www.microsoft.com.
/technet/scriptcenter/default.mspx
David Moss
Beat the box
One downside of running a remote server is that you can't beat it over the head with a large lump of wood whenever something nasty goes wrong. If that box is nearly one hundred miles away, and locked insnside a heavily secured and protected data centre in Docklands, for which I have neither the key nor the patter to sweet-talk my way inside the building, things can get even more nervous.
Of course, this is all before I discovered the delights of ILO2 on HP rack-mount servers and their, albeit extra cost, software that lets you watch the boot sequence and so forth all from a distance. The box in question is a two-year-old Dell, which has done fine service over the years, running Server 2003 and Exchange Server 2003. It's set to auto-update every time Microsoft releases some patch or another bug fix, and it has so far never failed to work for me. If the worst came to the worst, I could call on my ISP to trip the power feed to the server using the remote capabilities of APC's power management and switching facilities. But this hasn't been necessary. Until now.
I knew something was wrong with the box when the IMAP and SMTP feeds started getting stuttery. A lack of incoming email from an Exchange Server is usually a good indicator that something's amiss. I tried Terminal Services to log into the machine, but glacial wouldn't even begin to describe the sloth-like speed of the response. After several hours of remotely poking the box with an electronic pointy stick, I gave in and asked Merula, my ISP, to give it the appropriate kick up the backside by cycling the power supply. These seconds that pass between the per-second ping line freezing and it starting up again would be familiar to Apollo or Shuttle astronauts who've brought a spacecraft through the upper layers of the atmosphere - complete blackout, staring mesmerised at the clock, then the huge sigh of relief once the counters start up again...
The machine was definitely back to its usual chirpy self, but I decided that I should keep a closer eye on it. After a few more days, it was showing early signs of the previous malaise, so I decided to poke about with some urgency. Then it struck me - I'd installed the current release of Microsoft Virtual Server R2 onto this box, with the intention of running one or maybe even a couple of virtual servers on the same box. But I'd half-cooked the cake: Virtual Server was installed, and up and running, but no VMs had been created or installed, so it was just idling away doing no work. After I removed Virtual Server, everything sprang back to life and the performance was fine for weeks with no signs of any problems or degradations.
Diagnosing this problem raised one very obvious question - why on earth had I installed Virtual Server onto a box that already had a medium-sized Exchange Server 2003 installation running? As so often, the answer falls into the category of perfect-world solutions, also known as "I wouldn't start from here". Clearly, it would have been better to install a simple base server, onto which I'd then install Virtual Server, which in turn would bring up the appropriate VMs, one of which would contain Exchange Server. But that wasn't the choice available to me - I had Exchange Server there, and Virtual Server over there, and no amount of jiggling this Rubik's Cube would get the right OS into the right space, especially as I had to do all this via remote desktop (aka Terminal Services) capabilities on a server to which I had no physical access. Juggling crocodiles would have been easier.
