Wow. Long blogging break! My apologies for letting time go by; we’ve been busy.
As we’ve been getting hands-on experience with Exchange 2007, I’ve discovered a couple of tips that might be waiting to ambush unsuspecting single-system Exchange administrators. Without further ado, here’s some crunchy Exchange 2007 goodness.
Tip #1: Make sure you have an SMTP connector defined on your Exchange 2003 server.
By default, Exchange 2000 and Exchange 2003 don’t configure an SMTP connector, and many single-server/single-site admins don’t bother to create an SMTP connector. You don’t need one in order to send mail to the Internet; by default, every Exchange 2000/2003 SMTP virtual server will do the necessary DNS lookups to deliver extra-organizational mail directly, unless an SMTP connector with the appropriate address space and scope exists. So far, so good, right? Well, Exchange 2007 is a bit different. Thanks to its new role-based architecture, the Hub Transport role does all the message routing inside of the organization.
When you install a new HT role (and for a single-server upgrade, you’ll probably have the Mailbox, Hub Transport, and Client Access roles on your single server), it comes out of the box with a minimal set of SMTP connectors — just enough to send and receive authenticated SMTP from other Exchange 2007 servers in the organization. Since you can’t do an in-place upgrade from Exchange 2003 to Exchange 2007, you have to deploy Exchange 2007 on a separate box, and then you have to define a Routing Group connector between your Exchange 2007 server and your Exchange 2003 server. And once you do, you may find that suddenly you’re not sending any mail outside of your organization any more.
Let’s follow the chain of events:
- The existing Exchange 2003 server is in its own administrative group and routing group. With no SMTP connector in the org, it sends outbound mail according to the configuration of the SMTP virtual server (which uses DNS by default).
- The new Exchange 2007 server installs into a new administrative group and routing group. (These groups are used by all further Exchange 2007 servers, but since we’re not installing any, that’s a moot point.)
- The new Exchange 207 Hub Transport role has a default SMTP receive connector and a default SMTP send connector, both of which are set to only exchange SMTP traffic with other authenticated Exchange 2007 servers in the org.
- You create, according to the docs, a Routing Group Connector between the Exchange 2003 server/RG and the Exchange 2007 server/RG.
- Now, suddenly, the Exchange 2003 server has a routable SMTP connector with the default address space (“*”) in the org. It therefore follows designed behavior and stops sending external message directly, instead queuing them up through the RGC to the new Exchange 2007 server. Since the new server isn’t configured to send external mail directly yet, the messages start piling up in its queues.
The fix is simple: either create the outbound SMTP send connector on the Exchange 2007 server before you create the RGC, or create an SMTP connector on your Exchange 2003 server before you create the RGC. Which option you pick depends on what you’re trying to accomplish.
Tip #2: If you are using HTTP, IMAP, or POP3 protocol access in Exchange 2003, you will suddenly be in a FE/BE situation when you install Exchange 2007.
A single-server Exchange 2003 box can easily server out RPC over HTTPS, OWA, Exchange ActiveSync, and other client protocols without requiring you to have a separate front-end server. But once you introduce that Exchange 2007 Client Access Server role, you’ve unknowingly switched to an effective FE/BE architecture. If you’re planning on having the two versions co-exist for a while, you’ll have to make the corresponding changes to your Exchange 2003 machine.
What kind of changes am I talking about? Well, take HTTP protocol access — OWA, EAS, RPC over HTTPS. You’ve been a good admin and deployed them under SSL. Now you’ve got an Exchange 2007 server for a time of co-existence, and you’d probably like to continue to have a single defined set of URLs until you’ve moved all the mailboxes off of Exchange 2003. It’s not simply a matter of migrating certificates and re-pointing your publishing rules, because while an Exchange 2007 CAS can talk to Exchange 2003 BE servers, an Exchange 2003 FE cannot talk to Exchange 2007 mailbox servers. If you want one machine to handle all incoming traffic, it has to be the Exchange 2007 machine
While the Exchange 2007 CAS role seems to be just a new name for a front-end server, that’s not really the case. The FE server architecture in Exchange 2000/2003 was never a required configuration; it was there to make your life as an admin easier by reducing the number of Exchange servers that had to be directly exposed to incoming connections from the Internet (this is in the pre-ISA days). The FE/BE architecture gives you URL consolidation, as well as performance wins and an easier path to hardening. The Exchange 2007 CAS, though, is a required part of the 2007 architecture. It handles a lot of key pieces of functionality, and while it can do the FE job when talking to an Exchange 2003 mailbox server, it isn’t “just” a front-end server.
So, the minute you decide to use the Exchange 2007 CAS role to access your Exchange 2003 mailboxes, you now have a problem. Exchange 2007 is going to mimic the functionality of a FE server — and one of the big limitations in the FE/BE architecture is that you can’t use SSL to secure FE/BE communications. Your single Exchange 2003 server is blithely running along using SSL. In order to get it working with the Exchange 2007 CAS, you have to disable SSL on the Exchange 2003 server.