Exchange Server Role Issues


Quick overview :

- 3 exchange servers
- DC1 - Mailbox, CAS, HT
- DC2 - Mailbox, HT
- DC3 - Mailbox, HT

Any mailboxes that are located on DC2 or DC3 are coming up with :

Outlook Web App isn't available. If the problem continues, please contact your helpdesk. When trying to access them via activesync or via webmail.

What is best practice here? Do the other servers need a CAS role?

They are connected over a managed WAN.

Who is Participating?
Simon Butler (Sembee)Connect With a Mentor ConsultantCommented:
You need to have a CAS role holder in each AD site for things to work at optimum levels.
Therefore the first thing I would do is add the CAS role to each server. After installation, ensure that the EXTERNAL URL is left blank. That will ensure that the proxy of traffic continues to work correctly. The traffic can hit the first server and Exchange will handle the rest.
It was probably working before when everything was in the same AD site, but as you noted, this has other implications. Exchange 2010 is heavily dependant on AD Sites and Services being configured correctly and the server configuration reflecting that.

Therefore what I would do is the following:

1. Add the CAS role to each server.
2. Immediately configure an RPC CAS Array for each AD site and apply that configuration to the databases on each server in each site.

Adding the CAS role to each server will help significantly. It will also mean that the clients will use a local server for their Exchange access, when the WAN links drop they will continue to access email. (I don't think SLAs are worth the paper they are written on, so I work on the basis that WAN links will fail, not if).

Do you actually know what the RPCCLIENTACCESSSERVER value that you have suggested changing/checking actually does? It has nothing to do with OWA access, and any change there will not get picked up by Outlook clients automatically. The only time that should be changed is for RPC CAS Array implementation, once that is done it shouldn't be touched.

Manpreet SIngh KhatraSolutions Architect, Project LeadCommented:
no their Mailboxdatabase should point to RpcClientAccessServer to DC1

- Rancy
elevatecsAuthor Commented:
Can you elaborate on where you specify this information?

I am assuming you specify this somewhere in custom attributes or from a policy of some kind?
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

Antonio VargasMicrosoft Senior Cloud ConsultantCommented:

please run the exchange management shell command:

get-mailboxdatabase | ft name, rpcclientaccessserver

this will give you the name of the client access server that your users are using (per mailbox database) to connect to exchange

the values should be DC1 for all databases

and you should use something like https://dc1.domain.local/owa on your browser to access the outlook web access dispite of the user mailbox database being on another server.

all the client connectivity, authentication and rendering is done on the CAS 2010 so it's there that you should connect.
Simon Butler (Sembee)ConsultantCommented:
If the servers are in a different networks then you should really have the CAS role on all of the servers? Any reason why you didn't? Due to the way that Exchange 2010 client access works, all of your clients are connecting to a single server. If that server goes down all client access across all three servers will fail.

I would also recommend against following the advice above. I don't think it is going to resolve the issue because the clients will not pick up the information.

What you should have done, and I encourage you to do so, is configure AD Sites and Services for each location, so they are in their own site.
Then have all three roles on all three servers.
Finally configure an RPC CAS Array per AD site, along with a unique Autodiscover URL for each location and configured Exchange and DNS appropriately.

If you want to have CAS traffic from the internet coming through a single server, then that is fine, just don't configure an external URL on the other servers.

Being blunt, I think your design is quite poor and needs to be overhauled.

Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
What will the clients not pick up? if only one CAS server is present then the clients dont have to pick up anything.. they are probably already using outlook over rpc/tcp.. also as you should know when accessing owa the clients dont need to pick up anything.. you can access any server url and if the urls are well configured it's the server doing the proxying or redirecting (if that's the case) and not the clients...

a CAS array per site wont help also as they have only one server per site...
there is no such thing as a unique autodiscover url per site.. autodiscover is done internally by a SCP defined on the autodiscover internal uri attribute at the client access server level.. external or non domain joined autodiscovery is done based on the e-mail domain and it's not binded to a site location.. actually if you do understand the autodiscover process you should know that the external urls cannot be the same..

hope that helps.. Simon...

elevatecs... what you really need to know is that not having one client access server per site is not recommended.. although supported.. the reason is that like i said before the client connects to the CAS server and all the authentication and rendering is done there.. as oposed to exchange 2007 were the connection (outlook) was done to the mailbox server, with exchange 2010 it's done to the CAS. meaning that a user in dc2 (site 2) will establish a tunnel (RPC) to the CAS in site 1.. and the CAS in site 1 will establish a tunnel to the mailbox server were the user is (site 2).. as you can see you're having traffic over the WAN and you can avoid that by having a CAS per site and complying with the best practices..

as for your connection problem my previous post still applies.. (at least in my opinion)
elevatecsAuthor Commented:
Ok, this was not my design i have inherited it, so i am just playing catchup with this one.

I understand :

(1)  i can have a CAS at each site with individual OWA, Active Sync etc...

I dont understand why i would want this, especially when there is only one gateway. If the gateway goes down i have no redundancy anyways right?

Id still need to repoint MX records etc for mailflow to work. Not to mention this site has a 99.999% uptime guarantee and only a single IP i can use to forward DNS records to.

They also come into a remote portal (custom made) which has links to webmail, company web and other resources, which is also something i would need to change if i had multiple CAS running yes?

(2)  i can have 1 CAS and all just mailbox servers.

This is actually what i thought best practice actually was.

It seems simple, i know obviously there is a redundancy issue here, but realistically it is difficult to avoid considering the current topology of the internet connections.

So obviously based on the above posts i am conflicted.

We have enough WAN bandwith (10MB/10MB) to have one CAS server, i dont think the overhead here is too much to deal with and the connection is very reliable... so its only a server failure i have to contend with, which in all honesty i will have bigger things to worry about if that happens as they will be completely down.

Does anyone have any supported articles showing the best practice approach, because it seems like you can tailor it to your specific needs.
elevatecsAuthor Commented:
The main issue is :

- Web Outlook not available for mailboxes on other mailbox servers that dont have a CAS role.
- Active Sync Also not working ONLY for mailboxes hosted on other mailbox servers that dont have a CAS role.

If i do a local move request and move the mailboxes back to the CAS server they work perfectly, but then obviously performance suffers for the users when accessing mailboxes locally.

Co-Incidentally i did recently change A/D sites and services and put all of the servers in their own subnets etc..

Prior to this, all servers were sitting in default site, which was causing issues with the servers dishing out scripts to clients not in their subnet and causing A/D policies to be really slow.

I did read that the site link could be having issues communicating, but there are no issues between A/D replication or DFS Syncing so i think this is not correct.
elevatecsAuthor Commented:
FYI - the CAS server is specified as the RPCCLIENTACCESSSERVER, so i think this issue is something else, any other comments?
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
make sure that the internalurls are:

https://dc1.domain.local/... (i.e owa)
or.. (i.e owa) if you have an internal dns zone pointing the record to the CAS server ip

the externalurl should be: (i.e owa)

also please try to use the internal and external urls to access the owa page and post the results.. with a one CAS scenario, which you think you should follow given the fact that you have a good internet connection between the sites, the users should connect to the urls configured on that CAS, and be able to log in.. the only scenario that breaks CAS services access on a per site basis is when you have several CAS servers and the urls misconfigured.. like having the same external url on several servers and therefore breaking the service..

please do:
get-owavirtualdirectory |ft name, internalurl, externalurl
to make sure that you have the correct urls

again this command should give you only 1 URL because you have only one CAS

let me know the results so that we can troubleshoot further

I havent suggested changing anything, because as you should know the rpcclientaccessserver can be two thinks.. a client access server or a client access array.. so if Elevatecs has only one client access server and no client access array i dont know how can you change it.. maybe you do..
also to make clear.. the owa requests go to the server were the url typed on the internet explorer points them.. i.e typing https://dc1.domain.local/owa will send the request to the server.. and if the user is in a mailbox database that HAS AS RPCCLIENTACCESSSERVER DC2 (which again is not the case because elevatecs has only one.. just trying to clarify the ACTUAL behavior) the DC1 server WILL PROXY the request to the DC2 server... if DC2 has a different external URL (lets say dc1 has and dc2 has and a user sitting on the american database (as peer rpcclientaccessserver configuration) queries owa on the CAS holding that external url WILL REDIRECT the request to
so as you can see it has everything to do...
elevatecsAuthor Commented:
the internal url is set to

just to get things working quickly i was gling to change it to dc1.internal.local\owa

however something strange i found..

dc1\owa is found

dc1.internal.local\owa comes up with page cannot be found.

iis listeners appear to be set correctly and both dns records resolve to the same address...

so i cannot use the full fqdn.

can i ask, if i go to the cas on each server role, will the webmail from a central location still work? i dont want to redirect clients to 3 different owa/active sync locations.
elevatecsAuthor Commented:
Installing OWA on each server, Setting the local names correctly for the roles as per Sembee's instructions worked perfectly.

Appreciate the help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.