EWS connection Office365 - System.Net.WebException - (403) Forbidden RRS feed

  • Question

  • We have an application that should connect to Office365 mailboxes and update calendar entries for selected users.   The connection tests successfully but when an attempt is made to update a specific mailbox, we receive the following in our trace:

    Exception: System.Net.WebException
    Message: The remote server returned an error: (403) Forbidden.
    Source: System
       at System.Net.HttpWebRequest.GetResponse()
       at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)

     [3004] INFO  EWSSyncCore.ExAddressBookManager DoResolve [] - Resolving user : <user email address was here>
     [3004] FATAL EWSSyncCore.ExAddressBookManager DoResolve [] - Failed to Resolve the User
    Exception: Microsoft.Exchange.WebServices.Data.ServiceRequestException
    Message: The request failed. The remote server returned an error: (403) Forbidden.
    Source: Microsoft.Exchange.WebServices
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
       at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
       at Microsoft.Exchange.WebServices.Data.ExchangeService.ResolveName(String nameToResolve, IEnumerable`1 parentFolderIds, ResolveNameSearchLocation searchScope, Boolean returnContactDetails, PropertySet contactDataPropertySet)
       at EWSSyncCore.ExAddressBookManager.DoResolve(String Email, GroupwareUser& GWUserInfo)

    We have confirmed that the user mailbox does exist on the server and the error occurs regardless of the user being updated so we assume that this is related to the connection itself.  Other forum postings indicate that 403 can result when SSL connections are not used but we cannot find a way to confirm this is the cause in this case.  Any guidance you can provide to help debug this issue would be greatly appreciated.

    Wednesday, July 8, 2015 11:59 AM

All replies