Preparing the New Servers

We have begun installation on our new servers in earnest, coincident with the departure of our students, faculty and staff for vacation. This process will take about two weeks and will result in nine new servers in our collection of eleven. The main challenge is how to sequence the installation steps in order to minimize disruption to our 500 users. My colleague Richard has devoted the week to nstalling Win2k3 server software on the machines and testing user and mail account migration from the old servers to the new. Once we take the old servers down and interrupt service, he will have to move quickly in order to restore service ASAP. Importantly, we learned that passwords will not migrate — all of our users will have to create new ones when they first log on upon return from vacation! Exchange accounts will be moved via an export utility that spins off a PST file for each user, a process that will take a long time. Active Directory accounts will move by way of an application that can create and modify batches of accounts. This application will create new, temporary passwords for our users and save them in a file for us to distribute manually to users.

I spent today prepping our new web server. Here are some lessons I learned from doing this for the first time. IIS installation went quickly, though I forgot to enable server-side includes the first time through. As a result, the server returned 404 (not found) errors for my .shtml files until I figured that out. Activestate PERL was a piece of cake, though I neglected to add .cgi to the application mapping table and got stuck on that for a while. PHP was surprisingly hard work, since the documentation indicates that the Windows installer should not be used on production servers! The manual process was more tedious, though a couple of hours’ work finished the job. I elected the ISAPI method for PHP execution instead of CGI, because of the superior performance and security promised by that method. Finally, I have improved the structure of the cgi-bin and PHP script virtual directories, in order to minimize the chance of a user gaining script source access. One great new feature in IIS 6 is the Windows equivalent of a chroot “jail,” which automatically restricts their FTP activity to an AD-defined user directory.

There is a lot more pressure on us to quickly migrate popular services than there was to introduce these functions the first time. At least they are familiar to us and therefore quicker to configure than when we did not know anything about them.

Comments are closed.