The Edge Transport Server Role
The Edge Transport server role is new to Exchange 2007. It sits at the network perimeter and acts as an SMTP proxy, which shields back-end Exchange servers from the Internet, and it also performs a variety of message hygiene tasks prior to those messages being placed into the transport pipeline and ultimately into users' mailboxes.
In their native form, Edge Transport servers are compatible only with other Exchange 2007 servers. Edge Transport servers use a completely different architecture than any other type of Exchange server. Although Exchange is typically dependant on AD, an Edge Transport server isn't even a member of a domain. Instead, it contains an application partition that's populated with a small subset of AD information, which it gets by performing an Edge Synchronization with a Hub Transport server.
Because an Edge Transport server must be able to communicate with a Hub Transport server, it isn't generally well suited to be the only Exchange 2007 server in an Exchange 2003 organization. However, you can make an Edge Transport server work with an Exchange 2003 organization if you're willing to sacrifice recipient lookup, safe list aggregation, and the various domain security features. You can find step-by-step instructions for this type of deployment in the Microsoft article "How to Deploy an Edge Transport Server in an Existing Exchange Server 2003 Organization." Although this technique works, you need to have at least one Exchange 2007 server on the back end to get the full benefit of an Edge Transport server.
The Unified Messaging Server Role
The rules for cross compatibility are pretty cut and dried when it comes to unified messaging (UM). Essentially, UM works only if there's a Client Access server and a Hub Transport server in the same AD site as the UM server. More importantly, UM isn't compatible with Exchange 2003 mailboxes. You can still install a UM server even if you have legacy Exchange servers in your organization, but you won't be able to enable Exchange 2003 mailboxes for UM.
Routing Groups
Routing groups and administrative groups are major architectural elements in Exchange 2003 but have been discontinued in Exchange 2007. What really confuses a lot of administrators is that existing routing groups and administrative groups are still accessible through ESM. Furthermore, Exchange 2007 creates its own routing group and administrative group for backward compatibility, and these groups are also visible through ESM. Fortunately, ESM uses version control to prevent you from editing some Exchange 2007–specific objects to help you avoid corrupting those objects.
Microsoft designed Exchange 2007 without routing groups because the developers felt that routing groups were redundant. In the vast majority of cases, Exchange routing groups mimicked AD site structure. Because so much of Exchange's configuration information is stored in AD anyway, Microsoft made the decision to use direct server-to-server SMTP routing, and to fall back on AD site topology for routing should a Hub Transport server be unavailable. This system provides the benefit of easier discovery across the organization.
As I already mentioned, though, routing groups are still visible through ESM. As Figure 1 shows, a coexistence environment has at least two different routing groups present. One of these routing groups is named First Routing Group, and the other is named Exchange Routing Group (DWBGZMFD01QNBJR).
As you probably know, every Exchange 2003 organization contains at least one routing group. When you install the first Exchange 2007 server in a legacy Exchange organization, Setup automatically creates a routing group specifically for Exchange 2007 servers. This routing group's name is Exchange Routing Group (DWBGZMFD01QNBJR). If you take all of the letters in the long string of seemingly random characters and roll them forward one position (D becomes E, W becomes X, etc.), the characters spell EXCHANGE12ROCKS.
So why does Setup create a routing group if Exchange 2007 doesn't use routing groups? Exchange 2007 doesn't require routing groups if it's operating in an organization consisting solely of Exchange 2007 servers. However, routing groups are an absolute requirement for Exchange 2003 organizations, so Exchange 2007 creates a routing group that it can use solely to get along with Exchange 2003 servers in coexistence scenarios.
The most important thing to know about the Exchange 2007 routing group is that it's not an ordinary routing group. It's intended for use only with Exchange 2007 servers. Remember that ESM is an Exchange 2003 management tool and is therefore unaware of the specialized nature of the Exchange 2007 routing group. ESM sees the Exchange 2007 routing group the same way it sees any other routing group. It will let you move Exchange 2007 servers into Exchange 2003 routing groups and vice versa. However, Microsoft doesn't support mixing Exchange 2007 and Exchange 2003 servers within a common routing group. Likewise, Microsoft doesn't support renaming the Exchange 2007 routing group.
Administrative Groups
Administrative groups exist in Exchange 2003 as a way of controlling which parts of the Exchange organization a particular administrator is allowed to manage. Microsoft has done away with this method of delegation in Exchange 2007 in favor of a more granular delegation model.
To see how administrative delegation works in Exchange 2007, open EMC and select the Organization Configuration container. Click the Add Exchange Administrator link located in the Actions pane to launch the Add Exchange Administrator wizard, which Figure 2 shows. You'll be given the opportunity to assign one of several different administrative roles to a user or a group, and then to choose which Exchange servers the administrative role assignment applies to. Table 1 lists the specific functions of each of the roles. It's important to remember that an administrator can be assigned multiple administrative roles.
In a way, administrative groups behave similarly to routing groups in that administrative groups have been discontinued from Exchange 2007, but a special administrative group named Exchange Administrative Group (FYDIBOHF23SPDLT) is created in mixed organizations for backward compatibility. In fact, you can see this administrative group in Figure 1.
Just as you could not safely move an Exchange 2007 server into an Exchange 2003 routing group, you should also avoid moving an Exchange 2007 server into an Exchange 2003 administrative group and vice versa. Furthermore, Microsoft doesn't support renaming the Exchange 2007 administrative group. There's an interesting TechNet article that talks about some of the problems that can occur when you move an Exchange 2007 server out of its designated administrative group. The article is "Exchange 2007 server object has been moved to a different administrative group."
Master Mixed Mode
As you've seen, Exchange 2007 has no trouble coexisting with Exchange 2003 and even Exchange 2000. However, there are some compatibility and management issues that you'll have to take into account any time you're operating a mixed-mode environment. I hope these tips will help you master your mixed-mode monster.