Skip to content
This repository has been archived by the owner on Jul 22, 2024. It is now read-only.

Entries from Microsoft Bookings appear in EWS response and lead to NullReferenceException (using Exchange Online) #295

Open
alex3683 opened this issue Apr 21, 2023 · 2 comments

Comments

@alex3683
Copy link

alex3683 commented Apr 21, 2023

First a short note: I know that EWS for Exchange Online is discontinued and that MS Graph API should be used. We are going to switch to that, but it will take us some time. In the mean time we still have to support EWS for our customers. And I think the fix / Workaround could be quite simple, alas it can only implemented within the EWS managed API and not client code.

We observed the following symptom: Calling ExchangeService.SyncFolderItems failed for some users with the following exception and stack trace:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Exchange.WebServices.Data.SyncResponse`2.ReadElementsFromXml(EwsServiceXmlReader reader)
   at Microsoft.Exchange.WebServices.Data.ServiceResponse.LoadFromXml(EwsServiceXmlReader reader, String xmlElementName)
   at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.ParseResponse(EwsServiceXmlReader reader)
   at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ParseResponse(EwsServiceXmlReader reader, WebHeaderCollection responseHeaders)
   at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ReadResponse(EwsServiceXmlReader ewsXmlReader, WebHeaderCollection responseHeaders)
   at Microsoft.Exchange.WebServices.Data.SimpleServiceRequestBase.ReadResponseXml(Stream responseStream, WebHeaderCollection responseHeaders)
   at Microsoft.Exchange.WebServices.Data.SimpleServiceRequestBase.ReadResponse(IEwsHttpWebResponse response)
   at Microsoft.Exchange.WebServices.Data.SimpleServiceRequestBase.InternalExecute()
   at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
   at Microsoft.Exchange.WebServices.Data.ExchangeService.SyncFolderItems(FolderId syncFolderId, PropertySet propertySet, IEnumerable`1 ignoredItemIds, Int32 maxChangesReturned, Int32 numberOfDays, SyncFolderItemsScope syncScope, String syncState)
   at Microsoft.Exchange.WebServices.Data.ExchangeService.SyncFolderItems(FolderId syncFolderId, PropertySet propertySet, IEnumerable`1 ignoredItemIds, Int32 maxChangesReturned, SyncFolderItemsScope syncScope, String syncState)

I then asked the customer to provide an EWS Trace. This contained a lot of the well known <t:CalendarItem> elements, but far at the end an <t:Booking>, which seems to come from Microsoft Bookings . In parallel I had a look at the source of the EWS managed API and looked for a spot, where the NRE could occur. This then fell into my eye:

change.ServiceObject = EwsUtilities.CreateEwsObjectFromXmlElementName<TServiceObject>(
reader.Service,
reader.LocalName);

So in case EwsUtilities.CreateEwsObjectFromXmlElementName<TServiceObject> cannot provide an instance for the element it returns default (

return default(TServiceObject);
), so in practice null and
change.ServiceObject.LoadFromXml(
will throw the NRE. And in fact no element t:booking is registered here
private void InitializeServiceObjectClassMap()

It seems that this library had the same issue: ecederstrand/exchangelib#877

So my question is: What can we do, until we switch to Graph, to mitigate this? Is there any workaround we can implement on our side? Disabling Microsoft Bookings is no option. Honestly I fear there is no local workaround.

So would it be possible to provide a EWS managed API version that is more lenient in that regard and (maybe optionally) ignores new, unknown element types? The implementation would be quite simple. For me this just seems like a breaking change from Microsoft. We're quite stuck here ...

EDIT: This is what the Booking looks like, apart from the stuff after organizer much like a calendar item (XXXX where sensitive data was):

 <t:Booking>
                  <t:ItemId Id="XXXX" ChangeKey="XXXX" />
                  <t:Subject>XXXX</t:Subject>
                  <t:Sensitivity>Normal</t:Sensitivity>
                  <t:Importance>Normal</t:Importance>
                  <t:ExtendedProperty>
                    <t:ExtendedFieldURI DistinguishedPropertySetId="Meeting" PropertyId="35" PropertyType="Binary" />
                    <t:Value>XXXX</t:Value>
                  </t:ExtendedProperty>
                  <t:LastModifiedTime>2023-03-02T06:56:34Z</t:LastModifiedTime>
                  <t:Start>2023-03-02T07:10:00Z</t:Start>
                  <t:End>2023-03-02T07:40:00Z</t:End>
                  <t:IsAllDayEvent>false</t:IsAllDayEvent>
                  <t:LegacyFreeBusyStatus>Busy</t:LegacyFreeBusyStatus>
                  <t:Location />
                  <t:IsMeeting>true</t:IsMeeting>
                  <t:IsCancelled>false</t:IsCancelled>
                  <t:CalendarItemType>Single</t:CalendarItemType>
                  <t:MyResponseType>Organizer</t:MyResponseType>
                  <t:Organizer>
                    <t:Mailbox>
                      <t:Name>XXXX</t:Name>
                      <t:EmailAddress>XXXX@XXXX</t:EmailAddress>
                      <t:RoutingType>SMTP</t:RoutingType>
                      <t:MailboxType>Mailbox</t:MailboxType>
                    </t:Mailbox>
                  </t:Organizer>
                  <t:PreBuffer>0</t:PreBuffer>
                  <t:PostBuffer>0</t:PostBuffer>
                  <t:PricingType>Undefined</t:PricingType>
                  <t:Price>0</t:Price>
                  <t:BookingFee>0</t:BookingFee>
                  <t:BookingTax>0</t:BookingTax>
                  <t:SelfServiceId>00000000-0000-0000-0000-000000000000</t:SelfServiceId>
                </t:Booking>
@SchultzAndreas
Copy link

I fixed the bug. You are welcome to clone my fork, the only change is adding the booking element.

jbennink added a commit to jbennink/ews-managed-api that referenced this issue May 6, 2024
…by SchultzAndreas from 25-03-2023. This will be Beta5
@jbennink
Copy link

jbennink commented May 6, 2024

@SchultzAndreas Thanks for this. I ran into this as well, apparently when Booking is enabled on the account you can get this, did not see this before. I am running on a fork by @sherlock1982 so I added your fix to my own fork of that fork :-|

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants