If your organization is running Microsoft Mail or Exchange Server 4.0 or 5.0 and you are looking at migrating to Exchange 2000, there’s something you need to know. Before upgrading your servers to Exchange 2000, you have to upgrade them to Exchange 5.5 with Service Pack 3 (SP3). There’s no extra cost, since Microsoft includes the Exchange 5.5 upgrade media and licenses with the Exchange 2000 upgrade. However, the larger issue is whether you want to make that big a leap at one time.
My organization had been living with the antiquated Microsoft Mail 3.5 for several years. During that time, it fulfilled our minimum needs for e-mail, but it was very slow and not very configurable, so we decided to upgrade. However, we did not make the two-hop leap to Exchange 5.5 and then to Exchange 2000. Instead, we chose to upgrade to Exchange 5.5 and to put off upgrading to Exchange 2000 until the future. This article is a look at our Exchange migration and installation process.
Investigation of alternatives
We spent some time looking at alternate systems, including Novell GroupWise and Lotus Notes, but our local reseller suggested that we use Exchange. This was what he used, and he recommended it very highly.
We decided on Microsoft Exchange Server 5.5 for a number of reasons:
* Reliability—We wanted a system that would have as close to 100 percent uptime as possible. We have some 250 users and a lot of them rely on e-mail for interdepartmental communications.
* High message throughput—We have a number of managers who send upwards of 100 messages per day, so we cannot afford for the system to get bogged down.
* Ease of installation—We have a small IT staff at our facility and could not afford to put a lot of time into the implementation.
* Ease of configuration—We wanted to pretty much be able to drop in the system and have it go live as fast as possible.
Aim of the project
We sought to migrate all 200-plus users to Microsoft Exchange Server prior to Jan. 1, 2000, because of Y2K issues with Microsoft Mail. This included users who accessed our current network across a T1 WAN connection.
We began by carrying out the following tasks:
1. We went into MS Mail Admin’ (a DOS utility) and printed out all of our existing MS Mail accounts.
2. We used MS Mail Admin’ to list and print all of our MS Mail distribution lists.
3. We used User Manager For Domains to make approximately 150 NT user accounts.
4. We used Exchange Admin’ to create a matching amount of Exchange accounts (once the server was set up!) one by one.
5. We purchased a server.
Starting out
We started by loading Windows NT 4.0 SP5 (later upgraded to SP6) on our new server. We took our local reseller’s advice on the specification of the machine and ended up with a 750-MHz processor, 128-MB RAM (upgraded to 256 MB before we went live), and 9.5-GB SCSI hard drives in a RAID array. We then started to load Exchange 5.5 on our new server.
Server installation and configuration
Installing Exchange was not quite as straightforward as we thought it would be, and we ran into some problems. Our reseller supplied us with a CD containing the software, and we tried everything we could think of to get NT to recognize the disk with no luck. We took the disk to another server, and that one wouldn’t read it either, so we returned it and had it replaced. Happily, the second disk worked fine.
The server already had an Internet Protocol (IP) address and “supposedly” had network connectivity, but when we tried to browse the domain, we couldn’t see any other servers. We rebooted and tried to log in to the domain—no luck! We removed the network card and replaced it, and we were back in business.
After sorting out these initial problems, we were able to proceed. Before inserting the installation CD, we had to decide on the following items:
* An organization name
* Exchange Server site name
* An NT Server Administrator account name and password
* The name of the Microsoft Exchange Server Administrators Group
We created the Service Account that Exchange would use and created an Exchange Server Administrators Global Group in NT using User Manager For Domains.
Now we were finally ready to get the software installed. We inserted the CD and located and changed directories to the Setup directory. Then, we located and changed directories to the correct computer type—ours was an Intel-based server, so we chose the i386folder.
We executed SETUP.EXE, clicked OK to dismiss the Welcome screen, and selected the Typical install from the Server Setup dialog box, shown in Figure A.
Figure A
The Server Setup dialog box
When the Licensing Mode dialog box appeared, we chose Per Server Licensing and then entered the Organization Name and Site Name in the dialog box shown in Figure B.
Figure B
The Organization And Site dialog box
We answered yes to the prompt Are You Sure You Want To Create A New Site? Next, the Site Service Account box appeared, asking us to choose the Service Account. We entered the Service Account name and password we had created earlier. Microsoft Exchange Server Setup copied the Microsoft Exchange Server files to the hard drive and installed the services that Exchange requires to run.
The next screen asked us to which Windows NT Program Group the Microsoft Exchange Servers application icons should be installed. The default is Microsoft Exchange Server, and we saw no reason to change this. Once the installation was finished, the Microsoft Exchange Performance Optimizer dialog box appeared, as shown in Figure C.
Figure C
The Performance Optimizer Wizard
We clicked Next to launch the Performance Optimizer Wizard, and then we selected Run Optimizer to have the wizard analyze our hardware configuration and arrange files on the Microsoft Windows NT Server for optimum performance. We had been advised that running the Optimizer was critical to the efficient operation of Microsoft Exchange Server. (You don’t have to run the Performance Optimizer Wizard during install, but you should run it before the Microsoft Exchange Server goes into production.)
On completion of the install, we were prompted to reboot our server, which we did. Although the initial install was now complete, we still had to take care of some configuration work.
In order for the Microsoft Exchange Server to be administered, permissions had to be granted to the Administrators Group. Here are the steps we followed:
1. We ran Exchange Administrator.
2. We connected to our new Microsoft Exchange Server.
3. We pulled down the File menu and selected Properties.
4. We chose the Permissions tab. A list of Microsoft Windows NT user accounts in our domain appeared, and we selected all the Domain Admins in our domain.
This completed the configuration that we handled in-house; our local reseller (who has a lot of Exchange experience) then came in and carried out the following procedures:
* Directory Service site configuration
* Site addressing
* Server configuration
* Directory service configuration
* Directory synchronization
* System Attendant configuration
Setting up mailboxes and users
This left us to start setting up users. We made the biggest mistake of the entire project at this point. Being unfamiliar with the workings of Exchange Server, we figured that we would set up user containers by department, such as Human Resources, Admissions, Cardiac Rehab, and so forth.
This appeared at the time to be the best way to set up the users, as it would present them by the department that they belonged to. We set out creating the user containers and then populated them with our users accounts. Only after creating some 200 users did we find out from a TechNet article that you can’t move user mailboxes between containers on which they’re set up! This represented a big problem, as staff members at our organization frequently change departments. We understood from TechNet that the best way would have been to create Address Book views instead, which is a far more flexible way of setting up users.
At this point, we decided to bite the bullet and keep it the way we had it for now. We were ready to hit the desktops via the SneakerNet!
We already had a plan of attack on how to tackle the user configuration as follows:
1. Install Exchange Client 5.1. This was done by visiting each user’s desk and installing the client from a CD.
2. Log in as the user and set up the Exchange service in his or her profile.
3. Copy all the user’s folders and messages from the PST into the new Exchange mailbox and remove the old PST file.
4. Remove the MS Mail service from the user’s profile.
Conclusion
The big gotcha in this project was setting up the mailboxes in departmental containers. That was a major mistake, but sometime in the future, we hope to correct it. The only other real surprise was the speed of e-mail delivery once we had installed Exchange. Now we truly had real-time messaging! During the migration and after, we found that Exchange Server met and exceeded our expectations on all counts, and we have now been on it for almost a year and a half with few problems.
The release of Exchange 2000 doesn’t mean that Exchange 5.5 can’t be a good interim solution before moving to Exchange 2000, which requires a solid Windows 2000 and Active Directory infrastructure before being implemented. You can purchase Exchange 2000 and use the included Exchange 5.5 with SP3 to upgrade your current mail servers and then roll out Exchange 2000 after you have Windows 2000 and ADS firmly in place.
No comments:
Post a Comment