I hope you're not growing weary as we trudge down the path and pave the way to Exchange 2000 Server. In this concluding installment of "Preparing for Exchange 2000 Server," I discuss some of the final steps in preparing for Exchange 2000.

Before getting to the nuts and bolts of deploying Exchange 2000, you need to make several assessments. The first is for add-ons and third-party products. Many Exchange deployments have extra utilities and programs—such as management agents, backup agents, and virus scanners—running on their Exchange servers. You must consider how viable each additional piece of software will be in a Windows 2000 (Win2K)/Exchange 2000 environment. Many of these third-party vendors might not have the newer versions available in time for your deployment. One example is backup software. Exchange 2000’s backup API changes significantly because of technology advances such as multiple storage groups and databases. Backup software vendors need time to modify and test their products. Antivirus products are in a similar position, with the advent of the new antivirus API available since Exchange 5.5 Service Pack 3 (SP3).

Your server hardware is another key area of assessment. We discussed hardware in earlier steps, but it's a crucial consideration at this point, also. Win2K and Exchange 2000 will be doing significantly more, so the hardware platform must be adequate. Domain controllers, for example, have more to do than in the days of Windows NT 4.0 and NT LAN Manager (NTLM) authentication. Kerberos authentication requires more work.

Your server hardware assessment needs to have two perspectives. First, can your current platforms meet your needs for Win2K/Exchange 2000? Second, should you investigate new technologies such as 8-way processing and storage area networks (SANs)? I would rather plan now to deploy new technology than try to fit new technology in later as an afterthought.

The last assessment concerns your clients. Client considerations drive many organizations. You need to decide what your default client will be for Win2K/Exchange 2000. Will you upgrade everyone to Windows 2000 Professional (Win2K Pro) and Outlook 2000? If you decide to use existing clients, what's required to integrate them into the new environment? In addition, is the time right to move from Messaging API (MAPI) to Internet protocol-based clients? Performing these assessments upfront will prevent significant pain later.

The final step is deploying Exchange 2000. How will you migrate your existing Exchange users to Exchange 2000? You have two basic approaches: Upgrade your Exchange 5.5 servers (in-place strategy), or move users from Exchange 5.5 servers to Exchange 2000 servers (move-user strategy). Neither strategy is right or wrong (I prefer the move-user approach), and you should try both in a test environment to see which fits your organization best. You also must plan your public folder content at this time. Finally, you must address issues with other services such as SMTP or NNTP.

How soon can you get to a native Win2K/Exchange 2000 environment? How will you deploy your administrative and routing groups for Exchange 2000 in light of your current Exchange 5.5 site design? Be sure you have a complete plan in place before you begin deploying Exchange 2000. You can use the steps I've covered over the past several weeks as a rough map. Take these steps into consideration along with your organizational requirements and begin your Exchange 2000 planning today.