So this is a complicated scenario but only because this particular customer made it that way; in fact the solution ended up being very simple.
One of my Consultant co-workers pinged me on an issue he was sorting through at a customer site. They were using UAG for their Outlook Anywhere endpoint, both internally & externally. They had a policy to only allow Outlook Anywhere for roughly 30% of their user base. They were enforcing this using AD group membership in UAG to block access to the Outlook Anywhere rule for all users except for those on the allowed list.
Not only was this a nightmare to manage but it also caused Outlook Authentication prompts in certain scenarios. I’ll explain:
When internal Outlook users moved between wired & wireless networks (or vice versa), Outlook would be disconnected just long enough for it to attempt an Outlook Anywhere connection over HTTPS (since the RPC/MAPI connection didn’t reconnect quite fast enough for Outlook’s liking). Well since they were using NTLM for Outlook Anywhere this didn’t really pose a problem for the users who had been allowed to use the OA rule in UAG. However, the users who had been blocked (the majority of their users) would get Outlook auth prompts.
This raised another question from the Consultant & the client; why does enabling Outlook Anywhere on your Client Access Server result in all Outlook clients being enabled for Outlook Anywhere? Shouldn’t there be a method to disable it by default & only enable it via AutoDiscover in Outlook on the mailboxes we choose? Well I’m not Microsoft so I couldn’t answer that but what I was able to do was give them a much better solution going forward which wouldn’t require the hassle of managing group membership for the UAG rule.
When you enable Outlook Anywhere on your Client Access Server (Exchange 2007/2010), AutoDiscover will then start handing out information to all Outlook Clients on how to connect via OA if a direct RPC/MAPI/TCPIP isn’t available. This allows external Outlook clients to connect to their Mailbox without the use of a VPN.
Exchange AutoDiscover hands these out using what’s called Outlook Providers. These allow Administrators & Exchange itself to differentiate between the various settings used with Outlook Anywhere VS direct RPC/MAPI/TCPIP connections.
The EXCH Outlook Provider is used to hand out settings used when connecting via RPC/MAPI/TCPIP while the EXPR Outlook Provider is used to hand out settings when connecting via Outlook anywhere (RPC over HTTPS). You can view the settings of each by running Get-OutlookProvider | Format-List.
This is the response received using the Test E-mail AutoConfiguration utility in Outlook for a mailbox after Outlook Anywhere has been enabled in the environment. This image shows the EXCH settings.
This image shows the EXPR settings received in the same AutoDiscover response. These are the settings Outlook will use to connect to Outlook Anywhere if it needs to. Notice here it says “Exchange HTTP” for the Protocol opposed to “Exchange RPC” in the previous image.
Below you’ll find the XML response from the “XML” tab of the Test E-mail AutoConfiguration utility. You can see the settings for both the EXCH & EXPR Outlook Providers.
<ServerDN>/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=CASArrayAustin.contoso.local</ServerDN>
<MdbDN>/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=CASArrayAustin.contoso.local/cn=Microsoft Private MDB</MdbDN>
This image shows the actual Outlook Anywhere settings being configured on the client as a result of the AutoDiscover EXPR response. (File>Account Settings>Change>More Settings>Connection)
So the solutions here is actually fairly easy & oddly enough, not well known. The Set-CASMailbox command can be used to block a particular mailbox from accessing various Client Access features. In this case we can use it to block Outlook Anywhere for John’s Mailbox. (Note: This command can also be scripted or piped to take effect on any number of mailboxes in the environment).
Set-CASMailbox –Identity John –MAPIBlockOutlookRpcHttp $True
After running this command you may need to wait about 15min for AD replication to take effect as well as 15min for AutoDiscover, Outlook Anywhere, & ultimately Outlook to take the change. To speed this process up you can recycle the MSExchangeAutodiscoverAppPool in IIS as well as restart the Microsoft Exchange Service Host service on each CAS.
Now, if you run Test E-mail AutoConfiguraton you’ll see that the Outlook client doesn’t even get the EXPR response because they’ve had that feature blocked.
Now if you look at the Outlook Anywhere settings (below) in Outlook, they are no longer even configured/enabled. Now in my lab using Outlook 2013 I had to actually perform a profile repair to get this change to take effect immediately. You will likely either have to wait longer for it to take effect or manually repair the profile.
So in this customer’s case, users who were not allowed to use Outlook Anywhere would not get the Outlook Authentication prompt when moving from internal wired to wireless or vice versa because their Outlook client never attempted the Outlook Anywhere connection; they just remained in a disconnected state until the new connection came fully online.
Also, after showing the customer this command they no longer had to rely on UAG to control who could or couldn’t access Outlook Anywhere; they could now just script the Set-CASMailbox command.