Implementing a two-node single copy cluster in Exchange Server 2007

by Shijaz Abdulla on 03.05.2009 at 17:29

This article used to exist on www.shijaz.com before it was taken down in May 2009. Originally published in July 2007.

This article gives step-by-step explanation on how to implement Single Copy Cluster in Microsoft Exchange Server 2007.

Background

For Exchange Server 2003 administrators:

Short and sweet: A two-node Single Copy Cluster in Exchange Server 2007 works just about the same way a two-node Active-Passive cluster works in Exchange Server 2003.

For newbie Exchange administrators:

It is assumed you know what the following terms mean:

  • Cluster

  • Node

  • Failover

  • Storage Group

  • SAN

A two-node single copy cluster (SCC) is a clustered mailbox server that uses shared storage in a failover cluster configuration to allow multiple servers to manage a single copy of the storage groups. In short, the Exchange data is stored on a shared storage device (such as a Storage Area Network – SAN) and is connected to two server computers, but can be accessed by only one at a time. The server computer that has access to the storage resource at any given point of time is called the Active node and the server computer is not active is called the Passive node. When the active node fails, the passive node gains access to the shared storage and the Exchange services run on the second node. The passive node then becomes active and this process is called failover.

2node1

Procedure

Task 1 of : Configure Network Cards

Configure two network cards in each node: a public network card for the clients and a private network card for the two server nodes.

  1. To configure a cluster, you need a minimum of two network cards on each node. Verify that you have at least two on each of your two servers.

  2. To easily identify the network cards, rename one card to "Public" and the other to "Private". The Public NIC on each server connects to your LAN and will have an IP address on your local LAN. The Private NIC on your server connects to private network shared between your two nodes. This can be a cross-cable connection directly drawn between the Private NIC of Node1 and the Private NIC of Node2. Use an IP address scheme that is different from your LAN IP range for the Private interfaces. The Private interface is used for "heartbeat" communication between the nodes (to see if the other node is "alive").

Task 2 of : Configure Shared Storage

Configure shared data storage, and assign the same drive letter for the shared disk storage on both nodes in the SCC cluster

  1. Configure your shared storage device and create volumes for use by the Exchange cluster. For information on how to do this, refer hardware documentation/vendor.

  2. Once the volumes have been created, map them on both servers by the same drive letter using Disk Management. (Right-click My Computer > Manage > Disk Management)

Task 3 of : Create Windows Cluster User Account

Create a Windows cluster service account that will be used by the clustering service to start and stop service during failover. The necessary permissions for this account are granted when configuring the cluster.

  1. Open Active Directory Users & Computers

  2. Create a user (say) CLUSTERADMIN.

  3. Set Password Never Expires for this user. You don’t want the password time bomb to blow on your face!

Task 4 of : Create the Cluster

Create a new cluster on the first node by using the graphical Cluster Administrator tool or the cluster.exe command-line tool.

  1. See my article "How to setup an Exchange 2003 cluster" and follow only step 1 and step 2 to create the cluster.

  2. Add the second node to the cluster, by specifying the computer name and the password for the cluster service account. If you wanted to create a multi-node cluster, add all the nodes in this step.

Task 4 of : Install Mailbox Server Role

Install the Exchange Server 2007 Mailbox Role on the active node

  1. Start Exchange Server 2007 setup and choose Custom Exchange Server Installation. Select the Active Clustered Mailbox Role.
    2Node_1

  2. During installation, you will be prompted for the clustered Virtual Name and the clustered Virtual IP. This is the "virtual" hostname/IP that will always be online regardless of which node is up. The virtual hostname and virtual IP address is created as a resource on the cluster. Clients will be configured to use this virtual hostname.
    Note: You can also run setup from the command prompt with the following options: /newcms /CMSname:ClusterMailboxServerName /CMSIPAddress:ClusteredMailboxServerNameIPAddress /CMSSharedStorage CMSDataPath

  3. If applicable, move existing storage groups and mailbox databases to the active node by using the Move-StorageGroupPath and Move-DatabasePath cmdlets in the Exchange Management Shell. Brief syntax is as follows:
    Move-StorageGroupPath -Identity <StorageGroupIdParameter> [-ConfigurationOnly <SwitchParameter>] [-CopyLogFolderPath <NonRootLocalLongFullPath>] [-CopySystemFolderPath <NonRootLocalLongFullPath>] [-DomainController <Fqdn>] [-Force <SwitchParameter>] [-LogFolderPath <NonRootLocalLongFullPath>] [-SystemFolderPath <NonRootLocalLongFullPath>]
    Move-DatabasePath -Identity <DatabaseIdParameter> [-ConfigurationOnly <SwitchParameter>] [-CopyEdbFilePath <EdbFilePath>] [-DomainController <Fqdn>] [-EdbFilePath <EdbFilePath>] [-Force <SwitchParameter>]

  4. Your first node is now ready. Install the Mailbox Server role on the passive node. Select Custom Exchange Server Installation, choose the Passive Clustered Mailbox Role option. Once setup completes, you will be able to failover from the active node to the passive node. Test the failover using Move-ClusteredMailboxServer Cmdlet.
    Important: Always test the failover (also called ‘Handoff’) using the Move-ClusteredMailboxServer cmdlet on Exchange Server 2007. It is recommended NOT to
    use the Move Group option in Cluster Administrator.

  5. Move mailboxes or create new mailboxes on the active node.

Removing leading/trailing white spaces from displayName using PowerShell

by Shijaz Abdulla on 14.11.2008 at 06:09

I am moving thousands of Exchange 2003 mailboxes to Exchange Server 2007 over this weekend. Most of these are student mailboxes which have been provisioned using another third party system. Due to a minor bug, the third party system added a trailing space to every student’s display name.

A trailing space is a whitespace at the end of the displayName string. This may look like a very small issue, but unfortunately Exchange Server 2007 is very fussy about such things:

image 
The DisplayName property contains leading or trailing whitespace, which must be removed.

image
More of that… (ouch!)

Exchange 2007 would not let me move these mailboxes across from Exchange 2003 unless I correct the DisplayName property for all the mailboxes.

I have several thousands of mailboxes having an ‘inconsistent’ display name. Correcting each of these manually would have been a frustrating exercise – so I decided to coin my own PowerShell command to remove leading/trailing spaces from all mailboxes in a given mailbox database. Nerd

get-mailbox -Database ‘SERVERMailStore’ -ResultSize 4850 | Foreach { Set-Mailbox -Identity $_.Identity -DisplayName $_.DisplayName.Trim() }

where SERVER is the Exchange 2003 server hosting the mailboxes you want to modify, MailStore is the Mailbox store on that server containing those mailboxes. I set the ResultSize to 4850 because I have more than 4000 mailboxes and by default the get-mailbox command fetches only 1000.

Exchange 2003: Support ending April 2009

by Shijaz Abdulla on 10.11.2008 at 09:35

Mainstream support for Exchange Server 2003 will end on April 14, 2009. This means that you cannot contact PSS for supporting problems on Exchange Server 2003 after this date, unless you sign up for ‘extended’ support at an additional cost.

Maybe this is a good time for organizations to seriously start thinking about upgrading to Exchange Server 2007 and make use of the new, advanced features.

For those who have made it to Exchange Server 2007 SP0, here is a shocker: Mainstream support for Exchange Server 2007 SP0 (i.e. Exchange Server 2007 with NO service pack installed) will end on January 13, 2009. Yes, that’s about two months from now.

For those who are still wary of installing SP1 on Exchange Server 2007, it’s time to take a call on the chicken-and-egg upgrade dilemma between Windows Server 2008 and Exchange Server 2007 SP1.

Some more information:

  • Windows Server 2003 and Windows Server 2003 R2 will go out of mainstream support on July 2010.
  • Windows XP will go out of mainstream support on April 14, 2009.

Managing changes to legacyExchangeDN

by Shijaz Abdulla on 24.07.2008 at 16:37

If you had to change the legacyExchangeDN for your users as part of a migration or other manual process, or even an error in your automated user provisioning software, there are certain things that you need to be aware of.

For one thing, cached Outlook ‘autocomplete’ entries will stop working. If a sender uses his Outlook autocomplete to select a user whose legacyExchangeDN has been recently changedand sends an email to a user, chances are that the mail will bounce with the following NDR:

Jack Rabbit
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

The first thing you need to do after changing the legacyExchangeDN is to initiate an Offline Address Book rebuild. The way out of this problem is to instruct the sender to first download the Address Book by doing a full Send/Receive. Then ask the sender to manually select the affected recipient from the Address book instead of using the cached Autocomplete.

image

This is because, in an Exchange organization, Outlook client autocomplete caches do not save the SMTP email address. Instead, it saves the X.500 address using the legacyExchangeDN attribute from Active Directory. And that’s exactly what you have changed!

 

Workaround:

There is another workaround to prevent the NDRs. This would be to enter the old value of the legacyExchangeDN attribute as an X.500 address for the user account. This is done by opening the user object’s Email Address properties –> Add a Custom Address –> Enter the old value of legacyExchangeDN as the address and the address type as "X500" without the quotes. The drawback of this method is that you are populating the user’s email address field with garbage, which you don’t need after a while but can’t remove because you are unsure if traces of the old entries in Outlook caches are gone!

Getting the ‘Change Password’ feature to work in a co-existence scenario

by Shijaz Abdulla on 13.07.2008 at 13:11

If you are running Exchange 2003 and Exchange 2007 in co-existence and you have users on both systems, you will notice that, while Exchange 2007’s new OWA interface has a brand new Change Password option, the Change Password functionality for the users on Exchange 2003 has stopped working and you receive a 404 – File Not Found error.

clip_image001

 

This is because the IISADMPWD virtual directory, which was previously available on your Exchange 2003 Front-End server is no longer present on your Client Access Server. So here’s the solution:

1. If you are running Exchange Server 2007 on Windows Server 2003:

Simply enable the IISADMPWD virtual directory by following this article.

2. If you are running Exchange Server 2007 SP1 on Windows Server 2008

Things can get a little tricky here. Especially when you’ve noticed that there is no IISADMPWD folder inside the WindowsSystem32Inetsrv folder! Now what are we gonna do?! Here’s something that I’ve tried and it works:

a. Simply copy the WindowsSystem32InetSrvIISADMPWD folder from your Exchange 2003 Front End server and copy it to WindowsSystem32InetSrv folder on your Windows 2008 Exchange Client Access Server.

b. Open IIS Manager. Right click on Default Web site and choose Add Virtual Directory. Specify the alias as IISADMPWD and browse to the path of the WindowsSystem32InetSrvIISADMPWD folder.

c. Right click on the IISADMPWD virtual directory, and select the option Convert to Application.

d. Click on IISADMPWD application to select it. On the right pane, open the Authentication icon. Disable Anonymous authentication and enable Basic Authentication. Make sure only Basic Authentication is enabled.

e. Restart IIS service by using the command iisreset /noforce

Your Exchange 2003 users should now be able to change their passwords.

image

POP3 vs. Outlook Anywhere (Exchange RPC over HTTP)

by Shijaz Abdulla on 23.04.2008 at 08:56
The year is 2008 and you might be wondering why I’m making such a post.

This blogger has seen that even in this time and age, some people simply love POP3 and prefer it over better and more secure alternatives. This post serves as an eye-opener to users as well as administrators who are die-hard POP fans.

Some reasons why you shouldn’t use POP

  1. Traditional POP3 (without any secure configuration – which is also the most common way admins configure your Outlook Express) transmits your username and password over the network in plaintext. Any user with malicious intent, can “sniff” your password over the network and get hold of your email. In most cases, the credentials that you use to retrieve mail are the same that you use to send mail, which means the intruder can not only read your mail, but also send mails to other people on your behalf!
  2. Now, relating to the above point, replace the ‘hacker’ with malicious software/spyware/virus on the PC of a legitimate user on your network. The malware can do the sniffing and use the credentials to inject spam into your organization, as well as the rest of the known universe, pretending that its YOU the POP user who is sending the spam.
  3. All your emails are dumped to your PC from the server. What if you’ve been using POP for the past 5 years and your PC decides to crash – and you have no backup.
  4. What if your PC doesn’t crash, but your mail folders get corrupted – quite common with many POP3 clients.
  5. What if you want to access your received emails from some place else and you do not have your PC with you. Of course, for points 3, 4 and 5, you could leave a copy of your mails on the server – but what’s the point in sticking to POP3? – read on!
  6. For some users, their email might seem very secure when it’s sitting on their own PC and nowhere else. I have news for you. The moment someone else sits on your PC, kiss privacy goodbye. A knowledgable user can open password protected folders. An additional point to ponder: SMTP traffic on the internet is not encrypted by default. It is most likely that your sensitive email is flying about cyberspace in plain text anyway!
  7. If you travel to a partner/client’s office with your laptop, accessing your mailbox via POP3 might require intervention of their network administrator if POP is not already open on their firewall – or you may require some sort of firewall client.
  8. No access to your company’s Address Book.

Some reasons why you should use RPC over HTTPS instead

  1. Passwords don’t go out in plain text. Just about anybody can’t get hold of your password.
  2. If you use RPC over HTTPS, an SSL session is established between your PC and the server that has your email. The email content reaches you in a secure, encrypted channel.
  3. The email is stored on your server, and (hopefully) a backup is taken every night.
  4. If you use Outlook in cached mode, all you have is an offline copy of the same email – which means its available for your reference even when your PC is not connected to the office network.
  5. If your client PC crashes, or if your Outlook folders get corrupted, your emails are still safe on the server. All it needs is a fixing of your Outlook. (Note: If you archive some of your email on PST – make sure its backed up – or that the organization has a centralized email archiving system in place)
  6. You can access your company’s Address Book and all your contacts, tasks, calendar, etc.
  7. Presence information from Live Communications Server, integration with SharePoint workspaces, etc.
  8. Unlike POP3, Outlook Anywhere uses HTTPS and can be used from any partner network where they allow you to surf the net. No additional config required. 🙂

Some users need to have more than one Exchange mailbox open at the same time on the same PC (usually executive secretaries). The common excuse is that they cannot configure two Exchange mailboxes on the same Outlook profile.

It is indeed possible to configure two Exchange Server mailboxes on the same Outlook profile. Here’s a tip: In Outlook 2007: Tools –> Account Settings –> Select your Exchange mailbox –> Change –> More Settings –> Advanced tab –> Add –> type the second mailbox name –> OK –> Next…Finish. See this page for more details.

Integrated authentication on Exchange Server 2007 IIS virtual directories

by Shijaz Abdulla on 17.04.2008 at 22:06

In an earlier post, I explained how you can use Outlook Web Access (OWA) hosted on Exchange 2007 CAS Servers for accessing Exchange 2003 mailboxes in a co-existence environment by using the /exchange virtual directory.

Exchange Server 2007 CAS Servers come with Forms Based Authentication enabled by default. Now, if you wanted to disable the forms based authentication (required if you want to publish using ISA Sever 2006 Forms based authentication), OWA would still work fine internally (i.e. https://servername/exchange or /owa), as long as you choose Basic Authentication. The user will be presented with a popup password window instead of the form.

Now, what if you didn’t want users who are already logged in to the domain to be prompted for their password. The answer sounds simple – enable Integrated authentication, right?

Well, no. If you are co-existing Exchange 2003 and Exchange 2007 mailboxes and if your users have mailboxes on Exchange 2003 backend servers, and if they try to login via a CAS server using https://servername/exchange, they will receive an HTTP 404 Page not found message.

This is because ‘/exchange’ on the CAS is an Exchange 2003 virtual directory. Exchange 2007 supports Integrated Authentication only on Exchange 2007 virtual directories (see this article).

So the moral of the story is that you cannot enable Integrated Authentication on the CAS Server for the /exchange folder in an Exchange 2007 co-existence scenario. Exchange 2007 users can use Integrated authentication only if they use /owa virtual directory for accessing OWA.

End of support: Exchange Server 2003

by Shijaz Abdulla on 15.04.2008 at 16:29

Microsoft will pull the plug on Exchange Server 2003 support in April 2009.

Unless another service pack is released for Exchange Server 2003 (which is unlikely), the mainstream support for the product will end on 14th April 2009.

If you’re still running Exchange Server 2003, its time to start thinking of upgrading to Exchange Server 2007. One year from today, you will not receive support from Microsoft if you face problems on your Exchange 2003 installation, unless you purchase the ‘extended support’ option, which is available till August 2014.

More information on the Microsoft Support Lifecycle website.

New articles for Microsoft Knowledge Base (KB)

by Shijaz Abdulla on 20.03.2008 at 19:15

Two of my articles written for the Microsoft Knowledge Base have been published today:

  • KB556073: Outlook Web Access users are unable to save appointments or respond to meeting requests
  • KB556074: Users are unable to receive meeting requests and meeting updates in Exchange Server 2007

Hope you can solve more of your problems at support.microsoft.com!

OWA calendaring issue “This action cannot be performed”

by Shijaz Abdulla on 19.03.2008 at 07:17

This post discusses a common Outlook Web Access (OWA) calendaring issue reported at most forums. I could not find a satisfactory answer posted anywhere, including eventID.net, so I thought I’d share the knowledge.

A description of the problem:

When a user tries to save an appointment/calendar item or responds to a meeting request using Outlook Web Access provided by Exchange Server 2003, he/she sees the following error:

This action can’t be performed.

The user is unable to save changes to his/her calendar using OWA. Additionally, he/she may see the following error while trying to dismiss or snooze reminder popups in OWA:

One or more of your reminders cannot be snoozed or dismissed.

You will also get the errors in the event log of the Exchange server such as “Calendaring agent failed to save appointment.”

This can occur due to one or more of the following conditions:

  1. As per Microsoft KB 310440, check if the required registry keys are intact.
  2. Make sure your antivirus software is excluded from doing realtime scanning on Exchange database/log files.
  3. Open the affected user objects attributes in ADSIEDIT. Make sure that the legacyExchangeDN attribute is in order.

To elaborate on the third condition, make sure your legacyExchangeDN attribute looks something like this:

/o=OrganizationName/ou=First Administrative Group/cn=Recipients/cn=shijaz

and not:

/o=OrganizationName/ou=First Administrative Group/cn=Recipientsshijaz

(missing “/cn=” before the user alias)

Observation:

If you move a mailbox with a malformed legacyExchangeDN attribute to Exchange Server 2007, the user will not receive meeting requests/updates. These will get stuck up on the queue with a 430 4.2.0 “STOREDRV.Deliver.Exception:MAPIExceptionCanNotComplete” error.

< Previous posts