Script to set internal and external

URLs on all of your Exchange Virtual

Directories at once
I stumbled upon this script earlier today, it was posted on msunified.net. This is script is great! a
one stop shop for setting all of the necessary URLs needed for both internal and external access.
Copy this to a text file, save it with a .ps1 extension, and then open it and run it from the
Exchange Management Shell ( ./<scriptname>.ps1 )
#ChangeAutodiscoverPath.ps1
#Changing InternalURL Path
$urlpath = Read-Host "Type Internal Client Access FQDN starting
with http:// or https://"
Set-AutodiscoverVirtualDirectory -Identity * internalurl
$urlpath/autodiscover/autodiscover.xml
Set-ClientAccessServer Identity *
AutodiscoverServiceInternalUri
$urlpath/autodiscover/autodiscover.xml
Set-webservicesvirtualdirectory -Identity * internalurl
$urlpath/ews/exchange.asmx
Set-oabvirtualdirectory Identity * internalurl $urlpath/oab
Set-owavirtualdirectory Identity * internalurl $urlpath/owa
Set-ecpvirtualdirectory Identity * internalurl $urlpath/ecp
Set-ActiveSyncVirtualDirectory -Identity * -InternalUrl
"$urlpath/Microsoft-Server-ActiveSync"
#Changing ExternalURL Path
$urlpath2 = Read-Host "Type External Client Access FQDN starting
with http:// or https://"
Set-AutodiscoverVirtualDirectory -Identity * externalurl
$urlpath2/autodiscover/autodiscover.xml
Set-ClientAccessServer Identity *
AutodiscoverServiceInternalUri
$urlpath2/autodiscover/autodiscover.xml
Set-webservicesvirtualdirectory Identity * externalurl
$urlpath2/ews/exchange.asmx
Set-oabvirtualdirectory Identity * externalurl $urlpath2/oab
Set-owavirtualdirectory Identity * externalurl $urlpath2/owa
Set-ecpvirtualdirectory Identity * externalurl $urlpath2/ecp
Set-ActiveSyncVirtualDirectory -Identity * -ExternalUrl
"$urlpath/Microsoft-Server-ActiveSync"
#get commands to doublecheck the config
get-AutodiscoverVirtualDirectory | fl identity,internalurl,
externalurl

get-ClientAccessServer | fl
identity,AutodiscoverServiceInternalUri
get-webservicesvirtualdirectory | fl
identity,internalurl,externalurl
get-oabvirtualdirectory | fl identity,internalurl,externalurl
get-owavirtualdirectory | fl identity,internalurl,externalurl
get-ecpvirtualdirectory | fl identity,internalurl,externalurl
get-ActiveSyncVirtualDirectory | fl
identity,internalurl,externalurl

Demystifying the CAS Array

Object - Part 1
The Exchange Team
23 Mar 2012 1:20 PM

26

Since its release in 2009, the interest in Exchange 2010 has been fantastic. While working with
customers to educate them and prep them for moving to Exchange 2010, we've uncovered some
common misconceptions. One trend has to do with misconceptions around the Client Access Server
array object, or CAS array object for short. Technical Writer and frequent blogger Scott
Schnoll suggested I put pen to paper err keys to keyboard (?) when I was commenting on this trend
on an internal Microsoft distribution group, so here we are with this post.
Im not going to go into all of the technical aspects of a CAS array object in this post. That's already
been covered wonderfully by Nagesh Magadev in a prior post:Exploring Exchange 2010 RPC Client
Access service.
The following list is a collection of truths many customers are not aware of when it comes to the CAS
array object which I'll try to demystify. Part 1 will discuss the first three items and l'll cover the last
three items in part 2.
1.

A CAS array object does not load balance your traffic

2.

A CAS array object does not service Autodiscover, OWA, ECP, EWS, IMAP, POP, or SMTP

3.

A CAS array object's fqdn does not need to be part of your SSL certificate

4.

A CAS array object should not be resolvable via DNS by external clients

5.

A CAS array object should not be configured or changed after creating Exchange 2010 mailbox
databases and moving mailboxes into the databases

6.

A CAS array object should be configured even if you only have one CAS or a single multi-role
server.

Everyone confused? Nice. Lets try to fix that as best we can by going through each of these one at a
time. You'll see some server names throughout this article so why dont I show you what Im working
with in my lab first?

Name

ServerRole

AdminDisplayVersion

E2K10-MLT-01 Mailbox, ClientAccess,

HubTransport

Version 14.2 (Build 247.5)

E2K10-MLT-02 Mailbox, ClientAccess,

HubTransport

Version 14.2 (Build 247.5)

E2K7-MLT-02

Mailbox, ClientAccess,
HubTransport

Version 8.3 (Build 83.6)

E2003-BE

None

Version 6.5 (Build 7638.2: Service

Pack 2)

OK, let's dig in!

1. A CAS array object does not load balance your traffic

A CAS array object performs no load balancing. It's an Active Directory object used to automate some
functions within Exchange and that's all. Exchange 2010 documentation says all over the place that it's
recommended to use load balancers (LB) to load balance CAS traffic. So what do I mean by saying the
CAS array object performs no load balancing?
What you're actually doing with a load balancer is balancing traffic across a pool of CAS or perhaps
you could call it an array of CAS - but not the CAS array object itself. The difference is subtle yet
distinct; perhaps we didnt make the names distinct enough to help prevent the confusion in the first
place.

The primary reason, and perhaps the only reason, a CAS array object exists is to
automatically populate theRpcClientAccessServer attribute of any new Exchange
2010 mailbox database created in the same Active Directory site (as the CAS array
object).
The RpcClientAccessServer attribute is used to tell Outlook clients during the profile creation process
what server name should be in the profile. Thats pretty much it folks, there's no more magic going on
here and once you've created your CAS array object it's simply an object in Active Directory and
there's zero load balancing going on at this point in time.

The rest is up to you at this point. It's up to you to:

Create an A record in DNS that'll allow the client machine to resolve the hostname to an IP
address. This IP address will most likely be the virtual IP (VIP) of the LBreachable only by internal
clients. This VIP is where Outlook or any other MAPI/RPC capable application will then connect to gain
access to Exchange 2010 mailbox resources.

Configure your load balancing solution to pass traffic to the pool of CAS servers by way of
the VIP.
The CAS themselves have no idea there is any load balancing happening.
You may also be confused by what can be seen after creating a CAS array object using the NewClientAccessArray cmdlet or viewing a pre-existing CAS array object using the GetClientAccessArray cmdlet.
Here I'm creating a new CAS array object in my lab with the Name CASArray-A,
the FQDN of outlook.lab.local, and in the Active Directory site very aptly namedSite-A.

Figure 1: Creating a Client Access array

First of all my FQDN and Name fields dont match because the Name is a display name - it's purely
cosmetic. It's whatever you want to name it so you know what that CAS array object is being used for.
The FQDN is the record you must then create in DNS or else clients will never be able to resolve it to
an IP address to connect to. At this point, Ill remind you that there can be only one CAS array
object per Active Directory site.
So why is the Members property populated with two CAS immediately after creation? Didnt I tell you
there's no load balancing going on at this point? It looks kind of like I lied to you doesnt it?
To be honest, the Members property is a touch misleading. If you didnt read up on the steps to create
a CAS array object you may think youre done at this stage. You created your CAS array object and you
can see two CAS have automatically joined the array. By this time you may be off for a celebratory
drink or going down cube-town hallway to steal some cookies from this guy. Not quite yet my friend!
Due to the fact that we associated the CAS array object to Active Directory site Site-A, the cmdlet
simply goes and finds all Client Access servers registered as residing in Site-A and then lists them in
the Members column. I like to tell customers to think of this column as the Potential Members
column or as my colleague Kamal Abburi, another PFE here at Microsoft, suggests it's the Site CAS
Members column. You can add these Client Access servers as nodes in your load balancing solution

because they all reside in the same Active Directory site. But until the load balancer is configured we
have no load balancing.
How did the cmdlets know what site the CAS are in? Well, Im glad you asked because we get to break
out everybodys best friend AdsiEdit.msc and dig down into theConfiguration partition of Active
Directory to find the magic beans.

Figure 2: The msExchServerSite attribute of an Exchange 2010 server contains the Active Directory site the server resides in

Each Exchange server has an msExchServerSite attribute that contains the Active Directory site they
currently reside in. In case you're wondering, yes it's dynamically updated if you move an Exchange
server to a new site and the Microsoft Exchange Active Directory Topology service has a chance to run
and update a few things. But the AutoDiscoverSiteScope attribute (Part of Get/SetClientAccessServer) will not be dynamically updated and you may have funky Autodiscover results
until this is fixed depending on your site, server, and client layout.

2. A CAS array object does not service OWA, ECP, EWS, Autodiscover,
IMAP, SMTP, or POP
Lets go back for a moment to what a CAS array object actually does. It populates
the RpcClientAccessServer attribute of an Exchange 2010 mailbox database, which is then used to tell
Outlook where it needs to connect when using RPC (over TCP). For Outlook Anywhere (HTTPS) clients, it
indicates where the traffic that leaves the RPC-over-HTTP proxy needs to connect on the clients behalf
in order to reach their mailbox.
So what services does the Outlook client attempt to connect to when using RPC (over TCP)?
First Outlook connects to the CAS array object on TCP/135 to communicate with the RPC Endpoint
Mapper in order to discover the TCP ports the following two services are listening on.
1.

Microsoft Exchange RPC Client Access (aka MSExchangeRPC)

2.

Microsoft Exchange Address Book (aka MSExchangeAB)

Thats it for RPC (over TCP) mode!

Outlook Anywhere (aka RPC over HTTP) clients connect to the RPC-over-HTTP proxy component on
TCP/443 on a CAS by resolving the Outlook Anywhere external hostname, or what the Outlook profile
calls the proxy server.
Interesting geeky side note for anyone interested, Outlook automagically and quietly
adds /rpc/rpcproxy.dll to the server name specified, as thats really what it needs to connect to, but if
we asked people to type these names in, like we used to back in Outlook 2003 days, can you imagine
how many would have missed it, or got it wrong?)

Figure 3: Specifying the RPC Proxy URL in Outlook 2003

Traffic is routed out of the RPC-over-HTTP proxy to the appropriate MAPI/RPC endpoint using a list of
hard-coded, rather than dynamically assigned TCP ports, those being TCP 6001, TCP 6002, and TCP
6004. The Outlook Anywhere external hostname is purposefully not the same FQDN as the CAS array
object and Ill explain why later on.
A client may also make HTTPS connections to services such as Autodiscover, OAB downloads, EWS,
POP, or IMAP, but these services are defined by entirely different methods such as virtual directory
URLs or the
value. None of these additional services are serviced by the CAS array object as none of them are
using RPC, although its likely to be the same server they are connecting to. The CAS array objects
FQDN may share the same VIP as the other services URLs, but we strongly recommend the CAS array
object FQDN not be the same as the other services URLs if split DNS is in use. More on that last
recommendation later.

3. A CAS array object's FQDN does not need to be part of your SSL certificate
name list
This is a very common misconception usually spawned due to the item directly above. SSL certificates
in the realm of this article are only utilized when we want to do something like establish an SSLprotected HTTP session. Because RPC (over TCP) is not an HTTP session, it's not going to be protected
with SSL and therefore, we don't need the CAS array object's FQDN to be included on the subject name
list of the SSL certificate. Let's take a look at it.
Below is Outlook 2010 in MAPI/RPC mode connected to an Exchange 2010 CAS array object.

Figure 4: Outlook 2010 RPC (over TCP) connections to Exchange 2010 CAS

We can see it has made one directory and two mail connections. In the netstat output (overlayed
above the screenshot) we see the machine has made one endpoint mapper connection (TCP 135) to
the CAS array object as well as connections to TCP 59531 and TCP 59532 which represent the statically
assigned TCP ports for the MSExchangRPC and MSExchangeAB services respectively in this lab.
From the server side we can see the services listening using the command netstat n b.

Figure 5: Services Outlook needs to connect to when using RPC (over TCP)

As expected, it shows that none of the services are being contacted over HTTP (to TCP 443). This is
why you don't need the CAS array object FQDN on the SSL certificate.
Thinking you need the CAS array FQDN on the SSL certificate can sometimes be confused by the way
Outlook displays connections while in HTTPS mode as seen below.

Figure 6:Outlook Anywhere connections

This time we see Outlook 2010 has made two mail connections and a Public Folder connection when
the screen shot was taken and we can also see we are using HTTPS. From within Outlook it looks as if
we are connected to outlook.lab.local and E2K10-MLT-01.lab.local, which we are sort of, but utilizing
netstat once again we see we are actually connected to the RPC-over-HTTP proxy located
at webmail.lab.local on TCP/443 (HTTPS). Outlook will always display what server is eventually
connected to for data by itself or via RPC-over-HTTP proxy. If you're wondering why we see 6
connections via netstat instead of three, it's because HTTP is a half-duplex protocol and we therefore
establish an RPC_DATA_IN and an RPC_DATA_OUT channel for each connection seen inside Outlook.
You may also be thinking, Wait! Outlook 2007 and 2010 encrypt RPC sessions by default! We have to
have the name on the cert! Wrong-O my friends because the encryption setting you see below utilizes
RPC encryption and has nothing to do with SSL. The communication is still happening over RPC and not
over HTTPS.

Figure 7: When connecting using RPC (over TCP), Outlook uses RPC encryption

Simple isnt it! If a CAS array object met a Certification Authority and the CA said: Hey man you really
need me! Cmon Ill sell you a swanky wildcard cert on the cheap!the CAS array object would simply
reply Honey badger dont care! and probably use the CA to crack open a pistachio. Now that's of
course if you followed our recommendation to use a different FQDN for the CAS array object than
youre using for the other service FQDN(s). Yes, Im getting to why
I hope Part 1 of this article has been helpful to you so far in making sense of some common
misunderstood issues with CAS array objects, and hope that youll tune in for Part 2 at a later time
where we'll cover the remaining three common misconceptions about CAS array objects.

Brian Day
Premier Field Engineer, Messaging
Continue to Demystifying the CAS Array Object - Part 2.

Demystifying the CAS Array

Object - Part 2
The Exchange Team
28 Mar 2012 2:00 PM

21

Welcome back! In Demystifying the CAS Array Object - Part 1 we covered these three items to
begin demystifying the CASarray object in Exchange Server 2010.
1.

A CAS array object does not load balance your traffic

2.

A CAS array object does not service OWA, ECP, EWS, Autodiscover, IMAP, SMTP, or POP

3.

A CAS array object does not need to be part of your SSL certificate

Here in Part 2 we will cover the following three items, and once and for all lift the fog away from the
CAS array object to help you correct existing deployments and/or plan more strategically for future
deployments.
4.

A CAS array object should not be resolvable via DNS by external clients

5.

A CAS array object should not be configured or changed after creating Exchange Server 2010
mailbox databases and moving mailboxes into the databases

6.

A CAS array object should be configured even if you only have one CAS or a single multi-role
server.

4. A CAS array object should not be resolvable via DNS by external clients
As mentioned in Part 1 (at least twice, I stopped counting) your CAS array object FQDN should not be
the same FQDN used for other services such as OWA, ECP, EWS, EAS, Autodiscover, or the Outlook
Anywhere external hostname.
The primary reason for this is Outlook Anywhere clients will first attempt to resolve the CAS array
object FQDN via DNS so it knows if it should even bother to attempt a RPC (over TCP) connection or go
right to HTTPS. Do you allow RPC (over TCP) connections directly in from the Internet to your Intranet? I
hope you dont, and if you do youll be getting a big red flag on your Exchange Risk and Health
Assessment Program report. If the client does first attempt to connect via RPC (over TCP) due to
being able to successfully resolve the CAS array object FQDN there could be a significant delay before
the client falls back to attempt an HTTPS connection to the Outlook Anywhere proxy URL. This delay
may result in higher helpdesk call generation if end users perceive this delay as degraded performance
and/or the service being broken.
To avoid this situation simply make sure your internal CAS array object FQDN is something unique to
internal DNS, perhaps like outlook.corp.contoso.com while your other non-RPC (over TCP) service URLs
utilize something like mail.contoso.com internally and externally via split DNS.
If you haven't had the opportunity to utilize split DNS, it is when you have a set of internal AND
external DNS servers handling requests for the same forward lookup zone, for example contoso.com.
The two DNS infrastructures are completely isolated from each other. There are no zone transfers, nor
are they utilizing each other as DNS forwarders. This configuration allows internal users utilizing the
internal DNS infrastructure to resolve the host mail.contoso.com to an internal IP address (for example,
192.168.1.10) that goes to your load balancer VIP while external users resolve it to the public IP
address which may point to your Internet-facing Forefront TMG/UAG infrastructure in your perimeter
network. It's very common for the CAS array object IP address and the internal IP address of the nonRPC (over TCP) service URLs (OWA, ECP, EWS, etc) to be the same load balancer VIP, but they may
utilize different is-alive checks for proper service state detection.

Does your DNS serve a wildcard response?

I've had at least one customer who had an external DNS server that utilized a wildcard record in
response for any query it received for a non-existent hostname. This meant you could send a DNS
request for SomeFunkyNameThatDoesNotExist.contoso.com and the DNS server would always return
the IP address of their corporate web site. (Wildcard records are completely valid from an Internet
standards viewpoint. See section 4.3.3 in RFC 1034 for details -Editor).

Because of this their Outlook Anywhere clients could always resolve the CAS array object FQDN and
would first attempt a RPC (over TCP) connection before switching to HTTPS. If you find yourself in a
similar situation with an external DNS server utilizing a wildcard responses for a particular forward
lookup zone, I'd recommend trying to avoid using that forward lookup zone for your Outlook Anywhere
proxy URL.
A quick detour if we may to remind you not to forget to configure the proper service health monitors
for your load balancing solution. For the best service monitoring results consult with your load
balancing solution vendor. Check out Exchange Server 2010 Load Balancer Deployment for a list
of the load-balancer vendors who've gone through Exchange 2010 solution testing and links to their
relevant web pages (for Exchange 2010). Note, it's *not* a definitive list of supported load balancing
vendors in any way. It's simply a list of vendors who've chosen to engage with Microsoft directly for
solution testing and support.
A quick and dirty example may be that your HTTPS service based FQDNs have is-alive tests performed
against TCP/443 responses and the load balancing solution stops sending new client traffic to any
Client Access server which stops responding on TCP/443. The CAS array object RPC (over TCP) service
FQDN may have is-alive tests performed on the RPC Endpoint Mapper on TCP/135 as well as the two
static TCP ports you chose for RPC Client Access Service and the Address Book service. If any of those
three ports stop responding on a particular Client Access server, the load balancing solution will not
send new client traffic to that CAS for RPC (over TCP) until all of ports begin responding once again. If
you don't configure static TCP ports then Exchange will choose a dynamic TCP port for each service at
startup making is-alive testing more difficult if not impossible for some load balancing solutions.

5. A CAS array object should not be configured after creating Exchange

Server 2010 databases
Many times we're all in a rush to install the Mailbox servers, have the mailbox databases created, and
hopefully begin storage solution validation testing with Jetstress. May I suggest you slow your horses
down for a moment and save yourself some trouble later? While Mailbox servers are considered by
many to be the most important server role, it's no good to you if the front door is nailed shut because
you cant get to them through Client Access servers.
If you start creating mailbox databases before a CAS array object is in place you'll see a random Client
Access server in the same Active Directory site stamped on the RpcClientAccessServer attribute of the
each database.
Instead of looking like it should (use the CAS array object's FQDN)

Figure 1: If a CAS array object is created, the RpcClientAccessServer property of the mailbox database is populated with the CAS
array object's FQDN

It will look something like this:

Figure 2: If the CAS array object is not created, the RpcClientAccessServer property of the mailbox database is populated with the
Client Access server FQDN

Client profiles will look like the following

Figure 3: If a CAS array object is not created, Outlook clients are configured with the Client Access server's fqdn

Clients will connect like the following

Figure 4: Clients connect to the Client Access server's fqdn

At first glance this may seem very innocuous and everything will work just fine, but you are setting
yourself up for trouble later. If you start to move mailboxes to Exchange Server 2010 with this
configuration in place Outlook will use the CAS name in the Server field of the user profile. It'll work,
unless that Client Access server becomes unavailable or is perhaps decommissioned at a later date
and replaced with a differently named server. Wouldnt you rather be using a load-balanced pool of
Client Access servers about the time that happens? ? Yes, you would!
You may think to yourself Ok smarty pants, if that day ever comes Ill create a CAS array object and
fix RpcClientAccessServer on the databases and life will be good. Im here to tell you that will only
work for mailboxes you move to Exchange 2010 after the fact. Any user with a pre-existing Outlook
profile configured to point to a CAS name and not the CAS array object will continue to connect to the
CAS name and it will not update itself to utilize the CAS array object FQDN.
The profile will not update itself because the client will not receive an ecWrongServer response from
CAS. It will not receive this response because any CAS is a valid connection point for any mailbox
database via RPC (over TCP) so clients can survive datacenter switchover/failover events without being
reconfigured and all an admin has to do is flip the CAS array object DNS record to point to a surviving
pool of CAS. Currently the only way to fix mailbox profiles would be a manual profile repair within
Outlook, by publishing an Office PRF file via GPO (not going to work for non-domain joined machines),
or by decommissioning the CAS server named in the users profiles so the endpoint is no longer
available. This last option should (test test test!!) trigger a full profile repair by Autodiscover in Outlook
2007 or Outlook 2010. Outlook 2003 is only repairable with a profile repair or a PRF file. Autodiscover
will not as of this articles writing update a profile to a new server name as part of the normal
Autodiscover process which updates the Outlook Anywhere configuration and discovers EWS URLs for
other features such as OOF Management, Free/Busy, and Inbox Rules management.
This also means if you move a mailbox from a database in an AD Site-A that uses a CAS array object
named Boston-CASArray to a database in AD Site-B which uses a CAS array object named RedmondCASArray that the profile will not update and the server name field will remain the Boston-CASArray
FQDN is. You may want to keep this in mind if you have a user population that migrates to different
sites due to job changes or perform a massive internal mailbox move to another site at some time
during the solution lifecycle. If you do find yourself creating Exchange 2010 databases before creating
a CAS array object it is imperative that you go back and fix the databases RpcClientAccessServer
attribute to use the CAS array object before moving mailboxes into the databases.

6. A CAS array object should be configured even if you only have one CAS
server or one multi-role server.
Reflect for a moment about what was discussed in the prior item. A client will not update itself to use a
CAS array object if you add one at a later time. Well what if you only have one CAS? You may think it

doesnt matter. I guess one could argue it doesnt matter at that very moment, but why not future
proof things if you can and save some cycles and frustration later? What if a year from now you find
yourself in need of replacing that CAS? If youre clients profiles are all pointing to a CAS name then you
have no clean way to transition them without some kind of outage or manual work. You will have to
repair their profiles with one of the means already mentioned after adding a new CAS, or you will have
to decommission the existing CAS and introduce a new CAS with the same hostname which will require
some downtime. To me none of those options are acceptable.
What if later on your business requirements change and then dictate you should have client access
high availability? You can only achieve this goal by adding a second CAS and a load balancing solution.
You will find yourself stuck in the same boat again having to repair everyones profile through one of
the means already discussed. Again these are not acceptable options to me.
What I would suggest is you create a CAS array object from the very beginning. How do you do that if
you have no load balancer and only a single CAS? Simple! Configure the CAS array object like you
normally would. Give it a name, an AD site, a FQDN, and then simply point the DNS A record to the IP
as the only existing CAS or multi-role server you have at that time. You have just future-proofed
yourself and if you ever have to replace the single CAS or multi-role server all you have to do is build
the new server, and then change the DNS record IP address and everything keeps working without
interruption. If you ever want to add high availability at a later time then all you have to do is get your
load balancing solution operational and then change the CAS array object DNS record IP address to
point at the VIP of the load balancing solution. Easy!
Hopefully this article has been helpful in addressing some of the CAS array object misconceptions and
will go a long ways towards helping everyone move towards a healthy Exchange Server 2010
migration.

Brian Day Premier Field Engineer, Messaging

How to Install an Exchange

Server 2010 Client Access Server
Array using Windows Network
Load Balancing

This tutorial will demonstrate the steps for deploying Exchange Server
2010 as a Client Access Server array using Windows NLB.
If youre 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 PREREQUISITES

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 aDatabase Availability Group (DAG).
The reason is that DAG members utilize Windows Failover Clustering, which
cant 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,WebBasic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-MgmtConsole,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-DigestAuth,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-BasicAuth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-MgmtConsole,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-DigestAuth,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 Im

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-FirstSite-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 theirRpcClientAccessServer.
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.

Exchange 2010 - Load balancing:

Prepare Exchange 2010 Server

This is the mobile optimised version of this site. For the regular
version go to exchange.sembee.info
If you are going to use an external load balancer with Exchange 2010,
then you have two main options, depending on what the load balancer
supports.
1. Use dynamic ports.
2. Configure static ports.
Once you have made that decision, then there are a number of steps
that are required:
1. Configure the static ports
2. Configure the RPC CAS Array
3. Adjust the clients to use the RPC CAS Array
4. Adjust Exchange to use a generic host name for web services
5. Implement the load balancer.
These configuration changes can also apply if you need to get
Exchange to communicate through internal firewalls.
The most common configuration is to use static ports, which means
modifying the Exchange configuration.
These instructions apply to Exchange 2010 SP2 and later.
Static Ports for the RPC Client Access Service

The RPC CAS functionality communicates through port 135 and a

dynamic port between 6005 and 59530. Therefore when you are
setting the static ports you need to avoid this range. The guidance
from Microsoft is to use a port between 59531 and 60554.
Two services need to have static ports set:
MAPI Connections
Address Book Service
Static Port for MAPI Connections
This is a registry change on the server and should be made on all
CAS role holders in the site.
1. Open regedit and open the following key:
HKEY_LOCAL_Machine, \ System \ CurrentControlSet \

Services \ MSEXCHANGERPC
2. Create a new key called ParametersSystem (no space) if it isn't
already present.
3. Create a new REG_DWORD value called "TCP/IP Port"
4. Assign a Decimal value for the port that you want to use.
5. Close the registry editor and restart the Microsoft Exchange RPC
Client Access Service
This example registry change sets the value to 59560
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem]
"TCP/IP Port"=dword:0000e8a8

Static port for Address Book Service

Another registry change on the server, again all CAS role holders in
the site.
1. Open regedit and open the following key:
HKEY_LOCAL_Machine, \ System \ CurrentControlSet \
Services \ MSEXCHANGEAB
2. Create a new key called Parameters
3. Create a new String (REG_SZ) value called RpcTcpPort
4. Enter the port number that you want to use - this should be
different to the port for MAPI connections.
5. Close the registry editor and restart the Microsoft Exchange
Address Book Service
This example registry change sets the value to 59561
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters]
"RpcTcpPort"="59561"

Confirm the changes are active

To confirm the changes are active, start a command prompt and type

netstat -an -p tcp | find /i "listening" | findstr 59560

and repeat for the other ports.
If you run this command:
netstat -ano -p tcp | find /i "listening" | findstr 59560
It will also show you the Process ID (PID) - then use Task Manager
with PID's displayed (Show Columns command) to confirm the correct
service is listening.
Public Folder Access
If you want to assign public folder access a static port as well, then
you need to make the same change for MAPI connections, but on the
servers with the Public Folder database. If you put that port through a
load balancer then it should be a 1:1 mapping to a single server only,
as the clients cannot connect to another public folder database on
another server automatically.
RPC CAS Array Configuration

The RPC CAS Array is effectively a virtual Exchange server and exists
in DNS only. It takes minutes to setup, and is best configured right at
the start of your Exchange installation before any mailboxes are
moved to the server. If it is setup after clients are using Exchange
2010 then you have to touch each client to get them to use the RPC
CAS Array address - they will not start using it automatically.
1. Configure the DNS Entry.
The first step should be to configure the DNS entry for the CAS
Array address.
This is an internal ONLY DNS entry, it should not resolve
externally. The common convention for the host name is
Outlook.
Therefore create a new A record in your internal DNS, called
"outlook" and set it with the IP address of your existing Exchange
2010 server with the CAS role installed. DO NOT configure it
with the load balancer address until you are satisfied it is working
correctly.
Once created, choose View, Advanced and then open the
properties of the A record again and change the TTL time to 30
minutes. (0:0:30:0).

2. Create the Exchange RPC CAS Array.

To create the array in Exchange use the following command:
New-ClientAccessArray Name HQ CAS Array Fqdn
outlook.domain.local Site HQ
Each CAS Array should be unique to the AD site. The "Name"
can be anything - the FQDN shoudl be the host that you created
in step one and the Site is the AD site the Exchange server is in.
If you haven't touched the AD site configuration (in AD Sites and
Services) then the default name is "Default_First_Site_Name".
3. Configure the Exchange databases to use the RPC CAS Array
The final step on the Exchange server is to adjust the database
configuration to use the RPC CAS Array address instead. This
also changes what Autodiscover pushes out to the clients during
a new profile configuration, so will be effective immediately.
get-mailboxserver -identity servername | get-mailboxdatabase |
Set-MailboxDatabase RPCClientAccessServer
outlook.domain.local
This command sets the same value on all databases on the
server.
Client Changes

Before the load balancer can be used, all clients need to be using the
RPC CAS array address.
If you have implemented this before you moved mailboxes to
Exchange 2010 then they will use it from the start.
However if this is a post implementation change then you will have to
touch each client.
This means going to every installation of Outlook and repairing the
profile. This will change the Exchange server name from the actual
address of the Client Access role server, to the RPC CAS Array name.
Until this change is made, the clients will continue to connect directly
to the CAS role, even after the load balancer has been implemented.
Web Services Changes

To complete the implementation, you need to adjust how Exchange

uses web services. This usually means switching to a generic URL - a
change that is encouraged as SSL vendors will shortly not issue SSL
certificates to internal server names.
These changes have to be made in a number of places, and full
details on the process are outlined in our web services and other client
access host name guide.
More Information
Static RPC Ports on an Exchange 2010 Client Access
Server: http://social.technet.microsoft.com/wiki/contents/articles/864.c
onfigure-static-rpc-ports-on-an-exchange-2010-client-accessserver.aspx

Exchange 2010 - Reset a Client Access

Virtual Directory
Home Page | Exchange 2010 | Exchange 2007 | Exchange 2003
Outlook | Network Tasks
This is the mobile optimised version of this site. For the regular
version go to exchange.sembee.info
On This Page
Introduction - Resetting A Client Access Virtual Directory
Resetting the Outlook Anywhere Virtual Directory
Introduction - Resetting a Client Access Virtual Directory
Sometimes as part of the troubleshooting process, you need to reset
the virtual directories back to their default state. A wizard has been
provided to do this for you.
1. Open Exchange Management Console and expand Server
Configuration, then Client Access Server.
2. Right click on the server that you want to reset the virtual
directory on and choose "Reset Virtual Directory..."

3. On the first screen, select Browse. Then choose the virtual

directory that you want to reset. You can only reset one at a
time, so if you want to reset them all, run the process multiple
times.

In this example, we are going to reset the Autodiscover Virtual

Directory.

4. Then choose Next. Select the path to the log for the process the default is usually fine in most cases and press Next.

5. A summary of the task will be shown.

6. Once the process has finished, run IISRESET from an elevated

command prompt and test again.
Outlook Anywhere Virtual Directory

To reset the Outlook Anywhere virtual directory, you need to follow the
instructions on the Outlook Anywhere page.

Exchange 2010 - Autodiscover

Troubleshooting
Home Page | Exchange 2010 | Exchange 2007 | Exchange 2003
Outlook | Network Tasks
This is the mobile optimised version of this site. For the regular
version go to exchange.sembee.info
On This Page
Introduction
Background on Autodiscover
Common Symptoms with Autodiscover
Issues With Autodiscover
Correct Configuration of the Autodiscover Service
Exchange Server Configuration
DNS Configuration
Resetting the Autodiscover Virtual Directory
SSL Prompts when using Exchange 2003
Introduction

Autodiscover is one of the major pain points for Exchange

administrators, but is actually quite easy to troubleshoot and resolve
as the main issues with it are well known.
Background on Autodiscover

First, some background.

Autodiscover, and its companion, the availability service, are key to
the operation of Exchange. Primarily designed for hosted Exchange
operations, it is used by all Exchange server implementations of
Exchange 2007 and higher and is not an optional function.
Not only does it do the first time configuration of the Exchange client,
but they also tell the client whether anything has changed, as well as
provide the means to get free/busy information. Outlook 2007 and
higher uses Autodiscover.
The Autodiscover lookup takes place frequently in the background by
Outlook 2007 and higher, no matter which version of Exchange you

are using, so it is possible to get issues with Autodiscover with an

Exchange 2003 server involved. As the process is constantly being
used, it is not something that administrators can simply ignore and
configure the clients manually.
Autodiscover works in one of two ways.
1. A lookup from the domain.
2. DNS records.
The first method is for clients that are members of the domain and can
reach the domain controller. That means they are on the LAN, or
connected via a VPN. Exchange publishes a URL in to the domain,
which the clients query and this tells them where to go to get further
information from Exchange for the Autodiscover information.
The second method involves the Outlook client making DNS lookups
against a number of preset host names. These host names are
derided from the user's email address. If the user's email address is
john.smith @ example.com then the autodiscover process will query
example.com, autodiscover.example.com and then an HTTP
request.
This occurs for clients that are both members of the domain, if they
cannot reach the domain controller, and for non-members.
Outlook can also query SRV records, which is useful when an
Exchange server is hosting multiple
In both cases, the autodiscover process will use SSL, so the actual
host name queried will be https://host.example.com/ .
Common Symptoms with Autodiscover

The most common problems that are connected to Autodiscover

include:
Frequent prompts for SSL certificates on clients (including
those on Exchange 2003).
Frequent user name and password prompts.
No free/busy information
Unable to set Out of the Office (OOTO).
Issues with Autodiscover

The problems with autodiscover usually fall in to one of three main

areas:

1. SSL Certificate issues.

This is the most common, and is usually caused by having the
incorrect names on the SSL certificate, or attempting to use the
self signed SSL certificate.
2. DNS Issues.
This is usually a matter of not having
autodiscover.example.com on the external DNS.
3. On the domain only, incorrect or invalid URLs being published.
Correct Configuration of the Autodiscover Service

If you get autodiscover to work correctly, then you will usually find that
the availability service will also work.
Exchange Server Configuration.
Starting with the Exchange server itself, the configuration is carried
out on the server with the Client Access Role.
The get-autodiscovervirtualdirectory command, and setting internal
and external URLs on the autodiscover virtual directory have no affect
on the operation of Autodiscover and should be left alone in their
default state.
There is only one value that you need to worry about, and that is the
value of AutodiscoverServiceInternalURI which is on getclientaccessserver
Run the following command:
get-clientaccessserver | select Name, AutodiscoverServiceInternalURI

You will get a response back similar to this:

Name
AutoDiscoverServiceInternalUri
--------------------------------exch-server
https://exchserver.example.local/Autodiscover/Autodiscover.xml
The value returned is published to the domain by Exchange at regular
intervals, therefore it should:
a. Resolve to the Exchange server.
b. Be one of the names in the SSL certificate.
If both of those are not correct, the Autodiscover is likely to fail.
If the URL is incorrect, then correct it using this command:

Set-ClientAccessServer -Identity

Where exch-server is the name of the Exchange Server, exchserver.example.local is its FQDN.
Browse to the URL mentioned in the URL - if you get an SSL prompt,
then you will need to correct the SSL certificate.
Multiple Exchange Servers
If you have multiple Exchange Servers in the same AD site, then you
can get the issue of the server's overwriting each other at frequent
intervals. This isn't a problem if the SSL certificates are setup
correctly, with every server holding the Client Access Server role being
listed. However if that isn't the case, then you should set all of the
servers in the same AD site with the same host name.
Multiple AD Sites
Autodiscover is AD site aware, which means that you have can have
multiple internal Autodiscover URLs, one for each AD site. This stops
the domain joined clients from querying a remote Exchange server.
This is known as Site Affinity. It is configured thus:
Set-ClientAccessServer -Identity

Where Office 1 is the name of the AD site being configured (all other
values as above).
Changes from 2015
In 2015 the rules around SSL certificates will change. You will not be
able to get SSL certificates issued to host names that are not valid on
the internet. This means that domains using .local or other nonregistered domains will have to use a split DNS system so that an
external host name can be used.
DNS Configuration

Other than ensuring the host name used internally resolves, you also
have to ensure that public DNS is configured correctly, particularly if
you are going to use Outlook Anywhere.
If you do not have any clients on the LAN which are NOT members of
the domain, then you do not need to do anything internally for DNS.
However if you have clients on the network which are not members of
the domain, using Exchange, this could be Windows, MACs or mobile

devices, then you should ensure that autodiscover.example.com

resolves internally to the Exchange server via a split DNS system.
For external DNS, the most configuration is to have
autodiscover.example.com resolve to the external IP address of the
Exchange server, along with your preferred URL for OWA, ActiveSync
and Outlook Anywhere and then have the correct names in the SSL
certificate.
However if you are hosting multiple domains, then having many
Autodiscover entries can get expensive and difficult to maintain.
Therefore an alternative existing using SRV records. Your external
DNS provider must support SRV records for this to work. The
configuration of SRV records for Autodiscover is covered in MSKB
940881 and applies to all version of Outlook from 2007.
You can also use the HTTP redirect method for public Autodiscover,
but this requires additional IP addresses and web sites and is
therefore not commonly implemented.
For general DNS configuration for Exchange servers, see the DNS
Configuration page.
Resetting the Autodiscover Virtual Directory

In some cases, it can be just as quick to reset the virtual directory. If

you have been changing authentication settings and other settings to
try and correct issues, then it can mean you are simply going round in
circles.
In Exchange 2010, there is a wizard to reset the virtual directory which
should be used.
For Exchange 2007, you have to use Exchange Management Shell:
Remove-AutodiscoverVirtualDirectory -Identity

Where server is the netbios name of the server which holds the Client
Access Role and is the one you want to reset the virtual directory.
Then you need to recreate it using the following command on the
server where you want to reset the virtual directory.
New-AutodiscoverVirtualDirectory -WebsiteName

After recreating, run IISRESET for the changes to write to the IIS
metabase correctly.
SSL Prompts when using Exchange 2003

If you are still on Exchange 2003, but Outlook 2007 and higher is
generating SSL prompts, then this is probably caused by a DNS issue
- specifically an SSL certificate on the root of the domain or a wildcard
in the DNS (or both).
A wildcard in the DNS is very common setting applied by web hosts,
so that anything.example.com resolves to the public web site.
It is also best practise for the root of the domain (example.com) to
resolve to the public web site, as many people no longer enter www
when entering a URL.
If the server holding the web site is shared, and has an SSL certificate
installed on to another web site which is using the same IP address,
then you will get prompts, often from another domain to your own.
This is most often the case where your internal WINDOWS domain is
different to your EMAIL domain (so example.local and example.com).
Resolution - remove the wildcard from the public DNS so that
autodiscover.example.com doesn't resolve.

Exchange 2010 - Outlook

Anywhere
Home Page | Exchange 2010 | Exchange 2007 | Exchange 2003
Outlook | Network Tasks
This is the mobile optimised version of this site. For the regular
version go to exchange.sembee.info
On This Page
Introduction - What is Outlook Anywhere?
Enable Outlook Anywhere using Exchange Management
Console
Enable Outlook Anywhere using Exchange Management Shell
Change the Authentication Methods
Outlook Anywhere with a Wildcard Certificate
Reset the Outlook Anywhere Virtual Directory
Introduction - What is Outlook Anywhere?

Outlook Anywhere is a method for Outlook to connect to Exchange

over the internet using the HTTPS protocol. By using HTTPS the
session is secure. You need to use a trusted SSL certificate - the self
signed certificate created during the installation of Exchange is not
supported for use with Outlook Anywhere.
Enable Outlook Anywhere using Exchange Management Console

Outlook Anywhere is the new name for RPC over HTTPS which was
first introduced with Exchange 2003, and is significantly easier to
configure. It is a simple two step process.
1. Open the Exchange Management Console and expand Server
Configuration, Client Access.
2. Right click on the server that you wish to Enable Outlook
Anywhere on, and choose "Enable Outlook Anywhere...". You
can also select it from the Action Pane on the right.

3. A single window wizard will start. You need to external the

EXTERNAL host name that the server responds to. Ideally this
should match the common name on the SSL certificate.
The authentication type can be set - the wizard only allows you
to choose one or the other.
Basic Authentication will cause an authentication prompt every
time the client connects.
NTLM Authentication will not cause an authentication prompt if
the client is a member of the domain.
4. Allow secure channel (SSL) offloading is not enabled in most
deployments. It is used when something else is providing the
SSL connection, such as an appliance.
After making the selections, choose Enable.

5. You will then get a Completion, which shows you the command
that has been used to enable the feature.

6. After approximately 15 minutes an entry will be made in the

Application Event Viewer of the server indicating the feature
has been configured.

Enabling Outlook Anywhere Using Exchange Management Shell

To enable the feature using EMS, use the following command:

Changing the Authentication Methods

If you want to support multiple authentication methods, then you need

to change it through EMS.
However as you are changing an instance that is already configured,
you need to include the identity.
Note - the client will have its authentication method set by
Autodiscover, so if you change an Autodiscover enabled client, then it
will be "corrected" at the next Autodiscover refresh.
Set-OutlookAnywhere -Identity:

You can find the identity by running the command

Get-OutlookAnywhere | Select Server,Identity |fl

Outlook Anywhere with a Wildcard Certificate

If you are using a wildcard SSL certificate, rather than a unified

communications certificate, then you need to make an additional
configuration change:
Set-OutlookProvider expr -CertPrincipalName:

Reset the Outlook Anywhere Virtual Directory

To reset the Outlook Anywhere virtual directory, follow these

instructions:
1. Disable Outlook Anywhere in Exchange from the same menu
as step 1 above.
2. Wait for the event log entry to appear indicating the option has
been disabled.
3. In Server Manager, remove "RPC over HTTP Proxy" from
Windows Features.
4. Once the remove wizard has completed, check in IIS manager
for the two directories named RPC and RPCWithCert have
been removed. If not, delete them.
5. Run IISRESET to ensure the changes are written to the IIS
metabase.
6. Reinstall the RPC Over HTTP Proxy in Windows features.
7. Enable Outlook Anywhere as per the instructions above.
If you are using SBS 2008, then you need to follow specific
instructions for that version.

Exchange 2010 - Exchange

Troubleshooting Assistant
Home Page | Exchange 2010 | Exchange 2007 | Exchange 2003
Outlook | Network Tasks
This is the mobile optimised version of this site. For the regular
version go to exchange.sembee.info

On This Page
Introduction - What is the Exchange Troubleshooting
Assistant?
Accessing the Troubleshooting Assistant
Using the Troubleshooting Tool
Shortcuts to the Tools
Introduction - What is the Exchange Troubleshooting Assistant?

The Exchange Troubleshooting Assistant (EXTRA) was first

introduced with Exchange 2003 as a separate download. Since
Exchange 2007 it has been integrated with the product.
In Exchange 2010, The EXTRA tool is used as the basis for a number
of tasks. The Mail Flow Troubleshooter, Message Tracking Log
Explorer and Performance Troubleshooter all use EXTRA as their
underlying basis.
Accessing the Troubleshooting Assistant.

It is important that you use the correct version for your version of
Exchange. Using the Exchange 2003 tool against Exchange 2010 is
going to give you false results.
For Exchange 2010, there is nothing to download. It is built in. You can
access it in one of three ways.
1. Through the Exchange Management Console
Each task for the tool has its own shortcut, and can be
accessed through the management console in the tool box.

2. Running the Tool Directly

You can run the tool itself and then select which task you want
to do. Use the following command for that:

"%ProgramFiles%\Microsoft\Exchange Server\V14\Bin\ExTRA.exe"

3. Running the Tool Directly, with a specific tool started

If you know which tool you want to use, then you can start the
EXTRA tool with the relevant tool started. Click Start, Run and
copy the relevant command in to the box:
Mail Flow Troubleshooter
"%ProgramFiles%\Microsoft\Exchange Server\V14\Bin\ExTRA.exe" -AS -PS LaunchMailflowTroubleshooter

Message Tracking Log Explorer

"%ProgramFiles%\Microsoft\Exchange Server\V14\Bin\ExTRA.exe" -AS -PS LaunchMessageTracking

Performance Troubleshooter
"%ProgramFiles%\Microsoft\Exchange Server\V14\Bin\ExTRA.exe" -AS -PS LaunchPerformanceTroubleshooter

Using the Troubleshooting Tool

Each tool has its own instructions, which you should follow and then
review the advice given. It may well link to Technet Articles which will
provide further information on the issue.
Shortcuts to the Tools

You can create shortcuts to these tools, as well as the others in the
Toolbox, by using the methods on the Toolbox Shortcuts page.

Exchange 2010 - Exchange 2010

Server Shutdown Script
Home Page | Exchange 2010 | Exchange 2007 | Exchange 2003
Outlook | Network Tasks
This is the mobile optimised version of this site. For the regular
version go to exchange.sembee.info
On This Page
Introduction - Why Use a Script to Shutdown Exchange?
Shutdown Script
What Does the Script Do?

 Shutdown or Restart the Server After Stopping Exchange

Starting Exchange with a Script
This is the Exchange 2010 version of this article. For the
Exchange 2003 version - go here and for Exchange 2007 go here.
Introduction - Why Use a Script to Shutdown Exchange?

If you are running Exchange 2010 on a domain controller, then you will
find that it takes the machine a long time to shutdown. This is because
the domain functionality stops quicker than Exchange, therefore
Exchange is unable to write to the domain controller and has to be be
"killed" by the operating system.
This continual "killing" of the Exchange services, instead of allowing
them to shutdown gracefully is not good for the database and is one of
the prime reasons for recommending that Exchange is not installed on
a domain controller.
A better option is to stop the services before you begin to shutdown
the server. This will also cause the server to shutdown more quickly
because it isn't waiting for the services to timeout. This can
significantly decrease the shutdown/reboot time of SBS Server.
Even if you have a dedicated Exchange server, if you are using a
UPS, then you may also want to shutdown the Exchange services
before the UPS shuts down the OS. In many cases the domain
controller may shut down before Exchange, which will cause delays as
Exchange needs to communicate with the the domain controller during
the shutdown process.
While you can stop the services yourself using the services
administrative tool, instead use a batch script with a shortcut on the
desktop.
Due to the dependencies required for some services, you can shortcut
the list by stopping one service with the /y command.
Shutdown Script

Below is a sample script. Simply copy and paste it in to a new notepad

document and save it as "stop-exchange.cmd".

net stop msexchangeadtopology /y

net stop msexchangefba /y
net stop msftesql-exchange /y
net stop msexchangeis /y
net stop msexchangesa /y
net stop iisadmin /y
net stop w3svc /y

What does the script do?

net stop msexchangeadtopology /y
Stops the "Microsoft Exchange Active Directory Topology Service"
which will stop the following services
Microsoft Exchange Transport Log Search
Microsoft Exchange Transport
Microsoft Exchange Throttling
Microsoft Exchange Service Host
Microsoft Exchange Search Indexer
Microsoft Exchange RPC Client Access
Microsoft Exchange Replication
Microsoft Exchange Protected Service Host
Microsoft Exchange Mail Submission
Microsoft Exchange Mailbox Replication
Microsoft Exchange Mailbox Assistants
Microsoft Exchange File Distribution
Microsoft Exchange EdgeSync
Microsoft Exchange Anti-spam Update
Microsoft Exchange Address Book
It will also stop POP3, IMAP4 and Unified Messaging if those are
enabled.
net stop msexchangefba /y
stops the "Microsoft Exchange Forms-Based Authentication" service
which does not have any dependencies
net stop msftesql-exchange /y
stops the "Microsoft Search (Exchange)" service which does not have
any dependencies
net stop msexchangeis /y

stops the "Microsoft Exchange Information Store" service which does

not have any dependencies
net stop msexchangesa /y
stops the "Microsoft Exchange System Attendant" service which does
not have any dependencies
net stop iisadmin /y
stops the IIS admin service, which does not have any dependencies.
net stop w3svc /y
stops the "World Wide Web Publishing" service, which may have any
dependencies - on SBS this will also stop the Remote Desktop
Gateway service, which could kick you out of the server if you are
using the RWW to access the server.
If you are using a third party plug-in, then you may find that there is a
dependency on that plug-in which can cause the script to fail. The /y at
the end of each command should deal with it, but if you find that the
third party service doesn't stop in time, adjust the script to include a
delay. (Sleep is part of the Windows Resource Kit tools, if you don't
have it installed on the server)
For example, this is a script used with an old version of McAfee Group
Shield
net stop "McAfee GroupShield Exchange" /y
sleep 30
net stop msexchangefba /y
net stop msftesql-exchange /y
net stop msexchangeis /y
net stop msexchangesa /y
net stop iisadmin /y
net stop w3svc /y

Shutdown or Restart the Server After Stopping Exchange

If you are using these scripts to shutdown Exchange before a server is

shutdown (for example by a UPS) or rebooted, then you may want to
fully automate the process by scripting the shutdown/restart as well.
This can be easily achieved by adding an extra line to the end of the
script:
Restart the server
shutdown /r /t 00

shutdown /s /t 00

Shutdown the server

shutdown /s /t 00
shutdown /s /t 00

Starting Exchange with a Script

Finally, you might also want a script to start Exchange again. This can
be useful if you apply an update which requires a restart of the
Exchange services, but don't need to restart the server. However
starting the services is a little more complex as the less number of the
services are dependant on other services. Therefore more services
have to be started manually. Simply copy and paste it in to a new
notepad document and save it as "start-exchange.cmd".
Remember to add POP3 and IMAP services if you are using those.
net start "World Wide Web Publishing Service"
net start "Microsoft Exchange System Attendant"
net start "Microsoft Search (Exchange)"
net start "Microsoft Exchange Information Store"
net start "Microsoft Exchange Unified Messaging"
net start "Microsoft Exchange Transport Log Search"
net start "Microsoft Exchange Transport"
net start "Microsoft Exchange Throttling"
net start "Microsoft Exchange Service Host"
net start "Microsoft Exchange Search Indexer"
net start "Microsoft Exchange RPC Client Access"
net start "Microsoft Exchange Replication"
net start "Microsoft Exchange Protected Service Host"
net start "Microsoft Exchange Mailbox Replication"
net start "Microsoft Exchange Mailbox Assistants"
net start "Microsoft Exchange Mail Submission"
net start "Microsoft Exchange Forms-Based Authentication service"
net start "Microsoft Exchange File Distribution"
net start "Microsoft Exchange EdgeSync"
net start "Microsoft Exchange Anti-spam Update"
net start "Microsoft Exchange Address Book"

http://exchange.sembee.mobi/2010/
http://exchange.sembee.mobi/2010/
http://exchange.sembee.mobi/2010/

Changing the RPCClientAccessServer

- How Outlook Behaves
When an Outlook client goes to connect to an Exchange 2010 database, it looks at an attribute associated
with the mailbox database called RPCClientAccess to determine which client access server/client access
server array to use for connectivity.

There may be a time in where you need to change which RPCClientAccess server your clients use for
connectivity on the Exchange mailbox database. The problem is, if you change the RPCClientAccess on a
mailbox database to a different Exchange 2010 client access server/client access server array without
"moving" the mailbox, Outlook 2007 and Outlook 2010 clients do not pickup this change automatically.

Further more, if you perform an Outlook Profile repair process, it will update with the new RPC endpoint
for the users mailbox database defined under the RPCClientAccess attribute. But guess what, Outlook
reverts to a Working Offline mode. Creating a new outlook profile will resolve the issue, however if you
remove the Host A record for the old client access server in DNS, Outlook will resume working as normal
again.

Outlook only updates to a new RPCClientAccess value smoothly when moving users to the mailbox
database. If you want to transition users smoothly to another client access server or client access server
array, you can create another database, set the RPCClientAccess as desired, then move users to the
database. This will allow the outlook profiles to update without issues.

Other then moving mailboxes there is one other thing you can do to get Outlook to update to the new
RPCClientAccess value. If you remove the "Host A" record from the old client access server in DNS, this
will cause Outlook to forcefully repair itself and update its profile.

Lets hope Microsoft makes it easier in the next release of Microsoft Outlook.

For additional reading about this problem, please look at the following links:

http://www.outlookforums.com/threads/84315-Outlook-goes-offline-after-changing-

RPCClientAccessServer-parameter-on-mailbox-database

http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclientaccessserver-databaseparameter/

http://www.scottfeltmann.com/blog/2010/06/28/outlook-profile-not-updating-after-creating-cas-array/
Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer "new server exchange name fqdn"

Increasing event log levels

Increasing the event log levels is a great way to get more information on what is going on logged
in the event viewer (as well as to get your event logs flooded). Slightly different to use in
Exchange 2003 and 2007/2010 but the result remains the same.
Exchange 2003: Right click the server object in the Exchange system manager console and go to
the diagnostic logging tab. Increase the logging to the highest level for the entries related to the
issue you are troubleshooting.
Exchange 2007/2010: I prefer the powershell route to increase the logging in these versions of
Exchange. You can get the current eventloglevel by using the following command:
Get-eventlogloglevel
From this you can mark and copy the desired item you want to increase logging on by using the
following command:
Set-eventloglevel identity MSEXCHANGESA\OAL GENERATOR Level High
Note that you can also pipe these commands if you want to increase everything in a certain set.
Get-eventloglevel MSEXCHANGSA\* | set-eventloglevel level high
You can find more information about the commands used and the different levels at the
following technet link:
http://technet.microsoft.com/en-us/library/dd335139.aspx