Ondrej Sevecek's English Pages

note that this works as well with a later call to Exchange's command Enable-OutlookAnywhere. The Exchange 2007/2010/2013 cmdlet correctly determines the website name and ID and sets its MetabasePath property correctly according to the site ID.

You can later verify the results with call to:
Get-OutlookAnywhere | fl *

so it works similarly even in SBS (small business server) environment.

... note also that I have currently verified the functionality on an Exchange 2010 running on Windows 2012 (R1) where I wanted to move publicly facing CAS and its OutlookAnywhere into a separate web site instead of using the Default Web Site.

I just uninstalled the RPC over HTTP proxy feature by using Server Manager on an already running Exchange server which didn't have Outlook Anywhere enabled. I created a new IIS web site for the publicly facing virtual directories. I have installed the RPCoverHTTP feature back again, now to the newly created IIS web site using the registry key. After that, I have simply enabled the OutlookAnywhere within Exchange.

Now, the MetabasePath was still incorrectly pointing to the W3SVC/1/Root/RPC which was incorrect. My custom IIS web site has been created with a different ID apparently.

I went into ADSI Edit and found the OutlookAnywhere virtual directory object at CN=Rpc (Default Web Site),CN=HTTP,CN=Protocols,CN=<servername>,CN=Servers,CN=Exchange Administrative Group (<id>),CN=Administrative Groups,CN=<orgname>,CN=Microsoft Exchange,CN=Services,CN=Configuration,...

It seems like the Rpc virtual directory object is automatically created during Exchange 2010 installation and does not change when you enable/disable OutlookAnywhere functionality.

So I simply corrected the name and attributes of the AD object in ADSIEdit. What needed to be mended was msExchMetabasePath attribute of the object. I also changed the object name to reflect the name of the custom IIS web site.

Now the Get-OutlookAnywhere does not complain that the virtual directory does not exist in IIS anymore. And the client connection seems to be working well.

But main problem is that HKLM\Software\Microsoft\RPC\RpcProxy do not exist before installation of RPC over HTTP Proxy.

Just create key "RpcProxy" in regedit and put WebSite = REG_SZ = <the name of your custom web site>
Then install RPC