Configuring the Network Settings for the Cluster nodes

When you start the servers that are to be the nodes in the cluster, start by naming the machines E2K7Node1 and E2K7Node2 or whatever naming scheme you want to use (these names have nothing to do with the Exchange server name which your clients will be configured to connect to later on). Now name the two network connections Public and Private for the external and the internal network respectively (remember to do this on both nodes).

Figure 1: Network Connections Click Advanced > Advanced Settings, if its not already the case, make sure Public is listed first on the binding order list, then Private and lastly Remote Access Connections.

Figure 2: Binding order Also make sure you untick File and Printer Sharing for Microsoft Networks for the Private network connection.

Figure 3: Disabling File and Printer Sharing for Microsoft Networks Configure the Public network with the respective network settings you use in your test environment.

Figure 4: Configuring the Public network Configure the Private network with an IP address and a subnet mask. Nothing else is required since this network is only used for communication (heartbeats) between the nodes in the cluster.

Figure 5: Configuring the Private network Now click Advanced then select the DNS tab. Here you should untick both Register this connection's addresses in DNS and Use this connection's DNS suffix.

Figure 6: Configuring DNS settings for the Private network Click the WINS tab. Untick Enable LMHOSTS lookup and select Disable NetBIOS over TCP/IP.

Figure 7: Configuring WINS settings for the Private network Click OK three times and close the network connections window. Now add both Windows 2003 Servers as member servers in your Active Directory test domain.

Creating and Configuring the Windows 2003 Server Cluster

Now that the two servers are ready to act as nodes in a Windows 2003 cluster, its time to create the actual Windows 2003 Server Cluster. In order to do so logon to E2K7Node1 with a Domain admin account, then click Start > Administrative Tools > Cluster Administrator, and select Create new cluster in the drop-down box. Now click OK.

Figure 8: Creating a new cluster Note You can also open a command prompt and type Cluster.exe /create /wizard in order to start the cluster wizard. Click Next.

Figure 9: Cluster Wizard Specify the domain name as well as the cluster name (name for the Windows 2003 cluster NOT the Exchange cluster name which the clients will connect to), then click Next.

Figure 10: Cluster Name and Domain Type the name of the Windows 2003 server that is to be the first node in the cluster, in this case E2K7Node1, then click Next.

Figure 11: Adding the First Cluster Node Let the cluster wizard determine the cluster configuration and click Next. Note You can ignore the two warnings in Figure 12, since the nodes in a cluster continuous replication based mailbox server setup arent going to share the same disk subsystem.

Figure 12: Analyzing Cluster Configuration Now enter the IP address that the cluster management tools should use to connect to the cluster, in this case 10.10.1.216, then click Next.

Figure 13: Specifying the IP address the Cluster Management Tools should connect to Enter the credentials of the cluster service account (When speaking test environments Im often too lazy to create a specific cluster service account and instead tend to use the Administrator account which will have the appropriate permissions) and click Next.

Figure 14: Entering the credentials of the Cluster Service Account Now click Quorum and select Majority Node Set as the resource type, then click Ok and Next.

Figure 15: Proposed Cluster Configuration

Figure 16: Setting Majority Node Set as the Resource Type Now wait for the cluster to be configured, then click Next.

Figure 17: Creating the Cluster When the cluster has been completed successfully you can click Finish.

Figure 18: Cluster Wizard Successfully Completed

We now have a full working Windows 2003 cluster running, but since theres only one node its not very fault tolerant. So lets add the second Windows 2003 server too. We can do this by right-clicking E2K7Node1 in the left pane of the Cluster Administrator, then selecting New > Node as shown in Figure 19 below.

Figure 19: Adding a second node to the Cluster The Add Nodes Wizard will launch and you can click Next.

Figure 20: Add Nodes Wizard Enter the name of the server that is going to be the second node (in this case E2K7Node2), then click Next.

Figure 21: Entering the name of the second node Again let the Add Notes Wizard determine the cluster configuration, then click Next.

Figure 22: Analyzing Cluster Configuration

Enter the password for the cluster service account (in this case the Administrator account), then click Next.

Figure 23: Entering the password for the Cluster Service Account When you are verified, you want to add the second node to the cluster with the configuration shown in Figure 24, click Next.

Figure 24: Proposed Cluster Configuration for node 2 When the cluster has been configured properly without any errors or warnings, click Next.

Figure 25: Cluster is configured for the second node When the Add Notes Wizard has completed successfully, click Finish.

Figure 26: Completing the Add Nodes Wizard

The second Windows server is now part of the cluster as can be seen in Figure 27 below.

Figure 27: Cluster Administrator with two nodes In part one of this article series we went through the installation of the Windows 2003 cluster. In this second article well install the Windows components required by Exchange Server 2007 as well as configure the Majority Node Set (MNS) Quorum with File Share Witness. Finally well finish off by enabling and configuring the transport dumpster on the Hub Transport server in the Active Directory site.

Installing the necessary Windows Components

Before we move on and try to install the Exchange Server 2007 Beta 2 bits, we need to make sure the required Windows components have been installed. All types of Exchange Server 2007 installations (no matter what server role we're talking about) needs the Microsoft .NET Framework 2.0 component installed. Note If you have installed Windows Server 2003 Enterprise Edition with Service Pack 1 on the nodes, you need to download the Microsoft .NET Framework Version 2.0 Redistributable Package (x86), since its only a standard Windows component when speaking Windows Server 2003 R2.

Figure 27: Installing the Microsoft .NET Framework 2.0 Windows Component Since were installing the Mailbox Server role in the cluster, we also need to install the below IIS 6.0 components: Enable network COM+ access Internet Information Services World Wide Web Service

Note Remember to install these components on both cluster nodes.

Configuring the Majority Node Set (MNS) Quorum with File Share Witness
I bet some of you are thinking: What the heck is a Majority Node Set (MNS) Quorum with File Share Witness? And I understand why as this is a completely new type of quorum model, which is made available by installing the update (MS KB article 921181) mentioned in the beginning of this article series. The update makes it possible to make use of a file share witness that is external to the cluster as an additional "vote" to determine the status of the cluster in a two-node MNS quorum cluster deployment, which is a requirement in order to make use of the cluster continuous replication (or CCR in short) functionality in Exchange Server 2007. The file share for this file share witness can be located on any type of Windows Server in your environment, but best practice is to use an Exchange 2007 Hub Transport Server in

the Active Directory server site containing the nodes in the respective cluster. Well also use a Hub Transport Server in this article series. The first thing you need to do is to create the file share on the Hub Transport server. You can do this either via the CLI or by using the GUI. In this article well do so using the GUI. So log on to the Hub Transport server with a domain admin account, then open Windows Explorer and create a new folder called MNS_FSQ_E2K7CLUSTER on the C: drive or wherever you want it to be created.

Figure 28: Majority Node Set File Share Quorum folder Now take Properties for the newly created folder, and click Sharing.

Figure 29: Majority Node Set File Share Quorum Folder Share Click Permissions and configure the share permissions so only the Administrator (or the Cluster Service Account if created) are allowed access to the share.

Figure 30: Share Permissions for Majority Node Set File Share Quorum folder Click OK then select the Security tab.

Figure 31: Security permissions to the Majority Node Set File Share Quorum folder Here you should give Full Control to the local administrator and the domain administrator account or cluster service account. Make sure you untick Allow inheritable permissions from the parent to propagate to this object and all child objects when doing so, then click OK twice and log off the server. Back on E2K7Node1 you should set the Majority Node Set Private Property attribute to point to the file share we just created, we do so by opening a command prompt then issuing the following command: Cluster res Majority Node Set /priv MNSFileShare=\\EDFS03\MNS_FSQ_E2K7CLUSTER Note Make sure to replace server name so it matches the name of the Hub Transport Server in your environment. You will get a warning that all properties were stored but not all changes will take effect until the next time the resource is brought online, just like its shown in Figure 32 below.

Figure 32: Configuring the Majority Node Set on E2K7Node1 In order to force all changes to take effect, we will move the cluster group from one node to the other (will take the cluster group offline and online again). Do this using the below command: Cluster Group Cluster Group /Move When you have done so you will see that the cluster group is now online on E2K7Node2, as is the case in Figure 33 below.

Figure 33: Moving the cluster group from one node to the other Now lets verify the 7Priv property is set correctly, this can be done by issuing the below command: Cluster Res Majority Node Set /Priv As you can see in Figure 34 below, this property has been set correctly for the purpose of this article series.

Figure 34: Verifying the property of /Priv is set correctly

Configuring the Transport Dumpster

When using a CCR in your environment you should consider to configure the transport dumpster on the Hub Transport Server. Microsoft recommends that you configure the

MaxDumpsterSizePerStorageGroup parameter, which specifies the maximum size of the transport dumpster queue for each storage group, to a size that is 1.25 times the size of the maximum message that can be sent. For example, if the maximum size for messages is 10 megabytes (MB), you should configure the MaxDumpsterSizePerStorageGroup parameter with a value of 12.5 MB. In addition they recommend you configure the MaxDumpsterTime parameter, which specifies how long an e-mail message should remain in the transport dumpster queue, to a value of 07.00:00:00, which is 7 days. This amount of time is sufficient to allow for an extended outage to occur without loss of email. When using the transport dumpster feature, additional disk space is needed on the Hub Transport server to host the transport dumpster queues. The amount of storage space required is roughly equal to the value of MaxDumpsterSizePerStorageGroup multiplied by the number of storage groups. You use the Set-TransportConfig CMDlet to enable and configure the Transport Dumpster. So in order to, for example, configure the maximum size of the dumpster per storage group to 25 MB with a dumpster life of 10 days, you would need to run the following command:
Set-TransportConfig -MaxDumpsterSizePerStorageGroup 25MB -MaxDumpsterTime 10.00:00:00

In order to see the MaxDumpsterSizePerStorageGroup and MaxDumpsterTime configuration settings, you can type Get-TransportConfig as I did in the figure below.

Figure 35: Transport Configuration Settings

Installing the Active Clustered Mailbox Role on E2K7Node1

Its time to install the Exchange Server 2007 Beta 2 bits on each node, well start with E2K7Node1. First, if you havent already done so, I recommend you copy the Exchange Server 2007 Beta 2 binaries to a drive locally on each node. When you have done so double-click Setup.com.

Figure 36: Launching Exchange Setup The Exchange Server 2007 Installation Wizard will start, and as you can see Step 1: Install .NET Framework 2.0 and Step 2: Install Microsoft Management Console (MMC) have already been completed. Note If you have installed Windows Server 2003 with Service Pack 1 on each node, you need to download Microsoft Management Console (MMC) 3.0 and install it manually (by following the link in Step 2). But since Im using Windows 2003 R2 Servers in my test environment, the MMC 3.0 is installed by default.

Figure 37: Exchange Server 2007 Installation Menu As you can see we still need to complete Step 3: Install Microsoft Command Shell (MSH), before we can start installing Exchange. Therefore click the link to download MSH then unzip and install it.

Figure 38: Installing Microsoft Command Shell (MSH) The Exchange Server 2007 Installation Wizard should refresh automatically, so now click Install Microsoft Exchange. Click Next then accept the License Agreement and Next once again. Decide whether you want to enable Error Reporting or not (a good idea to enable this functionality since the Exchange Product Group will receive any obscure errors you should experience in your cluster setup) then click Next.

Figure 39: Enabling Error Reporting Now select Custom Exchange Server Installation then click Next.

Figure 40: Selecting a custom Exchange Server installation Tick Active Clustered Mailbox Role and click Next.

Figure 41: Selecting to install an Active Clustered Mailbox Role Now select Cluster Continuous Replication then specify a name for the mailbox server (the name you want your Outlook clients to connect to) and a unique IP address on your public network. Finally specify the path for the clustered mailbox server database files or use the defaults (as is the case in this article series) then click Next.

Figure 42: Selecting to install a Cluster Continuous Replication cluster and specifying name and IP address of the clustered mailbox server Let the readiness check complete, and if no issues are found click Next to begin the installation.

Figure 43: Exchange Server 2007 Clustered Mailbox Role Readiness Check The Exchange Server 2007 installation wizard will now copy the needed Exchange files, install and configure the Mailbox Role then finally create and configure the clustered mailbox server resources locally and create the object in Active Directory. When each step has been completed untick Exit Setup and open Exchange System Manager (yes this will be corrected in a later build), then click Finish. We dont want to open the Exchange Management Console just yet, well install Exchange on the second node first.

Installing the Passive Clustered Mailbox Role on E2K7Node2

Log on to E2K7Node2 with a domain admin account and do the exact same steps as we did when installing Exchange Server 2007 on E2K7Node1. Only difference is you should tick Passive Clustered Mailbox Role instead of Active Clustered Mailbox Role as shown in Figure 44 below.

Figure 44: Installing the passive clustered mailbox role on the second node

Verifying the functionality of the Cluster Continuous Replication based Mailbox Server
Its time to verify that our Exchange 2007 clustered mailbox server is working as expected. Lets first open the Cluster Administrator and check whether the respective Exchange Resources have been created. If you take a look at Figure 45 below it looks good, we have both nodes listed in the left pane and all Exchange resources have been created and are currently owned by E2K7Node2.

Figure 45: Listing all Exchange cluster resources in the cluster administrator Try to open the Exchange Management Shell by clicking Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell on one of the nodes, then type Get-ClusteredMailboxServerStatus Identity E2K7CCR. As you can see in Figure 46 below the status of the clustered mailbox server is Online, and E2K7Node2 is currently the active node.

Figure 46: Requesting the online status of the clustered mailbox server Now that we have verified the clustered mailbox server is online, lets try to move the Exchange resources from node one to node two using the MoveClusteredMailboxServer CMDlet. In the test environment used in this article, we do so by issuing below CMDlet:
Move-ClusteredMailboxServer -Identity:E2K7CCR -TargetMachine:E2K7Node1 -MoveComment:"This is a test!"

Youre then asked to confirm this action, type Yes then hit Enter. After a while the clustered mailbox resources will have been moved to the first node.

Figure 47: Moving the clustered mailbox resources to the first node Note Even though its possible to move the cluster resource groups between nodes using the Cluster Administrator console, you should always do so using the MoveClusteredMailboxServer CMDlet as the Move Group task in the Cluster Administrator console isnt Exchange 2007 aware. Let's also take a look at the clustered mailbox server in the Exchange Management Console. To do so click Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Console, then drill down do Server Configuration > Mailbox. Notice the clustered mailbox server which we named E2K7CCR is listed in the Result pane and that its recognized as a cluster server.

Figure 48: Viewing the clustered mailbox server in the Exchange Management Console Lets try to take a look at the transaction log file replay from one node to the other. The easiest way to do that is to generate a few log files by sending a couple of test messages with an attachment or two. Note Since the new transaction log file size in Exchange Server 2007 is 1 MB instead of 5 MB

as was the case in previous versions of Exchange. Its not required to attached files larger than 1 MB in order to generate these log files. As you can see in Figure 49 below, the log files were replayed to E2K7Node2 within the same minute as they were generated on E2K7Node1.

Figure 49: Log file replay

Simulating a failover from E2K7Node1 to E2K7Node2

Okay lets try to simulate a fail over from E2K7Node1 (which currently is the active node) to E2K7Node2, so that we can see what will happen from the Outlook client perspective. In order to switch from one node to the other well issue below CMDlet which we also used earlier on in this article:
Move-ClusteredMailboxServer -Identity:E2K7CCR -TargetMachine:E2K7Node2 -MoveComment:"This is a test!"

When a manual move or a failover occurs, the balloon shown in Figure 50 will appear as all services needs to be stopped on E2K7Node1 before they are brought online on E2K7Node2.

Figure 50: Connection to the Exchange Server has been lost Depending on the amount as well as size of the databases in your Cluster Continuous Replication setup, this will take somewhere between 10 seconds to approximately 1 minute, which shouldnt cause panic for the end-users. When E2K7Node2 has taken over, the end-users will be notified that the connection to the Exchange Server has been restored (Figure 51).

Figure 51: Connection to the Exchange Server has been restored

Installing the Exchange Server 2007 Single Copy Cluster

Its time to install the Exchange Server 2007 Beta 2 bits on each node, well start with E2K7SCCNode1. First, if you havent already done so, I recommend you copy the Exchange Server 2007 Beta 2 binaries to a drive locally on each node. When you have done so double-click Setup.com.

Figure 34: Launching Exchange Setup The Exchange Server 2007 Installation Wizard will start, and as you can see Step 1: Install .NET Framework 2.0 and Step 2: Install Microsoft Management Console (MMC) have already been completed. Note If you have installed Windows Server 2003 with Service Pack 1 on each node, you need to download Microsoft Management Console (MMC) 3.0 and install it manually (by following the link in Step 2). But since Im using Windows 2003 R2 Servers in my test environment, the MMC 3.0 is installed by default.

Figure 35: Exchange Server 2007 Installation menu As you can see we still need to complete Step 3: Install Microsoft Command Shell (MSH), before we can start installing Exchange. Therefore click the link to download MSH then unzip and install it.

Figure 36: Installing Microsoft Command Shell (MSH) The Exchange Server 2007 Installation Wizard should refresh automatically, so now click Install Microsoft Exchange. Click Next then accept the License Agreement and then Next once again. Decide whether you want to enable Error Reporting or not (a good idea to enable this functionality since the Exchange Product Group will receive any obscure errors you should experience in your cluster setup) then click Next.

Figure 37: Enabling Error Reporting Now select Custom Exchange Server Installation then click Next.

Figure 38: Selecting a custom Exchange Server installation Tick Active Clustered Mailbox Role and click Next.

Figure 39: Selecting to install an Active Clustered Mailbox Role Now select Single Copy Cluster then specify a name for the mailbox server (the name you want your Outlook clients to connect to) and a unique IP address on your public network. Finally, specify the path for the clustered mailbox server database files (the virtual shared database disk you created earlier on), then click Next. Note In order to set the path for the clustered mailbox server database files, its important the cluster group containing the shared disks is owned by E2K7SCCNode1. The reason for this is that you arent allowed to use the shared disks if the cluster group is currently owned by E2K7SCCNode2.

Figure 40: Selecting to install a single copy cluster and specifying name and IP address of the clustered mailbox server Let the readiness check complete, and if no issues are found click Next to begin the installation.

Figure 41: Exchange Server 2007 Clustered Mailbox Role Readiness Check The Exchange Server 2007 installation wizard will now copy the needed Exchange files, install and configure the Mailbox Role then finally create and configure the clustered mailbox server resources locally and create the object in Active Directory. When each step has been completed, untick Exit Setup and open Exchange System Manager (yes this will be corrected in a later build), then click Finish. We dont want to open the Exchange Management Console just yet, well install Exchange on the second node first.

Figure 42: Installation of the Exchange 2007 clustered mailbox role completed successfully Log on to E2K7SCCNode2 with a domain admin account and perform the exact same steps as we did when installing Exchange Server 2007 on E2K7SCCNode1. Only difference is you should tick Passive Clustered Mailbox Role instead of Active Clustered Mailbox Role as shown in Figure 43 below.

Figure 43: Installing the passive clustered mailbox role on the second node When you have installed the Exchange Clustered Mailbox Role on the second node, we can move on to the next section, where we verify that the functionality of the clustered mailbox server works as expected.

Testing the functionality of the Single Copy Cluster

Its time to verify that Exchange 2007 clustered mailbox server is working as expected. Lets first open the Cluster Administrator and check whether the respective Exchange Resources have been created. If you take a look at Figure 44, it looks good, we have both nodes listed in the left pane and all Exchange resources have been created and are currently owned by E2K7SCCNode1.

Figure 44: Listing all Exchange cluster resources in the cluster administrator Now try to open the Exchange Management Shell by clicking Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell on one of the nodes, then type Get-ClusteredMailboxServerStatus. As you can see in Figure 45 below the status of the clustered mailbox server is Online, and E2K7SCCNode1 is currently the active node. This just keeps getting better and better doesnt it?

Figure 45: Requesting the online status of the clustered mailbox server Now that we have verified that the clustered mailbox server is online, lets try to move the Exchange resources from node one to node two using the MoveClusteredMailboxServer CMDlet. In the test environment used in this article, we do so by issuing below CMDlet: Move-ClusteredMailboxServer -Identity:MailboxServer -TargetMachine:E2K7SCCNode7 -MoveComment:"Testing functionality!" Youre then asked to confirm this action, type Yes then hit Enter. After a while the clustered mailbox resources would have been moved to the second node.

Figure 46: Moving the clustered mailbox resources to the second node Note Although its possible to move the cluster resource groups between nodes using the Cluster Administrator console, you should always do so using the MoveClusteredMailboxServer CMDlet as the Move Group task in the Cluster Administrator console isnt Exchange 2007-aware. Lets also take a look at the clustered mailbox server in the Exchange Management Console. To do so click Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Console, then drill down to Server Configuration > Mailbox. Notice the clustered mailbox server which we named MailboxServer is listed in the Result pane and that its recognized as a cluster server. Also notice that the Mailbox Database for this server points to the S: drive exactly as we specified during the installation of the Active Clustered Mailbox Role.

Figure 47: Viewing the clustered mailbox server in the Exchange Management Console

Conclusion
As was also the case with Exchange Server 2003, Exchange Server 2007 provides high availability of server resources, as one node takes over should the active node for some reason fail. But bear in mind that a single copy cluster is susceptible to failure of the shared storage subsystem. This means that no matter how many nodes form part of your cluster, youll always have a single point of failure when using this type of cluster. If you want a cluster without a single point of failure, you should consider the other type of cluster supported in Exchange Server 2007 called Cluster Continuous Replication (CCR), which not only provides high availability of server resources, but also storage groups. Cluster Continuous Replication (CCR) combines a traditional active/passive cluster with the new log file shipping and reply mechanisms in Exchange Server 2007. Log file shipping and reply makes it possible to keep a replica of the production mailbox databases. In my next article series here on MSExchange.org, Ill take you through how to prepare for, install and last but not least verify the functionality of a Cluster Continuous Replication setup. Until then have a nice one!

Introduction
In the previous article in this article series covering how you prepare for, install and configure an Exchange Server 2007 Single Copy Cluster (or in short SCC) in a virtual server 2005 R2 test environment, we went through how to create the Windows 2003 cluster. In this part two well create and configure the Windows Server 2003 Cluster. I bet many of you are eager to get going, so lets start right away.

Creating the Windows Server 2003 Cluster

Okay now that we have the two virtual Windows 2003 Servers prepared, we can create the actual Windows 2003 cluster. In order to do so, turn off E2K7SCCNode2 then logon to E2K7SCCNode1 with a Domain admin account. Now click Start > Administrative Tools > Cluster Administrator, then select Create new cluster in the drop-down box and click OK (alternatively you can open a command prompt and type Cluster.exe /create /wizard).

Figure 15: Creating a new cluster

Click Next.

Figure 16: Windows 2003 Cluster wizard If its not already the case, specify the domain in which the two Windows 2003 Servers are members, then type the name of the cluster (the name clients will be connecting to), then click Next.

Figure 17: Specifying the domain and cluster name If its not already the case, type the name of the Windows 2003 Server, which will be the first node in the cluster, then click Next.

Figure 18: Specifying the name of the first cluster node The cluster wizard will now determine the cluster configuration, and after a while you should hopefully get a checkmark in each checked configuration step. We can now click Next.

Figure 19: Analyzing cluster configuration Now enter an IP address that cluster management tools will use to connect to the cluster, then click Next.

Figure 20: Specifying the IP address used by the cluster management tools You should now enter the cluster service account and password, then click Next.

Figure 21: Entering the username and password of the cluster service account

Note Since were installing the Windows 2003 cluster in a test environment, well use the administrator account. But please bear in mind that you should always create a dedicated cluster service account when speaking about production environments. You now see a screen with the proposed cluster configuration, click the Quorum button and make sure that the cluster configuration quorum is set to Disk Q. Then click Next.

Figure 22: Proposed cluster configuration The cluster will now be created, again you need to wait for each step to complete, then click Next > Finish.

Figure 23: Creating the cluster We have now created the cluster itself but since it only consists of one node, well need to add the other Windows server as well. In order to do so turn on E2K7SCCNode2 and login with a domain admin account. Now click Start > Administrative Tools > Cluster Administrator. Select Add nodes to cluster in the drop-down menu then specify the cluster name in the Cluster or server name box and click OK.

Figure 24: Adding a node to the cluster Click Next in the Add Nodes Wizard.

Figure 25: Add notes cluster wizard Type E2K7SCCNode2 (or whatever you named the second Windows server), then click Add and Next.

Figure 26: Specifying the second cluster node When the configuration has been analyzed click Next.

Figure 27: Analyzing cluster configuration

Enter the password for the cluster service account (in this case the administrator account), then click Next.

Figure 28: Entering the username and password of the cluster service account Verify that you want to add the node to the cluster with the configuration shown in Figure 29 below, then click Next.

Figure 29: Proposed cluster configuration After a short period the node would have been added to the cluster, if not you might want to expand the respective task as well as view the log. If each task has completed successfully, click Next > Finish.

Figure 30: Configuring the cluster with the second node Theres one last this you want to do before we move on and that is to right-click and select Properties for the Private network in the left pane in Figure 31 below.

Figure 31: Cluster administrator will cluster resources listed and online Since the sole purpose of the Private network is to be used for communications between the internal cluster nodes, you should select Internal cluster communications only

(private network), then click OK. Do the same for the Public network but set it to Client access only (public network).

Figure 32: Changing the cluster role for the private network Alright we now have a fully operational 2 node Active/Passive Windows cluster up and running.

Installing the necessary Windows Components

Before we move on and try to install the Exchange Server 2007 Beta 2 bits, we need to make sure the required Windows components have been installed. All types of Exchange Server 2007 installations (no matter what server role we're talking about) needs the Microsoft .NET Framework 2.0 component installed. Note If you have installed Windows Server 2003 Enterprise Edition with Service Pack 1 on the nodes, you need to download the Microsoft .NET Framework Version 2.0 Redistributable Package (x86), since its only a standard Windows component when speaking about Windows Server 2003 R2.

Figure 33: Installing the Microsoft .NET Framework 2.0 Windows Component Since were installing the Mailbox Server role in the cluster, we also need to install the below IIS 6.0 components: Enable network COM+ access Internet Information Services World Wide Web Service

Note Remember to install these components on both cluster nodes. Alright we have reached the end of part two. In the next, last part of this series, well go over the most exciting part, and that is to install Exchange Server 2007 and last but not least verify cluster functionality

Introduction
In the previous article in this article series covering how you prepare for, install and configure an Exchange Server 2007 Single Copy Cluster (or in short SCC) in a virtual server 2005 R2 test environment, we went through how to create the Windows 2003 cluster. In this part three well install Exchange Server 2007 and verify cluster functionality.

Since this is the part weve all been waiting for (where we finally install and play with Exchange Server 2007), lets get going.

Installing the Exchange Server 2007 Single Copy Cluster

Its time to install the Exchange Server 2007 Beta 2 bits on each node, well start with E2K7SCCNode1. First, if you havent already done so, I recommend you copy the Exchange Server 2007 Beta 2 binaries to a drive locally on each node. When you have done so double-click Setup.com.

Figure 34: Launching Exchange Setup The Exchange Server 2007 Installation Wizard will start, and as you can see Step 1: Install .NET Framework 2.0 and Step 2: Install Microsoft Management Console (MMC) have already been completed. Note If you have installed Windows Server 2003 with Service Pack 1 on each node, you need to download Microsoft Management Console (MMC) 3.0 and install it manually (by following the link in Step 2). But since Im using Windows 2003 R2 Servers in my test environment, the MMC 3.0 is installed by default.

Figure 35: Exchange Server 2007 Installation menu As you can see we still need to complete Step 3: Install Microsoft Command Shell (MSH), before we can start installing Exchange. Therefore click the link to download MSH then unzip and install it.

Figure 36: Installing Microsoft Command Shell (MSH) The Exchange Server 2007 Installation Wizard should refresh automatically, so now click Install Microsoft Exchange. Click Next then accept the License Agreement and then Next once again. Decide whether you want to enable Error Reporting or not (a good idea to enable this functionality since the Exchange Product Group will receive any obscure errors you should experience in your cluster setup) then click Next.

Figure 37: Enabling Error Reporting Now select Custom Exchange Server Installation then click Next.

Figure 38: Selecting a custom Exchange Server installation Tick Active Clustered Mailbox Role and click Next.

Figure 39: Selecting to install an Active Clustered Mailbox Role Now select Single Copy Cluster then specify a name for the mailbox server (the name you want your Outlook clients to connect to) and a unique IP address on your public network. Finally, specify the path for the clustered mailbox server database files (the virtual shared database disk you created earlier on), then click Next. Note In order to set the path for the clustered mailbox server database files, its important the cluster group containing the shared disks is owned by E2K7SCCNode1. The reason for this is that you arent allowed to use the shared disks if the cluster group is currently owned by E2K7SCCNode2.

Figure 40: Selecting to install a single copy cluster and specifying name and IP address of the clustered mailbox server Let the readiness check complete, and if no issues are found click Next to begin the installation.

Figure 41: Exchange Server 2007 Clustered Mailbox Role Readiness Check The Exchange Server 2007 installation wizard will now copy the needed Exchange files, install and configure the Mailbox Role then finally create and configure the clustered mailbox server resources locally and create the object in Active Directory. When each step has been completed, untick Exit Setup and open Exchange System Manager (yes this will be corrected in a later build), then click Finish. We dont want to open the Exchange Management Console just yet, well install Exchange on the second node first.

Figure 42: Installation of the Exchange 2007 clustered mailbox role completed successfully Log on to E2K7SCCNode2 with a domain admin account and perform the exact same steps as we did when installing Exchange Server 2007 on E2K7SCCNode1. Only difference is you should tick Passive Clustered Mailbox Role instead of Active Clustered Mailbox Role as shown in Figure 43 below.

Figure 43: Installing the passive clustered mailbox role on the second node When you have installed the Exchange Clustered Mailbox Role on the second node, we can move on to the next section, where we verify that the functionality of the clustered mailbox server works as expected.

Testing the functionality of the Single Copy Cluster

Its time to verify that Exchange 2007 clustered mailbox server is working as expected. Lets first open the Cluster Administrator and check whether the respective Exchange Resources have been created. If you take a look at Figure 44, it looks good, we have both nodes listed in the left pane and all Exchange resources have been created and are currently owned by E2K7SCCNode1.

Figure 44: Listing all Exchange cluster resources in the cluster administrator Now try to open the Exchange Management Shell by clicking Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell on one of the nodes, then type Get-ClusteredMailboxServerStatus. As you can see in Figure 45 below the status of the clustered mailbox server is Online, and E2K7SCCNode1 is currently the active node. This just keeps getting better and better doesnt it?

Figure 45: Requesting the online status of the clustered mailbox server Now that we have verified that the clustered mailbox server is online, lets try to move the Exchange resources from node one to node two using the MoveClusteredMailboxServer CMDlet. In the test environment used in this article, we do so by issuing below CMDlet: Move-ClusteredMailboxServer -Identity:MailboxServer -TargetMachine:E2K7SCCNode7 -MoveComment:"Testing functionality!" Youre then asked to confirm this action, type Yes then hit Enter. After a while the clustered mailbox resources would have been moved to the second node.

Figure 46: Moving the clustered mailbox resources to the second node Note Although its possible to move the cluster resource groups between nodes using the Cluster Administrator console, you should always do so using the MoveClusteredMailboxServer CMDlet as the Move Group task in the Cluster Administrator console isnt Exchange 2007-aware. Lets also take a look at the clustered mailbox server in the Exchange Management Console. To do so click Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Console, then drill down to Server Configuration > Mailbox. Notice the clustered mailbox server which we named MailboxServer is listed in the Result pane and that its recognized as a cluster server. Also notice that the Mailbox Database for this server points to the S: drive exactly as we specified during the installation of the Active Clustered Mailbox Role.

Figure 47: Viewing the clustered mailbox server in the Exchange Management Console

Conclusion
As was also the case with Exchange Server 2003, Exchange Server 2007 provides high availability of server resources, as one node takes over should the active node for some reason fail. But bear in mind that a single copy cluster is susceptible to failure of the shared storage subsystem. This means that no matter how many nodes form part of your cluster, youll always have a single point of failure when using this type of cluster. If you want a cluster without a single point of failure, you should consider the other type of cluster supported in Exchange Server 2007 called Cluster Continuous Replication (CCR), which not only provides high availability of server resources, but also storage groups. Cluster Continuous Replication (CCR) combines a traditional active/passive cluster with the new log file shipping and reply mechanisms in Exchange Server 2007. Log file shipping and reply makes it possible to keep a replica of the production mailbox databases. In my next article series here on MSExchange.org, Ill take you through how to prepare for, install and last but not least verify the functionality of a Cluster Continuous Replication setup. Until then have a nice one!

Exchange Server 2003 database portability

In Exchange Server 2003, portability was not easy. We needed to fulfill some prerequisites before starting the process of moving a database to another server. The prerequisites for Exchange Server 2003 are: The servers must belong to the same Administrative Group and Exchange Organization We have to modify some Active Directory attributes for the affected users (msExchHomeServerName, homeMTA and homeMDB). These are user attributes related to the database (or server) location of the new Exchange Server We have to manually change all of the client settings to use the new server

There is a Knowledge Base article explaining the procedure mentioned above for an Exchange Server 2003 environment. It can be found at the Microsoft Support Website: http://support.microsoft.com/?id=555603

Exchange Server 2007 mailbox portability

The whole process of moving a database in Exchange Server 2007 is simplified, if we compare it with the same process for previous Exchange Server versions. For Exchange Server 2007, the only prerequisite for moving a mailbox database between servers, is that both servers must be in the same Exchange organization. The problems related to the user attributes affected by the database change are addressed through a parameter called configurationonly on the move-mailbox cmdlet. On client side (for Outlook 2007 users) the problem is automatically solved by the AutoDiscover Service in Exchange Server 2007; for previous Outlook versions, the users had to manually configure all the changes. For OWA clients there is no change, because the Client Access Server (CAS) will change the settings to the correct mailbox server.

Remember that even with all these new features, this process must be completed to minimize downtime and it is not a simple procedure. Note: You can only move mailbox databases, Public Folders are not portable.

Moving a database between Mailbox Server in Exchange 2007

Now that we have seen how it works for Exchange Server 2003 and 2007, we will review a step-by-step procedure on how to move databases between two mailbox servers and how Exchange 2007 helps us decrease the downtime involved in this process. We are going to discuss a scenario (Figure 01), where we have two mailbox servers (srvmbx01 / srv-mbx02), and another server which has the CAS role (srv-cas) that provides the autodiscover services and protocol access to our clients. The users (for the purposes of this article) will be Anderson.Patricio and Jose.Rodas. They belong to a mailbox database called Sales which is located in the srv-mbx01 mailbox server. Lets suppose that this server experiences a hardware failure. So, we will have to move the database on this server to another Mailbox server. Our objective is to do it with the least effort and impact on our users.

Figure 01: Scenario where we are going to move a database between mailbox servers On Exchange Server Srv-MBX01 we are going to check the number of messages and mailbox size of user Anderson.Patricio who has a mailbox on srv-mbx01 in the sales database. (Figure 02).

Figure 02: The total number of items and size of Anderson.Patricios Mailbox So now, we are going to start the database move process between the Exchange Server 2007 computers. Note: During this period the messages sent to users who are in the mailbox sales database in the srv-mbx01 will not be delivered. First of all, we have to be sure that that our mailbox database is in a clean shutdown state. We can get a database in that state through various ways, for example with an online or offline backup. In this article, we will dismount the sales database, and copy the sales.edb file. But we must verify the status of the mailbox database using our old friend eseutil with the /mh switch (eseutil /mh <database name>) (Figure 03).

Figure 03: Verifying that the mailbox database sales is in Clean Shutdown Now, we are going to copy the sales.edb file containing all of the users messages to a new server, called srv-mbx02. Then, we will create a new mailbox database with the same name as the original one. To do so, we will follow these steps: 1. Log on to the Srv-mbx02 server 2. Open the Exchange Management Console 3. Expand Server Configuration 4. Click on Mailbox 5. Click on Srv-MBX02 and, into Result Panel, click on First Storage Group 6. In the Toolbox Actions, click on New Mailbox Database
7. We must complete the name of the original mailbox database located in the srv-

mbx01. For the purposes of this example, the name will be Sales. Take a note of the path where this database will create the file. Clear the checkbox called Mount this database. After that, click New (Figure 04)

Figure 04: Creating a database in the new server

8. Completion. This will be the final page of our process of creating a mailbox

database in the srv-mbx02 server. Click Finish. (Figure 05).

Figure 05: Final screen showing that the new mailbox database Sales was created on srv-mbx02 server Now, we can check the Properties of our newly created database from Toolbox Actions. We can click on the checkbox This database can be overwritten by restore (Figure 06).

Figure 06: Preparing the mailbox database switch So now our database has been successfully created on the new server, and we must now copy the sales.edb file of the original server into the srv-mbx02 server. The path where we will copy the original *.edb file must be the same as that which we defined in the database creation process (Figure 04). Finally, we have to mount the database, click on sales database and in the Toolbox Actions click on Mount Database. The result expected will be as follows in Figure 07.

Figure 07: The mailbox database sales mounted on the new server During the process of moving the database to another server, our users experienced some issues in their clients. The following are some examples of that. First is the error message for Outlook Web Access (Figure 08) and also the error message for Outlook 2007 (Figure 09).

Figure 08: Message error that appeared in the OWA connection

Figure 09: Message error that appeared in the Outlook 2007 client

Although the mailbox database is mounted on the new server (srv-mbx02), all of the users attributes are set to the other server. So, we will have to change these settings to set those attributes on the new server. We can do this using the follow cmdlet: get-mailbox database <old database> | move-mailbox targetdatabase <new database> -configurationonly:$true

Figure 10: Moving the configuration for all the mailboxes from srv-mbx01\sales to srvmbx02\sales Now, we can validate if user Anderson.Patricio has been updated to the new server (Figure 11). The user has changed the Exchange Server name and mailbox database but the data is still the same, because the only change was the database move between servers.

Figure 11: The user Anderson.Patricio with his new attributes After moving the database to the new server and correctly configuring the user settings, the Outlook 2007 clients are going to get a message asking for an application restart (Figure 12).

Figure 12: Message dialog box warning user to restart his/her Outlook 2007 After restarting Outlook 2007, we can check if we are being connected to the new server through connection status. To get this applet, we should CTRL + Right Click on the Outlook icon in the system tray. (Figure 13).

Figure 13: Checking Outlook clients with the new settings In the OWA environment, we just need to log on again and we will be able to access the mailbox normally on the new server. After our tests, we can evaluate the results of moving databases between servers on the following environments: Microsoft Outlook 2007 clients will be redirected by the AutoDiscover Service, without requiring user intervention OWA clients will be automatically redirected to the new server, because of the Client Access Server Outlook legacy clients must be manually configured because they do not have the ability to use the AutoDiscover service

Fixing Search issues after a database move

After the database move between srv-mbx01 and srv-mbx02 servers, our users may be getting this kind of error in the Outlook Web Access Search feature (Figure 14).

Figure 14: Some users may experience this problem in the OWA search feature To reset the Exchange Search Service, we can use a script called ResetSearchIndex.ps1 which is located in the scripts folders under the Exchange Server 2007 installation directory. The full syntax of the script is: .\ResetSearchIndex.ps1 force sales, Where sales is the mailbox database name

Figure 15: Resetting the Microsoft Exchange Search Indexer using the EMS for the new database

Conclusion
In this article weve reviewed the step-by-step procedure for moving a mailbox database between Mailbox Servers in an Exchange Server 2007 environment. We have discovered

that this process is easier than the same process in previous versions, and the objective of this process is to decrease the downtime in an Exchange Server 2007 environment by using less administrative effort.

Of course, today there are many ways to recover a mailbox easily, but every administrator should define the risks and create a disaster recovery plan showing the way to recover mailboxes in his environment.

Recover deleted mailboxes that are tombstoned in the database

If an administrator has deleted a user and with that its mailbox and within 30 days (by default) he discovers that this mailbox should not have been deleted, there is an easy way to reconnect the orphaned mailbox to a new user. The timeline for not deleting an unconnected mailbox from the storage is 30 days by default and can be increased using a private storage system policy. The administrator can have a look into the private storage of the private storage where he will find all orphaned mailboxes with a red cross. The cleanup agent is the piece of software that regularly scans all mailboxes and checks, if there is a connection between a user object in Active Directory and a mailbox in the private information store. If there is not, it marks the mailbox for deletion. The retention time for the tombstoned mailbox now begins to run. If the cleanup agent has not run yet, you can start him manually by triggering it.

Figure 1: How to manually run the Cleanup Agent If the administrator has now found the orphaned mailbox he only has to click right on it and choose Reconnect to connect it to a new user in Active Directory.

Figure 2: Reconnect a mailbox With Exchange Server 2003 we have a newly created Mailbox Recovery Center, which makes it easier to reconnect a mailbox. You just have to mount the private store, then you will see only the reconnectable mailboxes and a right click solves your problem.

Figure 3: Reconnect a mailbox using Mailbox Recovery Center These two methods are easy ways to reconnect an orphaned mailbox that is still available in the storage to a newly created Active Directory User. If the 30 days retention time is not enough, there is an easy way to increase this using system policy. A good feature provided by a private storage system policy is to only delete tombstoned mailbox stores after a backup of the storage was made.

Restoring Mailboxes from the Recovery Databases by Using Exmerge.exe

Exchange Server 2003 provides quite a flexible and easy way to mount storage databases using the new Recovery Storage Group feature. After having started to restore the database from a tape you configure the Recovery Storage Group that can be created by right clicking the server object in Exchange System Manager and choosing to create a Recovery Database Storage Group. Within this group you can now mount your restored database and use the Exmerge utility to move the recovered mailbox data from the Recovery Storage Group to the regular storage group. Using this method, you can recover a whole database or just a single mailbox. Every mailbox that is connected to the Recovery Storage Group is disconnected and therefore not accessible to users with mail clients. Before you can run Exmerge.exe successfully you have to grant the appropriate user permission to be able to open the store. In general nobody is able to open storage than his own. Microsoft recommends creating a new security group for it, adding the logon account to this group and then granting this group permission on the database object in Exchange System Manager. Another quick and dirty way to grant permissions to the

appropriate group is to put them into the security group Exchange Domain Server. This will grant the account the permission, too.

Figure 4: Using the Recovery Storage Group If you have successfully created the Recovery Storage Group youll have to complete some final steps before starting the recovery procedure. These steps are defining the path for transaction logs and system files and then adding the database to be recovered to the Recovery Storage Group by using the context menu. Afterwards you can start your backup and restore application and choose the database to be restored. After the restore is complete, you can hopefully mount this store successfully. With this procedure you are prepared to start the Microsoft Exchange Mailbox Merge Wizard (better known as Exmerge). After having started Exmerge.exe from command prompt just follow the instructions within the wizard to specify the export method, source and destination server. If the Recovery Storage Group is on the same Exchange server as the online database, this might be a single server. You should then choose the appropriate mailbox to be recovered and choose a temporary folder for log files. The wizard then copies the data from the mailbox into the recovery database and merges it with the corresponding mailboxes in the original storage. After this procedure is completed you can successfully use the recovered mailbox within your MAPI application.

Final conclusion

With the Exchange Server 2003 newly created Mailbox Recovery Center and the possibility to create your own Recovery Storage Group every Exchange administrator will have two more great features to easily recover lost or orphaned mailboxes within your organization. The Recovery Storage Group can successfully connect to Exchange 2000 databases, if SP3 is being applied to the Exchange 2000 Server. That means you can use these tools within a mixed environment, too. In general these features provide a way to choose the Microsoft provided ways and tools to provide a successful plan for disaster recovery without having to buy 3rd party tools for brick-level backups which would enlarge the backup schedules during the night enormously.

Configuring A Specific Mailbox

In order to configure a mailbox to allow for recovery of mailboxes that belong to users who have been deleted, you need only configure two settings. Configure your mailboxes to support recovery as follows: 1. Open the Exchange System Manager. 2. Expand the nodes until you have found the private store of concern. 3. Right-click the applicable private store and select Properties. 4. Switch to the Limits tab, as shown in Figure 1. 5. Configure the settings as you desire and click OK to accept them. The settings are explained below in some detail.

Figure 1 - Configuring limits on a Mailbox store. Keep deleted items for (days) - Sets the number of days that that deleted items (such as e-mail messages) remain on the server before they are permanently removed. You can type a number from 0 to 24,855. If you type 0, deleted items are removed from the server immediately. Keep deleted mailboxes for (days) - Sets the number of days that deleted mailboxes remain on the server before they are permanently removed. You can type a number from 0 to 24,855. If you type 0, deleted mailboxes are removed from the server immediately.

I recommend setting the deleted items setting at something around 14 days (in case the Boss deletes that important internal memo on accident) and setting the deleted mailboxes setting at something between 30 - 45 days to give you a fair shot at fixing an error such as this, should one occur. That's all there is to configuring an individual mailbox store for recovery, we will next look at creating a policy to apply to all private stores.

Configuring A Mailbox Policy

Should you have more than one mailbox store, you may want to consider creating and applying a mailbox policy to implement a recovery setting across all of your mailboxes

equally. Of course, you can create mailbox and public store policies for other reasons as well:so get in there and see what's up! To create, configure and implement a mailbox policy, follow the steps below: 1. Open the Exchange System Manager. 2. Ensure that viewing of Administrative Groups is on. If not, right-click the organization, and then click Properties. On the General tab, select Display administrative groups. You will have to exit and restart Exchange System Manager. 3. Open the administrative group that contains the mailbox(es) you want to work with. If it does not already contain a System Policies folder, create one by right-clicking on the Administrative Group node and selecting New | System Policy Container. 4. Right-click the System Policies folder and select New | Mailbox store policy, as shown in Figure 2.

Figure 2 - Creating a new mailbox store policy. 5. From the New Policy window, check the boxes of the tabs you want to use in the policy. For this example, we want the Limits box at a minimum. 6. On the General tab of the Properties window, type a policy name. 7. On the Limits tab (see Figure 3), configure the deletion settings as you desire. Close out the policy by clicking OK.

Figure 3 - Configuring the mailbox store policy 8. To apply the policy to one or more mailbox stores, right-click on it in the System Policy container and select Add Mailbox Store, as shown in Figure 4 9. Select the mailbox stores you want to add the policy to and click OK.

Figure 4 - Associating the policy with a mailbox store. If click on the Policies tab of the Properties page the mailbox store, you can see that the policy is indeed in effect. Additionally, any settings you configured via a policy will cause those boxes to be made unavailable for configuration from the Properties page. Now that we've seen how to configure for recovery on one or many mailboxes, let's get down to actually recovering an orphaned mailbox--so we can get our administrator back on his vacation and get Skippy off the hook. After all, we wouldn't want to get him fired on his first day at work, would we? The Exchange 2000 Server Orphanage The process to actually recover (reconnect) an orphaned mailbox is pretty simple, once you actually get to that step. To reconnect a mailbox with a user account, proceed as follows: 1. From Active Directory Users and Computers, create a new user object for the user. Ensure that you clear the Create an Exchange Mailbox check box. 2. In the Exchange System Manager, navigate to the mailbox store where the mailbox is located. 3. Verify that the mailbox icon has a red X on it. Only mailboxes that display this icon have been deleted (but will be retained for the time period specified). If the mailbox does not have the red X on it, then you will need to run the mailbox cleanup agent by right clicking on the Mailboxes object and selecting Run Cleanup Agent, as shown in Figure 5.

Figure 5 - Running the Cleanup Agent. 4. Right-click the mailbox and select Reconnect. This will open the New User for this Mailbox window as shown in Figure 6.

Figure 6 - Picking the user to reconnect with. 5. Select the user you wish to associate with this mailbox and click OK. That's it. You're done. The only thing you really have to watch out for here is possible replication delays you may experience if you are not working on the Exchange Server locally. Since the user account must be replicated throughout Active Directory and be

"seen" by the Exchange Server, you may want to force replication if required. Not a big problem, but something to be aware of. Wrap-Up Accidentally deleting a user account from the Active Directory database is never a welcome thing. Performing an authoritative restore for just one account is not really a likely event. At least you can rest easy knowing that you can reconnect the new user account with the orphaned mailbox:see, not everything is all bad. Now, back to that hard earned vacation!

What is an Edge Transport Server anyway?

The Exchange Product group developed the Edge Transport Server to give Enterprise organizations powerful out-of-the-box protection against spam without needing to invest in a 3rd party anti-spam solution. The messaging hygiene features in the Edge Transport server role are agent-based and consist of multiple filters which are frequently updated. Although the primary role of the Edge Transport server is to route mail and do message hygiene, it also includes features that will let you do other things such as rewrite SMTP addresses, configure transport rules, enable journaling and associated disclaimers, etc. It is important to understand that by default the Edge Transport server only filters out spam messages and other unwanted mail using the built in agents. This means that this Exchange 2007 Server role does not perform any filtering when it comes to mail-borne viruses. To filter virus infected messages using the Edge Transport server, you must install Forefront Security for Exchange or a 3rd party product on the server.

Deployment Considerations
The Edge Transport Server role in Exchange Server 2007 is designed to be installed in your organizations perimeter network (aka DMZ or screened subnet). The Edge Transport Server is the only Exchange 2007 server role that should not be part of your corporate Active Directory on your internal network; it should instead be installed on a stand-alone server in a workgroup or as a domain member in an Active Directory dedicated to servers located in the perimeter network as shown in Figure 1.

Figure 1: Typical Edge Transport Server Deployment Scenario Although the Edge Transport Server role is isolated from Active Directory on the internal corporate production network, it is still able to communicate with the Active Directory by making use of a collection of processes known as EdgeSync that run on the Hub Transport Server and which, since it is part of the Active Directory, have access to the necessary Active Directory data. The Edge Transport server uses Active Directory Application Mode (ADAM) to store the required Active Directory data, which is data such as Accepted Domains, Recipients, Safe Senders, Send Connectors and a Hub Transport server list (used to generate dynamic connectors so that you do not need to create them manually). It is important to understand that the EdgeSync replication is encrypted by default, and that the replication is a one-way process from Active Directory to Active Directory Application Mode (ADAM), this means that no data is replicated from ADAM to AD. The first time EdgeSync replication occurs, the ADAM store is populated, and after that data from Active Directory is replicated at fixed intervals. You can specify the intervals or use the default settings, which when speaking configuration data is every hour and every 4th hour for recipient data. Although the Edge Transport server role has been designed to provide improved antispam and antivirus protection for an Exchange 2007 organization, you can deploy this server role in an existing Exchange 2003 organization as well. Since you install the Edge Transport server role on a stand-alone machine in the perimeter network (aka DMZ or screened subnet), this is even a relatively simple task. But even though you would be able to use the Edge Transport server role as a smart host or an SMTP relay server in an Exchange 2003 organization, you will not be able to replicate configuration and recipient data from Active Directory to ADAM using EdgeSync as this requires an Exchange 2007 Hub Transport server on the internal network. However, this doesnt hinder you from using the filtering agent that doesnt rely on the EdgeSync service. If you only use the

Intelligent Message Filter (IMF) in your Exchange 2003 organization, deploying an Edge Transport server in the perimeter network (aka DMZ or screened subnet) would make sense, since it would provide an additional layer of anti-spam protection. And as mentioned previously, you could also install Forefront Security for Exchange Server on the Edge Transport server in order to filter out virus infected messages. Like is the case with the Exchange 2007 Hub Transport server, the Edge Transport server has its own Jet Database to process the delivery of inbound as well as outbound E-mail messages. When inbound E-mail messages are stored in the Jet database and are ready for delivery, the Edge Transport server lookups the respective recipient(s) in the ADAM store that as mentioned, among other things contains recipient data replicated from the Active Directory using the EdgeSync service. In a scenario where you have deployed multiple Edge Transport servers in your organization, the Edge Transport servers uses DNS round robin (which is supported by most DNS servers today) to network and load-balance network traffic between the servers. I leave the details on how to deploy multiple Edge Transport servers using load balancing and a high availability approach for another article.

Summary
In this part of the series covering the Edge Transport server role in Exchange server 2007, we went over Microsofts vision with this server role and explained how it can be used in your organization. In the next article we will cover how to deploy the Edge Transport server. If you would like to read the other parts in this article series please go to Uncovering the Exchange 2007 Edge

Introduction
In the first part of this article series, we took a look at Microsofts vision with the Edge Transport server role as well as talked about why you might want to consider deploying it in your organization. In this part we will go through the steps necessary in order to deploy a single basic Edge Transport server in an Exchange 2007 based messaging infrastructure.

Prerequisites
In order to follow along with the deployment steps in this article, you need to have the following ready in your lab environment: An Exchange 2007 SP1 organization where you have deployed at least one Hub Transport server Have a Windows Server 2003 SP1 or Windows Server 2008 Standard edition ready (the server on which we will install the Edge Transport server role)

Installing required components and configuring the server

Okay so before we can install the Edge Transport server role on the server, there are several steps we must complete first. Creating a DNS Suffix Before you can install the Edge Transport Server role, you should make sure you have created a DNS Suffix on the server. Be sure to pick the right NetBIOS name as well as DNS Suffix the first time as its not supported to change these once the Edge Transport server role has been installed. In addition, the readiness check will fail if a DNS Suffix cannot be located. Creating the DNS Suffix is a very simple process; you can do so by logging on to the server with the Administrator account, or another account with administrator rights. Then click Start and then right-click My Computer and select Properties in the context menu On the system property page, click the Computer Name tab and then Change (see Figure 1).

Figure 1: Computer Name Tab Now click the More button and then enter the respective DNS Suffix (see Figure 2). Click OK four times.

Figure 2: DNS Suffix and NetBIOS Computer Name Click Yes to reboot the server, so the changes takes effect. Since the Edge Transport server role uses ADAM directory service as the repository for the replicated configuration and recipient data from Active Directory, it should come as no surprise that well need to install the ADAM component before we can install the Edge Transport server role. If you plan on installing the Edge Transport server role on a Windows 2003 R2 server, you can install the component via the Add or Remove Programs | Add/Remove Windows Components| Active Directory Services, here you need to tick Active Directory Application Mode (ADAM) as shown in Figure 3, then click OK twice.

Figure 3: Adding the ADAM Component Like is the case with any other Exchange 2007 Server role you also need to install both the .NET Framework 2.0 component as well as Windows PowerShell 1.0. SMTP Transport Stack As most of you might recall Exchange Server 2000 and 2003 extended and made use of the Windows Server 2000 or 2003 SMTP and NNTP services, and thus required you installed both the Windows NNTP and the SMTP component (which both are part of IIS) prior to installing the Exchange Server product itself. Since NNTP is one of the features which arent supported in Exchange Server 2007, you need to make sure this component isnt installed on the server, if it is the Exchange Server 2007 Readiness Check will fail. In addition because Exchange Server 2007 no longer makes use of the Windows Server SMTP service, but instead has its own transport stack, which has been written from the ground up in managed code, you also need to make sure the Windows Server SMTP component isnt installed on the server. Like with NNTP the Exchange Server 2007

Readiness Check will fail, if this component is found on the server. Some of you might ask why the Exchange Product group replaced the Windows SMTP component with their own? Well by doing so they have reduced the risks that are associated with denial of service attacks as well as eliminated the dependency on IIS as well as reduced the work which is required to properly secure the server for deployment in the perimeter network (aka DMZ or screened subnet). Name Resolution Its important that the Edge Transport server and the Hub Transport server in your Exchange 2007 organization can resolve each others FQDN NetBIOS names. In order to accomplish this, you can create the necessary host record in a forward lookup zone on the DNS server used by the Edge Transport server (typically a DNS server located in the perimeter network) and the Hub Transport server (typically an internal Domain Controller with DNS installed). Note that in order for the Hub Transport server to see the Edge Transport server, you must create the necessary forward lookup zone and name record on the DNS servers as shown in Figure 4.

Figure 4: DNS Management MMC Snap-in You may also choose to simply add the FQDN NetBIOS name and IP address of the Edge Transport server to the local hosts file on each Hub Transport server, and the FQDN NetBIOS name and IP address of any Hub Transport server to the local hosts file on the Edge Transport server in your Exchange organization. Although this is a perfectly supported solution, I dont recommend you use it unless youre dealing with a small shop which probably got one Edge Transport server and one or perhaps two Hub Transport server. If youre a messaging administrator/consultant in a large Exchange organization,

which contains multiple Edge Transport servers as well as several Hub Transport servers, its far better to keep the name resolution centralized on dedicated DNS servers.

Installing the Edge Transport Server Role

Okay, we can now begin the actual installation of the Exchange 2007 Edge Transport server role. As is the case with all the other Exchange Server 2007 roles, you install this role by performing navigating to the Exchange Server 2007 source directory (DVD media or the network share containing the Exchange Server 2007 binaries) and double-click on Setup.exe. When the Exchange Server 2007 setup splash screen appears click Step 4: Install Microsoft Exchange. When the Exchange Server 2007 Installation Wizard has initialized, click Next then accept the End User License Agreement (EULA), then click Next again. You now have the option of enabling Error Reporting (which is recommended, so that the Exchange Product group receives information about any issues you encounter, which in the end gives us a better product). When you have decided whether you want to enable error reporting or not, you can click Next. Since were going to install the Edge Transport server role, you now need to choose Custom Exchange Server Installation, then click Next (see Figure 5). This is also the screen where you have the option of changing the path for the Exchange Server installation (in the bottom of the screen).

Figure 5: Installation Type Setup page Tick Edge Transport Role (see Figure 6), then click Next.

Figure 6: Selecting to install the Edge Transport Role When you have selected the Edge Transport serve role as well as the installation path, click Next. If the Readiness Check completes without any issues, you can begin the installation by clicking the Install button. The Installation Wizard will now copy the required files then begin the installation. Since the server on which Edge Transport role is a stand-alone machine, which doesnt belong to an Active Directory Forest, and since this type of installation is pretty small, the installation process will complete relatively fast. When the installation has completed, click Finish.

Summary
In part 2 of this article series covering the Edge Transport server role, I took you through the steps necessary in order to deploy an Edge Transport server properly. In the next part, we will verify that the Edge Transport server role was installed correctly as well as create the Edge subscription. If you missed the first part in this article series please read
Home

Articles & Tutorials Exchange 2007 Articles Planning & Architecture

Uncovering the Exchange 2007 Edge Transport Server (Part 3)

In this part of the series uncovering the Edge Transport server role, we will create an Edge Subscription and verify it works as expected.

Published: Sep 30, 2008 Updated: Sep 30, 2008 Section: Planning & Architecture Author: Henrik Walther Company: Interprise Consulting A/S Printable Version Adjust font size:


vote

Rating: 4/5 - 5 Votes

Top of Form

1 2 3 4 5

Bottom of Form

If you would like to read the other parts in this article series please go to:
Uncovering the Exchange 2007 Edge Transport Server (Part 1) Uncovering the Exchange 2007 Edge Transport Server (Part 2)

If you would like to be notified when Henrik Walther releases the next article in this series please sign up to the MSExchange.org Real time article update newsletter.

Introduction
In part 2 of this article series, we went through the steps necessary in order to deploy a basic Edge Transport server in your organization. In part 3, we will go through the steps required in order to subscribe the Edge Transport server to an Exchange Server 2007 based messaging infrastructure. As you learned in part 1 of this articles series, an Edge Transport server should not be part of the corporate Active Directory infrastructure, but should instead be installed on a stand-alone server in a workgroup or as a domain member in an Active Directory forest dedicated to a set of servers located in the perimeter network. This makes it easier to roll out updates, monitor the servers using solutions such as System Center Operations Manager 2007 (SCOM 2007) as well as simplify overall management and administration.

Now that we have an Edge Transport server deployed in our perimeter network, we can create the so called Edge Subscription, so that Active Directory data such as Accepted Domains, Recipients, Safe Sender lists, Send Connectors can be replicated from the corporate Active Directory forest to the ADAM instance that is created on the Edge Transport server. Part 1 uncovers the inner details of how an Edge Subscription is working, so if you have not read that article or perhaps need a refresher, I suggest you do so before continuing with this one.

Creating the Edge Subscription XML File

The very first step in order to get and Edge Subscription up and running are to generate the Edge Subscription XML file on the Edge Transport server. Note: Although the recommended method for establishing end-to-end mail flow between the Edge Transport server(s) and the Hub Transport servers with in the Exchange organization is to create an Edge Subscription for the Edge Transport server, you can also do so by creating and configuring the Send connectors (that the EdgeSync service creates automatically) manually. Although this will establish working end-to-end mail flow between the Edge Transport server(s) and the Hub Transport server(s), you should bear in mind that you cannot make use of the recipient lookup feature or safe list aggregation as these features requires that the Edge Transport server has a subscription to the organization. In addition the management of the Edge Transport server(s) will be more time consuming. In order to generate the Edge Subscription file, we need use the New-EdgeSubscription CMDlet (no GUI exists for this step!). To do so open the Exchange Management Shell (EMS) on the Edge Transport server itself, then type: New-EdgeSubscription file C:\EdgeSubscriptionFile.xml (or whatever you want to name the file as the name of the file doesnt have any impact on anything), then hit Enter as shown in Figure 1.

Figure 1: Creating a New Edge Subscription File Note: When you run the New-EdgeSubscription CMDlet, an ADAM account is created as well. This account is used to secure Lightweight Directory Access Protocol (LDAP) communications during data transfer. The credentials for the account is also retrieved when running the CMDlet.

As you can see from the figure, you now need to confirm that you really want to create an Edge Subscription, as this process makes certain configuration of the Edge Transport server, so that its ready to be managed via the EdgeSync service. As this is exactly what we want to do, type Y then hit Enter. Warning Any Accepted Domains, Message Classifications, Remote Domains, and Send Connectors will be overwritten when you make a new Edge Subscription file. Also bear in mind that the Internal SMTP Servers list (a list of all internal SMTP server IP addresses or IP address ranges that should be ignored by the Sender ID and Connection filtering agents) of the TransportConfig object will be overwritten during the synchronization process. In addition the Management Shell tasks that manage these types of objects will be locked-out on the Edge Transport server, which means you need to manage those objects from within the organization and then have the EdgeSync service update the Edge Transport server. When running the New-EdgeSubscription CMDlet on a newly installed Edge Transport server, this information can be ignored, since you havent configured anything manually on the server yet. Since the XML file which we as you can see in Figure 2 saved in the root of the C: drive needs to be imported on a Hub Transport server, we need to transfer the file to a Hub Transport server in the Exchange 2007 organization. You could do so by copying the file to a floppy disk, or perhaps even smarter by making use of the Disk drives feature in a Remote Desktop Connection client (if you have enabled Remote Desktop on the Edge Transport server and have TCP port 3389 open in the firewall between the parameter network and the internal network).

Figure 2: Edge Subscription XML File

Importing the Edge Subscription XML File

When the file has been transferred to a Hub Transport server in the AD site from where you want to establish replication to the Edge Transport server, you need to import it by opening the Exchange Management Console (EMC), then expand the Organization Configuration node then select Hub Transport. Note: In order to import the Edge Subscription file on a Hub Transport server, you must logon with an account that is local Administrator on the respective Hub Transport server, as well as belongs to the Exchange Organization Administrators group. Now click on the Edge Subscriptions tab (see Figure 3).

Figure 3: Edge Subscriptions Tab on the Hub Transport Server Since we have to create a new Edge Subscription based on the XML file we generated in a previous step, click New Edge Subscription in the Action pane (or if you prefer rightclick somewhere in the Work pane and select New Edge Subscription in the context menu). Importing the Edge Subscription file will establish an authenticated communication channel as well as complete the Edge Subscription process by beginning an initial replication. The Send connector which is used when messages are sent to the Internet via the Edge Transport server is created by default. In addition the EdgeSync service will replicate Send Connector configuration, Accepted Domains, Remote Domains, Safe Sender lists as well as Recipient data (SMTP address including Contacts, Distribution Lists and proxy addresses) from Active Directory to the ADAM store. We will now be taken to the New Edge Subscription Wizard, where we have to specify the Active Directory site in which the Edge Transport server will become a member. If

you only have one site select Default-First-Site-Name. If your Exchange organization is deployed across multiple sites, click the drop-down list and choose the respective site. If your Active Directory topology consists of multiple Active Directory sites, it is recommend you import the Edge Subscription file on a Hub Transport server that is located in the site which got the best network connectivity to the perimeter network in which the Edge Transport server is deployed. Now specify the location of the Edge Subscription file by clicking Browse, and then click New (Figure 4).

Figure 4: Creating a New Edge Subscription Wait for the New Edge Subscription Wizard to complete, then click Finish Note: If you are a PowerShell fanatic, you can of course also import the Edge Subscription file using Exchange Management Shell (EMS). This is done by using the NewEdgeSubscription FileName:C:\EdgeSubscriptionFile.xml Site:Default-First-SiteName CMDlet.

When the Edge Subscription file has been imported, it is a good security practice to delete it, although it will expire 24 hours after it was generated. Now that we have created an Edge Subscription the Edge Sync service on the Hub Transport Server will synchronize configuration data such as each hour and recipient data every fourth hour to the Edge Transport server. If you do not want to wait for four hours before the replication occurs, you can force the EdgeSync synchronization manually. In order to do so open the Exchange Management Shell (EMS) on a Hub Transport server, then type Start-EdgeSynchronization as shown in Figure 5.

Figure 5: Manually Starting the Edge Synchronization Forcing a synchronization using the Start-EdgeSynchronization is also a good idea if you have made bulk change in Active Directory (perhaps added 50 new mail-enabled or mailbox-enabled users), so that these changes are replicated immediately. When the EdgeSync service synchronizes data from Active Directory to ADAM store on the Edge Transport server, it is sent hashed in order to protect the synchronized data. In addition the LDAP connection is secured by the ADAM credentials which are stored in the Edge subscription file. Last but not least all recipient and safe senders lists data stored in ADAM are hashed.

Verifying the EdgeSync Service Works as Expected

In order to see whether the Hub Transport server configuration data has propagated properly to the Edge Transport server, you should verify a Send Connector has been created on the server. You do so by performing the following steps:
1. Log on to the Edge Transport server. 2. Open the Exchange Management Console.

3. Click the Edge Transport node in the navigation tree in the left pane. 4. Now click the Send Connectors tab in the Work pane (see Figure 6).

Figure 6: Send Connector on the Edge Transport Server

5. Verify a Send Connector has been created. Also make sure each domain that are listed under the Accepted Domains tab on the Hub Transport server is listed, when typing Get-AcceptedDomain in the Exchange Management Shell on the Edge Transport server. You should get a list similar to the one shown in Figure 7.

Figure 7: Listing the Accepted Domain Note: You can also use the Test-EdgeSynchronization CMDlet for additional testing purposes.

If everything is as expected, you now have a subscribed working Edge Transport server in your parameter network - congratulations!

Summary
In this part 3 of the series uncovering the Edge Transport server role in Exchange server 2007, we took a ride through the steps necessary in order to subscribe an Edge Transport server to an Active Directory site in the corporate Active Directory forest on the internal network. In the next part we will take a close look at the anti-spam filtering agents included with this Exchange 2007 server role. If you would like to read the other parts in this article series please go to:
Uncovering the Exchange 2007 Edge Transport Server (Part 1) Uncovering the Exchange 2007 Edge Transport Server (Part 2)

How to Secure Exchange 2007 Edge Transport Servers

Published date Category Author Wed, 2006-10-18 16:41

Exchange 2007

Rodney Buike Printable Version | Email this Article

Top of Form

node 2 90 Aw esome

557 /fivestar/vote/node/557

Your rating: None Average: 4.5 (2 votes)

Poor Okay Good Great Awesome

node/557

Rate

fivestar_form_node_557

Bottom of Form

Post to del.icio.us | Furl it | Spurl it

This article originally appeared on msexchange.org The Exchange 2007 Edge Transport Server is most vulnerable due to its location on the edge of the network. This article shows you a simple way to secure your Edge Transport server(s).

Introduction

The Edge Transport server role in Exchange 2007 performs a number of functions including routing messages between the Exchange organization and the internet, as well as providing Anti-virus and Anti-Spam protection. It is meant to be installed on the edge of the corporate network, or on a screened subnet. This location makes it more vulnerable than the servers on your protected network. This means you are required to do a little more work to secure the server itself. The Security Configuration Wizard in Windows Server 2003 SP1 is an ideal tool to use to reduce the attack surface of your Edge Transport server(s). The Security Configuration Wizard (SCW) is a new feature in Windows Server 2003 that is part of Service Pack 1. It is an easy to use wizard that allows you to quickly create and apply security templates to servers. Being wizard based, it is very user friendly and has some great features to help you secure, not only your Edge Transport servers, but all your Windows 2003 SP1 servers. Some of my favorite features include the ability to copy the XML file to other servers and apply them throughout the network and the ability to rollback changes in case you went overboard with the restrictions and broke something. If you are unfamiliar with this new tool be sure to check the links at the end of this article for more information.

Installing SCW
Installing the Security Configuration Wizard is pretty straight-forward. Open up Add/Remove Programs, select Add/Remove Windows Components and scroll down the list until you see Security Configuration Wizard (see Figure 1). Check the box and click Next to complete the installation.

Figure 1: Install Security Configuration Wizard That takes care of the basic installation. For Exchange 2007 servers there is one more step. You must register the Exchange2007.xml file for SCW to be able to load and apply the rules. Begin by browsing to C:\Program Files\Microsoft\Exchange Server\Scripts and locate a file called Exchange2007.XML. Copy this file to %windir%\Security\msscw\scripts. Once complete open up a command prompt. From the command line change directories to %windir%\System32 and run the following command: SCWCMD Register /kbname:MSExchangeEdge kbfile:%windir%\security\msscw\kbs\Exchange2007.xml

Figure 2: Register Exchange 2007 SCW Database Believe it or not, that was the hard part!

Running SCW
With all that out of the way we are ready to run SCW and lock down our Edge Transport Server. To launch SCW, click Start > Programs > Administrative Tools > Security Configuration Wizard. You will be welcomed with the Welcome to the Security Configuration Wizard page at which you can click Next to begin. On the next screen you will be asked to create, edit, apply or rollback a configuration. The last one is a lifesaver if you happen to mess up and things stop working. We are starting with a base system so choose Create a new security policy (see Figure 3) and click Next.

Figure 3: Create New Policy The next screen allows you to choose a server for your base server. In this case I am going to choose the local server, but you do have the option of doing this for remote servers as well. Once you click Next the

SCW will configure the Security Configuration Database. Once this is complete, click on View Configuration Database to open up SCW Viewer and then scroll down the list. Everything you see here includes a custom template to begin securing that particular server. If you successfully registered the XML file you should see some Exchange 2007 entries including Exchange 2007 Edge Transport. By clicking of the triangle next to the entry you can expand it for more information (see Figure 4).

Figure 4: SCW Viewer Close SCW Viewer and click Next to proceed. The first set of configuration options come under the RoleBased Server Configuration. Click Next and under Select Server Roles choose Exchange 2007 Edge Transport (see Figure 5) and uncheck any roles not being performed (File Server for example) then click Next again.

Figure 5: Select Server Roles Click Next again on the Select Client Features page, the Select Administrator and Other Option page and the Select Additional Services Page. Those selections will be chosen for you based on the role you chose earlier and any services required. Next you will be asked if you wish to change the startup of unspecified services. Unspecified services are defined as services not listed in the database or not yet installed. If you set this to disabled and then install a new application that installs a service, that service would be set to disabled and require you to enable it manually. The choice is yours; I set it to disabled and then enabled them manually. The next screen shows you what changes to the services will be made. You can review this and if one of those unspecified services shows up here as disabled, you can enable it. Once you click Next again, the Network Security portion of the wizard starts. Here is where access restrictions and ports are configured and there is some customization required here so click Next once again to continue. The Open Ports and Approve Applications page requires a few modifications. We first need to open TCP 389 (LDAP) and UDP 636 (LDAP/SSL) to allow ADAM to communicate with Active Directory. To do this simply click on Add and under the Port Number tab enter the port number and check of TCP, UDP or both. You will need to add the following two ports.
Port Number Protocol 389 TCP 639 UDP

Table 1 Once those two have been added (see Figure 6) there is some additional configuration that needs to be performed before we can proceed.

Figure 6: Additional Ports for ADAM The next thing we want to do is restrict the interface that some of the ports can communicate through. Your Edge Transport server should have two network interfaces, one internal and one external. The goal here is to prevent LDAP traffic to go through the external interface which would not be very secure! Select 25 (SMTP) and click on Advanced. Click on the Local Interface Restrictions tab and then choose Over the following local interfaces and check both the internal and external interfaces. Repeat for the two ports you created, 389 and 636, and for 3389 (Remote Desktop Protocol) EXCEPT only choose the internal interface (see Figure 7).

Figure 7: Local Interface Restrictions Click Next and verify the ports and interfaces are correct as shown in Figure 8.

Figure 8: Confirm Port Configuration Click Next again to proceed. The next section is the Registry Settings portion of the wizard. Check the box next to Skip this section and click Next. You can also skip the Audit Policy section of the wizard. That completes the creation of the policy! Not so hard was it! Before we get carried away let's save the configuration. Clicking Next will take you to the Security Policy File Name page which allows you to name the policy and offer a description of what the policy does, some of the custom settings etc You can also view the settings with the SCW Viewer by clicking on View Settings. Enter the name of the policy and click Next. Your final choice will be to apply the policy now, or leave things as is and apply it later. Leave the default of Apply Later and click Next one last time. You are at the end of the wizard and clicking Finish will close it out. You are now ready to apply the policy to your Edge Transport server or servers.

Applying the Policy

Applying the policy couldnt be simpler. Launch SCW and make your way to the second screen. This time choose Apply an existing security policy and click Browse to locate the policy (see Figure 9).

Figure 9: Apply Existing Policy Next choose the server you wish to apply the policy too and click Next twice to apply the policy (see Figure 10). Once it is complete click Next and then click Finish. You have now applied the policy and locked down your server. Copy the XML file to your other Edge Transport servers and apply it to them as well.

Figure 10: Applying the Security Policy

Conclusion
The last thing you should do is test that everything is still functional. After that sleep easier knowing your Edge Transport has a reduced attack surface that will go a long way to keeping it your server! This article was reprinted with permission from MSExchange.org