• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 371
  • Last Modified:

Possible to disable exchange autodiscover for activesync only?

Hi,

We have exchange 2010 sp3 and we manually configure activesync profile on every mobile device given to users (we have 3 cas array and use their address as Server Address in the activesync profile).
Thanks to autodiscover, we have big issues where the server address in the activesync profile on the mobile automatically switch to a different cas array address when the active directory site the user belongs to becomes unavailable, and remain with the wrong address even if the active directory site comes back online. Without manually changing the server address, the mobile can no longer access the mailbox.

I'm wondering if it's possible to simply disable the autodiscover for activesync only. If so, is there any side effects on mobile currently deployed? Last one, which is obvious: if it's possible, how do I do this without impacting everything else?
0
abissa
Asked:
abissa
  • 5
  • 4
1 Solution
 
Adam FarageEnterprise ArchCommented:
I will let another expert correct me, but this is not possible. You should look into Proxy / Redirection though and possibly fixing that. When an ActiveSync request comes into a particular AD site, the CAS will do the following:

- Lookup the homeMDB and msExchangeVersion from the global catalog server
- Authenticate the user and create a kerberos ticket

(and a few other things that dont pertain to this situation)

When the CAS realizes it is in a separate AD site, it will encapsulate the TCP (HTTPS) request with the Kerberos token and submit a HTTP 451 request back to the ActiveSync device. This will allow it to *redirect* only if a valid ExternalURL is available on the EAS (Exchange ActiveSync) virtual directory.

Check out the blog here that I wrote a while back, it goes into a bit more details:
http://exchangelaboratory.com/2013/04/04/exchange-proxy-and-redirection-exchange-2007-and-2010-explained/
0
 
abissaAuthor Commented:
Hi Adam,

Thanks for the quick reply. I've read your blog, it's well done and explanations are great. Actually, I believe our servers are properly configured as, as long as all AD sites are available, even if you try to access the wrong CAS array, you're redirected to the one your mailbox belongs to.
Our problem is that, when the AD site your mailbox belong to is not available, activesync device make a request to mydomain.com/autodiscover/autodiscover.xml which returns other cas array, and the activesync device takes the first one available. Thus, in the activesync profile of the device, the Server Address field automatically switch to a different cas array on which, of course, your mailbox doesn't exist. Worst, when the AD site you belong to comes back online, the Server Address doesn't switch back to the proper one. This means we have to manually update everyone's mobile with the proper address.
To prevent this, I thought about disabling the autodiscover for only activesync (your answer regarding this confirms what I've found on the web so far, i.e not possible, so I'll mark it as accepted solution).

A microsoft technician explained me that I should create Aliases (if I understand correctly, it would be to create alias for the cas array so we would use casArrayAddress.ALIASdomain.com instead of casArrayAddress.domain.com in the activesync profile of the users mobile (and users email address would become firstname.lastname@ALIASdomain.com. This way, if a device cannot contact casArrayAddress.ALIASdomain.com, it would automatically lookup for ALIASdomain.com/autodiscover/autodiscover.xml, which doesn't exist -> no other cas array address would be returned and the mobile profile wouldn't change). But it seems to imply a lot of changes and I'm not confident I've enough knowledge to do this, I haven't found any blogs which clearly explain the process.

A colleague just told me that he could eventually block, from the load balancer, any connection to https://domain.com/autodiscover/autodiscover.xml coming from a mobile device. I believe it's going to block owa from a mobile and is not a proper solution.

Anyway, thanks again fro your prompt reply. If by any chance you have any advises/ideas regarding those aliases I mentioned above, I would be really interested.

Have a nice day

Tom
0
 
Adam FarageEnterprise ArchCommented:
Tom,

Thank you for the complement :) I should start writing more blogs to my wordpress, but the interface is horrific so I usually use EE now.

If you dont mind, can you share your CAS Array configuration? Mainly the FQDN of each CAS Array? Also what is the ExternalURL of each Exchange ActiveSync virtual directory in the three AD sites?

It sounds like something is being duplicated here. Even though the site might be down, if the active database is moved to a site that is online that is where you should be fulfilling the request.
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
abissaAuthor Commented:
Hi Adam,

Thanks for the answer.
The thing is, for each dag, the only two db which are authorized to be mounted are in the same AD site. The 3rd db is in the data recovery center and should not be used. Thus, if an AD site is not reachable, this means users have no way to access their emails as we do not want them to connect to the DR site. That's why we don't want the autodiscover to redirect activesync devices to a different AD site which doesn't contain users mailbox.

Here's the config:
4 AD sites: GVA (Geneva), BJ (Beijing), NY (New York) and DR (Data Recovery)
9 Exchange servers 2010 SP3 ( two for each site and three in the DR site) - all servers have all cas, hub and mbx roles
3 DAGS: daggva (2 db on GVA site, one in DR), dagny  (2 db on NY site, one in DR), dagbj  (2 db on BJ site, one in DR)
3 CAS Array (FQDN): GVA = mail.domain.local - BJ: mailbj.domain.local - NY: mailny.domain.local
ActiveSyncVirtualDirectory (external URL):
GVA - https://mail.domain.org/Microsoft-Server-ActiveSync
NY -  https://mailny.domain.org/Microsoft-Server-ActiveSync
BJ - https://mailbj.domain.org/Microsoft-Server-ActiveSync
BJ - https://mailbj.domain.org/Microsoft-Server-ActiveSync

Basically, the issue occurs mostly for BJ users. If the BJ office network goes down or if their database is mounted in the recovery AD site (which should not happen as we configured it, but it still does if BJ site is down), then BJ mobiles cannot reach mailbj.domain.org and are automatically redirected to either mail.domain.org or mailny.domain.org. I thought at some point that if we change our configuration to allow users to access the data recovery site, then at least on their mobile the server address would switch to the address of the recovery site. But the problem would remain the same: as the recovery site is in Europe, it would be really slow for NY and BJ users, and their mobile would not switch back to their respective site once it's back online.

Hope the above helps. The more I think about it, the more I'm convinced that I'll have to create aliases for the casarray, or AD subdomain, to prevent mobile from accessing this domain.org/autodiscover/autodiscover.xml address.
0
 
Adam FarageEnterprise ArchCommented:
So help me understand this, lets say the BJ site goes down which site would host the once active Database? In theory DR, but do you have any ExternalURL setup there?

If there is no ExternalURL, then I would expect this to be normal.
0
 
abissaAuthor Commented:
If BJ site goes down, that's it. No site is configured to host the db. Users will not have access to their emails. DR could, but we don't want to. Thus, if BJ site is down, I don't want the activesync device to retrieve a different address, and according to your answer, it will try anyway to contact domain.org/autodiscover/.... and will find the others CAS array address
0
 
abissaAuthor Commented:
And just FYI, I opened a case with Microsoft two weeks ago. To make it short, the Professional support had to close the ticket as they judged we need to do a root/cause analysis, which they don't. They refunded us, advising to open a case with microsoft premium support..... no comment as it's more or less the same thing as professional support. Anyway, the problem I'm facing is a known bug which should have been resolved with SP3 RU2.... it didn't. So right now I'm just trying to find a workaround to, at least, have the mobile device making the autodiscover request on an URL which will not return anything, so the server address in the activesync profile on the mobile is not changed. This is why I was thinking about creating aliases.
0
 
Adam FarageEnterprise ArchCommented:
Hrm. I would request a bugcheck done and see if they can resolve it with a IU. This can be done, as I have done it before. It would involve opening a premier case and then requesting a bugcheck, but they are pretty good with it.

On top of that, if they do deem it a bug (which what you are describing is a bug) then pow - its free.

I was a Premier Field Engineer for Exchange @MSFT, which is one of the reasons I know this :)
0
 
abissaAuthor Commented:
Hi Adam,

I will try to open a premier ticket.
Thanks for the advices and for keeping on answering after the question despite it's been marked as resolved.

Have a nice day!

Tom
0
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.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now