May, 2008

Microsoft Exchange Hub Transport Role

The hub transport server role handles all e-mail flow inside the organisation, applies journaling policies, and delivers messages to the recipient’s mailbox. This role is similar to the bridgehead server in an Exchange 2000/2003 organisation. In fact it originally was called the Bridgehead Role until it was changed. The Hub server must be deployed in every Active Directory site that contains other Exchange server 2007 roles.

The Hub Transport server role stores all its configuration information in Active Directory. This information includes (as mentioned above) transport rules settings, journal rule settings, and connector configurations. Because this information is stored in Active Directory, you can configure settings one time, and then those settings are applied by every Hub Transport server in the organization.You can install the Hub Transport server role on the same hardware with any other non-clustered internal server role or on a server that is dedicated to the Hub Transport server role. You must deploy a Hub Transport server role in each Active Directory site that contains a Mailbox server role. Deploying more than one Hub Transport server per site provides redundancy if a server fails. When you install more than one Hub Transport server in an Active Directory site, the connections are distributed.The Hub Transport server, as well as the rest of the server roles, is installed on member server(s) in an Active Directory domain. There is no need for ADAM on this, or any other role aside from the Edge Transport. Because it is a member of an AD domain, all its configuration information is stored in AD and any other Hub Transport servers you install will get their configuration from AD.

CLICK TO ENLARGE

Mailbox, Client Access, Unified Message and Hub Transport can be installed in any combination on one physical server. This combined topology is well-suited for small and medium size customers. Alternately, administrators can segment these roles across multiple servers, potentially located in different domains and sites to support a large number of users or meet geographical deployment requirements. Note that if Mailbox role is installed on different physical server from Hub Transport and Client Access role, the Mailbox server will need to have at least one Hub Transport and Client Access server available in the Mailbox server’s AD site.Microsoft actually recommends that you do not backup hub transport servers in the traditional manner. This is primarily because of the transient nature of the messaging queues. Suppose for a moment that you made a backup of the hub transport server, and 15 minutes later the server failed catastrophically. It wouldn’t really do you any good to restore the database used by the message queues, because all of the messages that were in the queues at the time that the backup was made would have already been delivered.Not only is it not necessary to backup the message queues, you really don’t have to worry about backing up the server’s configuration either. The vast majority of the configuration information is stored in Active Directory.

Microsoft Exchange Performing an Edge Synchronization

OK so lets say now we have installed Exchange 2007 in a way that will allow it to perform the edge transport server role. The problem is that right now, the server is completely isolated. It is not a member of an Active Directory domain, nor is it aware of the existence of your Exchange Server organization. We need to configure Exchange in a way that will allow communications between the edge transport server and the rest of the Exchange Server organization without actually making the edge transport server a part of the organization.

To do this, we must create an edge synchronization. An edge synchronization is essentially a one way trust relationship. The edge transport server trusts the Active Directory, but the Active Directory does not trust the edge transport server.

Creating an edge synchronization involves creating an XML file that contains pertinent information about the edge transport server. This information is then imported into the Active Directory, to make the Active Directory aware of the edge server s existence.

Before I show you how to perform the edge subscription, I need to warn you about a couple of things. First, creating an edge synchronization overwrites anything that you have manually configured on the edge transport server. Specifically, the following objects and types of information are overwritten:

• Accepted Domains
• Message Classifications
• Remote Domains
• Send Connectors
• The Server s InternalSMTPServers list of TransportConfig Objects

Once you implement the edge synchronization, Exchange will also configure itself so that you can t use the Exchange Management Shell to configure any of these types of objects on the edge transport server. This is a security precaution designed to prevent scripting attacks. You will still be able to manage the server through the Exchange Management Console though.

Ok let s create the edge subscription. To do so, we need to begin by creating an XML file that can be used for the subscription process. To do so, open the Exchange Management Shell, and enter the following command:

• New-EdgeSubscription file C:\subscription.xml

When you enter this command, Exchange will display a warning….Press Y, and Exchange will create the edge subscription file (named subscription.xml) and place it in the server s root directory.

Now, copy the XML file that you just created to removable media, and delete the file from the edge server. Deleting the file is extremely important for security reasons. Finally, insert the removable media into your hub transport server, so that you can create the edge subscription.

You can complete the process by opening the Exchange Management Console and navigating through the console tree to Organization Configuration | Hub Transport. Now, click on the New Edge Subscription link, found in the Actions pane. When you do, Exchange will launch the New Edge Subscription Wizard. The wizard prompts you for the name and path of the subscription file that you created earlier. Once you supply this information, verify that the Automatically Create a Send Connector for this Edge Subscription check box is selected, and then click the New button and we are done.

Microsoft Exchange Edge Subscription Process

This post provides information about Edge Subscriptions and the EdgeSync synchronization process. Edge Subscriptions are used to populate the Active Directory Application Mode (ADAM) directory service instance on the Microsoft Exchange Server 2007 Edge Transport server role with Active Directory directory service data.

If you have been following these posts you will see from this extract that ADAM has a role.

The computer that has the Edge Transport server role installed doesn’t have access to the Active Directory directory service. All configuration and recipient information is stored in the Active Directory Application Mode (ADAM) directory service

The Edge Subscription Process

Creating an Edge Subscription establishes secure, automatic replication of information from Active Directory to ADAM. The Edge Subscription process provisions the credentials that are used to establish a secure Lightweight Directory Access Protocol (LDAP) connection between Hub Transport servers and a subscribed Edge Transport server. The Microsoft Exchange EdgeSync service that runs on Hub Transport servers then performs periodic one-way synchronization to transfer data to ADAM and keep that data up to date. This process reduces the administration that you must perform in the perimeter network by letting you perform required configuration on the Hub Transport server role and then write that information to the Edge Transport server.

You subscribe an Edge Transport server to an Active Directory site. Subscribing the Edge Transport server to the Active Directory site enables the Edge Transport server to receive updates to ADAM from Active Directory and creates a synchronization relationship between the Edge Transport server and the Hub Transport servers deployed in that site. The Edge Subscription process also creates an Active Directory site membership affiliation for the Edge Transport server. The site affiliation enables Hub Transport servers in the Exchange organization to relay messages to the Edge Transport server for delivery to the Internet without having to configure explicit Send connectors.

One or more Edge Transport servers can be subscribed to a single Active Directory site. However, an Edge Transport server cannot be subscribed to more than one Active Directory site. If you have more than one Edge Transport server deployed, each server can be subscribed to a different Active Directory site. Each Edge Transport server requires an individual Edge Subscription. A subscribed Edge Transport server can support only one Exchange organization.

In my next post I’ll talk about the process itself..

Exchange 2007 Edge Transport Agents

 In my last post you would have noticed that Exchange 2007 comes with additional protection in the form of agents. Maybe someone at Microsoft is a big fan of the Matrix I dont know. But i briefly wanted to cover agent roles on the Edge Server…

Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they are processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow.
Edge Transport Rules

Edge Transport rules are used to control the flow of messages that are sent to or received from the Internet. The Edge Transport rules help protect corporate network resources and data by applying an action to messages that meet specified conditions. These rules are configured for each server. Edge Transport rule conditions are based on data, such as specific words or text patterns in the message subject, body, header, or From address, the spam confidence level (SCL), or attachment type. Actions determine how the message is processed when a specified condition is true. Possible actions include quarantine of a message, dropping or rejecting a message, appending additional recipients, or logging an event. Optional exceptions exempt particular messages from having an action applied.

Address Rewriting

You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2007 organization. You configure the Address Rewriting agent on the Edge Transport server role to enable the modification of the SMTP addresses on inbound and outbound messages. Address rewriting is especially useful when a newly merged organization that has several domains wants to present a consistent appearance of e-mail addresses to external recipients.

Edge Rules Agent

The Edge Rules agent, which runs on the Edge Transport server, helps you control the number of unwanted messages that enter your organization. If your internal network is compromised, the Edge Transport rule agent can also apply the same or different rules to outgoing messages. In this manner, the Edge Rules agent helps you prevent infected or unwanted messages that are generated by infected computers in your internal network from leaving your organization. The following list provides some examples of when the Edge Rules agent can help you protect your organization:

Virus outbreaks   Thousands of new viruses are created each year. Most antivirus software providers are reactive when they update their software. To update their software, antivirus software providers have to identify the virus, create an update for their software, and then send the update to their customers. This causes a gap in protection where an infected message can enter an organization unexpectedly.

Denial of service attacks   Malicious individuals who want to do harm to organizations may use denial of service (DoS) attacks to draw attention to themselves or to cause damage. These attacks are typically unannounced and can be difficult or impossible to predict.

The Edge Rules agent is designed to help you reduce the impact of each of these risks. The Edge Rules agent lets you configure conditions and exceptions to identify both unwanted and wanted messages and to act on those messages by using configured actions.

Anti-Spam and Antivirus Scanning

In Exchange 2007, the anti-spam and antivirus features provide services to block viruses and spam, or unsolicited commercial e-mail, at the network perimeter. Most viruses use spam-like tactics to gain access to your organization and to entice users to open an e-mail message. If you can filter out most of your spam, you are also more likely to capture viruses before they enter your organization.

Spammers use a variety of techniques to send spam into your organization. Servers that run the Edge Transport server role help prevent users in your organization from receiving spam by providing a collection of agents that work together to provide different layers of spam filtering and protection. Establishing tarpitting intervals on connectors makes e-mail harvesting attempts ineffective.

The Sender ID agent

The Sender ID agent relies on the RECEIVED Simple Mail Transfer Protocol (SMTP) header and a query to the sending system’s domain name system (DNS) service to determine what action, if any, to take on an inbound message.

When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited e-mail messages that enter the organization.

Sender ID is intended to combat the impersonation of a sender and a domain, a practice that is frequently called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message.

Spoofed mails typically contain a From: address that purports to be from a certain organization. In the past, it was relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL FROM: header, and in the RFC 822 message data, such as From: “Michael Smith” Michael@mydomain.com, because the headers were not validated.

Microsoft Exchange Edge Transport Server Role

 Note: In pre-release versions of Microsoft Exchange Server 2007, the Edge Transport server role was referred to as the Gateway server role.

Since the Edge Transport Server Role is a transport role for messages you can’t benefit from it to provide your colleagues with Outlook Web Access, Outlook Mobile Access, Outlook Voice Access, Outlook Everywhere or one of the other nifty “road warrior” features Exchange 2007 provides to more easily work together. In this scenario you need a Microsoft Exchange Server 2007 box with the Client Access Server Role applied to it. Although enhancements were made to Client Access Servers security the face-off between security and functionality remains.

Exchange 2007 introduces a new concept to Exchange organizations, the concept of server roles. Similar to how a Windows server can host one or more roles, this type of configuration has been implemented in Exchange Server 2007.

In Exchange 2007, the Edge Transport server role is deployed in your organization’s perimeter network as a stand-alone server or as a member server of a perimeter-based Active Directory domain. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow, which provides Simple Mail Transfer Protocol (SMTP) relay and smart host services for the Exchange organization. Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they are processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow.

The computer that has the Edge Transport server role installed doesn’t have access to the Active Directory directory service. All configuration and recipient information is stored in the Active Directory Application Mode (ADAM) directory service. To perform recipient lookup tasks, the Edge Transport server requires data that resides in Active Directory. EdgeSync is a collection of processes that are run on a computer that has the Hub Transport server role installed to establish one-way replication of recipient and configuration information from Active Directory to the ADAM instance on an Edge Transport server. The Microsoft Exchange EdgeSync service copies only the information that is required for the Edge Transport server to perform anti-spam configuration tasks and the information about the connector configuration that is required to enable end-to-end mail flow. The Microsoft Exchange EdgeSync service performs scheduled updates so that the information in ADAM remains current.

You can install more than one Edge Transport server in the perimeter network. Deploying more than one Edge Transport server provides redundancy if a server fails. You can load-balance SMTP traffic to your organization between Edge Transport servers by defining more than one mail exchange (MX) resource record with the same priority in the Domain Name System (DNS) database for your mail domain. You can achieve consistency in configuration between multiple Edge Transport servers by using cloned configuration scripts. Additionally, an Edge Transport server template is provided for use with the Windows Server 2003 Service Pack 1 Security Configuration Wizard to help configure Windows Server 2003 at the appropriate role-based security level.

Microsoft Exchange Server Roles 2007

 Exchange Server 2007 introduces real server roles. As you might have read Exchange Server 2007 offers the following roles: In the next posts I’ll be discussing in detail the role each plays….

• Edge Transport Server Role

• Client Access Server Role

• Hub Transport Server Role

• Mailbox Server Role

• Unified Messaging (UM) Server Role

Exchange Server Front and Back-ends.

I currently running a Front –end / Back-end scenario in a DMZ and have been for two years. It’s worked well… but has been compromised so it’s not full proof, although that was down to other circumstances. The Front-end / Back-end configuration is available in both Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 and the basic principal is to divide server roles. The distinction is made between a front-end server that accepts requests from clients and then proxies them to an appropriate server for processing, making this effectively a Back-end server.

Scenarios

• According to the Microsoft documentation a Front-end / Back-end scenario comes to play when you experience or foresee experiencing performance, scalability or security issues with Microsoft Exchange:

Performance

• From a performance point of view you can deploy Front-end servers to lift the burden of SSL securing your Outlook Web Access (OWA) and Outlook Mobile Access (OMA), POP3 and IMAP from your Back-end server. Blocking Unsolicited Bulk E-mail (UBE or Spam) at the Front-End might speed up your Back-end to Outlook clients connected to the Back-end server.

Scalability

• From a scalability point of view you can use the configuration to make a neat Network Load Balanced (NLB) cluster of Front-end servers. Don’t use Clustering Services though to scale your Front-end servers, it won’t work.

Security

• Despite the performance and scalability improvements you can gain from implementing a Front-end / Back-end configuration you cannot use it by itself in any security scenario. Encrypting traffic with IPSec, Using the Security Configuration Wizard in Windows Server 2003 SP1 and even pinning down RPC ports will get you far, but in my opinion not far enough.

  In my opinion the security design flaw in the current Front-end / Back-end configuration is you actually install a fully fledged Exchange Server, which you afterwards strip of its databases and configure to relay everything to the back-end Exchange Server. It stays an Exchange Server however, which needs access to the Active Directory, DNS and other Exchange Servers. If you implement your Front-end server inside a DMZ you’ll be required to open up a whole lot of UDP and TCP ports, eventually rendering your DMZ pretty useless if the box gets compromised.

Yes I’m knocking it and Yes it works. In my next post I’ll look at the new flavours from Exchange Server2007