Friday, November 27, 2009 9:40 PM
When I try to save setting changes in my OWA Options I get an "Error The server method 'SetObject' failed." I've verifed that my ECP External/Internal URLs are correct on the Client Access settings, removed and re-added the ECP site, and restarted the server. I've also scoured Google which is usually pretty good for pointing me in the right direction for strange errors, but am unable to find anything there either. Thoughts?
Monday, November 30, 2009 12:02 AMI'm having exactly the same problem. If you come across a solution, mcandrew, or if anyone else happens to know how to solve this, I would be very happy to get a clue... :)
Monday, November 30, 2009 10:25 AMTry enabling anonymous rights on the /ecp virtual directory
Saturday, December 05, 2009 10:47 PM
Try enabling anonymous rights on the /ecp virtual directory
Thank you for replying. Will not enabling anonymous rights ont he /ecp virtual directory be a security risk?
Friday, December 18, 2009 12:36 PM
Monday, December 28, 2009 12:51 PMHave you configured a second SSL binding for OWA? I started getting this error after configuring a second HTTPS binding in IIS, as I was planning to use separate SSL certificates (with different CNs, and on different ports) for internal and external OWA access. When this resulted in the error you described, I checked the logs on the Exchange server and found the following corresponding error in the Application log:
Log Name: Application Source: System.ServiceModel 188.8.131.52 Date: 22/12/2009 17:40:18 Event ID: 3 Task Category: WebHost Level: Error Keywords: Classic User: SYSTEM Computer: Exchange-Server
Description: WebHost failed to process a request. Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/27717712 Exception: System.ServiceModel.ServiceActivationException: The service '/EWS/Exchange.asmx' cannot be activated due to an exception during compilation. The exception message is: This collection already contains an address with scheme https. There can be at most one address per scheme in this collection. Parameter name: item. ---> System.ArgumentException: This collection already contains an address with scheme https. There can be at most one address per scheme in this collection. Parameter name: item at System.ServiceModel.UriSchemeKeyedCollection.InsertItem(Int32 index, Uri item) at System.Collections.Generic.SynchronizedCollection`1.Add(T item) at System.ServiceModel.UriSchemeKeyedCollection..ctor(Uri addresses) at System.ServiceModel.ServiceHost..ctor(Type serviceType, Uri baseAddresses) at System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(Type serviceType, Uri baseAddresses) at System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(String constructorString, Uri baseAddresses) at System.ServiceModel.ServiceHostingEnvironment.HostingManager.CreateService(String normalizedVirtualPath) at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(String normalizedVirtualPath) at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath) --- End of inner exception stack trace --- at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath) at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath) Process Name: w3wp Process ID: 5212
I realised at this point that Exchange was choking on the second HTTPS binding. It seems you can only have one SSL port configured in IIS, and thus, only one SSL certificate. If you have multiple URLs that resolve to your mail server, and want to avoid certificate errors as a result of having the wrong CN on the certificate, you need to obtain an Exchange Unified Communications Certificate .
The reason I'd configured the second SSL binding in the first place was to avoid having to purchase a UC Certificate, as I wanted to use a basic class 1 certificate I already had for my external URL. In the end, I decided to use only the external URL and certificate, directing internal OWA users to the external URL. I then added an A record to our internal DNS servers to resolve requests for the external URL to the internal IP of the Exchange server.