Body |
... 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.
|