Tag Archives: Exchange 2010

Exchange 2007/2010 coexistence in a single server deployment

I’m making a notes here for myself, mainly because a lot of the upgrade/coexistence material is over-complex when you’re dealing with a single server deployment of Exchange. I decided that the lowest impact method to transition to Exchange 2010/2007 coexistence was to leave the public DNS/smarthost settings/MX records unchanged, and simply switch the IP addresses of the servers. So the alias mail.domain.com moves from Exchange Server 2007 to 2010.

  • Choose a public IP address for legacy.domain.com and create a host record in your public DNS.
  • On your border firewall, add this new host to the same rules you have defined for mail.domain.com. Pay attention to any other rules involving this host (permitting traffic from other firewall security zones, like wifi for instance).
  • Make sure your SSL certificate has the following FQDNs (assuming domain.com is your public DNS domain): internal server name (exch2010.domain.local), external server name (mail.domain.com), autodiscover for your main email domains (autodiscover.domain.com), legacy for your main email domain (legacy.domain.com).
  • If any of these are missing, re-key your certificate (GoDaddy lets you change Subject Alternate Names without buying a new cert, as long as you bought the multiple-SAN type). Prepare the cert request using the Exchange 2010 Management Console. When GoDaddy re-key a cert they use the SANs from the original cert request, regardless of whatever is defined in the new CSR. So before you upload the CSR, edit the SANs in the GoDaddy control panel.
  • Import the issued certificate using the Exchange 2010 Management Console.
  • Double-click on the cert you downloaded from GoDaddy. In the Details pane you can double check the Subject Alterative Names, and also the Thumbprint. Make a note of that.
  • Use the Exchange 2010 Management Shell to assign this cert to the main services, replacing the default self-signed one:
    Get-ExchangeCertificate
    Have a look at the current assignments, then:
    Enable-ExchangeCertificate -Thumbprint {Thumbprint} -Services "IIS, IMAP, POP, SMTP"
  • Now we need to import this same cert onto the Exchange 2007 server since it will be known as legacy.domain.com. Importing using the Exchange 2007 Management Shell cmdlet is not sufficient since the private key will not be imported. The only way I know of doing this is to export the cert from your Exchange 2010 server as a .pfx file, making sure to select the option to export the private key. Then on the Exchange 2007 server, create a dummy website with a custom host header so you don’t disrupt the running websites, enable SSL on a random port and import that .pfx certificate. Once that is done you can delete the dummy website.
  • Now in the Exchange 2007 Management Shell run:
    Get-ExchangeCertificate
    to list your certs. Your new cert’s thumbprint should be listed. Now we just need to enable the new cert for the same services the old one was using. e.g.:
    Enable-ExchangeCertificate -Thumbprint {Thumbprint} -Services "IIS, IMAP, POP, SMTP"
  • You could at this point tidy up and use Remove-ExchangeCertificate to remove the old cert but there’s not much point since the Exchange 2007 server will soon be decommissioned.
  • Configure your Exchange 2010 CAS and Hub Transport roles with the external hostname set to mail.domain.com. Do not build a send connector yet (Organization Configuration > Hub Transport).
  • In the Exchange 2007 Management Console, select Server Configuration > Client Access. For each of the service connection points (OWA, Exchange ActiveSync, OAB, etc.) ensure that the URLs are changed from mail.domain.com to legacy.domain.com.
  • There is another service connection point that’s not listed here in the Management GUI – the Exchange Web Services (EWS) virtual directory. Fail to migrate this one and you’ll get this error message from Outlook clients that try to edit their Out of Office settings:

    Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later.

  • This one can be updated using the Exchange 2010 Management Shell:
    Get-WebServicesVirtualDirectory -Server EXCH2007 | fl *url
    Get-WebServicesVirtualDirectory -Server EXCH2007 | Set-WebServicesVirtualDirectory -ExternalUrl https://legacy.domain.com/ews/exchange.asmx
  • In the Exchange 2007 Management Console disable all of the Send Connectors (Organization Configuration > Hub Transport), and Receive Connectors (Server Configuration > Hub Transport).
  • Shut down all the Exchange services on both servers, and set the IP address of the Exchange 2007 server to the one you created in DNS for legacy.domain.com. Then reboot.
  • Change the IP address of the Exchange 2010 server to the one you were using for Exchange 2007. Reboot it.
  • Do not manually delete any DNS records at this point!
  • The external smarthost is configured to accept mail only from one of the Exchange servers – mail.domain.com. Rather than edit this, and wait for propagation etc. it’s probably easier just to have your Exchange 2010 server send and receive all external email.
  • To do this, either edit your Send Connector and change the server name, or leave it disabled and create a new connector copying the settings, but with Exchange 2010 as the source server.
  • At this point I had a problem with inbound mail delivery. The queue viewer showed that it was stuck at the Exchange 2010 server, and was failing to resolve internal DNS for the Exchange 2007 server. I had manually deleted the DNS entries for the two Exchange servers when I redefined their IPs. The deletion then synced to the AD/DNS at another business site and the tombstone replicated back later on – deleting the newly updated records.
  • As is fairly typical, the Exchange 2007 server had a separate SMTP relay receive connector defined in Server Configuration > Hub Transport, to allow web servers and monitoring scripts to send email externally. Re-creating this on the Exchange 2010 server proved problematic. It turned out that once this connector was created, the mail flow from Exchange 2007 to 2010 would also bind to it, rather than the DEFAULT connector. Since the Externally Secured option prevents some of the other auth methods being enabled, one of the Exchange 2007 server’s transport queues was stuck with this error:

    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.

  • The solution was to create a new receive connector on the Exchange 2010 server, specific only to the legacy.domain.com IP address which matched the settings of the DEFAULT one. This can later be deleted when coexistence was is longer needed. Apparently the connectors are bound to in the order of the most specific first.
  • Following this migration work, it transpired that older iPhones on iOS 3.x, and Android handsets are not able to understand Exchange 2007/2010 coexistence and need the mail server name manually updating to legacy.domain.com. Also, Outlook 2003 (there’s always a legacy client with a home user somewhere!) needs to have encryption enabled for server communication.

Exchange 2010/2007 mixed mode – broken UM

This one was a very obscure issue. I recently installed the first Exchange 2010 server in our infrastructure and haven’t really configured anything on it yet. It turns out that at around the same time our Exchange 2007 Unified Messaging stopped working but it took a while for anyone to notice. Long enough in fact that I strongly suspected our PABX system was at fault, especially since it has recently had some hardware failures.

The symptoms were a total inability to leave messages on the UM server, but strangely it could still be contacted by dialing the voicemail number. The audio message was something like ‘we cannot connect you at this time’. The fact that an Exchange voice prompt can be heard strongly suggests that the telecoms system is ok.

The event log errors on the Exchange server are 1082:

Event Type: Error
Event Source: MSExchange Unified Messaging
Event Category: UMService
Event ID: 1082
Date: 04/10/2011
Time: 16:05:38
User: N/A
Computer: EXCH-01
Description:
The Unified Messaging server was unable to submit messages to a Hub Transport server because there is no Hub Transport server available to process the request with UM header file “C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging\voicemail429a59b-e196-4b25-940d-796c736fb93d.txt”. Make sure that there is a Hub Transport server located in the same Active Directory site as the UM server. In addition, make sure that the Microsoft Exchange Transport service is started on the Hub Transport server.

and 1185:

Event Type: Warning
Event Source: MSExchange Unified Messaging
Event Category: UMCore
Event ID: 1185
Date: 04/10/2011
Time: 16:06:48
User: N/A
Computer: EXCH-01
Description:
The Unified Messaging server was unable to submit a message to Hub Transport server “EXCH-01” because the following error occurred: Unexpected SMTP server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command.

Firstly I tried increasing the Exchange UM log level but that wasn’t helpful at all. Error 500 implies some sort of auth issue so I double-checked all the certificates were valid (Get-ExchangeCertificate | fl). Then I started reading. There isn’t a huge amount on this subject (most of what’s written relates specifically to 2010) but I found this excellent write-up by Terence Luk. His were the same symptoms I was seeing, but even creating a new Hub Transport Receive Connector didn’t fix it.

What was different about my infrastructure? Well in my environment all the roles (including UM) are on the same server. So I had to telnet from the Exchange server itself to test properly. And then I noticed something strange. My Exchange server was referring to itself by the IP of one of its iSCSI NICs, which are on a private IP range. Why? No duplicate A records in DNS from spurious interface registrations, no Client or Microsoft Networks assigned on the iSCSI NICs. A simple ipconfig seemed to list them in an unusual order, with the actual Local Area Connection in the middle. This was probably the cause. Next stop Eric Reitz’s How to set/view the NIC bind order in Windows. A new menu I never new existed until this point!

And sure enough, this fixed it. The Exchange 2007 server’s NIC binding order had been like this for well over a year and never caused any issues, but I think that the addition of the first Exchange 2010 server must have raised the security, probably implementing TLS for inter-role UM traffic where it wasn’t used before.