Using database availability groups is a great idea, especially because you can copy and store them in multiple locations—but mind the addressing issues.
Q: We deployed Exchange 2010, and made all mailbox servers highly available using database availability groups (DAGs). Things are in good shape and everything works as expected, except one minor detail.
When someone who receives a message sent by an employee with a mailbox hosted in a DAG, in turn sends another message to an employee or a recipient in another organization, the Internet message header of the received message shows that the mailbox server has been configured using an APIPA address such as 169.254.5.133. We use static IP addresses for all our Exchange 2010 servers, so we don’t understand why it shows up as an APIPA address (see Figure 1). Can you enlighten us?
A: This is an interesting question. The very short answer is that it only occurs when Exchange 2010 mailbox servers have been made highly available using one or more DAGs, and the DAG functionality is based on the Windows Failover Cluster (WFC) component. You don’t see this behavior with mailbox servers that aren’t part of a DAG.
Let’s take a closer look at what’s happening here. The WFC component in Windows Server 2008 R2 expects applications that use WFC—such as SQL, Exchange and file servers—to locate cluster resources in a specific way. The application should connect to a cluster resource by finding the proper information using a DNS server.
This is known as a Client Access Point (CAP). A CAP consists of a NetBIOS name and one or more IP address resources. In Windows Server 2008 R2, if the server supports dynamic updates, the CAP information is registered in the DNS once the CAP is brought online in the WFC.
Unfortunately, there are applications that skip the DNS step and instead connect directly to a cluster node using the first network adaptor in the binding list. By default, the first network adapter listed on the binding list is the Microsoft Failover Cluster Virtual Adapter (see Figure 2). This adapter is configured with an APIPA address.
Figure 1 An APIPA address in an Internet header
Figure 2 The Microsoft Failover Cluster Virtual Adapter
So, guess which application doesn’t use DNS to locate and connect a cluster resource? You guessed it: Exchange 2010 (and Exchange 2007, as well).
How can we fix this little annoyance? Fortunately, this is easy with the help of a little tool known as nvspbind, which you can download from the MSDN Code Gallery: code.msdn.microsoft.com/nvspbind. Nvspbind was developed specifically for modifying network bindings from a command line.
Let’s check the binding order of the adapters in the server. Run nvspbind.exe /o ms_tcpip. As you can see in Figure 3, Local Area Connection* 9 (which equals the Microsoft Failover Cluster Virtual Adapter) is listed first.
Figure 3 Viewing a binding order list using nvspbind
Next, we need to move Local Area Connection* 9 down the list. Run the following command:
nvspbind.exe /- “Local Area Connection* 9” ms_tcpip
Figure 4 Moving Local Area Connection* 9 down the binding order list
As you can see in Figure 4, Local Area Connection* 9 was moved down the binding order list. Now try to send a new e-mail. The Internet header should now show the real IP address of the server (see Figure 5).
Figure 5 An Internet header showing the real IP address of the mailbox server
Q: We just deployed Exchange 2010 servers. We intend to use DAGs to make our mailbox databases highly available. We’re planning for eight copies of each mailbox database. Each mailbox database will have copies on three physical locations. We’re going for databases of around 500GB each. Because of limited bandwidth to one of the physical locations, we expect a long seeding time. So, instead, we’re wondering if we can somehow manually copy the database files to a remote location with a USB drive?
A: Yes, you can do it this way, as well as with a supported method. To manually copy an offline database, disable circular logging for the respective databases. Do this by running:
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false
Then dismount the databases using:
Dismount-Database MDB01 -Confirm $false
Then copy the database and all log files to a second location, such as a USB drive.
When the copy process is complete, mount the active database copy again using:
Now connect the USB disk to the server that will host the database, and copy the database and log files to the same path as the one used on the source server from which the files were copied.
Now add the database copy using the Add-MailboxDatabaseCopy -SeedingPostponed parameter. The exact command would look something like this:
Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed
Notice there’s no seeding process because the EDB file and associated log files are already in place. Finally, enable circular logging again using:
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true
Q: We’re running Exchange 2010, and we have many “road warriors” who are highly dependent on the Outlook Web App, or OWA (what used to be called Outlook Web Access). These users can’t log on to OWA when their password has expired. We’ve also found that new employees for whom the account has been set to “User must change password at next logon” when the user account is first created (see Figure 6), can’t log on to OWA before they change the password using other mechanisms.
Figure 6 User must change password at next logon enabled
We’ve been living with this annoyance since we moved from Lotus Domino to Exchange 2003 many years ago. Do you know how we can rectify this?
A: Good timing for this question. When the Exchange team began planning Exchange 2007 SP3, as well as Exchange 2010 SP1, they decided to fix the lack of being able to log on to OWA when a user’s password has expired or the user account has been set to User must change password at next logon. They came up with the OWA Password Reset Tool. This is an IIS 7 module that detects expired passwords and redirects users to a brand-new change password page.
Figure 7 The Outlook Web App 2010 forms-based authentication logon page
Let’s see this in action, shall we? The user tries to log on to OWA 2007 or 2010 using the forms-based authentication (FBA) logon page, as shown in Figure 7. The user is now redirected to the new Change Password page, shown in Figure 8. Here, he’ll need to enter the current password as well as the new one, and then click the Submit button.
Figure 8 The Outlook Web App 2010 Change Password page
Now, the password is changed and the user can log on using the new password. Simple and user-friendly, right?
Bear in mind that the Change Password page isn’t enabled by default after installing Exchange 2007 SP3 or Exchange 2010 SP1. You need to enable this with a registry key. More specifically, you’ll need to log on to each Exchange 2007 or Exchange 2010 client access server (CAS) and launch the registry editor.
Within the registry editor, navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA. Here, you’ll need to create a new REG_DWORD key named ChangeExpiredPasswordEnabled. Enable this by setting the data value to “1,” as shown in Figure 9.
Figure 9 The registry key required to enable Change Password for OWA
Now your road warriors can log on to OWA, regardless of whether their password has expired or needs to be changed.