Exchange 2013 CAS Configuration Part 1

We continue the Deep Dive series. In it you might find the answers to some of your
technical questions. The industry experts will provide their insights on several topics and
research some new features of most popular applications. The first article of the series
can be found here. You are welcome for comments and discussion!
Exchange 2013 has brought major architecture changes and now there are just two
roles Client Access Server (CAS) role and Mailbox Server role, whereas the
previous version of Exchange had five server roles.
Mailbox Server role: It includes traditional features like Mailbox Database,
transaction logs, but now it also hosts Client Access protocol, Transport service and
Unified messaging server.
Client Access Server role: It is an office client access protocol like HTTP, POP and
IMAP and SMTP. Outlook no longer uses RPC to connect to the Client Access Server,
it uses RPC over HTTPS (also known as Outlook Anywhere) and Outlook client
doesnt connect using fully qualified domain name (FQDN) or CAS Array as it was
done in all previous versions of Exchange. It uses users mailbox GUID + @ + the
domain portion of the users primary SMTP address to connect to the mailbox. This
is a huge benefit to overcome limitations and complexity of Exchange 2010 RPC
Client Access service on the Client Access Server.
In this article we will show, how to configure Exchange 2013 Client Access Server
with various settings.
Creating and configuring SSL Certificate
Exchange 2013 uses SSL Certificate, which is used for secure connection between a
client and a server. Mobile devices, computers from both inside and outside the
corporate network can be considered as clients. By Default Exchange automatically
installs self-signed certificate on both CAS and Mailbox Server. This self-signed
certificate is used to encrypt communications between CAS and Mailbox Server.
Self-signed certificate has some limitations like Outlook Anywhere may not work
with it and it needs to be replaced with a third-party digital certificate. Below you
will find the process of creating and configuring a SAN certificate on Exchange 2013
CAS. It can be done using Exchange Admin Center (EAC) or PowerShell. We will
follow the PowerShell steps to create and configure the certificate.

1. Access Exchange management shell and type the command below. This will
generate a certificate request DSR file, which needs to be sent to a CA vendor like
Verisign.
$Cert = New-ExchangeCertificateServer BlueExch01 GenerateRequestFriendlyname
Exchange2013Certificate SubjectName c=US,o=Blue,cn=mail.blue.com DomainName
mail.blue.com,autodiscover.blue.com,legacy.blue.com PrivateKeyExportable $true
Set-content -path C:\CertReq2013.req -Value $Cert

2. Verify the content CSR generate file C:\CertReq2013.req using CSR Decode from
the link below. Then send the CSR file to Verisign to generate the
certificate http://www.sslshopper.com/csr-decoder.html
3. Once you receive the certificate from a 3 rd part CA, import the certificate on the
same server, where it was generated, using the command below and assign the
certificate to IIS and SMTP services.
Import-exchangecertificate -FileData ([Byte[]]$(Get-Content -path C:\VerisignCert.cer
-Encoding byte -ReadCount 0))
Get-ExchangeCertificate ThumbPrint
A549B0F9EDB7FD9C5A1C2012D4C2B64E10D3EC34 | Enable-exchangecertificate
-Services IIS,SMTP

4. Now that we have assigned the certificate on the first server, we again need to
export and import it on all other Client Access Servers in the organization. Below is
the PowerShell command to export the certificate in the PFX file format. This
command will prompt credentials to save in the certificate. The same credentials
need to be used while importing the certificate on another server.
$certexport = Get-ExchangeCertificate DomainName mail.blue.com | ExportExchangeCertificate BinaryEncoded:$true Password (Get-Credential).password
Set-Content Path c:\cert_export.pfx Value $certexport.FileData Encoding Byte

5. To Import the certificate on the new CAS server, copy the certificate
C:\cert_export.pfx to a local computer and use the PowerShell command below to
import the same. When it prompts the credentials, enter the same username and
password, which was used during the export. Once it is imported, assign a
certificate for its services.

Import-ExchangeCertificate FileData ([byte[]](Get-Content Path c:\cert_export.pfx

Encoding Byte ReadCount 0)) Password (Get-Credential).password
Get-ExchangeCertificate ThumbPrint
A549B0F9EDB7FD9C5A1C2012D4C2B64E10D3EC34 | Enable-exchangecertificate
-Services IIS,SMTP

6. If you are in a very large organization and you have multiple servers then, you
can import it, using the PowerShell script remotely across all the CAS servers.
$servers = Get-ClientAccessServer | Select Name
foreach($server in $servers){
Import-ExchangeCertificate FileData ([byte[]](Get-Content Path
<path_to_exported_certificate> Encoding Byte ReadCount 0)) Password (GetCredential).password Server $server.name }
In this part of the article we created and configured the certificate on all CAS
servers in an organization.
In the next part, you will see how to configure CAS URLs, Outlook Anywhere and
Send Connector settings.

Exchange 2013 CAS Configuration Part 2

In the previous article, we discussed the features of Client Access Server (CAS)
regarding creation and configuration of certificates. In this part, we will learn, how
to configure Outlook Anywhere, CAS URL and the connectors.
Outlook Anywhere Configuration
Outlook Anywhere is enabled by default across all CAS, but configuration mistakes
may appear sometimes. With the architecture change, connectivity occurs through
Outlook Anywhere only. Outlook Anywhere allows users to access email internally
and externally without connecting to VPN. To configure the Outlook Anywhere
settings, you should access Exchange Admin Center (EAC), navigate to the server
properties and configure Outlook Anywhere settings. Make sure, that the external
and internal host name is correct. In our case, we will configure mail.blue.com for
both internal and external hostnames and leave the authentication method as
Negotiation. The client will try to first authenticate through NTLM and if it fails,
then it will try to use basic authentication to access emails.

CAS URL Configuration

CAS URLs configuration is very important for proper functioning of client access
protocols. The CAS URLs include Auto Discover URL, ECP Virtual Directory, Exchange
Web Service Virtual Directory, Offline Address Book Virtual Directory and finally
Active Sync Virtual Directory. The user base is both internal and external. These
URLs with authentication need to be configured separately for both internal and
external. Authentication settings are configured based on the assumption that
there are TMG/UAG servers on the DMZ to accept web request from the Internet.
Internal URLs:
$urlpath = Read-Host Enter the internal Client Access FQDN starting with http:// or
https://
$Servername = Read-Host Enter the Server FQDN to configure the URL
Get-ClientAccessServer
-Identity
$Servername
|
Set-ClientAccessServer
AutodiscoverServiceInternalUri $urlpath/autodiscover/autodiscover.xml

Get-OwaVirtualDirectory -Server $Servername| Set-owavirtualdirectory internalurl

$urlpath/owa
-FormsAuthentication
$false
-BasicAuthentication
$false
-WindowsAuthentication $true
Get-ECPVirtualDirectory -Server $Servername| Set-ecpvirtualdirectory internalurl
$urlpath/ecp
-FormsAuthentication
$false
-BasicAuthentication
$false
-WindowsAuthentication $true
Get-webservicesvirtualdirectory -Server $Servername| Set-webservicesvirtualdirectory
internalurl $urlpath/ews/exchange.asmx
Get-oabvirtualdirectory
$urlpath/oab

-Server

$Servername|

Set-oabvirtualdirectory

-internalurl

Get-ActiveSyncVirtualDirectory -Server $Servername | Set-ActiveSyncVirtualDirectory

-InternalUrl $urlpath/Microsoft-Server-ActiveSync

External URLs:
$urlpath = Read-Host Enter the internal Client Access FQDN starting with http:// or
https://
$Servername = Read-Host Enter the Server FQDN to configure the URL
Get-OwaVirtualDirectory -Server $Servername| Set-owavirtualdirectory Externalurl
$urlpath/owa
-FormsAuthentication
$false
-BasicAuthentication
$false
-WindowsAuthentication $true
Get-ECPVirtualDirectory -Server $Servername| Set-ecpvirtualdirectory Externalurl
$urlpath/ecp
-FormsAuthentication
$false
-BasicAuthentication
$false
-WindowsAuthentication $true
Get-webservicesvirtualdirectory -Server $Servername| Set-webservicesvirtualdirectory
Externalurl $urlpath/ews/exchange.asmx
Get-oabvirtualdirectory -Server $Servername| Set-oabvirtualdirectory Externalurl
$urlpath/oab
Get-ActiveSyncVirtualDirectory -Server $Servername | Set-ActiveSyncVirtualDirectory
Externalurl $urlpath/Microsoft-Server-ActiveSync

Send and Receive Connector Configuration

During the installation of every CAS role, a Default frontend <server name>
Receive Connector is created to accept emails and configured to accept anonymous
connection as well. In the existing origination Send Connector would already be in
place, we just need to add Exchange 2013 mailbox server in the Send Connector
and remove legacy servers. In the new environment, we need to create a new Send
Connector for all the Internet domains.
Configure DNS Configuration
DNS configuration directs all client requests to Exchange 2013 servers. In our
example, we have mail.blue.com, which is the point of communication for all clients
to access emails from both internal and external.
CAS plays a major role in Exchange 2013 organization, though its functionality is
limited. To balance the load of the traffic across multiple servers, you can use the
DNS round robin or Layer 4 load balancing.
Hope this article has helped you enhance your knowledge of configuring Exchange
2013 Client Access Servers in the production environment.