Answer: Yes, you can.

Often people ask me whether wildcard SSL certificates can be used with Exchange Server 2010, because they have heard that they are either unsupported, not secure, or just not recommended.

What is a wildcard SSL certificate? From Microsoft TechNet:

A wildcard certificate is designed to support a domain and multiple subdomains. For example, configuring a wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, web.contoso.com, and autodiscover.contoso.com.

The attractiveness of wildcard SSL certificates is that they are usually cheaper than other types of certificates, and they make some Exchange Server configurations easier to manage.

Support for Exchange 2010 and Wildcard SSL Certificates

The support question is a relatively easy one to answer. Yes they are supported from a vendor perspective. One clue for this is that wildcard SSL certificates are an option in the Exchange 2010 new certificate wizard. Microsoft does not make a habit of including options in Exchange Server that will lead you down an unsupported path.

However they are not supported for all scenarios. For example:

• wildcard certificates can’t be used in conjunction with OCS 2007 (eg for secure communications for UM/OWA integration)
• wildcard certificates are not supported for older mobile devices such as Windows Mobile 5.0

Security Implications for Exchange 2010 and Wildcard SSL Certificates

The security question is also relatively easy to answer. The common assumption is that wildcard SSL certificates are less secure than other SSL certificates.

Microsoft’s own documentation even references “security implications”.

…many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain. A more secure alternative is to list each of the required domains as SANs in the certificate. By default, this approach is used when certificate requests are generated by Exchange.

Verisign/Symantec describes some of those implications here:

• Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
• Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.

However, put those concerns in the context of your Exchange organization. If you’re using a wildcard SSL certificate to secure a single, internet-facing Client Access server then the above issues do not create much concern.

On the other hand if you’re deploying a large, global Exchange organization with multiple geographic entry points for various services, or those services spread over many services, then those issues are of greater concern.

Summary

So in conclusion, yes Exchange 2010 supports wildcard SSL certificates and no they are not necessarily less secure than other certificates.

However, do your due diligence and make sure that the specific support and security scenarios that do exist will not adversely impact your own Exchange 2010 deployment.

Related posts:

• Exchange SSL Certificate Management Survey
• Exchange Server 2010 POP3: Securing POP3 Client Remote Access
• Autodiscover and SSL Warnings during Exchange 2010 Migration
• Exchange 2010 SSL Certificates
• SSL Certificate Trust Errors for New Thawte Certificates

This article Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported? is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

As the post says it is less than 10 minutes work to complete the survey.

I’ve just filled out the survey myself and it prompted a few thoughts on Exchange Server SSL certificate management.

For one thing, Exchange Server 2010 has much better certificate management tools than Exchange Server 2007. However the survey made me think of at least two ways that it could be improved.

1. Add an option to the Exchange Management Console to skip the CRL check when enabling an SSL certificate for Exchange services. Currently if the CRL check fails (very common when servers are not permitted to access the web directly) the administrator sees an error. Though you can work around it with proxy settings this can also break the Exchange management tools completely if misconfigured. The other workaround is to enable the certificate using the Exchange Management Shell.
2. Add an option to Exchange setup to use an internal Certificate Authority for the initial SSL certificate, if one is available. A lot of customers do use internal CA’s for the internal-facing Client Access servers, and this option would solve the Autodiscover certificate warnings that are caused by self-signed certificates.

Related posts:

• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Exchange Server 2010 POP3: Securing POP3 Client Remote Access
• Exchange Server 2010 and the Benefits of Commercial SSL Certificates
• Causes of MapiExceptionNotAuthorized Error Sending to Public Folders
• Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

This article Exchange SSL Certificate Management Survey is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

I’ve had a few questions lately about Autodiscover and Exchange 2010 SSL certificates. The questions are usually along the lines of:

• Do I need to add the Autodiscover name to my SSL certificate?
• Do I need an Autodiscover name for all of my SMTP domains in my SSL certificate?

Both questions can be answered easily once you understand the basics of Autodiscover.

Put simply, Autodiscover is a service hosted on Client Access servers that Outlook 2007 and 2010 clients can use to automatically discover information about the Exchange environment.

An example of Autodiscover in action is when a mailbox-enabled user launches Outlook 2007/2010 for the first time and the Outlook profile is automatically configured with the correct Exchange server name for that mailbox user.

For internal, domain-joined clients this involves looking up the Autodiscover SCP (Service Connection Point) for the AD Site that the user’s computer is in. Or if no SCP exists for that site the SCP in another site will be used. This is configurable and is known as Autodiscover site scope.

The SCP is returned as a URL. This URL will be one of the Client Access servers in the organization, and will look something like this:

Get-ClientAccessServer | fl name,autodiscoverserviceinternaluri

Name                           : ESP-HO-EX2010A
AutoDiscoverServiceInternalUri : https://esp-ho-ex2010a.exchangeserverpro.net/Autodiscover/Autodiscover.xml

So for an internal, domain-joined computer the SSL certificate must include the name (or names, if more than one exists) for the Client Access servers in the organization that a client will be discovering via that SCP lookup.

Externally connected clients are different, because they can’t lookup the SCP in Active Directory from outside of the network. These clients might be roaming laptop users with Outlook, or they might be ActiveSync capable smartphones such as iPhones. In either case they will attempt to connect to Autodiscover by performing a DNS lookup for “autodiscover.smtpdomainname”.

For example an iPhone user setting up their Exchange mailbox will enter their email address (eg john@exchangeserverpro.net), user name and password. The iPhone will then attempt to autodiscover the Exchange server by looking up “autodiscover.exchangeserverpro.net” in DNS. If it can resolve that name it will then connect to https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml to retrieve Exchange server information.

So for an externally connected client the SSL certificate must include the autodiscover.exchangeserverpro.net name, or optionally the “exchangeserverpro.net” name if you don’t configure an “autodiscover” name (though I recommend you do, as often the domain name on its own resolves to a different IP address such as the web server that hosts the company’s website). Naturally that name must also be in your public DNS zone.

Now that you can see that you need the “autodiscover.smtpdomainname” name in the Exchange 2010 SSL certificate the final question is whether you need to include autodiscover names for all of your SMTP domain names.

The answer is that you will only need an autodiscover name for each SMTP domain that a user is likely to enter as their email address (eg in the iPhone example above). So for most organizations this means any domain names that are used as primary email addresses for mailboxes. Any additional domains that may be legacy names from a previous company name or a merger can probably be left out of the certificate.

Related posts:

• Autodiscover and SSL Warnings during Exchange 2010 Migration
• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Exchange SSL Certificate Management Survey
• Exchange 2010 FAQ: Which Order Should I Install Service Packs and Update Rollups?
• Exchange 2010 FAQ: Can I Access Public Folders Using IMAP?

This article Exchange 2010 FAQ: Do I Need Autodiscover Names in the SSL Certificate? is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

We are approaching the stage of the migration project where the Exchange 2010 servers begin to perform production roles, such as message routing, remote access, and hosting mailboxes.

This period is referred to as the “co-existence” period.

For some organizations a co-existence period is not necessary, because they are small enough that 100% of the services and data on Exchange 2003 can be migrated across to Exchange 2010 within a single outage window.

For example a small business with just a few dozen, small mailboxes could perform the entire migration in a single weekend with no business hours impact.  Such organizations can skip the co-existence phase if they wish to, which reduces the amount of configuration work required.

However for the rest of us a co-existence period is required, which means there are some necessary configurations to put in place first before any production services or data are migrated to Exchange 2010.

Establishing the Legacy Namespace

The legacy namespace is the name that will be used by Exchange 2003 mailbox users to access Outlook Web Access after the remote access namespace is transitioned to the internet-facing Exchange 2010 Client Access server.

What this means is that Outlook Web Access/App connections are first made to the Client Access server.  Exchange 2010 mailbox users are proxied as normal to the appropriate Mailbox server.  However Exchange 2003 mailbox users are redirected to the legacy namespace instead.

Some people find the legacy namespace to be a confusing topic.  In effect the legacy namespace is simply another DNS name, published with ISA Server or another firewall, that legacy (Exchange 2003) mailbox users are redirected to for Outlook Web Access.

Creating the Legacy DNS Record

The legacy name can be anything you like however the name that is commonly chosen is simply “legacy”, or in this example scenario “legacy.exchangeserverpro.net”.

This legacy name should be included in your Exchange 2010 SSL certificate when it is provisioned.

Create a DNS record for the legacy name in your public DNS zone.  If you are using split DNS you should also create the record in your internal DNS zone.

The public IP address that the DNS record is created for can be the same as the public IP address of your primary remote access name (e.g. mail.exchangeserverpro.net) if you are using ISA Server 2006 to publish Exchange remote access.  ISA Server is capable of publishing the different names to different internal servers using the same web listener.

If you are using a different firewall or a simple NAT router then you may need to configure the legacy namespace on a separate public IP address.

Tip: If you are using split DNS take a look at how your existing OWA public name is configured in your internal DNS zone.  If it uses the public IP then do the same with your legacy name, however if it uses the internal IP then you should configure the legacy name to the internal IP as well for the internal DNS zone.

Configuring the OWA Virtual Directory for Legacy Redirection

The OWA Virtual Directory on the internet-facing Client Access server must be configured with the legacy URL to redirect users to.

Open the Exchange Management Shell and run the Set-OWAVirtualDirectory cmdlet with the following parameters:

• -Identity is the name of the OWA Virtual Directory being modified
• -Exchange2003URL is the legacy URL to redirect Exchange 2003 mailbox users to

Set-OwaVirtualDirectory -Identity "esp-ho-ex2010a\owa (Default Web Site)" -Exchange2003Url https://legacy.exchangeserverpro.net/exchange

Assigning the SSL Certificate to Exchange Server 2003

The Exchange 2003 front end server needs to be configured with the new SAN certificate that was provisioned for Exchange 2010.  This is so that remote access connections to the legacy namespace can occur over SSL without any certificate errors or warnings.

To export the certificate from Exchange Server 2010 launch the Exchange Management Shell and run the following commands.

First determine the thumbprint of the SAN certificate that is installed.

Get-ExchangeCertificate

Thumbprint                                Services   Subject
----------                                --------   -------
4DE8E0AC4ECB09623645842752FAA80C4160BF0B  ...WS.     CN=mail.exchangeserverpro.net, OU=IT Department, O=Exchange Ser...
F539B9045F765F9F0DFDE1EA9CB4BACAAE2C6C54  IP..S.     CN=esp-ho-ex2010a

In this example the thumbprint is “4DE8E0AC4ECB09623645842752FAA80C4160BF0B”.

Next export the certificate to a file by running the following command.  Note this is a single-line command.

$file = Export-ExchangeCertificate -Thumbprint 4DE8E0AC4ECB09623645842752FAA80C4160BF0B -BinaryEncoded:$true -Password (Get-Credential).password

A popup dialog appears for you to enter a password to protect the private key.  The username field is not important but requires something to be entered in it for the dialog to accept, so just enter “username” and then a strong password.

Next run the following command to generate the file.

Set-Content -Path "C:\Admin\ex2010cert.pfx" -Value $file.FileData -Encoding Byte

Open Windows Explorer and look at the location you specified as the –Path parameter in the above command, and you will now see the exported certificate.

Copy the file to the Exchange Server 2003 front end server.

On the Exchange 2003 front end server launch mmc.exe and add the Certificates snap-in to the console, choosing the Computer account context.

Choose Local Computer and then click Finish, Close, and OK to return to the console.

Right-click Personal and choose All Tasks -> Import.  Step through the Certificate Import Wizard choosing the certificate file that was copied from the Exchange Server 2010 server.

Enter the password that you used when the certificate was exported from Exchange Server 2010.

Place the certificate in the Personal certificate store.

Complete the wizard and confirm that the import was successful.

The imported certificate will now appear alongside the existing SSL certificate on the front end server, if you had one installed already.

The certificate now needs to be added to the HTTPS binding for the IIS website on the Exchange 2003 front end server.

Launch IIS Manager from the Administrative Tools menu of the Exchange 2003 front end server.

Right-click the web site that hosts the Exchange 2003 virtual directories, and then choose Properties.

Select the Directory Security tab and click on Server Certificate.

Click Next to step through the welcome page.  Choose Replace the current certificate, and then click Next to continue.

Select the SSL certificate that was imported from the Exchange 2010 server and click Next to continue.

Confirm your selection and then click Next again, and then Finish.

Click OK to apply the close the web site properties dialog box.

You should now test your Exchange 2003 remote access (e.g. Outlook Web Access) to verify that the new certificate is working correctly.

Related posts:

• OWA Error: The Mailbox You’re Trying to Access Isn’t Currently Available
• Free Sample Chapter from the Exchange Server 2003 to 2010 Migration Guide
• Exchange 2010 FAQ: Is Direct Exchange Migration from 2003 to 2010 Possible Without Upgrading to 2007?
• Exchange 2010 FAQ: How Do I Migrate Public Folders to Exchange Server 2010?
• Fixing Mail-Enabled Object Aliases for Exchange Server 2010 Migration

This article Configuring Co-Existence for Exchange 2003 and Exchange 2010 is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Understanding the Need for Secure POP3

The Post Office Protocol (POP) can be insecure as it allows the passing of user credentials in plain text.  To understand how serious this is, imagine that your end users are in a public wi-fi network and connecting to your corporate Exchange servers over POP3.  They’ll be authenticating with their Active Directory username and password.

If POP access is not secured those credentials will be sent “in the clear” and could be sniffed by an attacker who is also on the same wi-fi network.  To see an example of this in action, here is a POP3 session login sniffed on an insecure network.

Insecure POP3 login traffic

The user’s cleverly chosen password of “Seagull1″ is visible to anyone who is able to sniff the network traffic.

As you can see in the example above it is very important that POP traffic is secured if you plan to use it for remote email access in your Exchange 2010 environment.

Configuring Security for the Exchange Server 2010 POP3 Service

To configure the POP3 service on Exchange Server 2010 Client Access servers open the Exchange Management Console and navigate to Server Configuration/Client Access.

Click on the name of the Client Access server you want to configure, and then open the Properties of the POP3 protocol in the lower pane.

Configuring the POP3 protocol for Exchange 2010 Client Access servers

On the Authentication tab you can see that Secure logon is the default setting.  So why have I been explaining the importance of POP3 security to you when Exchange 2010 is secure by default?

Exchange 2010 POP3 default Authentication settings

Because I see a lot of customers changing this setting to Plain text logon, simply because that is the easiest way to get POP3 working quickly.  Usually they do this because they encounter logon errors for clients who are trying to connect.

POP3 logon errors for Exchange Server 2010 remote user

A network capture shows the same error occurring.

Exchange 2010 POP3 client logon error network traffic

This will happen if the email client is not configured to use SSL for the connection.

Configuring SSL connection for POP3 client

When the POP3 connection is made using SSL the client is able to logon and retrieve mail successfully.  And more importantly, they are doing so without attackers on insecure networks being able to sniff the credentials from the network traffic.

Network capture of SSL-secured POP3 traffic

Configuring Ports for Exchange Server 2010 POP3

You may have noticed in the screenshot above that when the client is configured for SSL it changes the port from 110 to 995.  TCP 995 is the port for SSL-secured POP3.  The POP3 service is bound to both ports 110 and 995 by default.  You can see this in the Bindings tab of the POP3 properties.

Exchange 2010 POP3 default port bindings

Configuring an SSL Certificate for Exchange Server 2010 POP3

Because SSL is being used to secure the POP3 connections you will need to configure an SSL certificate for your Client Access server.

This certificate must include the name that you want your remote users to connect to for POP3 access, as well as be trusted by the remote user’s computer that they are connecting from.  If it is not trusted, or there is a name mismatch, then they may receive certificate warnings in their POP3 email client.

Certificate warnings for Exchange 2010 POP3 users

To fix this after installing an SSL certificate configure the certificate name in the Authentication tab of the POP3 properties.

Configuring SSL certificate name for Exchange 2010 POP3

You’ll need to restart the POP3 service to apply this or any other configuration change that you make.

When all of the settings are configured correctly your remote email users will be able to connect to Exchange Server 2010 over POP3 securely.

In the next part of this tutorial series we’ll take a look at some of the other configuration options for Exchange 2010 POP3.

Related posts:

• Publishing Exchange 2010 POP3 with ISA Server 2006
• Exchange Server 2010 POP3: Getting Started
• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Exchange SSL Certificate Management Survey
• How to Configure Windows Live Mail for Exchange 2010 POP3

This article Exchange Server 2010 POP3: Securing POP3 Client Remote Access is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

When Exchange Server 2010 is first installed many administrators encounter an issue with Outlook clients and SSL certificate warnings, relating to the Autodiscover service and the use of SSL for Exchange Server 2010 by default.

Autodiscover is a service that allows compatible Outlook versions and mobile devices to automatically detect and configure a user’s mailbox settings.  When the Exchange Server 2010 Client Access server role is installed into an Exchange organization it automatically registers the Autodiscover service in Active Directory.

Outlook clients will connect to Autodiscover using SSL (HTTPS), but the new Exchange 2010 Client Access server is only configured with a self-signed SSL certificate when it is first installed.  This can lead to certificate warnings for your end users who are running Outlook 2007 or Outlook 2010.

Outlook Warning for Untrusted SSL Certificate

So you may wish to install the first Exchange 2010 server outside of business hours, so that you have time to resolve the SSL certificate warnings without impacting your end users.

There are three ways to quickly resolve the Outlook SSL certificate warnings in Exchange 2010 environments:

• Adding the Exchange Server certificate to the Trusted Root Certification Authorities on all of your end user computers using a Group Policy (not recommended)
• Issuing a new Exchange 2010 SSL certificate from a private Certificate Authority on your network (not ideal, but resolves the issue for computers that are domain members)
• Purchasing a new Exchange 2010 SSL certificate from a commercial Certificate Authority and installing it on the Exchange 2010 server (this is the best solution, but will of course require you to spend money)

Related posts:

• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Exchange 2010 FAQ: Do I Need Autodiscover Names in the SSL Certificate?
• Exchange 2010 SSL Certificates
• How to Configure Exchange Server 2010 Outlook Anywhere
• SSL Certificate Trust Errors for New Thawte Certificates

This article Autodiscover and SSL Warnings during Exchange 2010 Migration is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

SSL Requirements in Exchange Server 2010

Prior to Exchange Server 2007 an Exchange server could be deployed and by default would not require SSL for any of its communications.  The wise move when deploying Exchange Server 2003 (for example) was to install an SSL certificate for IIS and use SSL for external access (eg Outlook Web Access and ActiveSync).  However this was not mandatory and it certainly isn’t unusual to encounter legacy Exchange environments that allow external access over insecure HTTP connections.

For Exchange Server 2007, and then again with Exchange Server 2010, Microsoft changed the default behaviour so that SSL was required for many services, even when they are only used internally.  So a newly installed Exchange Server 2010 server that hosted the Client Access server role would have SSL enforced for services such as:

• Outlook Web App
• ActiveSync
• Exchange Web Services
• Outlook Anywhere

The administrator could disable that SSL requirement, but again the wise move is to protect Exchange Server 2010 communications with SSL encryption rather than allow them over insecure HTTP connections.

Because the SSL requirement is on by default the Exchange 2007 and Exchange 2010 servers are installed with a self-signed SSL certificate.  This self-signed certificate does the job of securing any SSL connections, however because it is self-signed no connecting clients or devices will trust it, so it is unsuitable for long term use.  The administrator needs to install a new SSL certificate for Exchange Server 2010.

Exchange 2010 SAN Certificates

Administrators who have installed SSL certificates for Exchange before may be familiar with the general process involved.  But they might not be familiar with the SSL certificate requirements for Exchange Server 2010.

In short, Exchange Server 2010 will respond to connections on multiple names.  These names typically include:

• The fully qualified domain name (FQDN) of the Exchange server, eg ex2.exchangeserverpro.net
• DNS aliases for external access, eg mail.exchangeserverpro.net or webmail.exchangeserverpro.net
• The Autodiscover name of each SMTP namespace in the organization, eg autodiscover.exchangeserverpro.net

This makes a standard single-name SSL certificate unsuitable.  Instead, Exchange Server 2010 must be installed with a SAN certificate.

SAN stands for Subject Alternative Names and is a type of SSL certificate that has an attribute that stores additional names for the SSL certificate to apply to.  For example, here is the certificate used to secure Outlook Web App for Microsoft.

Exchange 2010 SSL certificate used by Microsoft

In Exchange Server 2007 it was possible to make a series of configuration changes so that a single-name SSL certificate would work.  However these changes were complex, especially in larger environments, and the cost to perform and maintain them (in terms of administrative time spent) far outweighed the cost of a genuine SAN certificate from a commercial Certificate Authority.

Where to Buy SSL Certificates for Exchange 2010

There are lots of commercial Certificate Authorities to choose from when buying an SSL certificate for your Exchange Server 2010 servers.  These include:

• Verisign
• Thawte
• Digicert
• GoDaddy

Each of these providers is different in terms of pricing, licensing and support, so I do recommend that you take a close look and compare them in detail before making a decision.

However my recommendation is to use Digicert’s Unified Communications Certificate, which I like for the pricing, generous licensing terms, and support such as unlimited reissues of the certificate (if for example you forget one of the alternative names the first time you request the certificate).

How to Install an SSL Certificate for Exchange Server 2010

The process to acquire and install an Exchange 2010 SSL certificate is as follows.

1. Generate a new certificate request using the wizard built in to Exchange Server 2010
2. Submit the certificate request to your chosen Certificate Authority
3. Install the issued SSL certificate on the Exchange 2010 server
4. Assign the new SSL certificate to the appropriate services on the Exchange 2010 server

The complete process is demonstrated in this article:

• Configure an SSL Certificate for Exchange Server 2010

If you are performing these steps for training or demo lab purposes you may wish to save money and issue the certificate from a private Certificate Authority instead.  If that is the case then follow the steps in this article:

• How to Issue a SAN Certificate to Exchange Server 2010 from a Private Certificate Authority

When using private Certificate Authorities you can potentially encounter trust issues that prevent Exchange 2010 from using the certificate.  See this article for details of how to fix this problem:

• Exchange Server 2010 “The Certificate is Invalid for Exchange Server Usage” Error

And finally, in some network environments with restricted access to the internet you may find the new SSL certificate can’t be used by Exchange 2010 because it can’t check it against the certificate revocation list.  If that happens to you follow the steps in this article to solve the problem:

• Exchange 2010 Certificate Revocation Checks and Proxy Settings

Related posts:

• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Autodiscover and SSL Warnings during Exchange 2010 Migration
• SSL Certificate Trust Errors for New Thawte Certificates
• Exchange Server 2010 and the Benefits of Commercial SSL Certificates
• How to Issue a SAN Certificate to Exchange Server 2010 from a Private Certificate Authority

This article Exchange 2010 SSL Certificates is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Outlook Anywhere is a much better solution for remote email access than POP or IMAP because the end user experience is the same when the user is using Outlook on the LAN or remotely. Thanks to SSL encryption Outlook Anywhere is also inherently more secure than other protocols that have non-encrypted options that companies often deploy.

What is Outlook Anywhere?

Outlook Anywhere is a service provided by the Client Access server role that allows Outlook clients to make a secure connection over SSL/HTTPS to the mailbox from remote locations.  Previously this was known as RPC-over-HTTPS but was renamed to Outlook Anywhere in Exchange 2007 and 2010.

By wrapping normal Outlook RPC requests in HTTPS the connections are able to traverse firewalls over the common SSL/HTTPS port without requiring the RPC ports to be opened.

There are three main tasks to deploy Outlook Anywhere in an Exchange environment:

• Enable and configure Outlook Anywhere on the Client Access server
• Configure the perimeter firewall to allow SSL/HTTPS connections from external networks to the Client Access server
• Configure the Outlook clients to use Outlook Anywhere when connecting from remote networks

Enable Outlook Anywhere on Exchange Server 2010

In the Exchange Management Console navigate to Server Configuration -> Client Access, and select the Client Access server you want to enable for Outlook Anywhere.

If you have multiple Client Access servers in an Active Directory site then choose the one that is the internet-facing Client Access server.  Or if you have deployed a CAS array you will need to repeat this process on all members of the array.

Choose the Exchange Server 2010 Client Access Server to configure for Outlook Anywhere

With the server selected, in the action pane of the Exchange Management Console click on Enable Outlook Anywhere.

Enable Outlook Anywhere for Exchange Server 2010

The Enable Outlook Anywhere wizard launches.  Enter the external host name for Outlook Anywhere users to use when connecting remotely to Exchange, and choose an authentication method.

Configure Outlook Anywhere for Exchange Server 2010

The external host name you choose should ideally be one that is already included in the Exchange certificate configured on the Client Access server.  Otherwise you will need to create a new certificate for Exchange.

The Outlook Anywhere authentication method you choose will depend on a few factors in your environment.

• Basic Authentication – this requires that Outlook users enter their username and password each time they connect to Outlook Anywhere.  The credentials are sent in clear text so therefore it is critical that Outlook Anywhere connections only occur over SSL/HTTPS.  You may need to choose Basic Authentication if the connecting computers are not members of the domain, if the ISA Server publishing rule and listener are shared with other Exchange services that require Basic Authentication, or if the firewall being used does not support NTLM authentication.
• NTLM Authentication – this is ideal for connecting clients that are domain members because the username and password will not need to be entered by the user each time they connect.  However NTLM may not work with some firewalls or ISA Server publishing scenarios.

When you have configured the Outlook Anywhere settings click Enable to continue, and then click Finish to close the wizard.

The Outlook Anywhere configuration for Exchange 2010 will take effect within 15 minutes of completing the wizard.  The Application Event Log will record Event ID 3008 and a series of other events when the configuration has been applied to the server.

Configure the Firewall for Exchange Server 2010 Outlook Anywhere

To enable remote Outlook users to connect to Outlook Anywhere the perimeter firewall for the network must be configured to allow the SSL/HTTPS connections to pass through to the Client Access server.

The precise steps for this will depend on which firewall you are using in your environment.  However the basic components of this configuration are:

• A public DNS record for the external host name you are using for Outlook Anywhere
• A public IP address on the firewall that the public DNS record resolves to
• A NAT or publishing rule to allow SSL/HTTPS connections to reach the Client Access server

Exchange Server 2010 Outlook Anywhere Firewall Overview

If you are running an internet-facing Exchange Server 2010 CAS array then you would configure the firewall rule to direct traffic to the CAS array IP address.

Configure Outlook Clients for Exchange Server 2010 Outlook Anywhere

Before an Outlook client can connect to Outlook Anywhere it needs to be configured with the correct settings.  In Outlook 2010 open the Account Settings for the Outlook profile that is configured.

Outlook 2010 Account Settings for Exchange Server 2010 Outlook Anywhere

Double-click to open the properties of the Exchange Server profile that is configured.

Outlook 2010 Exchange Server Profile Settings

Click on More Settings, and then select the Connection tab of the settings dialog box that appears.

Outlook 2010 Connection Settings

Tick the box to Connect to Microsoft Exchange using HTTP, and then click the Exchange Proxy Settings button.

Enable Outlook Anywhere in Outlook 2010

Enter the External Host Name that was configured for Outlook Anywhere earlier on the Client Access server, and then configure the Proxy Authentication Settings to match the client authentication method chosen on the server.

Configure the Outlook Anywhere External Host Name and Authentication Settings in Outlook 2010

Click OK, OK, Next and then Finish to apply the change to Outlook 2010.  You must restart Outlook for the new settings to take effect.

Now that Outlook 2010 has been configured for Exchange Server 2010 Outlook Anywhere, any time the user launches Outlook from a remote connection and can reach the perimeter firewall over the internet they will be able to securely access their mailbox as though they were still on the corporate network.

Related posts:

• Exchange Server 2010 POP3: Securing POP3 Client Remote Access
• Autodiscover and SSL Warnings during Exchange 2010 Migration
• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Error Message “The ‘IIS 6 WMI Compatibility’ component is required” During Exchange 2010 SP2 Upgrade
• Exchange 2010 FAQ: How to Minimise Downtime During Mailbox Migration from Exchange 2007

This article How to Configure Exchange Server 2010 Outlook Anywhere is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Web browsers will return an error such as:

The security certificate issued by this website was not issued by a trusted certificate authority

On inspection of the certificate being issued by the website you may see this error:

The issuer of this certificate could not be found

This can be confusing for people who assume that any certificate issued by a commercial CA such as Thawte will be trusted by devices and web browsers that people are connecting from, especially when it occurs after renewing an existing Thawte SSL certificate.

Thawte has published the reason for this:

On June 27 2010, in the interest of better security, thawte signed all certificates with a primary and secondary intermediate that need to be installed along with the SSL certificate. Any certificate issued on or after this date requires the primary and secondary intermediate to be installed.

The new certificates are issued by an intermediate CA known as “Thawte SSL CA”.  This CA is not automatically trusted by most web browsers.  Thawte provides instructions for installing the correct certificates on the web server or ISA Server that is publishing the website.

Take note of the final steps, the change may not take effect until IIS or ISA Server are restarted.

If your site still have the chaining error, restart the IIS service. If the problem continues, the whole server needs a reboot to use the new roots.

Related posts:

• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Autodiscover and SSL Warnings during Exchange 2010 Migration
• Exchange 2010 SSL Certificates
• Exchange Server 2010 and the Benefits of Commercial SSL Certificates
• How to Issue a SAN Certificate to Exchange Server 2010 from a Private Certificate Authority

This article SSL Certificate Trust Errors for New Thawte Certificates is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

The business case is clear for purchasing SSL SAN certificates from a genuine commercial certificate authority to use with Exchange Server 2007 and 2010. For an outlay of as little as a few hundred dollars the business receives the benefits of:

• Far less administrative effort to implement and maintain SSL for Exchange services
• Compatibility with devices and applications that require connection to Exchange services over SSL
• Access to Exchange services such as Outlook Web App for remote workers without undermining the security of the network or encouraging insecure behavior by users

Read the full article here.

I frequently encounter customers who request to (in some cases demand to) or have already deployed Exchange Server 2010 with a self-signed or a privately issued certificate.  In 2007 it was possible though cumbersome and frustrating.  In Exchange 2010 it is possible in some scenarios, equally frustrating, and in a few cases seems to be impossible to achieve 100% seamless integration and trust even for domain members (notably Exchange 2010 with Outlook 2010).

Any perceived cost savings by avoiding commercial certificates are a false economy. You spend far more on consultant and administrator effort to implement and maintain the environment with non-commercial certificates.

I generally recommend Digicert’s Unified Communications certificate for Exchange Server 2010 deployments, as I find them easy to deal with and good value.

Related posts:

• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• Exchange SSL Certificate Management Survey
• Autodiscover and SSL Warnings during Exchange 2010 Migration
• Exchange 2010 SSL Certificates
• SSL Certificate Trust Errors for New Thawte Certificates

This article Exchange Server 2010 and the Benefits of Commercial SSL Certificates is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com