Exchange Queue & AEdge and Hub Transport Roles, Virtual Machines, and More

KC Lemson and Nino Bilic

In the May 2007 installment of Exchange Queue & A, we talked about the problems with storing .pst files on network shares. The Windows Server performance team recently started a blog and they discussed

this topic in all its gory, gooey technical detail, so we wanted to pass along the link. Now let’s get to the questions.

Q Am I required to deploy the Edge server role if I want to deploy Microsoft Exchange Server 2007?

A No, you are not required to deploy Edge in order to deploy Exchange Server 2007. You can have a single machine running the core server roles (such as mailbox, client access, and hub transport) accepting Internet e-mail for your domain and running anti-spam and anti-virus programs.

Q What are the differences between the Edge and Hub Transport server roles? What do I miss out on if I don’t deploy Edge?

A The primary purpose of the Hub role is to route mail within the organization and to apply business policies to those messages. With the Hub role, transport rules are based on Active Directory® objects—users, distribution lists, and so forth. The Hub role also lets you add disclaimers to messages or to journal messages sent to groups of users because you’ll probably want to base those rules on Active Directory membership. For example, you might want to journal all messages sent to DLOfUsersOnLitigationHold or add disclaimers to outbound mail sent by DLOfMembersOfLegalTeam. Although it is possible to run anti-spam agents on the hub server, they are not enabled by default so you’ll need to install them manually by running the install-antispamagents script available in the \scripts directory on the server.

The primary purpose of the Edge role is to route mail into and out of the organization as well as perform message hygiene (anti-spam, anti-virus, content or attachment filtering, and so on) on those messages. The anti-spam functionality is enabled out of the box when you install an Edge server. One of the unique features of the Edge role is that there is no requirement for it to be joined to a Windows® domain—it can be run on a standalone Windows Server® installation that is not part of a Windows domain, but Edge can still be managed as part of the Exchange 2007 organization in your corporate forest.

This is particularly advantageous in a perimeter network where you may want the server to be in a workgroup, or you may have a separate forest explicitly for machines in the perimeter network. Conveniently, Edge servers deployed in this situation can perform all message hygiene and routing for mail between the corporate network and the Internet, while still being managed in a manner that is consistent with the rest of Exchange 2007 systems administration.

On an Edge server, transport rules are based on SMTP addresses, not Active Directory objects—but of course you can use the SMTP addresses of DLs or users in your Active Directory. For the most part, the Edge transport rules are a subset of the Hub transport rules, the exception being the quarantine action, which is only available on Edge servers.

Edge servers also have some functionality exposed through agents that are not available on the Hub transport server: attachment stripping and address rewrite. Attachment stripping is the ability to selectively remove potentially dangerous attachments with extensions such as .exe and .com. The address rewrite agent allows you to rewrite the headers of e-mail so that although your domain and default SMTP proxy addresses on user accounts might be @contoso.com, for example, messages outbound to the Internet will appear to come from @northwindtraders.com. Also, Edge servers only perform routing based on domain or address space, so if you share the same SMTP address space between Exchange and another e-mail system, you’ll need to either perform that routing on the Hub server or do it in concert with the address rewrite agent on the Edge server.

Another important consideration is whether or not an Exchange 2007 server is directly Internet facing (whether that be the Hub or Edge server role). In other words, are connections to port 25 on your domain’s MX record connected to Exchange 2007 in some fashion? You may already have an SMTP gateway, virus wall or other solution in place on the Internet that is accepting mail for your domain and then passing it along to Exchange inside the corporate network. If you deploy Edge or Hub servers to be Internet-facing, then you can take advantage of one of the niftiest features of Exchange 2007: safelist aggregation. With safelist aggregation, users who add senders to their safe list in Microsoft Outlook® (which they typically do for Internet newsletters or e-mail from retailers) will get those lists securely propagated to the Edge or Hub roles so that messages from those senders will bypass the content filtering. Of course, one user’s spam is another user’s valued newsletter, so the safelist aggregation happens on a per-user basis. You can read more about how this works in the Exchange 2007 documentation.

If you do end up with a deployment in which a server running with the Hub role is accepting Internet e-mail for your domain, there are a few things to keep in mind. Of course, first make sure that you have a good firewall or port filtering solution in place so that your server is only receiving connections on the necessary ports, such as port 25. Also remember that you’ll need to install the anti-spam agents because they are not installed or enabled by default. Because the Hub server’s most common deployment scenario is within the corporate network, it does not allow anonymous connections out of the box—you’ll need to check the AnonymousUsers permission group on the port 25 receive connector. You’ll also want to ensure that you enable safelist aggregation and schedule it to run periodically so that as users update the safelists on their mailboxes, mail to those users from their safe senders lists bypasses content filtering. More details are available on our blog.

The following code shows an AT command that updates all mailboxes daily at 11:00 P.M. on all the servers by using a batch file that is named SafeList.bat:

at 23:00 /every:M,T,W,Th,F,S,Su cmd /c 
“D:\SafeList.bat”

This code shows the contents of the SafeList.bat file:

“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe” 
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command 
“get-mailbox | where {$_.RecipientType 
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”

If you need to verify that your settings are working properly, more information can be found in the Exchange 2007 documentation.

Q After I boot my Virtual PC image with Exchange on it, I keep having problems related to contacting the directory or LDAP server. Telnetting to 389 works and all services are running. Why is this?

A I had this problem myself last year at Tech•Ed. I had a copy of a Virtual PC on my laptop that I’d copied from a machine at work, and I was planning on using it to do demonstrations for members of the press who were publishing articles coinciding with the launch of Exchange 2007 Beta 2 the following month.

I’d done a million demos of the product and knew the build was solid, so I didn’t prepare extensively. You can imagine the sweat on my forehead when I booted up my Virtual PC on Monday morning, just hours before the first meeting, and every part of my build insisted it couldn’t contact a domain controller. Thanks to the high concentration of super-smart folks in the cabana, we were able to figure it out quickly.

The problem I had in the Tech•Ed debacle was the result of running Virtual PC on my super-slow laptop. At the root of the problem was a race condition with DNS and Active Directory. The DNS server on the image was configured to be integrated with Active Directory, but due to the sequence in which the services on the image were loaded (and the, shall we say, lack of zippiness of my laptop), the necessary directory services hadn’t started up by the time the DNS server tried to contact Active Directory.

This situation can happen on any server that has DC and Exchange on the same machine (it does not have to be a virtualized image), but it’s far more likely to occur in a virtualized environment where there’s an extra slowdown—particularly with a not-too-beefy laptop like mine.

I have also seen a similar problem happen with Virtual PC images that are copied between two machines, especially when one of those machines is on a different network. If this has happened to you, check the IP address of the OS in the image; it may have a stale IP address from the old network. Refresh it to get an IP from the new network and see if that helps.

To avoid these kinds of problems in the future, one alternative is to make the DNS server on the guest not be Active Directory-integrated as well as install DNS on both the host and the guest. Have the guest forward to the host for unknown records and have the host forward to its appropriate DNS server for unknown records as well. When your image boots and tries to update the DNS records, it will be less prone to failure.

Q It seems like Exchange 2007 setup is quite different than setup in earlier versions of Exchange. How does this thing work?

A Yes, indeed, there are several stages of Exchange 2007 setup. Here is a general overview of how the whole process works.

When you first run setup.exe, a process launches that gives you the links for most of the prerequisites that you need to install before you begin installation of actual server roles. Once you have installed all of those prerequisites, the Install Microsoft Exchange link becomes available for you to click on (see Figure 1).

Figure 1** Installation link available after general prerequisites are met **

If you ran setup.exe from the network and you clicked on the Install link, core setup files will be copied into the %TEMP%\ExchangeServerSetup\ folder on the local machine. The setup wizard then launches.

Setup wizard will walk you through the various choices such as license agreement, error reporting, and installation type (where you get to pick server roles you want to install). Wizard pages will vary based on the presence and state of the current Exchange organization (if any).

After that is complete, setup will run a readiness check—really a tweaked version of the Microsoft Exchange Server Best Practices Analyzer (BPA), which, by default, will connect to the Internet to download the latest prerequisite XML file. That presents an opportunity to update the prerequisites periodically or address any issues that the Exchange team has learned about since the product shipped. When the prerequisite check is complete, you will have a chance to review the results and continue; otherwise you will see any issues that you might need to address before continuing with setup. If your server fails a prerequisite check, the wizard will let you retry the check in most cases.

Once the prerequisite check has passed, you will actually get the Install button that will let you start the installation of any roles that you have chosen previously. Only the files for roles that you selected will be copied and installed.

At the very end of setup, you will get a chance to launch the Exchange Management Console as well as apply any Exchange 2007 updates that might be available.

KC Lemson is the User Experience Manager for Exchange Server. Her online banking account has been temporarily suspended.

Nino Bilic is a Supportability Program Manager for Exchange Server. He recently added a secondary e-mail address to his credit card.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.