As we come to the end of our server transition, here are some lessons learned:

- There was much less actual downtime than anticipated. Richard B. had to down the servers only when migrating data, but then he could bring the old servers back up again and test the data on the new servers.

- My attempts to promise a specific day for the cutover were defeated, twice. It would have been better to have told users that the new network would be in place when they saw it in place.

- The new web server was a useful place to post status announcements even while I was building it out. I had thought the entire server would be out of commission for much longer.

- Winter break was the best time to do this transition all year. It was quieter here than at any time during the summer, and users will return gradually over the next week and a half.

- The only big obstacle was the mass migrating of Exchange server accounts from one server to the other. The export utility worked fine, but the import failed. However, since the export creates an individual PST file for each user, it should not be a problem to import them into the new mail accounts individually or to provide users with instructions to import their own PST files if they so desire.

- AD Infinitum has been an essential tool, creating all AD accounts and generating secure, initial passwords for the new accounts on the fly. It's a great deal for $100.

Related: The Quietest Week of the Year, 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.

Our big server upgrade is coming up in just a couple of weeks. Our intrepid network administrator has chosen Christmas week to take down the old servers and bring up the new servers in their place. Exchange is projected to be down for a couple of days, the admin servers for the better part of a week, and the academic side of the network for at least a week, if not longer. Why perform a server migration halfway through a school year? It appears to be the time when the least users are active on the systems. There is actually quite a lot of administrative, teacher planning, and student email activity during the summer. A network migration would be more disruptive then than it will be during Christmas week.

Of course, the pressure will be on us to bring the servers back as quickly as possible. Note that we made this more difficult for ourselves by choosing to change our network structure. If all we were doing was to upgrade the servers, then the migration would be a lot more seamless, involving only data migration.