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.
“More Available” DHCP
Last year I upgraded our production AD environment from Windows 2000 Server SP4 based DCs to Windows Server 2003 64-bit R2 SP2 based DCs…yeah, a little bit late.
One of the issues with the previous environment was there was no redundancy in the DHCP implementation. Natively, within what Windows provides, your only real choice for highly available DHCP is to have a DHCP cluster. Since most admins, myself included, prefer to keep all of the network infrastructure services on the DCs (DNS, DHCP, WINS), that makes clustering a no-go…you cannot cluster DCs (more specifically, you cannot cluster DCs and still remain in a supportable configuration should you need assistance from PSS).
There are a few really good hardware based products out there for IP Address Management, such the devices from Bluecat Networks. These appliances have fail-over clustering capabilities and provide DNS and DHCP. But, as was the case with our organization, the desire to stay away from adding extra layers of complexity to the core infrastructure won out over an obviously attractive solution for creating highly available DHCP.
Enter the concept of what I like to call “more available”, or just MA for short. Using a combination of freely available utilities and built-in functionality in Windows Server 2003, you can create a MA solution for DHCP at no cost. A couple of assumptions must be made at this point though:
- You have at least two Domain Controllers in the domain.
- You are willing to install and authorize the DHCP service one at least two of the Domain Controllers.
- You are willing to create a service account that will be a member of the Domain Admins group.
- You are willing to have some divergence (i.e. difference) between the active copy of the DHCP database and the standby copy/copies of the DHCP database on the non-active DHCP servers.
The basic process works like this:
- A wrapper .BAT file is called by a scheduled task on the Domain Controller that is providing DHCP. This scheduled task must be run with credentials that have Domain Admin group membership.
- The wrapper .BAT file first runs a second .BAT file that uses the netsh command to export the DHCP database to a text file. Neat!
- The wrapper .BAT file next runs a third .BAT file that uses the great robocopy utility to copy the entire contents of a certain folder from the Domain Controller that is running DHCP to one or more other Domain Controllers that have DHCP installed and authorized, but not running.
- On each of the target Domain Controllers, a fourth .BAT file is run by a scheduled task (using the same account with Domain Admin credentials). This .BAT file makes a backup copy of the DHCP database on that target Domain Controller and then runs a fifth .BAT file to use netsh to import the DHCP database that was exported from the source Domain Controller. (This task should run later than the one on the source Domain Controller, say 5 or 10 minutes later.)
You can get Robocopy by downloading the Windows Server 2003 Resource Kit tools.
In the attached ZIP file are all of the .BAT files you’ll need to make this work.
- DHCP_processing.bat: The first wrapper file that performs the DHCP database export on the source Domain Controller and then copies the files to the destination Domain Controller(s).
- NETSH_export.bat: Called by the first wrapper file, it performs the export of the DHCP database on the source Domain Controller.
- DHCP_copy.bat: Called by the first wrapper file, it uses robocopy to copy the contents of the folder containing all of the script files and the exported DHCP database to the source Domain Controller(s).
- DHCP_import.bat: Another wrapper file, this one manages the state of the DHCP service on the target Domain Controller and creates a copy of the existing DHCP database before calling the last file to import the DHCP database.
- NETSH_import.bat: Called by the wrapper file on the target Domain Controllers, this one imports the DHCP database.
A few notes to keep in mind to make this work:
- All DHCP servers must be authorized in AD.
- You’ll want to edit the file paths in the provided .BAT files to match your environment.
- The DHCP service on the source Domain Controllers should be changed to Manual start up mode (to ensure that the DHCP service is never accidentally started, which would be a bad thing since you’d have multiple DHCP servers issuing addresses and no single point of reference).
- The service account to be used must be a Domain Admin.
- You should put all of the script files and the robocopy executable in a single folder, such “E:\DHCP\IMPORT_EXPORT” in my environment. Let robocopy copy all of files in the folder to the source Domain Controllers, even though they are not needed (this provides protection for your script files if you lose the source Domain Controller).
- Make sure your network group has configured the network infrastructure (routers and/or switches as required) to allow the IP address of any servers you’re setting this up on as “DCHP helpers”…that will be one less thing to do during a failure event.
In our environment, I have the scheduled tasks running twice daily at 10 AM and 7 PM as this was adequate to capture the vast majority of new DHCP lease issues (i.e. they happen on first and second shift before these times). You can certainly run the tasks as often as you want to reduce the differential between the contents of the two databases.
To put one of the standby DHCP servers in operation, simply stop the DHCP running on the original DHCP server (if it’s available) and start the DHCP service on the standby service. More Available DHCP has now been achieved.
More_Available_DHCP.zip (962 bytes, 989 hits)
l.root-servers.net IP address change
The IP address for the “l.root-servers.net” root DNS changed on November 1, 2007 and officially stopped responding to its old IP address of 198.32.64.12 on May 1, 2008. Of course, I just noticed this…
The new IP address is 199.7.83.42. The full details from ICANN (operator of the l.root-servers.net root DNS:
IMPORTANT: As of May 1st 2008, l.root-servers.net will cease to answer on 198.32.64.12
Following the renumbering of L.ROOT-SERVERS.NET on November 1st 2007 we will cease answering DNS queries on the old IPv4 address of 198.32.64.12 as of May 1st 2008.
The current valid IPv4 address for the server is:
199.7.83.42
We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root “hints” file. This should be updated with the new IP address.
New hints files are available at the following URLs once the change has been formally executed:
ftp://rs.internic.net/domain/db.cache
ftp://rs.internic.net/domain/named.cache
ftp://rs.internic.net/domain/named.root
Make sure you update your your DNS server’s root hints accordingly…
-
Translator
