Elan Shudnow’s Blog

There seems to be some confusion as to how TLS connectivity between a Hub Transport and Edge Transport works. A large reason for this is due to the Exchange 2007 Edge Transport Server not being a part of your Corporate Active Directory.  Because of this, people may think, that by default, Hub SMTP communication between a Hub Transport and Edge Transport is not encrypted and are asking, “How to secure SMTP communication between a Hub Transport and Edge Transport is encrypted.” Well the answer is, it already is…. Let me explain.

One of the steps in connecting your Edge Transport Server is to export an Edge Subscription XML file once all your Edge Transport prerequisites are done.  An explanation of these prerequisites is out of the scope of this article.  There are many things that occur during XML export process and import process.

To export an XML, you would run the following command:

New-EdgeSubscription -FileName “C:\Edge.XML”

As stated, there are many things that happen during the export.  Before running the above command, you want to ensure you have a certificate on your Edge Transport Server that is enabled for SMTP use.  To check this, you can run the following command:

Get-ExchangeCertificate

You should see that your server has a self-signed certificate that lasts for one year and is enabled for SMTP.

When exporting our XML file, the private key is stored in the local computer store and the public key is written to the Edge Subscription file.  Because of this, when you submit the XML file to the Hub Transport for importing, the Hub Transport will store a copy of this public key in Active directory. The Hub Transport will then use Active Directory as a Trusted Storage mechanism to validate the Edge Transport’s certificate. Vice Versa, when your Hub Transport and Edge Transport are now connected with each other, the Hub Transport will send a copy of its’ public key for an Edge Server to store in ADAM. It is because of this, both servers are allowed to take advantage of TLS communications for the secure transport of SMTP.

You don’t have to use a self-signed certificate.  If you don’t want your certificate to expire in one year and have to mess with it, you can use your own PKI cert or even a certificate from a 3rd party vendor.

Now what happens when you are approaching your certificate expiration date.  Well, even if your certificate expires, mail will still flow.  This is because our Transport servers use something called Opportunistic TLS. If you look at the Authentication Tab of your Connector, only Transport Layer Security will be selected. This is called Opportunistic TLS which means that TLS will be accepted and is the preferred method for communication, but TLS will not be required.  So even if your certificate expires, all that means is that mail will still flow, but less secure since TLS will not be able to be used.

As you can see, Transport Layer Security is selected.  Opportunistic TLS means that any time a sending server attempts to issue a StartTLS, our Exchange server will accept TLS communications and encrypt the communications.  By default, an Exchange 2007 Send Connector will attempt to issue StartTLS using the defined parameter IgnoreSTARTTLS which is set to 0 by default.  In order to see the setting on your Exchange Servers, you can type the following command:

Get-SendConnector “SendConnectorName” | fl

If you look on your Hub Transport, you may think that you see a Send Connector there going to your Edge.  This won’t be the case. A configuration object in Active Directory has a Site Association for an Edge Subscription.  Because of this, mail flowing from a Hub Transport to an Edge Transport utilizes the hidden Intra-Organization Send Connectors.

You will however, see the connectors that live on the Edge Transport Server. In reality, these Send Connectors or the Edge Server were created on our Hub Transport and live in Active Directory.  These Send Connectors get pushed out to the Edge Server via Edgesync replication.  To force this replication, you can type the following command:

Start-EdgeSynchronization

You should then see your Send Connectors on your Edge Transport Server.

Now you can launch the Exchange Management Shell and run the Get-SendConnector command above on the connector which points to our Hub Transport Servers; which is the connector I highlighted.  Run the following command:

Get-SendConnector “edgesync - inbound to default-first-site-name” | fl

As you can see, IgnoreSTARTTLS is set to false which means our Send Connector will allow Mutual TLS to take place if the Receive Connector advertises StartTLS; which it does by default.  So as long as your IgnoreSTARTTLS settings are False, Opportunistic TLS is enabled, and your certificate is valid, Secure SMTP using TLS will work between your Hub Transport and Edge Transport Servers.

Now what happens when our certificate expires?  Well, we can renew our certificate on our Server.  There are some good instructions here.  One difference you’ll want to do is instead of enabling the certificate for IIS, you’ll want to enable the certificate for SMTP.

Now don’t forget that earlier in this article, I talked about how the Edge Transport and Hub Transport trust each other’s certificates.  Because we have a new certificate, we’ll have to re-subscribe our Edge Servers to our Hub Transport Servers.  This way, our Hub Transport can receive our new certificate and store it in Active Directory for a Direct Trust.

If you ever introduce new Hub Transport servers, they’ll be able to send and receive mail securely due to the Intra-Org Send Connector and using Active Directory as a Trusted Storage Mechanism, but these new Hub Transport Servers will not be able to participate in Edgesync replication.  In order to allow for this, your Edge Transport Servers will need to be re-subscribed, especially if you want the Edge Transport to be able to send mail securely to this new Hub Transport.  That is because, as I stated before, part of the initial process of subscribing an Edge Transport is the Hub Transport placing its’ certificate into ADAM.

When you go to renew your Hub Transport certificates, a simple Start-EdgeSynhcronization will take the Hub Transport certificates and place them into ADAM so the Edge Transport Servers will trust your Hub Transport Servers.

Elan Shudnow :: Aug.20.2008 :: Exchange :: No Comments »

I have seen a lot of questions on what will happen to Outlook profiles when you migrate a user to Exchange 2007.  First, let me say, that in order for you to migrate to Exchange 2007, you have to upgrade your previous version of Exchange (2000 or 2003) to the latest service pack.  That is part of the puzzle as the latest service pack enables the functionality for an Outlook client to automatically updates its’ profile.

So, let’s take a look at the release notes for Exchange 2003 SP2 which you can find here.  The part we are interested in is:

Changes to how DSProxy Referral Mechanism Works

In Exchange Server 2003 SP2, the DSProxy referral process now tries to provide an Outlook client that has a global catalog that belongs to the same domain as the mailbox-enabled user by using a new algorithm. The new algorithm examines all global catalog servers that are directly connected to the Exchange server Active Directory site and provides the client with a global catalog that resides in the same domain as the mail recipient, if possible. This means that Exchange can now refer clients to out-of-site global catalog servers if there are no mailbox home domain global catalogs available in the Exchange server Active Directory site. For detailed information about DSProxy in SP2, see Microsoft Exchange Server 2003 Technical Reference Guide.

Elan Shudnow :: Aug.04.2008 :: Exchange :: 1 Comment »

I have seen many people encounter issues with publishing Symantec Enterprise Vault behind ISA 2006.  For our scenario, OWA users go through ISA both internally as well as externally.  Why do we do this?  Well, when you are publishing OWA 2007 behind ISA 2006, one of the requirements is to go onto your Exchange 2007 Client Access Server (CAS) and disable Forms Based Authentication and enable Basic Authentication instead. This is because ISA 2006 will be using Forms Based Authentication. Switching OWA on Exchange 2007 to use Basic Authentication instead of Forms Based Authentication allows us to avoid being prompted twice for authentication (once by ISA and then once by Exchange).  Basic Authentication on the CAS allows ISA to pass the authentication through to Exchange without being prompted a second time.

So why do we point both internal and external users through ISA?  That is because we want users to get the same OWA experience both internally and externally.  We don’t want internal users pointed directly to Exchange and get a Basic Authentication prompt while external users get Forms Based Authentication when outside the corporate network.  By pointing internal and external users directly through ISA, they will get the same experience internally and externally.

As you can see in the following image, in Symantec Enterprise Vault, IIS contains several directories which include a directory called EnterpriseVault:

Prerequisite

Properly configure IIS on your Client Access Server (CAS) to host the certificate(s) needed for external and internal access. The certificate recommended for this configuration is a Unified Communications (UC) certificate. You can read more about these different configurations here.

Note: For this article, we will be using a UC certificate that contains 4 Subject Alternative Names (SANs). Our requested certificate’s CN was webmail.shudnow.net. The first SAN name requested was also webmail.shudnow.net. Our request was created using the following EMS command:

New-Exchangecertificate -domainname webmail.shudnow.net, autodiscover.shudnow.net, casserver.shudnow.net, casserver -Friendlyname Shudnow -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true -subjectname “c=US, o=Shudnow Inc, CN=webmail.shudnow.net”

1. NetBIOS name of CAS (casserver)- used if there is a need/want to connect to services such as OWA using the NetBIOS name of the CAS while connected to the internal network.
2. FQDN name of CAS (casserver.shudnow.net)- used so we can publish Autodiscover internal URLs to point directly to the CAS.  This name is required if your Exchange Server will be hosting the Unified Messaging rule and you plan on integrating  Unified Messaging into your Office Communications Server 2007 Enterprise Voice envirnment.  If you have an internal PKI, I would recommend leaving this FQDN out and requesting a certificate with this FQDN to avoid exposing your servername to the public.
3. Autodiscover.shudnow.net - used so external clients can retrieve external URLs to connect to web distributed services.
4. Intuitivname.shudnow.net - used for services such as Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, web service distribution (OAB, OOF, and Availability). Common FQDNs used are exchange.domain.com, owa.domain.com, mail.domain.com, webmail.domain.com, etc. This article will use the example FQDN: webmail.shudnow.net.

Note: For purposes of this article, the only name in your certificate that is essential for publishing Symantec Enterprise Vault is #4 (Intuitivename.shudnow.net). But since you are requesting a certificate, I would advise you to properly create a certificate with any other names that are required which include #1-4.

You will also want to do the following:

1. At the minimum, the ISA 2006 Supportability Update is required which is located here.  I would recommend using SP1 instead which is located here.
2. Create an Exchange Web Listener

ISA 2006 Configuration

You must ensure that you go onto the CAS and export the certificate with its private key and import that into ISA 2006 (Please make sure you have the licenses needed for installing a certificate on multiple servers if required by your certificate vendor). A guide on how to do this is out of the scope of this blog. Once the certificate has been imported on the ISA 2006, ISA configuration can begin. Start by publishing each Exchange 2007 role as needed. For purposes of this article, we will only show how to publish your Enterprise Vault rule and steps needed to configure your OWA publishing rule to get Enterprise Vault to work through OWA.

Enterprise Vault Publishing Rule

For our Enterprise Vault publishing rule, we will go to Servername > Firewall Policy > New > Website Publishing Rule.

Give your Website Publishing Rule a name. Click Next to Continue.

Select Allow. Click Next to Continue.

Since we will be publishing a single Enterprise Vault Server, choose “Publish a single Web site or load balancer.” Click Next to Continue.

If you have installed a certificate for your Enterprise Vault Server, choose “Use SSL to connect to the published Web server or server farm.”  If you have not installed a certificate for your Enterprise Vault Server, choose “Use non-secured connections to connect the published Web server or server farm.”  We did install a certificate on our Enterprise Vault Server, so we will choose the first option. Click Next to Continue.

Enter the Internal Site name of your Enterprise Vault Server.  Then enter the IP Address of your Enterprise Vault Server. Click Next to Continue.

Because the IIS directory name on your Enterprise Vault Server is called EnterpriseVault, you must enter that name in the Path (Optional) field as is displayed in the following screenshot. Click Next to Continue.

Because we will be accessing Enterprise Vault through OWA, we will want to make to enter our OWA URL name in the Public Name field.  For purposes of this lab, our OWA URL will be webmail.shudnow.net. Click Next to Continue.

You will want to select the Listener you created for your Exchange environment. Click Next to Continue.

Select Basic Authentication. Click Next to Continue.

Leave the setting to All Authenticated Users. Click Next and then Finish.

Once you have finished the creating the publishing rule, go into the properties of your Enterprise Vault publishing rule and go to the Paths tab.  Ensure your paths display as follows (which they should if you followed the above correctly). Click OK to Finish.

OWA Publishing Rule

Typically, you create your OWA publishing rule using the Firewall Policy, “Exchange Web Client Access publishing Rule.”  There is a bug that prevents you from setting up Link Translation rules that are needed to get Enterprise Vault to work.  Because of this, make sure you write down all your settings for OWA because we will need to re-create the OWA publishing rule using a regular, “Web Site Publishing Rule.”  We will not go through the entire steps of creating the OWA publishing rule, but will rather go through the modification of this rule to ensure Symantec Enterprise Vault works.

So now we have our two publishing rules:

Open your Exchange OWA publishing rule and go to the Link Translation tab and select “Apply link translation to this rule.”  Click Next to Continue.

We will now want to make some Link Translation Mappings

These mappings include:

How does this work?

A user connects to OWA using webmail.shudnow.net.  They will attempt to access Enterprise Vault.  Because they are connected to OWA, you want them using the webmail.shudnow.net name.  ISA will create a link translation rule so when the user tries to access the Enterprise Vault rule, they will use the webmail.shudnow.net name instead.  But because ISA has the Enterprise Vault publishing rule, ISA knows how to proxy those requests to Enterprise Vault.  The reason we created the Public Name as webmail.shudnow.net for the Enterprise Vault rule is because this rule uses the listener for Exchange which contains a certificate that does not include the certificate that contains the entvault.shudnow.net name.  It does contain the webmail.shudnow.net name though.

Elan Shudnow :: Jun.24.2008 :: Exchange, ISA, Symantec :: No Comments »

Overview

The Messaging API is a COM-like API that provides access to the contents of messaging stores. CDO 1.2.1 (Collaboration Data Objects, version 1.2.1) is a package providing access to Outlook-compatible objects through a COM-based API. Using either CDO or MAPI, a program can connect to a MAPI store, and then perform operations against that store. Starting with Exchange 2007, Microsoft will distribute the MAPI client libraries and CDO 1.2.1 as a Web download.

System Requirements

This download is available here.

Elan Shudnow :: Jun.02.2008 :: Exchange :: 2 Comments »

I wanted to share some of my findings with running Exchange 2007 SP1 on Server 2008. I’ve noticed and heard of several issues and information that I believe people should be cognizant about.

Here are the issues and general information I have heard of and experienced so far that seems to be valuable to share. If you disagree with anything I am sharing, have found it works in a different way for you, and/or want to include your findings and any tidbits of information you may have, please feel free to comment.

• Hub Transport Server Role fails when IPv6 is disabled on that server
  • If IPv6 is disabled prior to the installation of Exchange Server 2007, when installing the Hub Transport Server role, your Hub Transport Server role will fail to install
  • If IPv6 is disabled after the installation of Exchange Server 2007, you may experience some Exchange services failing to start

• Outlook Anywhere is broken under certain conditions
  • Outlook Anywhere is not working for Outlook 2007 with IPv6 enabled (More information can be found from the following URLs: http://blog.aaronmarks.com/?p=65 and http://www.buit.org/2008/01/04/outlook-anywhere-is-broken-on-ipv6-in-windows-server-2008). I’m not sure if this also happens with previous versions of Outlook. The first link refers to Outlook 2007 while the second link refers to Outlook. I would figure this would be for all Outlook versions since RPC over HTTP proxy is not Outlook version specific. I can’t think of anything that would cause this to fail via Outlook 2007 and not previous versions of Outlook. But from what I’ve heard, this is definitely happening with Outlook 2007. More information below.
  • This bug consists of the fact that IPv6 is not listening on the loopback port 6004 (RPC/HTTP Proxy Service). This is causing Outlook Anywhere to fail with Outlook 2007. Not sure if this happens with previous versions of Outlook. The reason for this is because Server 2008 prefers communication using IPv6 over IPv4. Since IPv6 is not listening on port 6004, Outlook Anywhere will fail.

  TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
  TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING
  TCP 0.0.0.0:6004 0.0.0.0:0 LISTENING
  TCP [::]:6001 [::]:0 LISTENING
  TCP [::]:6002 [::]:0 LISTENING

  • People have been disabling IPv6 within the registry to ensure that IPv6 is not active at all so Outlook Anywhere will use IPv6 which is listening on IPv6. The problem with disabling IPv6, is if the CAS is also on the HTS, HTS will fail. So in this case, there are several options. The first being deal with the bug. The second being separate the CAS and the HTS so you can disable IPv6 on the CAS and leave IPv6 on the HTS on. The third option is presented in the second URL above which includes making some modifications to your host file.
  • Microsoft has stated this has been added to the QFE list for SP2

• NTLM seems to be very buggy with Outlook Anywhere. There are lots of reports of Outlook Anywhere NTLM Authentication not being functional when using Server 2008. More information can be found from the following URL: http://blog.aaronmarks.com/?p=65.
• OAB Generation fails on Server 2008 Clusters.  More information can be found from the following URL: http://www.spyordie007.com/blog/index.php?mode=viewid&post_id=25

• There is an HP Document (http://h71028.www7.hp.com/ERC/downloads/4AA1-5675ENW.pdf) which goes over some testing with varying network latencies using CCR over an OC3 link with a network latency simulator. I wanted to give an overall summary of their findings.
  • 20 ms latency – All the log files were shipped over properly and all CCR databases auto-mounted properly
  • 30-40 ms latency – Some manual mounting will be required to mount all your databases as the latency will prevent all logs to be shipped over fast enough for automatic mounting
  • 50+ ms latency – Log shipping mechanism was out of control

• In regards to SCR and the network latency topic. SCR is a manual failover mechanism. Because of this, CCR is a lot more dependent on network latency due to its automatic failover mechanism. Microsoft does provide recommendations on how to tune SCR for latency on the Exchange Technet Library which can be found here. The problem here is the article is geared for Server 2003 Networking. As for real world SCR scenarios, I have been told that a mailbox server that contains ~6,000 mailboxes has been successfully failed over to an SCR target across the world over a 200 ms link.

Update 1: There has been an update in regards to NTLM Authentication issues from the Microsoft Exchange Team Blog here.

Sid quoted the following:

As promised, here’s an update on the reprompting issue that many of you have encountered.

The gist of the issue is that IIS7 uses kernel mode windows authentication by default. Turning this off will fix reprompting. I will post a detailed update once I dig through some more and talk to the IIS PD, but for now I wanted to provide this update so you can give
it a shot and let me know if (no, “that”) it works for you.

Here’s the command that needs to be run on the CAS boxes ->

%Windows%\inetsrv\appcmd.exe set config /section:system.webServ

er/security/authentication/windowsAuthentication /useKernelMode:false

Update 2: From the same blog article in Update 1 here, you will find updated guidance on disabling IPv6 depending on what roles you have on your server.  You can also read the official Technet Documentation here.

Update 3: NTLM Authentication issues have been resolved in Release Update 4 for SP1 here.

Update 4: Microsoft has an interim  hotfix for the OAB issue.  Contact Premiere Support Services (PSS) for this hotfix.

Elan Shudnow :: May.22.2008 :: Exchange, Server 2008, Windows :: 1 Comment »

Welcome to Part 4 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 SP1 Failover Clustering. We first discussed what the lab setup is going to be using VMware Workstation, and then proceeded to the configuration of RocketDivision’s StarWind iSCSI Target software. We then went into Exchange 2007 and did the initial iSCSI Initiator connection to our iSCSI Target.

In Part 2, we prepared our Cluster Nodes by installing any prerequisites needed prior to the cluster formation and Exchange 2007 SP1 installation. When that was complete, we continued with our iSCSI configuration by adding our LUNs to the Cluster Nodes, partitioned these LUNs, formatted these LUNs, and ensuring that shared disk storage was working as intended.

In Part 3, we formed our cluster beginning with Node A followed by Node B. Once our cluster was formed, we will proceed with configuring the cluster to ensure optimal operating for our Exchange server. This consisted of cluster network configuration, quorum configuration, etc. Once configuration was completed, we validated cluster operations. This included testing failover.

In this final Part, we will install Exchange into our Cluster. The first step will be to install the Active Clustered Mailbox Role followed by our Passive Clustered Mailbox Role. We will then proceed with how to manage our new Exchange Cluster.

Part 1

Part 2

Part 3

Part 4

Active Node Exchange 2007 Cluster Installation (NodeA)

Final Preparation

We have finally reached the point where we will install Exchange 2007. Don’t forget that one of the prerequisites is to already have a Client Access Server and Hub Transport Server deployed. If you have not done this yet, I suggest you go do this before proceeding.

Insert your Exchange 2007 SP1 media (SP1 media required) and insert it into our Active Node. In the case of this lab, we are using VMware, so I will be mounting an ISO image to our Active Node (NodeA).

Please ensure that NodeA is currently the Active Node before proceeding. Go to Start > Administrative Tools > Failover Cluster Management > Expand our Cluster > Nodes. Once here, we can view both Nodes and see what disks they currently own.

If NodeA does not currently have ownership of our Database and Disk Quorum disk, run the following commands:

Cluster group “Available Storage” /move:<ActiveNodeName>

Cluster group “Cluster Group” /move:<ActiveNodeName>

Note: There are two Cluster Groups. The first is Available Storage which contains our Database Disk. The second is the Cluster Group which contains our Quorum Disk. It is only essential that NodeA owns the Database disk for installation. For safe measures, I still like to make sure the node we are working on owns both the Database and Quorum Disk.

Installation

Run Setup.exe and choose to Install Exchange Server 2007 SP1. This will bring you to several Pages in which you should review, accept, and continue. These pages include the Introduction Page, License Agreement, and Error Reporting, . Review this information and click Next to Continue.

Once you have reached the Installation Type page, select Custom Exchange Server Installation. We will want to use this option because the Typical Exchange Server Installation installs the Hub Transport Server Role, Client Access Server Role, and Mailbox Server Role. Because we are installing the Mailbox Server Role on a Cluster, we are limited to installing only the Mailbox Server Role. This is the reason why we have installed a Hub Transport Server and Client Access Server on another server prior to installing the Mailbox Server Roles on our Cluster Nodes. Click Next to Continue.

At the Server Role Selection page, choose Active Clustered Mailbox Role. As you can see, all other options have been greyed out and you are forced to install the Management Tools. Click Next to Continue.

At the Cluster Settings page, choose Single Copy Cluster. Then specify the name of the Clustered Mailbox Server Name. This is the name your users will see when specifying what server their mailbox is housed on. Finally, choose the path your database files will be installed. You cannot choose the root path and will be forced to create a subfolder. Click Next to Continue.

Select the IP Address that the Cluster Mailbox Server (CMS) EXServer01 will listen on. In the case of this lab, NodeA uses 192.168.119.160, NodeB uses 192.168.119.161, so we will use 192.168.119.162. We do not need to specify a Second Subnet as we are not deploying our Cluster across multiple subnets. Click Next to Continue.

Choose your Client Settings. If you have computers running Outlook 2003 or earlier or Entourage, choose Yes. Otherwise, choose No. If the wrong option is chosen, don’t worry, you can always add public folders once Exchange is installed. Click Next to Continue.

You will begin to see Readiness Checks being run for both the Mailbox Role as well as the Clustered Mailbox Server. Once this is completes successfully, click Install to Continue. If you have any failures, those failures will need to be remedied prior to continuing with the cluster installation.

Installation will commence. Upon a sucessful instatllation completeion, you will see status of all installation steps shown as Completed. If cluster installation has been unsuccessful, troubleshooting will need to ensue to ensure you can get Exchange installed on the cluster successfully. Clear the check box, “Finalize installation using the Exchange Management Console.” Click Finish to continue.

You will be prompted to reboot, but do not reboot. There is one step you will want to do prior to a reboot. Open the Exchange Management Shell (Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell).

We will now stop the CMS by running the following command:

Stop-ClusteredMailboxServer <CMSName> -StopReason Setup -Confirm:$false

You may now proceed to reboot NodeA. One thing to note, is that when you reboot NodeA, the disks will be moved over to NodeB which does not have Exchange installed. Because of this, once NodeA is back up, you will want to move the CMS group, Available Storage group, and Cluster Group group back to NodeA.

To get a list of the existing Cluster Groups that are installed, type the following command in the Command Prompt:

Cluster Group

As we can see, the Cluster Groups successfully moved over to NodeB. The reason why we wanted to turn off the CMS prior to shutting down, is because NodeB does not have Exchange installed and we don’t want the CMS try attempt to come online.

Run the following three commands to move all three groups back over to NodeA:

Cluster group “Available Storage” /move:NodeA

Cluster group “EXServer01″ /move:NodeA

Cluster group “Cluster Group” /move:NodeA

We will now want to move the storage that is currently in the Available Storage group over to the CMS group, EXServer01. The Database disk, named database, is the only disk currently in the Available Storage group. To do this, we will run the following command:

Cluster res “Cluster Group” /move:NodeA

Continue by making the Database disk a dependency of our Exchange Database. To find out how you will want to format the Database name for the dependency, open up the Failover Cluster Management MMC. Expand our Cluster > Services and Applications > CMS (EXServer01).

Take a look at the highlighted text. That is the name of our Database we will use in our Cluster dependency command. We will now want to make the Database disk a dependency of our Mailbox Database by running the following command:

Cluster EXCCLUS01 res “First Storage Group/Mailbox Database (EXServer01)” /AddDep:”Database”

The final configuration of NodeA is to configure the physical disk resource policies so that a failure of a disk resource does not cause failover of the CMS to another node by running the following command:

Cluster EXCCLUS01 res “Database” /prop RestartAction=1

Passive Node Exchange 2007 Cluster Installation (NodeB)

Final Preparation

Insert your Exchange 2007 SP1 media (SP1 media required) and insert it into our Passive Node. In the case of this lab, we are using VMware, so I will be mounting an ISO image to our Passive Node (NodeB).

Please ensure that NodeA is currently the Active Node before proceeding. Open a Command Prompt and type the following command:

Cluster group

We should see NodeA as the owner of all three Cluster Groups. If NodeA does not currently have ownership of all the Cluster Groups, run the following commands:

Cluster group “Available Storage” /move:NodeA

Cluster group “EXServer01″ /move:NodeA

Cluster group “Cluster Group” /move:NodeA

Installation

Run Setup.exe and choose to Install Exchange Server 2007 SP1. This will bring you to several Pages in which you should review, accept, and continue. These pages include the Introduction Page, License Agreement, and Error Reporting, . Review this information and click Next to Continue.

Once you have reached the Installation Type page, select Custom Exchange Server Installation. We will want to use this option because the Typical Exchange Server Installation installs the Hub Transport Server Role, Client Access Server Role, and Mailbox Server Role. Because we are installing the Mailbox Server Role on a Cluster, we are limited to installing only the Mailbox Server Role. This is the reason why we have installed a Hub Transport Server and Client Access Server on another server prior to installing the Mailbox Server Roles on our Cluster Nodes. Click Next to Continue.

At the Server Role Selection page, choose Passive Clustered Mailbox Role. As you can see, all other options have been greyed out and you are forced to install the Management Tools. Click Next to Continue.

You will begin to see Readiness Checks being run for both the Mailbox Role as well as the Clustered Mailbox Server. Once this is completes successfully, click Install to Continue. If you have any failures, those failures will need to be remedied prior to continuing with the cluster installation.

Installation will commence. Upon a sucessful instatllation completeion, you will see status of all installation steps shown as Completed. If cluster installation has been unsuccessful, troubleshooting will need to ensue to ensure you can get Exchange installed on the cluster successfully. Clear the check box, “Finalize installation using the Exchange Management Console.” Click Finish to continue.

Once you have reached this step, congratulations, your Exchange Cluster has finally been fully deployed. You will be prompted to reboot. Go ahead and do so.

All there is really now is to start the CMS back up, and you’re done; besides general configuration. To start the Exchange CMS, open the Exchange Management Shell (Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell).

We will now start the CMS by going on NodeA and running following command:

Start-ClusteredMailboxServer <CMSName> -Confirm:$false

Just to ensure that all Cluster Groups are online, run the following command:

Cluster Group

Post Installation

Generally, now would be the time to go do your general configuration. This includes licensing, configuring the Autodiscover Service, set Quotas, etc…

Before we do any of that, let’s make sure that the CMS will fail over to to NodeB. You can use the Cluster Group /move command, but it is best practice to use the Exchange Management Shell (EMS) command, Move-ClusteredMailboxServer. This is required in CCR Clusters due to the Cluster command not being Microsoft Cluster Service Aware which can ultimately break the log shipping mechanism.  You can read more about using Cluster Group /move vs Move-ClusteredMailboxServer here.

Let’s move our CMS over to NodeB by running the following command in the EMS:

Move-ClusteredMailboxServer EXServer01 -MoveComment “Failover to NodeB” -TargetMachine:NodeB -Confirm:$False

After running this command, go into the Failover Cluster Management MMC. Expand our Cluster > Services and Applications > CMS (EXServer01). There are a few things to take note of here. There are two preferred owners of this CMS, NodeA and NodeB. This means, if NodeA is the current owner of the resources of this CMS and it goes down, NodeB will take over. The same goes in a vice versa scenario.

As we can see, the current owner is NodeB which means the Move-ClusteredMailboxServer command was successful. All the “Other Resources” which are the Exchange Resources are also currently online. We have a successful verified Exchange Cluster failover.

Moving the CMS via the EMS is not the only way to move a CMS. Ever since Exchange Server 2007 SP1 was released, the ability to move a CMS to another node was added into the Exchange Management Console (EMC). So let’s go check out this command and move the CMS back over to NodeA, but this time, by using the EMC (Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Console). Then Expand Server Configuration > Mailbox > Choose Managed Clustered Mailbox Server from the Action Pane.

Select the option “Move the clustered mailbox server to another node.” Select Next to Continue.

Select NodeA as your Target Machine and set the Move comment to whatever you like. Select Next to Continue.

Review the Configuration Summary. Once satisfied, Choose Move to Continue.

Once again, after executing this move, go into the Failover Cluster Management MMC. Expand our Cluster > Services and Applications > CMS (EXServer01). As we can see, the current owner is NodeA which means the move via the EMC was successful. All the “Other Resources” which are the Exchange Resources are also currently online. We have a successful verified Exchange Cluster failover.

Summary

Well folks, that is all for Part 4 of this article and concludes this article series. To recap on what was included in Part 4 of this article series, we first started off recapping what was included in Part 1, Part 2, and Part 3 of this article and what the goal of this lab is for. It is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 Failover Clustering. In Part 2, we left off at the final stages of disk preparation. All of the shared disks were successfully portioned, formatted, and named. In Part 3, we formed the cluster, beginning with Node A followed by Node B. We then proceeded with configuring the cluster networks, quorum, and validated our failover cluster worked.

In Part 4, we installed the Exchange 2007 Active Clustered Mailbox role and the Passive Clustered Mailbox role. We then performed management on our Clustered Mailbox Server (CMS) by showing how we can move the CMS via the Exchange Management Shell (EMS) as well as using the Exchange Management Console (EMC).

I hope these articles will help you out on your endeavor to installing Exchange 2007 on Windows Server 2008. Thank you for viewing.

Elan Shudnow :: Apr.28.2008 :: Exchange, Server 2008, Windows :: 1 Comment »

Welcome to Part 3 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 SP1 Failover Clustering. We first discussed what the lab setup is going to be using VMware Workstation, and then proceeded to the configuration of RocketDivision’s StarWind iSCSI Target software. We then went into Exchange 2007 and did the initial iSCSI Initiator connection to our iSCSI Target.

In Part 2, we prepared our Cluster Nodes by installing any prerequisites needed prior to the cluster formation and Exchange 2007 SP1 installation. When that was complete, we continued with our iSCSI configuration by adding our LUNs to the Cluster Nodes, partitioned these LUNs, formatted these LUNs, and ensuring that shared disk storage was working as intended.

In this Part, I will be forming our cluster beginning with Node A followed by Node B. Once our cluster is formed, we will proceed with configuring the cluster to ensure optimal operating for our Exchange server. This consists of cluster network configuration, quorum configuration, etc. Once configuration is completed, we will validate cluster operations. This includes but is not limited to testing failover.

Part 1

Part 2

Part 3

Part 4

Failover Cluster Installation (NodeA)

Validate a Configuration

All of our prerequisites have been completed. It is finally time to get the cluster up and running. The first step is to go on NodeA while NodeB is shut down (or paused will suffice in VMware). Go to Start > Administrative Tools > Failover Cluster Management.

This will launch the Failover Cluster Management MMC. The section we will be working with the most is Management.

The first thing we will want to do is Validate a Configuration. This will help ensure that our NodeA has met the prerequisites for cluster formation. Click Validate a Configuration to proceed and then Click Next to bypass the Before you Begin window. Enter the name of our first node, NodeA and click Add. Click Next to Continue.

You are presented with a list of checks that will occur. If you would like to learn more about these checks, click More about cluster validation tests in the bottom part of the window. Click Next to Continue.

You will begin to see each Inventory item be checked. It will result in a Success, Failure, or Not Applicable. Once this is complete, the Cluster Validation Report is displayed. If you have any failures, those failures will need to be remedied prior to continuing the cluster formation.

Create a Cluster

Now that our cluster is validated, we can proceed with the creation of the cluster. Go back to the Failover Cluster Management MMC and then back to the Management section.

Click Create a Cluster. This will launch a wizard which will assist us in creating our cluster. Click Next to bypass the Before you Begin window. Enter the name of our first node, NodeA and click Add. Click Next to Continue.

Select an IP Address that you would like to use for administering the cluster. A name for the cluster must also be created. We will use EXCLUS01 for the cluster name and an IP Address of 192.168.119.220 for the Cluster IP. Click Next to Continue.

We are now provided with confirmation of the settings we will use when forming the cluster. Click Next to Continue.

Installation will begin and a progress bar will be displayed.

Once this is complete, the Cluster Summary Report is displayed notifying you whether cluster installation has been successful or unsuccessful. If cluster installation has been unsuccessful, troubleshooting will need to ensue to ensure you can get the cluster installed successfully. Click Finish to continue. The Failover Cluster Management MMC re-appears. You will now see that there is an EXCCLUS01 hierarchy with options to modify and manage your cluster. This gives you re-assurance that the cluster installation completed successfully.

Adding Cluster Storage

Before we bring up the second Node, we need to ensure we add the shared storage to the cluster due to the cluster installation not detecting shared storage and adding it automatically. As stated in this article series, we want the cluster service to have complete control over access to the shared disks. If both nodes are fighting for disk access at the same time, there is a risk of data loss or corruption. This is why we have only had 1 Cluster Node booted at any given time. When in the Failover Cluster Management MMC, Click on Storage in the hierarchy of EXCLUS01. You will see that no storage exists in the cluster.

In the Action Pane, Click Add a disk. Make sure both disks are selected. Click OK to Continue.

Cluster NodeA now has full control over both disks.

Select Cluster Disk 1 and choose Properties in the Action Pane.

Do the same for Cluster Disk 2 but rename it to Quorum.

Failover Cluster Installation (NodeB)

Validate a Configuration

All of our prerequisites have been completed. It is finally time to get the cluster up and running. The first step is to go on NodeB (It is safe to have NodeA up as the cluster service has control over the disks). Go to Start > Administrative Tools > Failover Cluster Management.

This will launch the Failover Cluster Management MMC. The section we will be working with the most is Management.

The first thing we will want to do is Validate a Configuration. This will help ensure that our NodeB has met the prerequisites for cluster formation. Click Validate a Configuration to proceed and then Click Next to bypass the Before you Begin window. Enter the name of our first node, NodeB and click Add. Click Next to Continue.

Select an IP Address that you would like to use for administering the cluster. A name for the cluster must also be created. We will use EXCLUS01 for the cluster name and an IP Address of 192.168.119.220 for the Cluster IP. Click Next to Continue.

You are presented with a list of checks that will occur. If you would like to learn more about these checks, click More about cluster validation tests in the bottom part of the window. Click Next to Continue.

You will begin to see each Inventory item be checked. It will result in a Success, Failure, or Not Applicable. Once this is complete, the Cluster Validation Report is displayed. If you have any failures, those failures will need to be remedied prior to continuing the cluster formation.

Joining NodeB to Cluster

While on NodeB, open the Failover Cluster Management MMC. Since NodeB is not a part of the cluster, we will see no cluster to manage. Right-Click Failover Cluster Management > Manage a Cluster.

Note: Joining NodeB to the cluster will require less information than it did when initially creating the cluster. This is because your 192.168.119.0 network has been chosen to be the network that administers the cluster.

Type in the Cluster Name EXCLUS01. The NetBIOS name or FQDN should both work if name resolution is properly configured in your environment. Click OK to Continue.

Right-Click our EXClus01 Cluster and choose Add Node…

This will launch a wizard which will assist us in joining our existing EXCClus01 cluster. Click Next to bypass the Before you Begin window. Enter the name of our second node, NodeB and click Add. Click Next to Continue.

At this point, you will be asked to go through another validation which tests both NodeA and NodeB together. One test that is done is taking storage offline to test storage between the cluster nodes. For example, testing disk failover, testing operating system versions between both nodes, and a slew of other tests to ensure that both nodes will function properly together in a cluster . Since I have shown how the validation tests work twice, I will not include a how-to screenshot on running a third validation test. Click Next to Continue once the validation pass succeeds.

We are now ready to add NodeB to our cluster. Click Next to Continue.

Installation will begin and a progress bar will be displayed.

Once this is complete, the Add Node Summary Report is displayed notifying you whether adding NodeB to the cluster has been successful or unsuccessful. If adding the node has been unsuccessful, troubleshooting will need to ensue to ensure you can get NodeB successfully added to the cluster. Click Finish to continue. The Failover Cluster Management MMC re-appears. You will now see that there is NodeB under the Node section in the EXCClus01 cluster hierarchy. This gives you re-assurance that NodeB was added to cluster successfully.

After adding a second node, your disk witness will automatically be selected. In the case of this lab, our disk witness was set to use the database disk. This will need to be changed.

This will be modified later in the article.

Configuring Cluster Network

NIC Configuration

We will now want to configure the cluster networks. In Server 2003 clustering, we had three options:

• Private
• Public
• Mixed

Administrators would configure the NICs in one of two different ways depending on the cluster design/needs:

Method 1 (Public/Private)

Public NIC - Public

Private NIC - Private

Method 2 (Mixed/Private)

Public NIC - Mixed

Private NIC - Private

In Method #1, the Public NIC could only be used for client communication and not heartbeat communication while the Private NIC was the only NIC used for heartbeat communication.

In Method #2, the Public NIC and Private NIC were used for hearbeat communication but the Public NIC was the only NIC allowed to accept client communication via the corporate network. In this case, the Private NIC was given a higher priority for cluster communication so the cluster hearbeat would preferrably use the Private NIC. In case of Private NIC failure, you would still be able to use the Public NIC for temporary heartbeat communication. This is my preferred method for reasons of redundancy, and is also the method that is used in Server 2008.

Note: When configuring clustering in Server 2008, you cannot use one NIC as Public and one NIC as Private anymore. You must use one NIC as private and one NIC as mixed (which would be Method 2).

Clustering NIC configuration options are as follows:

When in the Failover Cluster Management MMC, Click on Networks in the hierarchy of EXCLUS01. You will see that two Networks exist.

There are three types of Cluster Use:

• Enabled = Mixed
• Internal = Private
• Disabled = Unmanaged

Select Cluster Network 1 and choose Properties in the Action Pane.

We will then want to take a look at the options that are specified on this Cluster Network 1. We see that this is the NIC that belongs to our corporate network that we will want to use for both Client Communications as well as heartbeat communications. As I said earlier, we must configure 1 NIC to be mixed and 1 NIC to be private; this NIC being the public NIC as it belongs to our public 192.168.119.0/24 network.. Selecting both “Allow the cluster to use this network” and “Allow clients to connect through this network” equate to mixed mode. After ensuring these settings are correct on your Public NIC, rename the Cluster Network 1 to something that is more intuitive, such as Public.

Select Cluster Network 2 and choose Properties in the Action Pane.

We will then want to take a look at the options that are specified on this Cluster Network 1. We see that this is the NIC that belongs to our private heartbeat network that we will want to use solely for heartbeat communications. As I said earlier, we must configure 1 NIC to be mixed and 1 NIC to be private; this NIC being the private NIC as it belongs to our private 10.10.10.0/24 network. Selecting “Allow the cluster to use this network” without the option “Allow clients to connect through this network” equate to private mode. After ensuring these settings are correct on your Public NIC, rename the Cluster Network 2 to something that is more intuitive, such as Private.

Hearbeat Tolerance Configuration

Exchange 2007 also requires we use Cluster.exe to configure tolerance for missed cluster heartbeats. To do this, open a Command Prompt.

We will first want to ensure that each of our Cluster Nodes are currently online. To do this, type the following command in the command prompt: cluster EXCClus01 Node

Ensure that the Status for each node is Up. If this is successful, run the following two commands on your cluster to configure the heartbeat tolerance:

cluster EXCClus01 /prop SameSubnetThreshold=10

cluster EXCClus01 /prop CrossSubnetThreshold=10

Configuring Disk Majority Quorum

Earlier in the article, it was stated that once NodeB joined the cluster, the Disk Witness Disk was automatically chosen. Unfortunately, the disk witness went onto the Database disk instead of the Quorum Disk.

To configure the Cluster Quorum Settings, Right-Click EXClus01 > More Actions > Configure Cluster Quorum Settings…

Click Next to bypass the Before you Begin window.

We are presented with what type of Quorum we want to use. Ensure that “Node and Disk Majority (recommended for your current number of nodes” is selected. Click Next to Continue.

We can now see why the Database was being used for Quorum. There is a checkmark for the Database to be used. Uncheck this and place a checkmark next to Quorum. Click Next to Continue.

We are now ready to add NodeB to our cluster. Click Next to Continue.

Configuration will begin and a progress bar will be displayed.

Once this is complete, the Configure Cluster Quorum Settings Summary Report is displayed notifying you whether configuring the Cluster Quorum has been successful or unsuccessful. If configuring the Cluster Quorum has been unsuccessful, troubleshooting will need to ensue to ensure you can get the Cluster Quorum successfully configured. Click Finish to continue. The Failover Cluster Management MMC re-appears. You will now want to go back into the Storage section and verify the Quorum is configured to use the Quorum disk.

Now that we have everything configured with the cluster, we will want to test failover to make sure the cluster is functioning properly before we attempt to install Exchange. For this, I disabled both NICs on NodeA. I then went onto NodeB, opened the Failover Cluster Management MMC, and looked at the Storage. As you can see, both disks moved to NodeB. I opened the volumes via Windows Explorer and successfully viewed the .txt files I created in previous articles. Success!

I then proceeded to pausing my lab in VMware. I began by pausing NodeB and then verified that storage successfully moved to NodeA; which it did. Success again!

Summary

Well folks, that is all for Part 3 of this article. To recap on what was included in Part 3 of this article series, we first started off recapping what was included in Part 1 and Part 2 of this article and what the goal of this lab is for. It is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 Failover Clustering. In Part 2, we left off at the final stages of disk preparatation. All of the shared disks were successfully partioned, formatted, and named.

In Part 3, we formed the cluster, beginning with Node A followed by Node B. We then proceeded with configuring the cluster networks, quorum, and validated our failover cluster worked.

For Part 4, I will detail the following:

• Install the Exchange 2007 Active Clustered Mailbox Role in our Single Copy Cluster
• Install the Exchange 2007 Passive Clustered Mailbox Role in our Single Copy Cluster
• Management our Exchange Cluster

Elan Shudnow :: Apr.09.2008 :: Exchange, Server 2008, Windows :: 1 Comment »