Advanced Coverage for Experienced Exchange Administrators
Microsoft Exchange Server 2003 24seven doesn't try to take you back to square one. Instead, it builds on the knowledge you've already earned. Expert Jim McBee with assistance from Barry Gerber delivers targeted instruction and inside tips that will help you follow the best practices established by successful Exchange organizations across a wide range of industries. This is also a great way to make a smooth transition to the latest release of Exchange Server.
- Getting your Exchange installation right the first time
- Managing interactions with Active Directory
- Understanding Exchange data storage
- Preventing and recovering from disasters
- Administering daily operations
- Customizing Exchange
- Optimizing performance
- Achieving higher availability
- Isolating and solving common Exchange problems
- Troubleshooting SMTP and DNS problems
- Improving security against viruses and worms
- Securing clients
- Deploying and customizing Outlook web access
- Supporting mobile clients
About the Author
Jim McBee, MCSE and MCT, is a consultant based in Honolulu, Hawaii. He specializes in Exchange deployments and education and has worked for many Fortune 500 customers, as well as the U.S. Department of Defense. He is the author of Exchange 2000 Server 24seven, Exchange 5.5 24seven and co-author of Cabling: The Complete Guide to Network Wiring.
Barry Gerber, contributing author and author of Mastering Exchange Server 2003, shares his extensive real-world experience in easy-to-understand language in this administrator's guide to Microsoft's messaging and collaboration server.
Read an Excerpt
Microsoft Exchange Server 2003 24seven
By Jim McBee
John Wiley & SonsISBN: 0-7821-4250-8
Chapter OneIntroducing Exchange 2003 and Exchange Administration
74 percent of the business people surveyed recently believed that losing e-mail service presents more of a hardship than losing telephone service.
- META Group survey (metagroup.com)
When compared to Windows NT and Exchange 5.5, Windows 2000 and Exchange 2000 were revolutionary products. Everything from architecture and functionality to management interfaces changed drastically. The learning curve from the earlier to the later Microsoft operating and messaging systems was quite steep. On the other hand, compared to Windows and Exchange 2000, the 2003 versions are much more evolutionary than revolutionary products. If you know Windows and Exchange 2000, you will have little difficulty adapting to the 2003 flavors. You're going to welcome the evolutionary changes in Windows and Exchange 2003 with open arms. These changes will improve your end users' experiences and will make your administrative tasks easier. I will look at some of these changes in this chapter.
In order to manage Exchange Server 2003 successfully, you need to understand its various components. You need to know what executables run the components, what the components do, and to some extent how they do what they do. Finally, you need to know how components depend on each other and on various Windows services. Understanding these concepts will make it easier for you to perform day-to-day management tasks and put you in a much better position to troubleshoot problems that arise. A major portion of this chapter is devoted to Exchange components.
Exchange Server 2003 comes in two editions: Standard and Enterprise. The Enterprise Edition offers greater capacity, clustering, and more protocol support. I will try to help you better understand the two editions and the features of each so you can make cost-efficient decisions about the software that supports your Exchange and Windows 2003 systems.
If you have older Windows and Exchange installations, you have to decide how to get to Windows and Exchange 2003. You can upgrade or do a fresh install of the two products on new hardware and then move Exchange objects to the new server or servers. If your first thought is to upgrade existing servers, you've come to the right place. I'm going to try very hard in this chapter to talk you out of that approach. First and foremost, Exchange 5.5 cannot be directly upgraded to Exchange 2003.
Once your Windows and Exchange 2003 systems are up and running and you've eliminated earlier OS and Exchange versions, you have the option of switching them to native mode. Native mode offers a number of very useful enhancements, but sometimes for a variety of reasons you can't zap those old servers and "go native." I will try to help you deal with this dilemma later in this chapter.
A successful Exchange 2003 deployment hinges on many elements; these include a strong dependency on Windows 2003 Active Directory (AD), Windows 2003 Internet Information Server (IIS), a properly configured DNS (Domain Name Service) infrastructure, sufficient and reliable hardware, and good operational practices. Your Exchange 2003 installation will have serious problems unless you have a good understanding of not only Exchange 2003, but also Windows 2003, AD, and DNS. Like Exchange 2000, Exchange 2003's destiny is much more intertwined with Windows 2003 than versions 5.5 and earlier of Exchange. A basic understanding of the Exchange 2003 architecture and deploying Exchange 2003 on the proper hardware platform will also be crucial to your success.
One of the most important parts of deploying any Exchange system is making design decisions that relate to supporting your organization. This includes choosing the right edition of Exchange 2003 Server, deciding how to best store your data, maintaining time synchronization, setting reasonable standards (Active Directory, Exchange performance, user space allocation, etc.), and picking the right hardware. Placing your Exchange 2003 system on appropriately sized and configured hardware will also help to keep you happy and safe from end-user lynch mobs.
Finally, providing your user community with good documentation, notification, and training will help to minimize your administration woes. Most experienced Exchange administrators will tell you that educating their users, keeping them informed, and managing their expectations are some of the most powerful tools in their operations arsenal.
Yet perhaps first and foremost, essential tools to have in your bag of tricks are solid operational practices that will help reduce the likelihood of downtime and improve the recoverability from disasters- and help keep you sane. One particularly wise Exchange guru once said his secret to Exchange success was the following:
* Perform daily backups of Exchange.
* Check the event logs.
* Make sure the server does not run out of disk space.
* Check the queues.
* Then leave Exchange alone.
Although I elaborate on this in a lot more detail in Chapter 6, "Daily and Long-Term Operations," successful Exchange server administration and management strategies have not changed since Exchange was first released.
So, is that all there is to say about Exchange administration? If so, why have volumes of information been written about it, and why am I writing more? The answer is simple: We all benefit from shared experiences. Combine that with the fact that software documentation and training do not always make matters crystal clear, and you have good reasons for a book about skillfully maintaining Exchange.
What's New in Windows and Exchange 2003?
Windows 2003 includes improvements in Active Directory: easier deployment and management, increased security, and better performance and dependability. Additionally, overall security has been strengthened and support for applications that run on Windows 2003 has been significantly updated. Security improvements are a two-edged sword. Although they better protect everything in your Windows and Exchange environment, you and your users' first encounter with them is likely to come as a bit of a shock. For example, by default, Windows 2003 implements strong password requirements. Passwords must be of a specific length and must include uppercase and lowercase letters as well as numbers. All those three- and four-letter passwords won't cut it any more-at least if you don't change the defaults, which isn't all that easy.
Improvements on the Windows 2003 storage side, so important to smooth and reliable Exchange Server operations, include snapshot backups of disk volumes, system-level open-file backup and much easier Storage Area Network (SAN) management. On the networking side, Windows Server 2003 supports IPv6 for increased security and a solution to the rapid depletion of Internet Protocol (IP) addresses.
Together Windows and Exchange 2003 include a great new way to connect MAPI clients such as Outlook 2003 to Exchange servers over Internet-based connections. Until Exchange 2003, such connections required the use of the Windows RPC protocol either directly over TCP/IP or RPC-TCP/IP encapsulated in virtual private network packets. Use of direct RPC-TCP/IP became a major problem as many corporations and ISPs closed off port 135, the port that supports RPC, to protect against a variety of RPC-based attacks on Microsoft servers. Exchange 2003 supports RPC encapsulated in HTTP. This approach uses the same port 80 that is used for browsing the Web. You need Windows 2003, Exchange 2003, and Outlook 2003 running on Windows XP clients to pull all of this off, but RPC-over-HTTP solves a problem that has plagued Outlook-to-Exchange public network connectivity since the two products came on the market.
Exchange 2003 also includes something for wireless clients. The wireless client-server synchronization functionality of Microsoft Mobile Information Server, an add-on to Exchange 2000 Server, is now part of Exchange 2003. This allows all those wireless Pocket PC PDAs running around out there to seamlessly sync with Exchange inboxes, calendars, and contacts without user intervention.
Exchange 2000 used storage groups to hold both private and public e-mail and other items. This has not changed with Exchange 2003. However, 2003 brings a new kind of storage group to the table, recovery storage groups. You can use these to restore all or part of an Exchange mailbox or public folder store, without having to overwrite an existing store or create a new regular mailbox or public folder store. Exchange 2003 is set for maximum security on installation, rather than depending on administrators to figure out what they need to do to secure Exchange. Outlook Web Access (Internet browser access to Exchange mailboxes) is not only more secure, but it looks and feels more like Outlook 2003. The Exchange 2003 antivirus application programming interface (API) supports more virus and spam catching options. Wireless access to Exchange Server 2003 is greatly improved when compared to Exchange 2000 options. Migration to Exchange Server 2003 from Exchange 5.5, or Exchange 2000 for that matter, has been greatly simplified with the addition of the Exchange Deployment Tools.
A few features of Exchange 2000 Server were removed from Exchange Server 2003. These include real-time collaboration features, automatic mapping of the M: drive, and Key Management Services.
Real-time collaboration features such as chat, Instant Messaging, Exchange Conferencing Server, and OWA Multimedia Messaging are gone. Some of these features will work if you upgrade from Exchange 2000 Server, but if you need these features for new installations of Exchange 2003, you'll have to install Microsoft's new real-time communications and collaboration server called the Microsoft Live Communications Server 2003 (formerly known as Greenwich or the Real Time Communications Server).
The default M: drive mapping gave you file system-based access to the Exchange Information Store. By and large, it was more trouble than it was worth, leading to corruption of the mailbox store when file-based operations such as backup were performed. You can still access the Information Store through the file system, but you have to enable it in the Registry.
Key Management Services supported sending secure messages through Exchange Server by allowing certificate issuance to Exchange users and key escrow. That feature is now fully supported by Windows Server 2003's Public Key Infrastructure. Therefore, Key Management Services are no longer required.
Major Exchange 2003 Components
If you want to understand how Exchange 2003 works, you first need to get comfortable with the major Exchange components and the executable files that support them. It also helps to understand how the Exchange executables depend on each other and on key Windows 2003 components.
When you know the executables and dependencies, you can more easily manage the components and undertake certain kinds of troubleshooting. Here are a few examples:
* Exchange components cannot function if the Exchange System Attendant is not running.
* Many Exchange components are dependent on the Exchange Information Store.
* The Windows SMTP and NNTP services must be running before Exchange components are able to start up.
An Overview of Exchange Components
Table 1.1 presents a list of major Exchange components and the executable files associated with them. The table is designed to provide you with a brief introduction to the components. The sections that follow fill in the details for each of the components.
The System Attendant
The Exchange System Attendant is essentially the general manager of the Exchange server. It is the first Exchange service that starts and the last one that shuts down. Although a novice might actually think that this service performs few, if any, useful functions, it actually is responsible for a lot of odd yet important jobs. Some of the tasks that the System Attendant runs include:
* Performing offline address book generation.
* Running the DS2MB (Directory Service to Metabase) update process to keep the IIS Metabase in sync with the information in Active Directory.
* Generating proxy addresses for X.400, SMTP, and other address types based on the defined Exchange 2003 recipient policies.
* Emulating the Exchange 5.5 directory service through a process called DSProxy for MAPI clients prior to Outlook 2000 that cannot receive referrals.
* Passing referrals for Outlook 2000 and later clients that need to be referred to a Global Catalog server for querying address information.
* Running the Recipient Update Service to make sure that AD objects are included in the appropriate address lists.
* Running the DSAccess cache, which caches information about AD objects. This cache is available for Exchange 2003 to query rather than querying the AD directly for each lookup request.
* Inserting data into and managing the message tracking logs.
Note The System Attendant's process name is MAD.EXE; this is short for either Mailer Administrative Daemon or the Monitoring and Administration Daemon, depending on who you ask.
The Information Store
The current Information Store database engine is called ESE98 (Extensible Storage Engine). More information on the database engine and storage technology is in Chapter 4, "Understanding Exchange 2003 Data Storage."
Exchange breaks down storage into either public or private Information Stores. All mailbox data is stored in a mailbox store (private Information Store), while all public folder data is stored in a public folder store. These stores each have two separate components, an EDB file and an STM file.
Note A MAPI (Messaging Application Programming Interface) client is any client that sends and reads messages where the message properties are defined as MAPI properties. MAPI clients include the original Exchange client, Outlook 97/98/2000/2002 and Outlook 2003.
The EDB file is called the MAPI store. This is a rich, hierarchical property store; messages sent by MAPI clients are stored here. Therefore, all messages stored here have MAPI properties associated with them.
The STM file is not nearly as structured as the EDB file. Messages are not converted to MAPI messages when they arrive, but instead are stored in their native format (typically MIME). This includes messages sent by SMTP clients. However, the EDB file does contain a list of all messages stored in each folder, so certain MAPI properties for messages in the STM file are promoted to the EDB file. To improve performance, the STM file data is accessed through a kernel-mode device driver called ExIFS; a Windows Explorer extension that uses this device driver also allows the entire store to be accessible through the file system.
Note By now, you have probably seen the term "web store" or "web storage system" used (or overused) in technology media. The web store is not actually a single database but a technology for providing access to data through HTTP/DAV or the ExIFS.
Figure 1.1 illustrates two examples of message storage, a MAPI message and a MIME message.
The first message shown in Figure 1.1 is sent by a MAPI client such as Outlook 2003. The client designates most of the message's MAPI properties, and the client sends the message to the Exchange server; the message transport and the store may also set some of the message properties. The Information Store saves the entire message in the EDB file.
The second message is formatted by a client such as Outlook Express as a MIME message. The Internet Mail Service in Exchange 5.5 would have converted this message, but the Advanced Queuing Engine in Exchange 2003 simply passes it along to the Information Store in its native format. The Information Store determines that the message is in native format, and then "promotes" certain properties of the message header (such as the To, From, Subject, and Date information) to MAPI properties, and finally stores this information in the EDB file along with a "pointer" that points to the message body and attachments in the STM file. Technically, there are three separate phases of property promotion: The initial properties are promoted when the message is sent to the server by the client, the second set when the messages is accessed, and finally if the content is changed by a MAPI client.
Note In a pure MAPI environment with no SMTP connectivity to the outside world, your STM files will hardly grow in size at all. In an environment with all POP3 and IMAP4 clients, the STM file will grow significantly while the EDB file will hardly increase in size.
Content Conversion on Demand
The obvious question now is "What happens if a MAPI client reads a message that was sent to the Exchange server via SMTP and is formatted as a MIME message?" Simple. The Information Store retrieves the message into memory on the Exchange server and performs an "on-the-fly" conversion. The message is not converted in the STM file, merely in the copy in memory. The message is saved as a MAPI message only if a MAPI client modifies the message. If the message contains an attachment but the attachment is not modified, then it is not moved into the EDB data file.
The same holds true of a message that was sent by a MAPI client but is now being retrieved by a non-MAPI client such as Outlook Express. The Information Store converts the message on-the-fly to a MIME or non-MIME message and passes it on to the client.
Excerpted from Microsoft Exchange Server 2003 24seven by Jim McBee Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Part 1: Building a Foundation.
Chapter 1: Introducing Exchange 2003 and Exchange Administration.
Chapter 2: Windows Dependencies and Platform.
Chapter 3: Active Directory and Exchange 2003.
Chapter 4: Understanding Exchange 2003 Data Storage.
Chapter 5: Best Practices and Disaster Prevention.
Part 2: Operations.
Chapter 6: Daily and Long-Term Operations.
Chapter 7: Tweaking Operations.
Chapter 8: Keeping an Eye on Exchange 2003 Usage.
Chapter 9: Improving Performance.
Chapter 10: Recovering from Disasters.
Chapter 11: Clustering and Other Stories of High Availability.
Chapter 12: Public Folders.
Chapter 13: Server Troubleshooting.
Part 3: Connectivity.
Chapter 14: SMTP and Message Routing.
Chapter 15: Connectivity Within Your Organization.
Chapter 16: Internet Connectivity.
Part 4: Exchange 2003 Security Issues.
Chapter 17: Securing Exchange Server 2003.
Chapter 18: Securing Message Content.
Chapter 19: Exchange and Firewalls.
Part 5: Exchange Clients.
Chapter 20: Supporting MAPI Clients.
Chapter 21: Deploying Outlook Web Access.
Chapter 22: Going WirelessOutlook Mobile Access.