What are some important considerations when upgrading to Microsoft Exchange Server 5.5?
Planning an upgrade from Exchange Server 4.0 or 5.0 requires careful planning and consideration of key elements, notably conversion downtime and administration and setup. Here are some considerations.
Downtime for conversion. The time required to upgrade to Exchange Server 5.5 is the most significant consideration of the upgrade process. The database format of Exchange Server 5.5 differs from the format of previous versions of Exchange. The number of messages and folders and the total size of the Information Store affect the amount of downtime required to perform the upgrade. Limiting the private Information Store size through mailbox quotas or limits on the number of users per server will reduce overall upgrade time. Another consideration is that upgrading to Exchange Server 5.5 from version 4.0 takes approximately twice as long as upgrading from version 5.0, because the database is converted twice.
Because Exchange Server 5.5 can coexist with previous versions, you can minimize downtime by a phased upgrade: Add new Exchange Server 5.5 computers to an existing site and move mailboxes from Exchange Servers running previous versions. This capability is useful when you are adding new hardware components and platforms. The disadvantages of a phased approach include time required to move mailboxes, loss of the deleted items cache, effects on rules, and inability to receive mail while a mailbox is moving.
Administration and setup. Administration in Exchange Server 5.5 has improved with features such as deleted item recovery and improved support for Internet protocols such as Internet Message Access Protocol (IMAP) and Lightweight Directory Access Protocol (LDAP). In addition, you can use the Exchange Server 5.5 Administrator program to administer Exchange Server 4.0 and 5.0 servers. Here are some hints for upgrading:
- Internet Information Server (IIS) 4.0 ships with Exchange Server 5.5. When you use IIS 4.0 for Outlook Web Access (OWA), you must install Exchange Server 5.5 on the server. Servers that don't support OWA don't require version 5.5.
- To upgrade to Exchange Server 5.5, you must install Windows NT Server 4.0 Service Pack 3 (SP3).
- You can't use NT 4.0 Distributed File System (DFS) with Exchange Server. Exchange Server database files can't reside on a DFS partition because some NT functionality that Exchange Server requires doesn't support DFS. For example, Exchange requires an NTFS file system to install the Information Stores, but DFS doesn't appear to Exchange as NTFS.
- The Exchange Server 5.5 setup program gives you two options for upgrading from version 5.0. The In Place upgrade option upgrades the databases in the current location. The Fault Tolerant upgrade option upgrades the databases in a specified temporary location and then copies the new databases to the old location.
Some final notes: Check with independent software vendors (ISVs) to ensure that any third-party products you're running with Exchange Server support version 5.5. Second, before you upgrade to Exchange Server 5.5, review the README file in the root directory of the Exchange Server 5.5 CD-ROM. In addition, you must back up your existing Exchange server before upgrading. For more Exchange Server 5.5 upgrade documentation and tips, see http://support.microsoft.com/support/kb/articles/q179/2/58.asp and http://support.microsoft.com/support/exchange/content/whitepapers/ whitepapers.asp.
How can I quickly determine how many mailboxes are on an Exchange Server?
From Exchange Administrator, you can view the number of mailboxes on an Exchange server. As Screen 1 shows, you can select a server, expand the server Properties folders, and select Server Recipients. The window on the right lists all the server recipient mailboxes. The total number of mailboxes on the server appears in the lower left corner of the window as x Recipient(s). You can generate a quick report from Exchange Administrator by clicking File, Save Window Contents.
Exchange Server 5.5 is consuming all my system memory. With previous versions of Exchange, I had free memory on my server. What's going on?
Exchange Server 5.5 uses memory very differently from previous versions, and this change is an important enhancement. In Exchange 4.0 and 5.0, the Performance Optimizer allocated memory statically, usually when you installed Exchange Server. The Performance Optimizer limited Exchange Server to 80MB (or 20,000 buffers of 4KB each) of memory for its Information Store buffer pool (IS Buffers). Therefore, the amount of memory that Exchange Server used remained static, despite load conditions on the server.
With Exchange Server 5.5, Microsoft introduced dynamic buffer allocation (DBA), a memory-tuning algorithm that dynamically controls the amount of system memory that the IS Buffers use. DBA functions similarly to the way the NT operating system (OS) dynamically allocates memory for its file system cache. DBA ensures that Exchange Server can request as much memory as the server load requires, while considering the memory needs of NT and other memory-consuming applications on the system.
Microsoft designed DBA to maximize Exchange Server performance, maximize system memory utilization, balance Exchange Server's requirements with the system's requirements, and release memory when other system memory consumers need it. With these goals in mind, the DBA algorithm allocates memory as long as it is available. The DBA algorithm is sensitive to the load on both the Exchange server and NT. DBA will attempt to allocate more memory to Exchange when Exchange Server is under a heavy load and will attempt to free memory if the NT file system cache or another application is under a heavy load and requires more memory.
Exchange Server 5.5's DBA can change the behavior of a system compared with previous versions of Exchange Server. But don't be alarmed, because the software is just making optimal use of the hardware configuration. You can view this behavior with Performance Monitor under the Database object. The Cache Page Faults/sec counter shows the rate at which the database cache is allocating new pages of memory. The Cache Size counter displays the current size of the database cache.
I am trying to set up Exchange Server to work with my Internet firewall. Which TCP/IP ports does Exchange Server use to communicate?
Whether you are troubleshooting communications between two Exchange servers or between Exchange servers and clients, or configuring access to the Internet via a firewall, you need a guide to the TCP/IP ports (including User Datagram Protocol--UDP) that Exchange Server uses to communicate. For example, Exchange Server supports Simple Mail Transfer Protocol (SMTP) for communicating with other SMTP hosts on the Internet. If the Exchange server must access the Internet-based SMTP host through a firewall server (most do), you or the firewall administrator needs to know the TCP port that SMTP uses to establish a connection and transfer mail. The firewall server must let connections for that port pass through from the Internet to deliver SMTP Mail.
Exchange Server supports many different protocol choices for both server-to-server and server-to-client communication. The firewall server must let clients that support protocols such as Post Office Protocol (POP) 3, IMAP, and LDAP communicate with Exchange Server. However, not every Exchange Server deployment requires you to enable all ports at the firewall server. Determine which Exchange Server services will require access through a firewall. Table 1 lists Exchange Server's protocol ports and their functions.
How can I move Exchange Server from one computer to another?
Often, Exchange Server administrators need to move Exchange Server to another computer. You might need to make the move to recover from a disaster caused by hardware failure, or to upgrade the hardware. The moving procedure can be tricky. You must plan carefully and understand the steps required to perform this operation. Here are some important considerations for relocating Exchange Server from one computer to another.
Before moving Exchange Server to the new computer, verify that the computer to be moved is not the only NT domain controller in the domain. While this computer is shut down for the relocation, you need a domain controller that can validate logon requests. If the computer to be moved is a Primary Domain Controller (PDC), make sure that there are at least two Backup Domain Controllers (BDCs) in the NT domain. After you shut down the computer to be moved, upgrade the BDC to a PDC. If the computer to be moved is a BDC, make sure that the PDC in the domain is up and operational or that other BDCs are available that you can upgrade to become the PDC. Now, follow these steps:
Step 1. Configure new hardware (the hardware might be a different architecture, such as a Digital Equipment Alpha or simply a more powerful version of your current architecture) and install NT using a temporary server name and IP address. This machine is the destination server for your production Exchange server. It must be in the same NT domain as the existing server.
Step 2. Close the original Exchange server's Exchange services, perform a full backup of the Exchange Server Information Store and Directory (\EXCHSRVR\MDBDATA and \EXCHSRVR\DSADATA) and shut down the server. Perform a full backup of the existing production Exchange server that you want to move (this backup will be an offline backup of the Exchange Server directories). Don't let users log on to the server after you shut down Exchange Server services in preparation for the backup. When you've completed the backup, shut down the server.
You can accomplish the same result by copying the Exchange directories from the existing production server to the temporary server. Be careful! This approach is for advanced administrators who understand Exchange Server files and locations. A complete backup to tape is a much safer and less error-prone method.
Step 3. Using the NT Server Manager utility in the Administrative Tools menu, remove the old server from the NT Domain. Next, change the new server name and the IP address of the temporary server you created in step 1 to match the original server, and reboot the server. After you reboot, join the NT domain and reboot the server again. The process of removing the old server from the NT domain and adding the new server with the same name will ward off NT security and domain membership problems.
Step 4. Install Exchange Server on the new server, using the same organization and site name as for the original server. Create a new site. Do not attempt to join the existing production site. At this point, the production environment directory still has all the details of the original server and mailboxes, and you have a parallel nonproduction organization and site with the new server in it.
Step 5. Shut down the Exchange Server services and restore the Directory Service and Information Store from the original server to the new server. Perform a standard restore from tape to carry out this procedure. If you have manually copied Exchange files, ensure they are restored to the proper locations.
Step 6. Start the Directory Service. The new server will now understand that it belongs to the production site (because the details are in the Directory Service that you restored). The temporary parallel organization and site will no longer be present.
Step 7. Finally, use the ISINTEG utility (in the \EXCHSRVR\bin directory) with the -patch switch to check the integrity of the Information Stores (public and private). See Screen 2 for more detail. When you've completed the check, you can start the Exchange Server Information Store service, to complete the relocation.
Exchange Server will now be running on the new computer, and the changes will be transparent to users. You might have to make other minor reconfigurations. For example, you need to reconfigure any connectors running on the server or set up applications running with the Event Scripting Service. You might need to reconfigure any server or link monitor running on the server. Use the steps I've outlined as guidelines. However, try this procedure in a nonproduction environment first, to verify the steps or deviations specific to your organization.
