search

OfficeDev / ews-managed-api

Other
584 stars 317 forks source link

System.ArgumentException: Requested value 'User' was not found. #145

Open vkrepos opened 6 years ago

vkrepos commented 6 years ago

Hi,

Sometimes we get the following exception from EWS Managed API:

System.ArgumentException: Requested value 'User' was not found.

Apparently mailbox type can have a 'User' value in XML response but the corresponding value is absent from MailboxType enum. This leads to the exception. Could you please provide some help on fixing this issue? Hopefully, the fix should protect from other mailbox types not defined in MailboxType enum as well.

System.ArgumentException: Requested value 'User' was not found.
   at System.Enum.EnumResult.SetFailure(ParseFailureKind failure, String failureMessageID, Object failureMessageFormatArgument)
   at System.Enum.TryParseEnum(Type enumType, String value, Boolean ignoreCase, EnumResult& parseResult)
   at System.Enum.Parse(Type enumType, String value, Boolean ignoreCase)
   at Microsoft.Exchange.WebServices.Data.EwsUtilities.Parse[T](String value)
   at Microsoft.Exchange.WebServices.Data.EwsXmlReader.ReadElementValue[T]()
   at Microsoft.Exchange.WebServices.Data.EmailAddress.TryReadElementFromXml(EwsServiceXmlReader reader)
   at Microsoft.Exchange.WebServices.Data.ComplexProperty.InternalLoadFromXml(EwsServiceXmlReader reader, XmlNamespace xmlNamespace, String xmlElementName, Func`2 readAction)
   at Microsoft.Exchange.WebServices.Data.ComplexProperty.LoadFromXml(EwsServiceXmlReader reader, XmlNamespace xmlNamespace, String xmlElementName)
   at Microsoft.Exchange.WebServices.Data.ComplexPropertyCollection`1.LoadFromXml(EwsServiceXmlReader reader, XmlNamespace xmlNamespace, String localElementName)
   at Microsoft.Exchange.WebServices.Data.ComplexPropertyDefinitionBase.InternalLoadFromXml(EwsServiceXmlReader reader, PropertyBag propertyBag)
   at Microsoft.Exchange.WebServices.Data.ComplexPropertyDefinitionBase.LoadPropertyValueFromXml(EwsServiceXmlReader reader, PropertyBag propertyBag)
   at Microsoft.Exchange.WebServices.Data.PropertyBag.LoadFromXml(EwsServiceXmlReader reader, Boolean clear, PropertySet requestedPropertySet, Boolean onlySummaryPropertiesRequested)
   at Microsoft.Exchange.WebServices.Data.EwsServiceXmlReader.ReadServiceObjectsCollectionFromXml[TServiceObject](XmlNamespace collectionXmlNamespace, String collectionXmlElementName, GetObjectInstanceDelegate`1 getObjectInstanceDelegate, Boolean clearPropertyBag, PropertySet requestedPropertySet, Boolean summaryPropertiesOnly)
   at Microsoft.Exchange.WebServices.Data.GetItemResponse.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.ReadResponse(EwsServiceXmlReader ewsXmlReader)
   at Microsoft.Exchange.WebServices.Data.SimpleServiceRequestBase.ReadResponseXml(Stream responseStream)
   at Microsoft.Exchange.WebServices.Data.SimpleServiceRequestBase.ReadResponse(IEwsHttpWebResponse response)
   at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
   at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToItem(ItemId itemId, PropertySet propertySet)
   at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToItem[TItem](ItemId itemId, PropertySet propertySet)
joeyadams-bec commented 6 years ago

We also encountered this with a client using Office 365. We believe the "User" involved was a user created through Active Directory as part of a distribution list. Though we haven't confirmed exactly how that user got created.

It is possible to see the same error through EWSEditor. Open the Calendar containing the offending item (assuming it's a calendar item), and click through items until the error appears. To determine which recipient has the invalid Mailbox type 'User', you can look in the EWSEditor log (by default, %userprofile%\Documents\ewseditor.log ) to see the response XML returned from EWS:

<t:Attendee>
  <t:Mailbox>
    <t:Name>***REDACTED***</t:Name>
    <t:EmailAddress>***REDACTED***</t:EmailAddress>
    <t:RoutingType>SMTP</t:RoutingType>
    <t:MailboxType>Mailbox</t:MailboxType>
  </t:Mailbox>
  <t:ResponseType>Unknown</t:ResponseType>
</t:Attendee>
<t:Attendee>
  <t:Mailbox>
    <t:Name>***REDACTED***</t:Name>
    <t:EmailAddress />
    <t:RoutingType>SMTP</t:RoutingType>
    <t:MailboxType>User</t:MailboxType>
  </t:Mailbox>
  <t:ResponseType>Unknown</t:ResponseType>
</t:Attendee>
<t:Attendee>
  <t:Mailbox>
    <t:Name>***REDACTED***</t:Name>
    <t:EmailAddress>***REDACTED***</t:EmailAddress>
    <t:RoutingType>SMTP</t:RoutingType>
    <t:MailboxType>OneOff</t:MailboxType>
  </t:Mailbox>
  <t:ResponseType>Unknown</t:ResponseType>
</t:Attendee>
corygwarren commented 6 years ago

We have started getting the same for ~30% of a customers mailboxes. Would love to know where these "User" MailboxTypes are coming from, and how to handle this. Also getting "GroupMailbox" MailboxTypes for other customers, which throws the same exception

synic commented 6 years ago

Just a +1. We have also started seeing this for o365 accounts, but not for on premises Exchange.

davster commented 6 years ago

Thanks for reporting. Yes, that looks like a bug. It appears that the User enum value is missing from the schema but is present in the serialization code.

I found the offending check-in that caused this issue and have reached out to the dev to rectify and backport the fix. The suggested fix on our end is to update the schema, but then also to only emit the new "User" value when the request version is V2017_10_07 or greater as that is the current "beta" version which will be rev'd in early Jan. For earlier request versions, it will return Unknown instead so that it is schema compliant.

synic commented 6 years ago

What is the status on this bug? Has there been any movement? This is making it impossible for some of our users to use our service.

irockmikeford commented 6 years ago

@synic I was able to resolve this in our hybrid config by connecting to exchange online via powershell and find the offending mailbox with the get-mailbox command. once i noticed a mailbox that was listed that i could not see in in the office.com exchange online admin UI, run 'get-mailbox -identity insertmailboxname | FL' and you should see recipienttypedetails that match the mailbox name in the error you are getting from the o365 forest in EMC. in my case, it was a disabled mailbox. i was then able to run the remove-mailbox command to get rid of it, ran a schema refresh with Azure AD connect, then a delta ad sync. after this i was able to successfully access the o365 forest in EMC w/o any errors.

synic commented 6 years ago

Unfortunately, we don't actually manage any of the exchange servers that are connected to our service.

Our clients run their own servers, there are thousands of them. We simply integrate by connecting to them via EWS.

I do not have the power to fix it from the server side.

cortfr commented 6 years ago

Any update on this? We're running into this as well. @davster, would you mind sharing which commit caused the issue. Maybe we can patch it in the meantime? Thanks!

cortfr commented 6 years ago

Also, I believe #146 is related to this.

davster commented 6 years ago

CL 2309127 was the offending change - I just reached out to the dev responsible for this to get an update.

cortfr commented 6 years ago

Hi @davster, thanks... but forgive my ignorance... I take it that the CL is in a private repo to Microsoft, or is that CL posted somewhere so we can see the diff?

davster commented 6 years ago

My bad - forgot this was the public discussion alias. Yep, that is an internal change list number for the server side regression. The regression added a new code value for the enum, but didn't update the schema, nor did it consider the request version when emitting that new value. The fix in this case is on the server side and will require only emitting the new value when the request is the current latest beta version, and of course update the schema to reflect this new value.

Sent out a high prio email to the dev as a followup to see where this is since I pinged them in Dec.

cortfr commented 6 years ago

Ok thanks @davster. We are seeing this with Office 365 based Exchange accounts now too... so it's starting to hurt ;) . I'm wondering if you can think of any patch we can put into the EWS library to guard against it for the time being? Thanks again!

davster commented 6 years ago

As a temp workaround, in the managed API, when you try to deserialized the user kind and it is an unknown value, just use unknown. That is what the server side fix will be when the version is less than V2017_01_07. By the way, the team did make a fix for this back in Jan (schema rev), but the fix didn't include the server changes to not emit the new value when the request version is old. I am following up with them on that front.

cortfr commented 6 years ago

It's not going to win many style points, but I pushed a patch to my fork just now based on your suggestion. @davster would you mind reviewing? Is there a more idiomatic way to fix it? Thanks!

kb99 commented 6 years ago

@davster do you have any idea of what sort of timeframe it will be before the server-side code change gets deployed office365 exchange? We are also seeing this issue but are trying to gauge if its worth the development time/effort on our side to fork and manually patch the EWS API to guard against the issue. We are also getting errors related to #146 so may need to patch the EWS API unless there is a server-side fix for that in the pipeline as well?