Autodiscover is a web service running on Client Access servers that, as the name suggests, allows compatible client software to automatically discover a user’s mailbox settings by looking them up in Active Directory.

But first the client needs to locate a Client Access server to connect to for Autodiscover requests. Internal clients (eg Outlook 2007/2010 running on domain-joined workstations) perform a lookup in Active Directory for which Client Access servers have an Autodiscover Site Scope configured for the Active Directory Site they are currently located in.

If the client can’t determine which Site it is in (eg the subnet is not defined as one of the Site boundaries), or there is no Client Access server explicitly configured for that Site, then the client chooses a Client Access server at random.

The risk here is that the client will choose a Client Access server that is not the most ideal one in terms of bandwidth and latency. To resolve this you can configure what is referred to as “site affinity” by setting the Autodiscover Site Scope on Client Access servers. This makes sure that clients will connect to the closest Autodiscover instance.

You can see the current Autodiscover Site Scope for all of your Client Access servers by running this command in the Exchange Management Shell.

[PS] C:\>Get-ClientAccessServer | ft name,autodiscoversitescope

Name                                                        AutoDiscoverSiteScope
----                                                        ---------------------
AUSYDEXC01                                                  {au-Sydney}
USNYCEXC01                                                  {us-NewYork}
EULONEXC01                                                  {eu-London}

Let’s say for example there is another AD Site of au-Brisbane and users there connect to mailboxes hosted in the au-Sydney site. When these Brisbane Outlook 2007/2010 clients look for an Autodiscover server to connect to it is possible they will choose the New York or London server which have a slower connection over the WAN.

To add the au-Brisbane site to the Autodiscover Site Scope of the Sydney Client Access server we can run the following commands. Because this is a multi-value attribute we have to specify all of the sites in scope, not just the one that is being added. If this was a long list of sites it would be tedious to type out manually, so instead we can first retrieve the current list of sites into an array.

[PS] C:\>$sitescope = (Get-ClientAccessServer AUSYDEXC01).autodiscoversitescope

[PS] C:\>$sitescope
au-Sydney

Next we add the new site to the array.

[PS] C:\>$sitescope += "au-Brisbane"

[PS] C:\>$sitescope
au-Sydney
au-Brisbane

Finally we update the Client Access server with the new site scope settings.

[PS] C:\>Set-ClientAccessServer AUSYDEXC01 -AutoDiscoverSiteScope $sitescope

If there were multiple Client Access servers in the au-Sydney site we could update them all at once with the following commands.

[PS] C:\>$sydneycas = Get-ExchangeServer | where {$_.Site -like "*au-Sydney" -AND $_.IsClientAccessServer -eq $true}

[PS] C:\>$sydneycas | Set-ClientAccessServer -AutoDiscoverSiteScope $scope

You can see the result of the change by retrieving the site scopes again.

[PS] C:\>Get-ClientAccessServer | ft name,autodiscoversitescope

Name                                                        AutoDiscoverSiteScope
----                                                        ---------------------
AUSYDEXC01                                                  {au-Brisbane,au-Sydney}
USNYCEXC01                                                  {us-NewYork}
EULONEXC01                                                  {eu-London}

Note that Outlook clients will connect to Autodiscover using SSL so you must correctly configure an SSL certificate for the Client Access servers.

Related posts:

• PowerShell Script: Check Exchange 2010 Database Backups
• Using Test-ServiceHealth for Exchange Server Health Checks
• PowerShell Tip: Search for Commands by Keyword
• How to Migrate a Relay Connector from Exchange Server 2007 to 2010
• Exchange 2010: How to Report Who is Authorized to Send to a Distribution List

This article Modifying Autodiscover Site Scope for Exchange 2010 is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

So when it comes time to update the CAS array members with patches, update rollups or service packs, the update process needs to be managed in a way that prevents all of the CAS array members from being offline at the same time.

Typically this means installing the updates to CAS array members one at a time, allowing each one to complete the update and (if necessary) reboot before updating the next member.

This tutorial demonstrates how to update a Client Access Server array without causing the entire array to go offline at once.  For this tutorial Update Rollup 4 for Exchange Server 2010 RTM is being installed.

Preparing the NLB Cluster for Updates

The first step is to remove the server that is about to be updated from the Network Load Balancing (NLB) cluster.

There are two ways to take a CAS array member our of the NLB cluster:

• Issue a Stop command to the server
• Issue a Drainstop command to the server

The difference between the two is that Stop will immediately stop the server regardless of who is currently connected to it, while Drainstop will put the server in a state where it will not accept new connections but will continue serving existing connections until they disconnect.

For urgent updates a Stop command may be necessary, but for planned maintenance a Drainstop has the least potential impact on active client connections to the CAS array.

To issue a Drainstop launch Network Load Balancing Manager, right-click on the desired server, choose Control Host and then Drainstop.

When the server has no more active connections it will be in a stopped state.

Right click the server and choose Properties.  Set the default state of the server to Stopped.  This will prevent it from automatically starting and accepting client connections after any reboots that the updates require, to allow you time to verify the updates were successful first before rejoining the NLB cluster.

Stop Conflicting Services

The Client Access Server role is often installed on the same server as the Hub Transport server role, even when deployed as a CAS array.

Hub Transport servers often run additional applications such as antivirus and anti-spam software that hooks into the Exchange Server services.  These can cause conflicts with Exchange Server updates, for example if a third party application tries to automatically restart a service that it depends on that has been stopped by the update process.

Forefront is one example of this, so for servers running Forefront Protection for Exchange those services can be stopped using FSUtility.

C:\> fsutility /disable

Disabling Monitoring

If the CAS array members are monitored using SCOM or another system this should also be disabled, or placed into maintenance mode before the update is performed.  This prevents unnecessary alarms in the monitoring system due to stopped services or server restarts, and also prevents the monitoring agent from trying to perform any automatic remediation such as restarting services.

Backing Up the Server

Some organizations will require an ad-hoc backup be run of at least one CAS array member before updates are applied.  Others will be happy to rely on the latest scheduled backup instead.  And some will even be satisfied that multiple CAS array members exist and so if a bad update puts one of them out of action there is no outage to end users, and the server can simply be manually reinstalled.

Updating the Server

Install the update following the procedure for that update type.

Update rollups come in the form of a .MSP file (Windows Installer Patch) that is applied to the server.  Simply double-click the file or launch it from a command line window.

Service packs are a complete reissue of the Exchange Server setup files and are installed by running setup in upgrade mode, which can be run in either graphical or command line mode.

C:\> setup /m:upgrade

Both update rollups and service packs can take some time to install, so plan a large window of time for these updates.

Verifying the Update

After the update has completed, and if necessary the server rebooted, you should check the server’s health before placing it back into production in the CAS array.

Event Logs – look for error or warning events that have started since the update was applied.

Setup Logs – service packs write a complete setup log file to C:\ExchangeSetupLogs

Services – check the Exchange services are running (or at least those that you expect to be running, some such as IMAP and POP will be stopped if you have not explicitly enabled them)

[PS] C:\>get-service *exchange*

Status   Name               DisplayName
------   ----               -----------
Running  MSExchangeAB       Microsoft Exchange Address Book
Running  MSExchangeADTop... Microsoft Exchange Active Directory...
Running  MSExchangeAntis... Microsoft Exchange Anti-spam Update
Running  MSExchangeEdgeSync Microsoft Exchange EdgeSync
Running  MSExchangeFBA      Microsoft Exchange Forms-Based Auth...
Running  MSExchangeFDS      Microsoft Exchange File Distribution
Stopped  MSExchangeImap4    Microsoft Exchange IMAP4
Running  MSExchangeMailb... Microsoft Exchange Mailbox Replication
Stopped  MSExchangeMonit... Microsoft Exchange Monitoring
Stopped  MSExchangePop3     Microsoft Exchange POP3
Running  MSExchangeProte... Microsoft Exchange Protected Servic...
Running  MSExchangeRPC      Microsoft Exchange RPC Client Access
Running  MSExchangeServi... Microsoft Exchange Service Host
Running  MSExchangeTrans... Microsoft Exchange Transport
Running  MSExchangeTrans... Microsoft Exchange Transport Log Se...
Stopped  msftesql-Exchange  Microsoft Search  (Exchange)
Running  vmickvpexchange    Hyper-V Data Exchange Service

Returning the Server to Production

If the update was successful and the server healthy then it can be placed back into production.

Re-enable services such as Forefront Protection for Exchange.

C:\> fsutility /enable

Start the server in the NLB cluster.

Set the NLB initial host state to Started.

And re-enable monitoring agents and alarms for the server.

After the first CAS array member has been successfully updated you can move on to the next one.

Related posts:

• Getting Started with Exchange Server 2010 Client Access Server Arrays
• Upgrading to Exchange Server 2010 Service Pack 2
• Exchange Server 2010 Service Pack 2
• How to Install Updates on Exchange Server 2010 Database Availability Groups
• TechEd Video: Load Balancing with Microsoft Exchange Server 2010

This article How to Install Updates on Exchange Server 2010 CAS Arrays is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

If you’re new to the concept of Client Access Server arrays and need to know more then check out this article for an introduction and overview of CAS Arrays.

Client Access Server Array Pre-Requisites

Two or more Exchange Server 2010 Client Access Servers can be configured as a CAS array using NLB as long they are not also installed as Mailbox servers that are members of a Database Availability Group (DAG).

The reason is that DAG members utilize Windows Failover Clustering, which can’t co-exist with NLB.

To demonstrate the setup of a CAS array the following servers have been provisioned.

Server #1

• Operating System: Windows Server 2008 64-bit R2
• Name: EX3.exchangeserverpro.local
• Primary Interface: 192.168.0.34/24
• Secondary Interface: 192.168.0.36/24

Server #2

• Operating System: Windows Server 2008 64-bit R2
• Name: EX4.exchangeserverpro.local
• Primary Interface: 192.168.0.35/24
• Secondary Interface: 192.168.0.37/24

The IP address allocated to the NLB cluster will be 192.168.0.38.

Installing the Exchange Server 2010 Client Access Server Pre-Requisites

On each server, from an elevated Windows PowerShell prompt, run the following commands.

PS C:\> Import-Module ServerManager

Note: In my lab the servers are also Hub Transport servers, and so I installed both sets of pre-requisites. I also use the -Restart switch to automate the restart of the servers, however you can remove this if you wish to control when the servers are restarted.

For only the Client Access Server pre-requisites:

PS C:\> Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

For the Client Access Server and Hub Transport Server pre-requisites:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

After the servers are restarted run the following command, again from an elevated PowerShell window.

Set-Service NetTcpPortSharing -StartupType Automatic

Installing the Exchange Server 2010 Client Access Server Role

From an elevated command prompt run the following unattended setup command.

Note: Again, my lab servers are also Hub Transport servers.

For only the Client Access Server role with Management Tools:

C:\admin\Exchange Server 2010> setup /m:install /r:ca,mt

For both the Client Access and Hub Transport Server roles with Management Tools:

C:\admin\Exchange Server 2010> setup /m:install /r:ca,ht,mt

Installing Windows Network Load Balancing

On each of the servers, from an elevated PowerShell window run the following commands.

PS C:\> Import-Module servermanager

PS C:\> Add-WindowsFeature NLB

Creating the NLB Cluster

After both servers have been prepared the NLB cluster can be created.  On the first server launch the Network Load Balancing Manager from Administrative Tools.

From the Cluster menu choose New.

Connect to the first server for the NLB cluster.

Choose the interface that is to be used for the cluster, and then click Next.

Accept the default Host parameters and click Next.

Click Add and enter an IPv4 address for the NLB cluster, then click OK.

Click Next to continue.

Enter a name for the cluster.  In this example I’m using casarray.exchangeserverpro.local.  Click Next to continue.

Although the port rules can be made more specific, in this example the default rule is acceptable.  Click Finish to complete the creation of the NLB cluster.

At this stage you should have a single host NLB cluster that is successfully converged.

Right-click the cluster name and choose Add Host to Cluster.

Enter the name of the second server and click Connect.  Choose the interface to be used for the cluster and click Next.

Accept the default Host Parameters and click Next.

There are no changed necessary to the port rules, so click Finish.

You should now have a dual host NLB cluster that is successfully converged.

One final step, on each of the NLB members run the following command to allow the NLB virtual IP address to be reachable from outside of the subnet that it resides in.

netsh interface ipv4 set int "NLB" forwarding=enabled

Replance “NLB” with the name of your NLB interface on your server.

Creating the Client Access Server Array

Now that the NLB cluster has been formed we can create the CAS array in Exchange Server 2010.

First, register a DNS record for the NLB cluster name.

Next, launch the Exchange Management Shell on one of the Exchange servers and run the following command.

[PS] C:\>New-ClientAccessArray -Name CASArray -Site "Default-First-Site-Name" -Fqdn casarray.exchangeserverpro.local

Name                Site                 Fqdn                           Members
----                ----                 ----                           -------
CASArray            Default-First-Sit... casarray.exchangeserverpro.... {EX3, EX4}

Substitute the Name, Site, and FQDN as appropriate for your environment.

Updating Existing Mailbox Databases

When the CAS array has been established any new mailbox databases created on servers in that Active Directory Site will be configured with the CAS array as their RpcClientAccessServer.

However any existing mailbox databases need to be manually updates so that those mailbox users begin connecting to the new CAS array.

You can see here that the existing mailbox database on server EX2 is still configured with a standalone Client Access server as its RpcClientAccessServer.

[PS] C:\>Get-MailboxDatabase -Server EX2 | fl name, rpc*

Name                  : Mailbox Database 02
RpcClientAccessServer : EX3.exchangeserverpro.local

To update all databases on the server with the new RpcClientAccessServer run the following command.

[PS] C:\>Get-MailboxDatabase -Server EX2 | Set-MailboxDatabase -RpcClientAccessServer casarray.exchangeserverpro.local

The change can be seen by running the same command as earlier.

[PS] C:\>Get-MailboxDatabase -Server EX2 | fl name, rpc*

Name                  : Mailbox Database 02
RpcClientAccessServer : casarray.exchangeserverpro.local

Note that any existing Outlook profiles will not automatically update from the single Client Access Server to the new CAS array name. Those clients will not automatically failover to an alternate member of the CAS array when there is a server failure. You will need to update those profiles for them to receive the high availability benefits of the CAS array. This is one reason that it is important to establish CAS arrays prior to migrating user mailboxes to Exchange Server 2010.

Related posts:

• How to Configure a File Share Witness for an Exchange 2010 Database Availability Group
• TechEd Video: Exchange Server 2010 High Availability Deep Dive
• TechEd Video: Exchange Server 2010 High Availability Concepts
• Poll: Should CAS Arrays be Deployed in all Exchange 2010 Sites?
• Modifying Autodiscover Site Scope for Exchange 2010

This article How to Install an Exchange Server 2010 Client Access Server Array using Windows Network Load Balancing is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Export the SSL Certificate from the Exchange Server 2003 server

On the Exchange Server 2003 server go to Start -> Run and launch mmc.exe.

Click File and Add/Remove Snap-in.

Click on Add and choose the Certificates snap-in.

Choose Computer Account then click Next.

Choose Local Computer and then click Finish.

Click Close and OK to return to the MMC, with the Certificates snap-in now installed.  Navigate to Certificates (Local Computer)/Personal/Certificates.  The SSL certificate used for Exchange remote access will be visible in the right pane of the console.

Right-click the certificate and choose All Tasks -> Export.  Click Next to move past the welcome dialog for the Certificate Export Wizard.

Choose Yes, export the private key and then click Next.

Click Next to accept the default file format.

Enter a password for the exported certificate.  You will need to remember this password to import the certificate onto other servers.  Click Next to continue.

Enter a file name for the exported certificate.  Click Next to continue.

Click Finish to complete the wizard.

Import the SSL Certificate on the Exchange Server 2007 server

Copy the exported certificate file to the Exchange Server 2007 server.

On the Exchange Server 2007 server launch mmc.exe and add the Certificates snap-in.  Navigate to Certificates (Local Computer)/Personal/Certificates.  Right-click Certificates and choose All Tasks -> Import.  Click Next to move past the welcome dialog.

Browse to the location you copied the certificate file to.  Select the file and click Open.

Click Next to continue.

Enter the password for the certificate, and tick the box to mark the key as exportable.  Click Next to continue.

Click Next to import the certificate to the Personal certificate store.

Click Finish to complete the Certificate Import Wizard.

Note: These next steps apply to IIS 7 on Windows Server 2008.

Launch Internet Information Services (IIS) Manager from the Administrative Tools menu of the Exchange Server 2007 server.  Navigate to the Default Web Site.

Click Bindings in the Actions pane of the IIS Manager console.

Select https and then click Edit.

Use the drop-down list to select the SSL certificate that you imported on the server.

Click OK and then Close.

Related posts:

• Exchange Server 2010 and the Benefits of Commercial SSL Certificates
• Configuring the Exchange Server 2007 Client Access Server
• Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?
• 500 Internal Server Error for Exchange 2007 Outlook Web Access
• Exchange SSL Certificate Management Survey

This article Migrate SSL Certificates from Exchange Server 2003 to Exchange Server 2007 is © 2009 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Open the Exchange Management Console and navigate to Server Configuration/Client Access.

Configure Outlook Web Access

Before Outlook Web Access is published to the internet you must enter the external URL.  Open the properties of the owa (Default Web Site) and enter the external URL in the field shown here.

If you are publishing via ISA Server select the Authentication tab and choose Use one or more standard authentication methods, setting it to Integrated Authentication and Basic Authentication.

Click OK when complete.  A warning will appear that the changes will not take effect until IIS is restarted.

Click OK but don’t worry about restarting IIS yet, we’ll be restarting it soon.

Configure ActiveSync

Similar to Outlook Web Access the ActiveSync external URL must be configured if it is being published to the internet.  Choose the Exchange ActiveSync tab and then open the properties of Microsoft-Server-ActiveSync.

Enter the external URL in the field shown here.

Click OK when complete.

Configure Outlook Anywhere

In the Actions pane to the right of the Exchange Management Console click on Enable Outlook Anywhere.

Enter the external host name in the field shown here.

If you are publishing via an ISA Server on the same external IP address as Outlook Web Access then choose Basic Authentication.  If you can dedicate an external IP address for publishing Outlook Anywhere then choose NTLM Authentication.

Click Enable when complete.  You will receive a warning that Outlook Anywhere will not be available for up to 15 minutes.  Click Finish to clear that warning.

Related posts:

• Test your Exchange Server remote connectivity
• Exchange Remote Connectivity Analyzer Updated
• Publish Exchange Server 2007 OWA Using ISA Server 2006
• Migrate SSL Certificates from Exchange Server 2003 to Exchange Server 2007
• OWA Error: The Mailbox You’re Trying to Access Isn’t Currently Available

This article Configuring the Exchange Server 2007 Client Access Server is © 2009 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com