We’re programmatically (using the Microsoft Exchange Web Services Managed API 2.0) to access the user’s calendar (on Exchange 2010 SP1).
We have been able to successfully communicate with EWS via auto-discovery in our development environment on which we didn't have to make any specific settings (we used the default out-of-the-box settings) on Exchange.
Unfortunately the same doesn't work on the client’s environment. The client doesn't have a test environment. We’re supposed to communicate to their live Exchange server.
Initially auto-discovery didn't work on the client’s environment. We got the following error:
Microsoft.Exchange.WebServices.Data.AutodiscoverLocalException: The Autodiscover service couldn't be located.
at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.InternalGetLegacyUserSettings[TSettings](String emailAddress, List`1 redirectionEmailAddresses, Int32& currentHop)
at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.GetLegacyUserSettings[TSettings](String emailAddress)
at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.InternalGetLegacyUserSettings(String emailAddress, List`1 requestedSettings)
at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.GetUserSettings(String userSmtpAddress, UserSettingName[] userSettingNames)
at Microsoft.Exchange.WebServices.Data.ExchangeService.GetAutodiscoverUrl(String emailAddress, ExchangeVersion requestedServerVersion, AutodiscoverRedirectionUrlValidationCallback validateRedirectionUrlCallback)
at Microsoft.Exchange.WebServices.Data.ExchangeService.AutodiscoverUrl(String emailAddress, AutodiscoverRedirectionUrlValidationCallback validateRedirectionUrlCallback)
So now we explicitly specify the URL to the EWS. This gave us the following error:
Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The remote server returned an error: (401) Unauthorized. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(HttpWebRequest request)
--- End of inner exception stack trace ---
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(HttpWebRequest request)
at Microsoft.Exchange.WebServices.Data.SimpleServiceRequestBase.InternalExecute()
at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder(FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.WebServices.Data.CalendarFolder.Bind(ExchangeService service, FolderId id)
The exception is thrown in line 5 of the following code:
ServicePointManager.ServerCertificateValidationCallback = this.CertificateValidationCallBack;
ExchangeService exchangeWebService = new ExchangeService(ExchangeVersion.Exchange2010_SP1);
exchangeWebService.Credentials = new WebCredentials("[email protected]", "myPassword");
exchangeWebService.AutodiscoverUrl("[email protected]", this.RedirectionUrlValidationCallback);
**CalendarFolder calendarFolder = CalendarFolder.Bind(exchangeWebService, new FolderId(WellKnownFolderName.Calendar, userName));**
CalendarView calendarView = new CalendarView(startDate, endDate);
calendarView.PropertySet = new PropertySet(BasePropertySet.IdOnly, AppointmentSchema.Subject, AppointmentSchema.Start, AppointmentSchema.IsRecurring, AppointmentSchema.AppointmentType, AppointmentSchema.End, AppointmentSchema.Duration);
FindItemsResults<Appointment> findResults = calendarFolder.FindAppointments(calendarView);
We don’t mind that auto-discovery doesn’t work since we can explicitly specify the URL to the EWS. What we would like to know are what settings, permissions etc. we need to check on the client’s instance of Exchange to determine why the above exception (ServiceRequestException) is being thrown.
We have requested the following commands to be executed on the Exchange Management Shell on the client's instance of Exchange:
Test-OutlookWebServices –Identity username
Get-OrganizationConfig
We are yet to receive the results. Please let us know if there is anything else we should check.