Dusty Cables dot com

a tech blog

Tag Archives: SSL Certificate

Configure Outlook Anywhere and Autodiscover on a single-server Exchange 2007 on Windows Server 2008

October 14th, 2008. Published under Uncategorized. 1 Comment.

Exchange 2007 logo
What an ordeal this was, and the most frustrating part was that Outlook Anywhere was failing because of a stupid oversight on Microsoft’s part. This oversight will of course be detailed at the end of this article. Still, because I appreciate so much when others document and explain the steps of a complicated configuration, I’ll try to gather all the info I used from various locations into one “step-by-step” of what worked for me.

Goal:

Successfully configure both Outlook Anywhere and the Autodiscover service

Environment:

Windows Server 2008 Active Directory domain, one Domain Controller (called SERVER1 for the sake of this article, FQDN would be SERVER1.corp.domain.com), one server running Exchange Server 2007 SP1 (a.k.a. SERVER2). Both servers are running fully updated Windows Server 2008 installs. Outlook Web Access (owa.domain.com) and ActiveSync are properly working by forwarding ports 80 and 443 from the public IP on the firewall to the Exchange server and are utilizing the default SSL certificate (phones must import this cert for ActiveSync to work).  Here is some solid background on Autodiscover and Outlook Anywhere.

We need to acquire a third-party certificate, as it is stated in several places that the given certificate will not work with Outlook Anywhere. Besides this, it is so much easier to use a UCC (Unified Communications Certificate), also known as a SAN (Subject Alternative Name) certificate, than it is to get multiple single-name certificates. This type of certificate allows us to provide multiple names in one certificate. The Autodiscover service requires us to register the subdomain “autodiscover.domain.com” and Outlook Anywhere uses the external domain name of the Exchange server, which is commonly something like mail.domain.com. In my case I used the Outlook Web Access address of owa.domain.com for the external domain name of the Exchange server, since I already had this configured. I was able to put these two domain names, along with the root (domain.com) and the internal NetBIOS and FQDN (Fully Qualified Domain Name) of the Exchange server, SERVER2 and SERVER2.corp.domain.com. From what I have read from Sembee’s site, this is good for internal use of the certificate.  If you aren’t familiar with Sembee, you need to be.  Do what he says and you’re golden.  In fact, that article is the gist, but not quite everything, of what I followed to get everything up and running.

Step one:  Configure DNS records

You’ll need to configure both the external domain name of your Exchange server (owa.domain.com) and autodiscover.domain.com to point to your Exchange server.  I’m sure you can find directions to do this with your domain registrar.

Step two:  Activate Outlook Anywhere on the server

I did this from the EMC (Exchange Management Console) by expanding Server Configuration, clicking Client Access, and then clicking on Enable Outlook Anywhere in the right pane.  This launches a short wizard walking you through the activation.  Basically, you set the external domain name of the server (owa.domain.com) and do not check SSL offloading.  Not much to it.

You can also use the EMS (Exchange Management Shell) by typing the following command:

Enable-OutlookAnywhere -Server SERVER2 -ExternalHostname "owa.domain.com" -ExternalAuthenticationMethod "Basic" -SSLOffloading:$False

That code was gathered from this TechNet page.

Step three:  Acquire third-party certificate

I followed Sembee’s directions and used Digicert’s site to configure the “New-ExchangeCertificate” EMS command necessary to create the certificate request.  Just follow the directions provided when the cursor is in each text field.  Be sure to enter all the domain and NetBIOS names you want in the Subject Alternatives Names field.  NOTE:  The UCC I purchased limited me to five names here.  The UCC allowing more names was more expensive, so I kept mine to these five:

  1. autodiscover.domain.com
  2. owa.domain.com
  3. domain.com
  4. SERVER2
  5. SERVER2.corp.domain.com

I also selected 2048 on the Key Size, since it is more secure than 1024.  I didn’t read anything about going either way with this, so I’d always choose more secure over less secure.  Once Digicert’s wizard is complete, copy the resulting command and paste it into your EMS window.

Now you need to open the resulting CSR file and copy the entire contents of it.  Paste this into the new certificate request form at one of many SSL certificate suppliers.  I personally used DomainsForExchange.net, which ended up getting me a certificate from Starfield Secure Certificate Authority.  The certificate request required authorization from either the Technical or Administrative WHOIS contact for each of the domains in the request, so make sure your WHOIS info is correct and that those contacts, if not you, are aware of the request and will approve it.  For the NetBIOS name, which of course doesn’t have WHOIS info since it isn’t a domain name, the approval request email message came to email address of the SSL certificate supplier user account.

Once approval goes through, I downloaded both a CRT file (the certificate) and a P7B file, which is a PKCS #7 certificate or an “intermediate certificate bundle”.  I didn’t know what that meant, either, so I precisely followed these directions to import both of my new certificates.  These directions come from Starfield, so where you see their name, you’ll have to substitute it for your own certificate authority’s name.

After importing the P7B cert into the Intermediate Certificate Authorities store, you’ll get to import the UCC.  The directions from the securepayment.net article discuss importing a CER file, but everything is working fine after I imported a CRT file using these directions.  You import using the following command:

Import-ExchangeCertificate -path "C:\certificatefile.crt"

The Powershell will return a “Thumbprint” code you’ll need for the very next command necessary to enable the new certificate:

Enable-ExchangeCertificate -Thumbprint longthumbprintcodehere -Services:"SERVICENAME, SERVICENAME, SERVICENAME"

The services available to use are SMTP, IIS, POP, IMAP, and UM.  I personally used SMTP and IIS only.  The new certificate is now properly installed.

Step Four: Configure external names of web services

The involved Exchange services must match the external web addresses, or URLs, to ensure proper operation.  The services needing to be altered are found in the EMC under Server Configuration -> Client Access -> SERVER2.  Click on the server name and in the bottom of the center pane you will see tabs for the services needing adjustment.  The order I have is Outlook Web Access, Exchange ActiveSync, and Offline Address Book Distribution.  Right-click the OWA object and select Properties.  On the General tab, you’ll see Internal URL and External URL.  Mine read “https://SERVER2.corp.domain.com/owa” and “https://owa.domain.com/owa”, without quotes, respectively.  The other services follow in the same manner.  Access them the same way from the other tabs.  Exchange ActiveSync should read “https://SERVER2.corp.domain.com/Microsoft-Server-ActiveSync” and “https://owa.domain.com/Microsoft-Server-ActiveSync”.  OAB should read (on the URLs tab) “http://SERVER2.corp.domain.com/OAB” and “https://owa.domain.com/OAB”.

The Outlook Anywhere service also needs to match the external URL.  This can be accessed by right-clicking on the server object in the top-center pane, selecting Properties and then the Outlook Anywhere tab.  This should read “owa.domain.com”.  Also note this is where you can change the authentication type (Basic vs. NTLM).

Lastly, the “web services” URLs need to be set.  I followed Sembee’s intstructions again and used the EMC:

Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -internalurl https://owa.domain.com/EWS/Exchange.asmx -WindowsAuthentication:$True

Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -externalurl https://owa.domain.com/EWS/Exchange.asmx -WindowsAuthentication:$True

Note the only difference in the two lines is the “-INternalurl” vs. the “-EXternalurl” parameters.

If you use Unified Messaging, then you’ll also need the following command similar to the previous two:

Set-UMVirtualDirectory -identity "EXCH\UnifiedMessaging (Default Web Site)" -externalurl https://owa.domain.com/UnifiedMessaging/Service.asmx -BasicAuthentication:$True

The Exchange services need to be restarted after these changes, but I found it easier to restart the server given the number of running Exchange services.

Step Five: Test (but expect failure at this point)

I began testing at this point, thinking all was well.  Since I was configuring all this remotely, I tested externally using https://www.testexchangeconnectivity.com.  If you are testing internally, you can hold CTRL and right-click your Outlook client (assuming it is already connected to your Exchange server) and select “Test E-mail AutoConfiguration”.  I cannot elaborate on this as I did not use it.

Where the test failed for me is the very last step, which has to do with the “RPC over HTTP Proxy” and user authentication not communicating with the Domain Controller.  RPC over HTTP Proxy is a necessary component, and I already had it installed to get OWA working.  If your testing fails here as well, continue on, my friend.

Step Six: Fix stupid oversight mistakes

Here’s where we point at Microsoft and say “duh”.  Firstly, this article explains the registry additions needing to be made to get the Exchange server to properly authenticate users against the Domain Controller and also the necessary modifications to the Exchange server’s hosts file.

Registry changes on the Exchange server (SERVER2):

HKLM\Software\Microsoft\RPC\RPCProxy
ValidPorts
Values to ADD to the existing value: SERVER1:6004; SERVER1.corp.domain.com:6004;

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator
PeriodicPollingMinutes
Change value to: 0 (that’s a zero)

Registry changes on the Domain Controller (SERVER1):

HKLM\System\CCS\Services\NTDS\Parameters
Create a REG_MULTI_SZ value named “
NSPI interface protocol sequences”
Set value to:
ncacn_http:6004

There are other registry changes listed on that article, but (I’m pretty sure) those don’t apply to my environment.

The DSProxy service listens only on IPv4, so IPv6 needs to be manually disabled.  This issue is detailed by Microsoft here.  In the single-server scenario, the way to disable IPv6 is to edit the hosts file, found in system32\drivers\etc directory.  The IPv6 line in the hosts file needs to be commented out by adding the pound character (#) in the front of the line containing “::1     localhost”.  Also, the NetBIOS name and FQDN of the Exchange server needs to be added with the private IPv4 address in the following format:

192.168.1.101        SERVER2
192.168.1.101        SERVER2.corp.domain.com

The space between the IP address and the hostnames is made using the tab key.  Make sure when you save the file that it saves as “hosts” with no extension.  Sometimes Notepad saves the file with a “.txt” extension, which must be corrected if this happens.

Step Seven: Test again

Once making the hosts file changes, the test at https://www.testexchangeconnectivity.com passed all sections for me.  Outlook configuration is a breeze with the Autodiscover service working properly.

I hope this article helps someone in configuring their Exchange 2007 single-server setup.  If anyone feels I’ve missed something, please let me know.