Protecting Exchange with Data Protection Manager 2007
There’s a small (though important) typo in the TechNet article Protected Computer Software Prerequisites in regards to the required steps to protect Exchange Sever 2007 (or Exchange Server 2003) databases.
To properly protect Exchange Server data, you’ll need to have the current version of the eseutil.exe and ese.dll files available to the DPM server. This article proposes to do that via a file system hardlink, although the file paths listed are incorrect. If you go this route (versus manually copying the files into the DPM bin directory), you’ll want to use the correct paths.
Incorrect (as specified in the article):
fsutil hardlink create “c:\program files\microsoft\dpm\bin\eseutil.exe” “c:\program files\microsoft\Exchange\bin\eseutil.exe”
Correct:
fsutil hardlink create “C:\Program Files\Microsoft DPM\DPM\bin\eseutil.exe” “C:\Program Files\Microsoft\Exchange Server\Bin\eseutil.exe”
Oddly enough, the TechNet article does not address the ese.dll file, which is also required. Use this command to hardlink it.
fsutil hardlink create “C:\Program Files\Microsoft DPM\DPM\bin\ese.dll” “C:\Program Files\Microsoft\Exchange Server\Bin\ese.dll”
Data Protection Manager 2007 error ID 31309
To protect a server using Data Protection Manager 2007, you must install two prerequisite software items:
- The DPM agent (see my previous post about the Visual C++ 2008 Redistributable cleanup issue), and
- The VSS hotfix from MS KB 940349
If you attempt to protect data on a server immediately after it reboots following the hotfix installation, you may get an error message with ID 31309 stating that you must install the required prerequisite software…which of course, you’ve already done. Fortunately, the fix to this annoyance is the same as for error ID 31008 as discussed in MS KB 947470. The issue is that the agents don’t update the DPM server immediately. The updates occur approximately every 20 - 30 minutes.
Just complete these steps and you should be on way to protecting that server:
- Start the Data Protection Manager 2007 Administrator Console, and then click the Management tab.
- Click the Agents tab, and then click Refresh information in the Action pane.
- Verify that OK appears in the Agent Status column for each protected server.
- Click the Protection tab, and then follow these steps:
- Create a new protection group, or modify an existing protection group.
- Select a data source.
- Verify that you can add a data source to the protection group successfully.
Data Protection Manager 2007 Management Pack updated
Version 2.0 of the Data Protection Manager 2007 management pack for Operations Manager 2007 was recently released.
This is is not a converted version, so installation is easy. Be sure to remove the previous version if you had it installed.
On the DPM side of things, make sure that you have SP1 or the Feature Pack in KB949779 installed before importing the management pack. As usual, get your management packs in the Catalog.
This management pack offers end-to-end monitoring of both the DPM servers and clients.
Exchange Server 2007 SP1 Update Rollup 5 SCR bug
I ran across this the other day while trying to get SCR setup on the Exchange servers in our warm DR site…when trying to run the Enable-StorageGroupCopy cmdlet to configure the SCR instance you get the following error:
Enable-StorageGroupCopy: Standby continuous replication is not supported between computers in different Active Directory domains. The target node is in domain <child.domain.local>, which is different from the source domain <domain.local>.
Tim McMichael has a blog entry about it here that gives you some alternate methods to get SCR configured. I choose to first run the Enable-StorageGroupCopy cmdlet from a second Exchange mailbox server in the warm site that hadn’t been updated with Update Rollup 5 yet. Of course, I’ll need that second mailbox server for the remaining storage groups soon enough, so it looks like the option to use another server of the same OS level is the best choice…a VM works as well as anything else.
On a side note, I certainly hope that full support for SCR is included in Exchange Server 2007 SP2…including thge ability to view the SCR instances on the SCR target in the GUI. It would be nice to be able to activate and deactivate from the GUI as well…or at least something more than what you can do now…which is nothing!
Exchange 2007 problem over site-to-site VPN with Cisco ASA
I’m currently working to get a new warm DR site up and running with Active Directory, Exchange Server 2007 SCR and Data Protection Manager 2007. After installing and configuring the Hub Transport server in the DR site, I sent a test message using bmail to my mailbox to test SMTP connectivity and routing between sites. I certainly didn’t expect to find what I did.
When looking at the queue for delivery to the AD site where the primary Exchange installation is (and where my mailbox is homed at), I noticed it was in a retry state with the following error message:
451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.
So not the most explicit reason for the routing failures, but something at least. I first thought that perhaps I had somehow changed the settings on the “Default” receive connector on one or both ends of the connection (i.e. the Hub Transport at the DR site and one or more of the Hub Transports at the main site). On the “Default” receive connectors, you’d want to ensure that you’ve not changed any of the authentication methods on the Authentication tab. Specifically, Exchange Server authentication and Integrated Windows authentication need to be selected as they are by default.
The settings were as they should have been, but yet routing between AD sites was still stuck. The problem, as it turns out, was the Cisco ASA 5510 device providing the site-to-site VPN connectivity between the two locations. It seems there’s a bug in the ASA version 7.1 code base that causes the ESMTP inspection process to remove some information that is not required by the relevant RFCs. Unfortunately, Exchange Server 2007 requires that information for ESMTP hostname validation. From the Cisco WIKI article on the bug:
The Extended Simple Mail Transport Protocol (ESMTP) inspect feature masks the hostname and causes an error when a mailserver is configured to ensure the HELO reply is a valid hostname.
So…the solution is fairly simple once you identify the relatively obscure cause…simply turn off ESMTP inspection on the ASA device. You can do this by following the CLI steps outlined in the WIKI article or by using the ASA GUI (Configuration > Security Policy > Service Policy Rules > Edit Service Policy Rule), select the Rule Actions tab and then select the Protocol Inspection tab as seen in the figure below. Uncheck ESMTP, save and you’re good to. Mail flows and all is well.
-
Translator
