Monday, September 27, 2010

Configuration Cluster Continuous Replication 2007

                             
Introduction:
Exchange Server 2007 introduces several new high availability features; one of them is the Cluster Continuous Replication (CCR) feature. This feature takes the new Exchange Server 2007 Log file shipping and replay features.
Prerequisites
• A Windows 2003 Active Directory forest with at least one Domain Controller 2003 forest functional level.
• Two Windows 2003 Server R2 Enterprise Editions or Windows 2003 Server SP1 Enterprise Editions.
• One Windows File share Witness (MS recommends this to be an Exchange 2007 Hub Transport Server in the existing Exchange 2007 organization)

In addition to the above prerequisites you should be aware of the following general requirements as well:
• When dealing with CCR environments you must use/can only use one database per storage group.
• You cannot create a public folder database in a CCR environment if you already have more than one public folder database in your organization.
• You can create up to 50 storage groups and 50 databases on a CCR cluster. Bear in mind though, that you should create only one database per storage group.
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 MBX1 and MBX2. Now name the two network connections Public and Private for the external and the internal network respectively.

                                          Figure 1: Network Connections
Click Advanced > Advanced Settings, if it’s 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


                     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, it’s time to create the actual Windows 2003 Server Cluster. In order to do so logon to MBX1 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
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 MBX1, then click Next.
                                          Figure 11: Adding the First Cluster Node
Let the cluster wizard determine the cluster configuration and click Next.
                                          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 192.168.10.100, then click Next.
                       Figure 13: Specifying the IP address the Cluster Management Tools should connect to
Enter the credentials of the cluster service account 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 there’s only one node it’s not very fault tolerant. So let’s add the second Windows 2003 server too. We can do this by right-clicking MBX1 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 MBX2, 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, 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
Alright we have reached the end of part one, but you can look forward to part two of this article series in the near future. Until then have a nice one!
Configuring the Majority Node Set (MNS) Quorum with File Share Witness
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. We’ll 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 we’ll 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_E2K7CCR 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 MBX1 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=\\HUB\MNS_FSQ_E2K7CCR

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 it’s shown in Figure 32 below.
                                              Figure 32: Configuring the Majority Node Set
Now let’s verify the Priv 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 33 below, this property has been set correctly for the purpose of this article series.
                                        Figure 33: 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 e-mail. 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 34: Transport Configuration Settings
Installing the Active Clustered Mailbox Role on MBX1
It’s time to install the Exchange Server 2007 bits on each node, we’ll start with MBX1. First, if you haven’t already done so, I recommend you copy the Exchange Server 2007 binaries to a drive locally on each node. When you have done so double-click Setup.com.
                                                Figure 35: 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) and Step 3: Install Microsoft Command Shell (MSH), have already been completed.
                                           Figure 36: Exchange Server 2007 Installation Menu

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 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 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 40: 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 41: Exchange Server 2007 Clustered Mailbox Role Readiness Check
                                                                  Figure 42
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 don’t want to open the Exchange Management Console just yet, we’ll install Exchange on the second node first.
Installing the Passive Clustered Mailbox Role on MBX2
Log on to MBX2 with a domain admin account and do the exact same steps as we did when installing Exchange Server 2007 on MBX1. Only difference is you should tick Passive Clustered Mailbox Role instead of Active Clustered Mailbox Role as shown in Figure 44 below.
                         Figure 43: Installing the passive clustered mailbox role on the second node
Verifying the functionality of the Cluster Continuous Replication based Mailbox Server
It’s time to verify that our Exchange 2007 clustered mailbox server is working as expected. Let’s first open the Cluster Administrator and check whether the respective Exchange Resources have been created. If you take a look at Figure 44 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 MBX1.
                                 Figure 44: 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 CCR. As you can see in Figure 45 below the status of the clustered mailbox server is Online, and MBX2 is currently the active node.
                           Figure 45: Requesting the online status of the clustered mailbox server
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 CCR is listed in the Result pane and that it’s recognized as a cluster server.
                Figure 46: Viewing the clustered mailbox server in the Exchange Management Console
Let’s 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.
As you can see in Figure 47 below, the log files were replayed to MBX2 within the same minute as they were generated onMBX1.

                                                    Figure 48: Log file replay
Conclusion
You benefit from several advantages when you choose to install the Exchange 2007 Mailbox Server role in a Cluster Continuous Replication setup in your organization.
1. The primary reason here is that you no longer have a single point of failure.
2. When talking about the Mailbox/Public Folder databases. Should the database on one node crash, an automatic fail over to the other node containing the secondary database is completed.
3. This also means you no longer need to use a shared storage system in the CCR setup, as is the case with Exchange 2007 Single Copy Clusters as well as cluster setup in previous versions of Exchange.
4. In addition the two nodes in the CCR setup can even be placed in two different locations, as long as they belong to the same subnet. Not only that, the installation of the Exchange 2007 cluster has also been further simplified over previous versions.
5. Since CCR setup makes use of log file shipping and replay to a secondary database, you also don’t have to do full online backups far as often as was the case in Exchange 200x and earlier versions.
6. Last but certainly not least, the fail over process been improved in several areas now that the new file share witness model have been introduced.

Friday, September 24, 2010

IMPLEMENTING TLS BETWEEN EXCHANGE 2003 SERVERS

1. Overview

If you require secure SMTP mail communication between two Exchange Routing Groups in the same Exchange Organization, or between two separate Exchange Organizations. you can use Transport Layer Security (TLS) to accomplish this requirement.

Note: Some of these steps are summarized, and will refer to existing documentation where applicable; this document can be used for Exchange 2000, and/or Exchange 2003. Or to configure Exchange 200x, to support TLS for a third party SMTP Server.

In order to secure mail flow using TLS, you will need to add an additional IP address, SMTP Virtual Server, and SMTP Connector, on each of the Bridgehead servers for each of the Routing Groups, or Exchange 2003 Organizations, between which you wish to have secured mail flow. This will also require that certificates be installed on these new SMTP Virtual Servers. Ideally you would want to make sure that no other connectors are configured between the Routing Groups or to the other Exchange 2003 Organization, to prevent unsecured mail flow between them.

2. TLS enabling process

- Configuring an Additional IP Address

It is common to configure additional IP addresses for a given physical interface card to allow for IP-based virtual servers such as Web Servers or SMTP Virtual Servers. For this implementation, add a second or additional IP address to each of the Exchange Servers that will serve as the Secure SMTP Connector Bridgeheads in each of the Routing Groups or Exchange Organizations, between which you require secured mail flow.

To configure additional IP addresses for a given interface:

1. Log on to the Exchange server computer by using an administrative-level account.
2. Right-click My Network Places , and then click Properties .
3. Right-click the interface that you want to configure, and then click Properties
4. The driver and protocols support on this interface are displayed. Click Internet Protocol (TCP/IP) , and then click Properties .
5. Click Advanced to open the Advanced Properties window.
6. Click IP Settings .
7. Click Add under IP addresses , and then type the additional IP address and subnet mask.
8. Click OK to accept the advanced TCP/IP settings.
9. Click OK to accept these TCP/IP settings.
10. Click OK to accept the properties for the interface.

The new settings that you have configured are available immediately.

- Configuring the Default SMTP Virtual Server

First we need to configure the Default SMTP Virtual Server to listen on the main IP address.

1. Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
2. Expand Administrative Groups (if appropriate), expand AdministrativeGroup (if appropriate), expand Servers, expand ServerName, and then expand Protocols.
3. Right-click the Default SMTP Virtual Server objects, and then click Properties.
4. On the General tab, for IP address, select the primary IP address from the drop-down list.

- Creating and Configuring the Secure SMTP Virtual Server

Add a new SMTP Virtual Server, that will serve as the Secure SMTP Connector Bridgehead, and configure this Secure SMTP VS to listen on the secondary IP address added in the “Configuring an Additional IP Address“ section of this document.

1. Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
2. Expand Administrative Groups (if appropriate), expand AdministrativeGroup (if appropriate), expand Servers, expand ServerName, and then expand Protocols.
3. Right-click SMTP, point to New, and then click SMTP Virtual Server.
4. In the Name box, type the name of the virtual server, and then click Next.
5. Select the IP address that you want to use (suggest using the additional IP address that was added in the “Configuring an Additional IP Address” section of this document, and then click Finish.

- Configuring the Secure SMTP VS to use a certificate

To configure the Secure SMTP VS to use a certificate follow the steps below in conjunction with the appropriate How to use Certificates with…article at the end of this document:

1. Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
2. Expand Administrative Groups (if appropriate), expand AdministrativeGroup (if appropriate), expand Servers, expand ServerName, and then expand Protocols.
3. Right-click the Secure SMTP VS, and then click Properties.
4. Click the Access tab, and then click Certificate to set up new key certificates and to manage key certificates that are installed for the SMTP virtual server. See the appropriate article for more details on using certificates with Virtual Servers in Exchange Server:

- Set TLS encryption levels for the Secure SMTP Virtual Server

To configure the Secure SMTP VS to require inbound TLS Encryption follow these steps:

1. Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
2. Expand Administrative Groups, expand AdministrativeGroup, expand Servers, expand ServerName, and then expand Protocols.
3. Right-click the Secure SMTP VS, and then click Properties.
4. Click the Access tab, and then click Authentication.
5. Click to select the Requires TLS encryption check box.
6. Click OK, then click OK again.

Note: Under the Access tab on the Secure SMTP VS properties, Communication button, there is additional level of security that can be enabled, "Require Secure channel", this will require TLS communication between any and all SMTP communication to or from the Secure SMTP VS even between SMTP Virtual Servers on the same Exchange server, and would require a certificate be installed on the Default SMTP VS, as well as any other SMTP Virtual Servers in the same Routing Group.

- Creating and Configuring the Secure SMTP Connector

Create a new SMTP Connector and configure it as follows:

1. Click Start, point to Programs, point to Microsoft Exchange, and then click System Manger.
2. Expand Administrative Groups, expand AdministrativeGroup, then expand Routing Groups, and then expand the routing group that you want to use as the originator of the connection.
3. Right-click Connectors, point to New, and then click SMTP Connectors.
4. In the Properties dialog box, click the General tab.
5. In the Name box, type a descriptive name for the connector (suggested name Secure SMTP Connector).
6. Also on the General tab, click Forward all mail through this connector to the following smart hosts, and then type the IP address of the remote Bridgehead Server through which you want to route the secure mail flow to the other Routing Group. Enclose the address in square brackets, for example [192.168.1.1].
7. Also on the General tab, click Add, under the Local bridgeheads settings dialog box, and select the Secure SMTP VS that was created in the “Creating and Configuring the Secure SMTP Virtual Server“ section of this document, and then click OK.
8. Click the Connected Routing Groups tab, and then click Add.
9. Select the remote routing group with which you require secured mail flow, then click OK.
10. Click the Advanced tab, Click the Outbound Security button, and check the TLS Encryption check box.
11. Click OK, then click OK again.

Note: These steps can also be used to connect two separate Exchange Organizations, instead of using the Connected Routing Groups tab, use the Address Space tab, on the Secure SMTP Connector to configure the remote domains SMTP Address space.

Note: On the Delivery Tab of the Secure SMTP VS, Outbound Security button, has a TLS encryption checkbox, it is not recommended to enable this setting. If this is enabled, it will force TLS encryption between the Secure SMTP VS and other Exchange/SMTP Servers in the same Routing Group.

To verify that the SMTP Traffic is encrypted, start a Network Monitor capture on one of the Secure SMTP Bridgehead Servers, and then initiate an SMTP mail message from a client on one side of the secured mail flow environment once the mail is delivered, stop the capture, and then examine the packets that were sent. Note that all SMTP packets between the Secure SMTP Bridgehead Servers with a destination of port 25 (0019h) are encrypted.