Preparing to Install Exchange 2003

After a solid Windows 2000/Windows 2003 infrastructure has been put in place, Exchange 2003 can be planned for implementation. The installation preparation process follows standard project methodology, which includes planning, prototype testing, implementing, and ongoing support.

Planning Your Exchange 2003 Installation

Chapter 1, "Exchange Server 2003 Technology Primer," covers the differences between the Exchange 2003 Standard Edition and the Enterprise Edition, and why an organization would choose one version over the other for a server. Chapters 4, "Exchange Server 2003 Design Concepts,"and 5, "Designing an Enterprise Exchange Server 2003 Environment," of this book address the planning and design of an Exchange 2003 implementation for a small/medium versus a medium/large organization, respectively.

Choosing to Install Exchange in Either a Test or Production Environment

When installing Exchange 2003 for the first time, the organization should make the decision whether the implementation will be exclusively a test environment implementation, or whether the test will be simply a preinstallation of a future production environment. It is typically suggested to have the first implementation of Exchange 2003 be one of building a completely isolated test environment.

Having a test environment isolates test functional errors so that if there are any problems in the testing phase, they will not be injected into the existing networking environment. Any decision to move forward or hold back the implementation of Exchange will not change the impact the decisions have for the organization.

Many times when an organization begins to install Exchange as if it is a test environment, it loads an evaluation copy of the Windows or Exchange license on a low-end hardware system. Then because it has so much success from the initial tests, the organization puts the system into a production environment. This creates a problem because the system is built on expiring licenses and substandard hardware. When committed to being solely a test environment, the results should be to rebuild from scratch, and not put the test environment into position as a full production configuration.

Prototyping Your Exchange 2003 Installation

When the decision is made to build in a test or production environment, build Exchange 2003 in the expected environment. If the system will be solely a test configuration, the implementation of Exchange 2003 should be in an isolated lab. If the system will be used in production, the implementation of Exchange 2003 should be focused on building the appropriate best-practice server configuration, which will give the organization a better likelihood of a full production implementation success.

Some of the steps an organization should go through when considering to build a test Exchange environment include

• Building Exchange 2003 in a lab

• Testing email features and functions

• Verifying design configuration

• Testing failover and recovery

Much of the validation and testing should occur during the test process. It's a lot easier testing a disaster recovery rebuild of Exchange in an exclusively test environment than to test the recovery of an Exchange server for the first time during a very tense server rebuild and recovery process after a system crash. Additionally, this is a good time to test application compatibility, as covered in Chapter 17, "Compatibility Testing for Exchange Server 2003," before migrating to a full messaging environment and then testing to see whether a third-party fax, voicemail, or paging software will work with Exchange 2003.

Another item to test during the prototype testing phase is directory replication in a large multisite environment to ensure that the Global Catalog is being updated fast enough between sites. And of course, security is of concern for many organizations these days, and the appropriate level of security for the organization should be tested and validated . Many times the plan for securing mailbox or public folder access sounds great on paper, but when implemented, is too limiting for the average user to get functionality from the service. Slight adjustments in security levels help minimize user impact while strengthening existing security in the organization.