|< Day Day Up >|| |
Electronic messaging has ceased being a novelty and is considered mission critical for most enterprises. Competitive pressure requires a nonstop flow of communication using electronic mail (e-mail). When the e-mail environment is not operating properly, work slows (or stops), information is delayed, and money is lost.
The choices made during deployment of Exchange affect the monitoring, management, and administrative options that are available afterward. Administrative procedures should be planned during the design and planning stages of the project. Successful Exchange management begins before the first Exchange server is installed and continues throughout the life of the messaging system. Proactive and consistent management is the key to maintaining a successful messaging environment.
Messaging system architects and designers spend considerable time carefully selecting and configuring the hardware and software. Exchange implementations require equally careful planning for system management, administration, and monitoring to reduce messaging downtime and to improve troubleshooting. Yet monitoring, management, and administration are often an afterthought, although it is estimated that the cost of the hardware and software is far less than the lifetime cost of managing the messaging environment. Keeping Exchange servers operational requires discipline and some well thought out management practices.
A good understanding of Microsoft Exchange Server 2003 is necessary before plans for Exchange system management, administration, and monitoring can be developed. A key element of this is understanding the relationship and dependencies between Exchange and the underlying operating system.
Just as the design decisions made during Exchange deployment affect your management options, the Windows design and management decisions may influence or constrain the implementation strategies that can be used to effectively and efficiently support Exchange.
Microsoft completely redesigned Exchange when they introduced Exchange 2000 Server. Exchange 2003 does not represent this order of architectural change. With Exchange 2003, Microsoft built on the same architecture they introduced with Exchange 2000. Microsoft's design goals for Exchange 2000 were different than previous releases and these differences provided new choices for how to design and implement your support infrastructure, how to monitor and manage messaging traffic, and how to avoid disaster through proactive planning and management. You should understand Microsoft's design goals for Exchange 2000, because they also apply to Exchange 2003.
If you are still managing an Exchange 5.5 environment, you may be tempted to simply continue using your existing management practices.
However, after reviewing the differences between Exchange 5.5 and Exchange 2000/2003, you will understand that too much has changed and that the previous management practices are obsolete. Exchange 2000 was a major redesign. The underlying architecture is completely different from Exchange 5.5, the interaction between components is different, and many of the management tools are different. You must understand these differences to effectively monitor, manage, and troubleshoot your Exchange servers, messaging connections, and interoperability with foreign mail systems.
This chapter will provide you with the basic prerequisite knowledge about Microsoft's design goals, the differences between Exchange versions, and the relationship between Windows and Exchange. Understanding these topics is essential for making the critical decisions required to successfully manage Exchange.
Exchange 2000 was a major change from previous releases of Microsoft Exchange Server. This version of Exchange included an abundance of new features and functions. However, Exchange 2000 was much more than new features and functions, it was a major technology refresh. Exchange 2000 was even more tightly integrated into the underlying operating system than its predecessors. The basic architecture had been redesigned with many previous architectural components disappearing and new ones emerging to play key roles. These architectural changes allowed for more flexibility and provided the platform for future product growth. These changes greatly influenced the design principles used for deploying Exchange and also influenced the day-to-day management of any Exchange messaging system.
It probably would be fair to characterize the typical Exchange 5.5 environment as a reasonably large (1,000 to 100,000 users) organization with users in multiple locations. Exchange 2000 continued to focus on this type of environment. However, Microsoft increased its focus to target two new types of customers: departments at the low end of the user population range and Internet Service Providers at the high end of the user population range.
To satisfy the needs of these new types of customers, Microsoft implemented architectural and functionality changes to improve scalability, reliability, and availability. Microsoft improved Exchange's use of clustering technology with a goal of achieving the type of high availability (typically 99.999%) required by Internet Service Providers.
Exchange 2000 also improved access and integration with Internet Information Server, greatly increasing Exchange's support for Internet protocols and standards. For the most part, Microsoft chose not to focus on proprietary mechanisms. Instead, most new functionality was implemented with Internet protocols such as HTTP and Simple Mail Transfer Protocol (SMTP)/ MIME. These changes were largely to prepare the way for Exchange 2000 to become the next generation web and application server.
The new functionality included tools to support unified messaging, including streaming media and multimedia form factors. Although Exchange 2000 did not provide full-featured unified messaging, it did provide the underlying functionality and interfaces to allow third-party developers to deliver unified messaging.
|< Day Day Up >|| |