Solution provider takeaway: Solution providers who are confused about Microsoft Exchange 2007 deployment and design can learn how to address hardware requirements, Active Directory considerations and role selection.
With any Exchange deployment there are a few key factors that will require attention. Everything from hardware to high availability has to be established before you install the first server for your customer. That's not to say Exchange 2007 cannot grow -- it certainly can and it's quite flexible. But the key to the growth of your customer's messaging infrastructure rests in providing a strong foundation from the outset. Here's how to build that foundation when you deploy Exchange.
If your customer plans on deploying Exchange in a pristine environment that doesn't have a pre-existing messaging infrastructure, you will have a lot to plan but quite a bit of freedom. If, on the other hand, your customer has a legacy Exchange environment, you have to consider how you will transition over to Exchange 2007 and how long the Exchange 2000/2003 and 2007 environments will coexist. (Note: Exchange 5.5 is so architecturally different from 2007 that it is no longer even possible to perform the transition. Exchange 5.5 is in the same category as Lotus Domino and Novell Groupwise, which require a migration process.)
It's important to remember that Exchange 2007 doesn't have an in-place upgrade process. It requires 64-bit hardware and a 64-bit OS, which wasn't required in previous versions of the platform.
The Active Directory connection
With legacy Exchange environments (Exchange 2000 and 2003), the Active Directory (AD) schema required an update so that certain objects could be created with attributes that weren't previously defined in the existing schema. Aside from that, however, the actual AD infrastructure wasn't too great a concern, because administrative and routing groups were utilized to control the permission sets and flow of messages.
With Exchange 2007, confidence is completely placed in the AD infrastructure. To ensure that your customer's environment is ready for Exchange deployment, you need to make sure replication between sites and domains is performing optimally. There's a tendency on the part of administrators to use their own manual site topology links, but there's a better way: Windows Server's Knowledge Consistency Checker. It monitors the physical connections between sites and subnets and establishes a site replication topology with costs based on connection speeds and bandwidth utilization.
Another important step before deploying Exchange for your customer is to ensure that every site has at least one global catalog server. From an Exchange perspective, these assist in the sending and receiving of mail, so it's best to keep one in every site to facilitate the process. You also want to make sure that your customer's Schema Master domain controller is running Server 2003 with Service Pack 1 or later (or Server 2008). Servers running Exchange should also be Server 2003 with Service Pack 1 or later (or Server 2008). Raise the domain functional level to native mode as well as the Exchange Organizational level to native mode.
Exchange configuration checks
Once you're confident that your customer's AD is honed, your next step in the Exchange deployment is determined by the size of the organization and/or the policies in place. In a small environment, such as one where you will be installing a single Exchange server, you can perform the installation through the setup GUI process, and all of the underlying Active Directory schema, domain and configuration changes will be made at the same time.
In an environment that is somewhat larger (multiple sites and domains) or one that has a policy requiring that installations of this sort be handled in stages, run the Setup.com command with switches that you can run one at a time. These switches, including /PrepareLegacyExchangePermissions and /PrepareSchema, ensure the smallest impact on your customer's environment with each step. Keep in mind that simply running the /PrepareAD switch with the setup program will make all the necessary changes (so that it is not necessary to run the other two switches). Your next step is to run the /PrepareDomain or /PrepareAllDomains switches to configure permissions.
While you might think you are ready to deploy Exchange for your customer, there is a tool you can run to really ensure that their environment is prepared -- the Exchange Best Practices Analyzer. This tool will scan the directory and configuration environment and provide feedback that highlights any errors you might need to address before deployment, or it might simply provide you with informational warnings about things it sees. Make sure you have the latest version of the tool.
Before you actually install Exchange, you need to determine if you're going to perform a typical installation or a custom installation. The typical installation includes three main roles -- mailbox, Client Access server (CAS) and Hub Transport (HT) server -- plus the management tools for Exchange. A custom solution enables you to choose individual roles, including the unified messaging role, install an Edge Transport (ET) server, or even prepare for a high-availability solution through mailbox active/passive clustering.
To deploy the roles properly, you should have a solid understanding of what each role provides:
- CAS: This role is similar to the front-end server for the Exchange 2000/2003 infrastructure and provides connections to a mailbox through Outlook Web Access (OWA), ActiveSync for Mobile devices, Outlook Anywhere, POP and IMAP support.
- ET: This is not a part of Active Directory (and cannot be installed with any other role), but it resides on the perimeter of the network using Active Directory Application Mode (ADAM) as its underlying directory and synchronizes with the HT servers on the internal network. Its purpose is to provide additional security and antivirus and antispam capabilities to your customer's messaging organization. ET is a recommended but not required role.
- HT: HT is similar to the Bridgehead server of Exchange 2000/2003 -- all mail coming in and out of your customer's organization goes through the HT role. Transport rules established on the HT role allow your customer to control mail while in transit.
- Mailbox (MB): MB hosts mailbox databases and public folder databases. Ordinarily, you can install the MB role with other roles on a single server (with the exception of ET) unless you plan on using cluster services to provide some of the high-availability options within Exchange.
- Unified Messaging (UM): This provides VoIP with your customer's mailbox. Email, voicemail and incoming faxes can all come to inboxes. End users can check the messages and calendar through multiple access interfaces (phone, email or Web browser). For this to work, you will need a telephony expert for the installation and configuration of the telephony infrastructure (or the reconfiguration of your customer's existing infrastructure). You may have a legacy PBX that will work with a VoIP gateway, or you can purchase a new IP-PBX.
About the author
J. Peter Bruzzese, MCSE, MCT, MCITP: Messaging, is a regular contributor to Redmond Magazine and Windows IT Pro. He has also written several books, including Tricks of the Microsoft Windows Vista Masters (Que 2007). He writes a monthly article titled "Exclusively Exchange for Realtime Publishers" and provides free Exchange training at www.exclusivelyexchange.com. Peter is also the co-founder of ClipTraining.com, which provides a screencast training library to clients as well as custom screencasts for internal training to users.