With the correct SSL certificates installed on the Exchange 2013 servers we can now proceed with configuration of the Client Access server role.
Both of the Exchange 2013 servers deployed so far, EX2013SRV1 and EX2013SRV2, are multi-role servers, and need their Client Access roles configured.
Configuring Client Access URLs
The Client Access URLs are configured to match the namespaces that we planned earlier. Because the AutoDiscover URL was already configured immediately after Exchange 2013 was installed that only leaves:
- Outlook Anywhere
- Outlook Web App
- Exchange Control Panel
- ActiveSync
- Exchange Web Services
- Offline Address Book
These are easy to configure with a simple PowerShell script. Here is an example:
param(
[Parameter( Mandatory=$true)]
[string]$Server,
[Parameter( Mandatory=$true)]
[string]$InternalURL,
[Parameter( Mandatory=$true)]
[string]$ExternalURL
)
Write-Host "Configuring Outlook Anywhere URLs"
Get-OutlookAnywhere -Server $Server | Set-OutlookAnywhere -ExternalHostname $externalurl -InternalHostname $internalurl -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod NTLM
Write-Host "Configuring Outlook Web App URLs"
Get-OwaVirtualDirectory -Server $server | Set-OwaVirtualDirectory -ExternalUrl https://$externalurl/owa -InternalUrl https://$internalurl/owa
Write-Host "Configuring Exchange Control Panel URLs"
Get-EcpVirtualDirectory -Server $server | Set-EcpVirtualDirectory -ExternalUrl https://$externalurl/ecp -InternalUrl https://$internalurl/ecp
Write-Host "Configuring ActiveSync URLs"
Get-ActiveSyncVirtualDirectory -Server $server | Set-ActiveSyncVirtualDirectory -ExternalUrl https://$externalurl/Microsoft-Server-ActiveSync -InternalUrl https://$internalurl/Microsoft-Server-ActiveSync
Write-Host "Configuring Exchange Web Services URLs"
Get-WebServicesVirtualDirectory -Server $server | Set-WebServicesVirtualDirectory -ExternalUrl https://$externalurl/EWS/Exchange.asmx -InternalUrl https://$internalurl/EWS/Exchange.asmx
Write-Host "Configuring Offline Address Book URLs"
Get-OabVirtualDirectory -Server $server | Set-OabVirtualDirectory -ExternalUrl https://$externalurl/OAB -InternalUrl https://$internalurl/OAB
Simply run the script using the Exchange Management Shell (from a server or workstation with the Exchange 2013 management tools installed) with the required parameters, for example:
[PS] C:\Admin>.\ConfigureURLs.ps1 -Server ex2013srv1 -InternalURL mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net
[PS] C:\Admin>.\ConfigureURLs.ps1 -Server ex2013srv2 -InternalURL mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net
Configuring OWA and ECP Authentication
The default authentication for Exchange 2013 OWA is forms-based. If you need to use a different authentication type then you should configure it now on the OWA and ECP virtual directories for your Exchange 2013 servers. The virtual directory configuration is found in the Exchange Admin Center in the Servers -> Virtual Directories area.
![exchange-2013-owa-auth]()
For example, here I am changing the username format to UPN so that users can login with their “email address” (because the organization uses UPNs that match the primary SMTP address).
![exchange-2013-owa-auth-02]()
Restart IIS
An IISReset of each server should also be performed so that the virtual directory changes can take effect.
[PS] C:\Admin>iisreset ex2013srv1
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
[PS] C:\Admin>iisreset ex2013srv2
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
Configure POP/IMAP Settings
If you are also using POP or IMAP in your environment you should configure those services as well. For each server set the X509 certificate name, and the internal/external connection settings.
[PS] C:\>Set-PopSettings -Server ex2013srv1 -X509CertificateName pop.exchangeserverpro.net -InternalConnectionSetting pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS -ExternalConnectionSettings pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS
WARNING: Changes to POP3 settings will only take effect after all Microsoft Exchange POP3 services are restarted on
server EX2013SRV1.
[PS] C:\>Set-PopSettings -Server ex2013srv2 -X509CertificateName pop.exchangeserverpro.net -InternalConnectionSetting pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS -ExternalConnectionSettings pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS
WARNING: Changes to POP3 settings will only take effect after all Microsoft Exchange POP3 services are restarted on
server EX2013SRV2.
Restart the POP services for the servers.
[PS] C:\>Invoke-Command -ComputerName ex2013srv1,ex2013srv2 {Restart-Service MSExchangePOP3}
The same basic process applies to IMAP as well.
[PS] C:\>Set-ImapSettings -Server ex2013srv1 -X509CertificateName imap.exchangeserverpro.net -InternalConnectionSetting imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS -ExternalConnectionSettings imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS
WARNING: Changes to IMAP4 settings will only take effect after all Microsoft Exchange IMAP4 services are restarted on
server EX2013SRV1.
[PS] C:\>Set-ImapSettings -Server ex2013srv2 -X509CertificateName imap.exchangeserverpro.net -InternalConnectionSetting imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS -ExternalConnectionSettings imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS
WARNING: Changes to IMAP4 settings will only take effect after all Microsoft Exchange IMAP4 services are restarted on
server EX2013SRV2.
[PS] C:\>Invoke-Command -ComputerName ex2013srv1,ex2013srv2 {Restart-Service MSExchangeIMAP4}
Testing the Client Access Server Configuration
Ideally we would test the new configuration before pointing any production users at it. However, to test in this case we would need to change the DNS records for our Client Access namespaces (autodiscover.exchangeserverpro.net and mail.exchangeserverpro.net) to resolve to the IP address of the Exchange 2013 servers. Since that would potentially have a negative impact on end users, instead we can use a hosts file to point a test PC at the new servers.
First, create a new user and mailbox on an Exchange 2013 database. This is performed using the Exchange Admin Center.
![exchange-2013-test-user]()
Next, modify the hosts file on a test PC. The file is located in C:\Windows\System32\drivers\etc, and will require admin/elevated rights to modify.
![exchange-2013-test-user-hosts-file]()
Note: Without a load balancer in place you may need to repeat your tests multiple times for each Exchange 2013 server IP. Later when the production cut over takes place you can use DNS round robin instead.
From the test PC logged in as the Exchange 2013 test user you should be able to launch Outlook and have the profile automatically configured to open the mailbox. While you’re logged in to the mailbox you may also like to do some send/receive tests between the Exchange 2013 test mailbox and some Exchange 2010 test mailboxes to verify that mail flow is working between the servers.
In the next part of this series we’ll look at configuring the Exchange 2013 Mailbox server role.
This article Exchange Server 2010 to 2013 Migration – Configuring Client Access Servers is © 2014 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
![]()
