Prevent Outlook Anywhere (aka RPC over HTTP) from being automatically configured in Exchange 2007 with autodiscover

Update #2 – July 28th 2014 –

Removing the EXPR while Autodiscover is being utilized (which is probably the case in most deployments) will achieve preventing Outlook Anywhere from being used.

With that being said, a few commentators stated that they would like to continue using Outlook Anywhere and with Autodiscover enabled and the EXPR removed this will result in constant “removal” of the Outlook Anywhere settings that were statically configured.

If you want only specific users to be able to use Outlook Anywhere while others don’t I would advice considering the Set-CasMailbox -MAPIBlockOutlookRpcHttp:$true cmdlet to allow/block specific users.

UpdateJune 29th 2013 –

If you’re going to deploy Exchange 2013 anytime soon – work your way to adapt autodiscover, and bring back the EXPR value. See Exchange 2013 Outlook Anywhere Considerations for more.

This is an unsupported method, use at your own risk!

Once “Outlook Anywhere” is configured on a client access server an EXPR entry is created. Then the autodiscover application picks up the change and publish it, along with the url’s for OAB,EWS & Availability.
This basically “force” the automatic propagation of settings into the profile, including the checkbox for “Connect to Microsoft Exchange using HTTP” and filling the information for the HTTP proxy and authentication methods.

Microsoft documented Deployment Considerations for the Autodiscover Service in: – Where only Site Affinity is can be configured.

The Outlook provider setting and autodiscover relation are referenced quite good in the Exchange team blog:

A client of mine needed the possibility to disable the automatic propagation of the  “Connect to Microsoft Exchange using HTTP” setting in an Exchange 2007 environment .
he did of course wanted to keep the ability to connect using “Outlook Anywhere”  if desired when configuring that manually.

Because autodiscover was made to auto-configure clients that are inside & outside the corporate network disabling this feature disables the ability for external outlook clients, that not domain joined to automatically connect using “Outlook Anywhere” . it does, however does not affect the configuration of a profile.

Within the exchange shell:
Get-outlookprovider –identity EXPR | remove-outlookprovider
Once this is done, recycle the application pool of AutoDiscover in IIS.

This solution will keep the outlook clients from automatically propagate the settings for “Outlook Anywhere” , but retains the possibility for configuring it manually.
All web services and autodiscover information other then the proxy information itself are intact.

Updates (Thanks for all commentators)

New-OutlookProvider -Name:EXPR

I have done the required testing to make sure this solution works.

This is an unsupported method, use at your own risk!

Exchange 2007 & Exchange 2003 Coexistence – CAS Proxy issues

sorry for the huge gaps , but it’s been very busy and messed up lately… well anywayz

A CCR implementation, along with 2 HUB/CAS & 2 ISA servers to serve.

on the legacy side , an Exchange 2003 cluster based windows w2k & 2 front ends.

all seems to be working great , except that when it all came to start testing connectivity and co-existence with the 2003 backend cluster

using the new CAS servers to replace the frontend servers things went bad.

i’ve had error 500 when accessing 2007 mailboxes with /exchange,  404 errors when accessing /exchange and using 2003 Mailboxes.

also , event id 1000 , with source EPROX was logged in the CAS application log,  the description doesn’t make much sense..except that it wrote the Backend cluster 2003 name..
” The description for Event ID 1000 from source EXPROX cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. ”
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:

Solving.. 🙂

the error 500 was solved when i double checked that all the CCR mailbox role features were installed, web-ISAPI-ext was missing, and now the 2007 mailboxes works with /exchange.

now, if you’ll read some in technet you’ll find out on the hows and why and so on… BUT ! you should keep in mind that if you work with a Clustered backend , and you want to support any front end/cas

you should also follow the following KB:

“How to configure host header and authentication information in Exchange 2000 Server or Exchange Server 2003 Outlook Web Access on a Windows Server 2003 or Windows 2000 server cluster”

long story short now –
to make this legacy proxy support , you should first check that navigating to your CAS mailboxes with /exchange WORKS to 2007 mailboxes first.
rather use the default Form auth and dont change nothing to test it.

then , make sure you’ve added ALL the host headers you will use (eg;, owa.local.dom etc..) on your clustered backend 2003/2000 exchange servers.

once this works , you should not see any EPROX errors in applications log , nor Availability service errors that actually say that the CAS server cannot find your backend servers.

then you should be able to test with 2003 mailboxes through the CAS servers , and decommission any front end servers you might have.

Hope this helps!

Memory & Exchange x64 bit Technology

Well, as far as deployments , it’s seems that “most” implementations are rather normally okay, there’s times when memory issues did rise and troubleshooting this might be a real pain..

Mostly, i’d deal with a mail server that has no less then 16gb and is an all-in-one configuration, running 64bit Server 2003 sp2 with extra special care for all drivers , updates , prerequisites & page file configurations.

Usually, even if they run All roles + an Anti Virus product , while carefully setting backup & maintenance times, things go smooth.

Yet, there are times when the server is having issues, while troubleshooting is necessary of course, i’d rather go with the future spirit & just think my way up to Server 2008 .
Check out the Blog from mike in the Exchange Team blog it has some great links and more deep explanations..

server 2008 manages this issues out of box and the applications are far more compatible, easier life for all of us. really.

uh and yea i’m running vista sp1.

SeSecurityPrivilege issues while running setup for Exchange 2007

So, yet another implamentation of exchange, this time i’ve encounted the following error while installing the CAS role on the server.

Setup exited with the following error:

The process does not possess the ‘SeSecurityPrivilege‘ privilege which is required for this operation.

Searching the privilege showed that “Exchange Servers” & more accurate in our situation , the “Domain Administrators were not configured in the “Manage auditing and security log” , because the Default Domain Policy & Default Domain Controllers Policy GPO’s was re-created and the default ones were left with the link set to off.

Easy to monitor those privileges with whoami.exe from the support tools, i love it that the server 2008 installs them all as dependencies !

Once we’ve added the DomainAdministrators , DomainExchange Servers to the policy , setup ran okay 🙂

Export-mailbox fails with error

while testing yet another ex2k7 implantation , i’ve encountered an error while trying to export mailboxs to pst with the Export-mailbox cmdlet.

I’ve verified full mailbox access permissions and 2007 32bit tools on xp sp2 with outlook 2007.

yet, still failed with the following error:

Export-Mailbox : Error was found for user01 (

because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221241

With some filtering of search results i’ve find a suggestion to run the cmd fixmapi in cmd.. if your not femiliar with this utility (like i was) , this util exists in your %systemroot%system32 , along with the mapi32.dll files .. besides that 3 notes for you:

  1. FixMAPI does not replace the current mapi32.dll file if the file is marked as read-only.
  2. FixMAPI does not replace the current mapi32.dll if Microsoft Exchange Server is installed on the computer.
  3. When FixMAPI makes a backup copy of the current copy of mapi32.dll on the computer, it assigns the backup copy a name different from “mapi32.dll”. It then directs subsequent calls intended for that assembly to the backup copy.

oh yea, closeing all applications and running fixmapi in cmd , just like that fixed the issue.