GetAttachment broken

[Tabernarius]

Attachment.Load() returns a 500 Internal Server Error (ErrorInternalServerError). The request is

The response: a:ErrorInternalServerError An internal server error occurred. The operation failed. ErrorInternalServerError An internal server error occurred. The operation failed. This happens when connected to Office 365, which seems to run Exchange 2016. I am using the EWS Managed API 2.2 NuGet packages. This is the version information I get back from another soap call: ServerVersionInfo MajorVersion="15" MinorVersion="1" MajorBuildNumber="734" MinorBuildNumber="8" Version="V2016_10_10" We started getting this error yesterday. Perhaps the client needs to be updated to match the new server software?

[davster]

Where did you get that Id? I just cracked it and it is corrupt.

[Tabernarius]

I got the Id from Microsoft.Exchange.WebServices.Data.Item.Attachments How can you see it is corrupt?

The next comment shows part of the soap response to GetItem. (GitHub ate the xml in this comment)

[Tabernarius]

            <t:Attachments>
              <t:FileAttachment>
                <t:AttachmentId Id="AAIARgAAAAAAGkRzkKpmEc2byACqAC/EWgkA3BcK9tpiYkqUxrYiq+JB7QACPb3KKwAA3BcK9tpiYkqUxrYiq+JB7QAC11rlWwAALgAAAAAAGkRzkKpmEc2byACqAC/EWgMA3BcK9tpiYkqUxrYiq+JB7QACPb3KKwAAARIAEAD/yE8Ivr4URbMiAIvddHi4" />
                <t:Name>Leeg.pdf</t:Name>
                <t:ContentType>application/pdf</t:ContentType>
                <t:Size>15933</t:Size>
                <t:LastModifiedTime>2016-11-17T08:59:11</t:LastModifiedTime>
                <t:IsInline>false</t:IsInline>
                <t:IsContactPhoto>false</t:IsContactPhoto>
              </t:FileAttachment>
            </t:Attachments>

[davster]

That's odd. I assume by the build number that you are making this request against Office365. I just tried the same request against my mailbox in the cloud and it is able to parse your id just fine - it just obviously couldn't find the item since it was my mailbox instead of yours.

I can see that it is corrupt because I wrote the Id serialization/deserialization code in Exchange and have a special tool that I wrote that lets we crack an id and see all of the constituent parts. HOWEVER - I noticed that I haven't update my cracking tool in a while

[Tabernarius]

Thanks for your reply, davster. I am making the request against Office365. The message is in a sub folder of the publicfolder.

Since the custom clients have worked in this same scenario for years until it broke yesterday, I assume that an update in Exchange on Office365 broke it.

I tried Office365 support, but they don't answer questions about the EWS / third party clients. What would you suggest I do to get this resolved?

[Ellistine1]

I'm also having the same problem. I've been downloading attachments successfully since we moved to 365 and all of a sudden I'm getting 'An internal server error occurred. The operation failed' message when calling attachment.load().

[davster]

Are these all public folder items?

[Tabernarius]

Yes, they are public folder items. I have just tested it with a private Inbox and it works in that scenario.

[Ellistine1]

Public folder for me also.

[Tabernarius]

While this is still broken, as a workaround we are using a folder in an Inbox to move the messages to using Item.Move.

[davster]

As an FYI, I found the issue and have a fix being validated right now. Once it has been backported and begins rolling out world wide, I will respond to this thread. Thanks all for reporting it!

[davster]

Ok - fixed has been checked in. We are starting the process of backporting now and then the subsequent rollout. BTW, I love how replying to the GitHub email throws all of the email header goo in the GitHub comment even though it suggests that you can reply to the email. Note to self...

[Ellistine1]

Cool. I'll pretend I know what that all means ;-) How long does this sort of thing take to roll out?

[MichelZ]

@davster Sorry to hijack this, but does this mean we'll see more activity from Microsoft on this project again? Especially maybe a new set of NuGet packages?

[davster]

@Ellistine1 - i actually made all that up to sound smart :) the short of it, give it a few days and the problem should be rectified. There are quite a few servers that need the updated bits.

@Michelz - yes. That was something that unfortunately fell on the back burner and we are addressing this soon.

[Tabernarius]

Thanks David!

[Ellistine1]

All seems to be working again. Many thanks for your help David.

[Tabernarius]

Issue resolved.

[davster]

Yep - we actually checked in the fix on Thanksgiving eve. Thanks to my coworkers (or should that be cohorts??) Bruce and Suneel for their efforts in getting the fix backported to previous builds and rolled out. Sorry again for the inconvenience. Eventually you will be really happy with the feature I was working that caused this regression. But no hints yet :)

[Tabernarius]

This problem is back, with the same error message, again only in public folders.

[Ellistine1]

Still seems to be ok for me. Perhaps it's effects particular servers?

[davster]

@Ellistine1 - That is likely the case. @Tabernarius, in the response HTTP headers, there should be an entry for BE (back end) server. If you tell me what that is, I can check to see if that server is on an older build.

[Tabernarius]

BEServer is AM4PR0301MB2164

[davster]

Interesting. The change was checked into build 761.007 and that box has 761.009, so it should be working. Are you getting the same response (InternalServerError)?

[Tabernarius]

Yes: HTTP/1.1 500 Internal Server Error

a:ErrorInternalServerError

    <faultstring xml:lang="en-US">An internal server error occurred. The operation failed.</faultstring>

[Tabernarius]

This is the request. Pretty much the same scenario as before.

` <?xml version="1.0" encoding="utf-8"?>

`

[davster]

I pulled logs for your failed requests. The particular failure you are hitting (which was different than the previous issue) was fixed in build 770. Looking at the deployment schedule, build 771 is already rolling out in production (28% saturation), so the fix should be on your server soon (next few days).

[Tabernarius]

Thanks, David!

[donfmorrison]

This still seems to be an issue? I started getting the "Internal Server Error" when calling FileAttachment.Load today. This same code has been working fine for about 4 months.

Here is the trace:

<Trace Tag="EwsRequestHttpHeaders" Tid="3" Time="2017-02-19 05:03:33Z">
POST /EWS/Exchange.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
Accept: text/xml
User-Agent: ExchangeServicesClient/15.00.0847.030
Accept-Encoding: gzip,deflate

</Trace>
<Trace Tag="EwsRequest" Tid="3" Time="2017-02-19 05:03:33Z" Version="15.00.0847
030">
  <?xml version="1.0" encoding="utf-8"?>
  <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m=
http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://s
hemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xm
soap.org/soap/envelope/">
    <soap:Header>
      <t:RequestServerVersion Version="Exchange2013_SP1" />
    </soap:Header>
    <soap:Body>
      <m:GetAttachment>
        <m:AttachmentIds>
          <t:AttachmentId Id="AAMkADg3NmZlY2Y5LWZjOGQtNDQzYi04ZGNlLTk4ZWRlNjhiM
Y4NQBGAAAAAADlB1j4VYRVSIjfVmQvvDvCBwCgMuTyd3JYRIY7SR/u98OlAAAAAAEMAABYZAV9/UqRT
aNd+w41agaAABdnqAtAAABEgAQAGEBRUFK5PVHuOOiOyIVt44=" />
        </m:AttachmentIds>
      </m:GetAttachment>
    </soap:Body>
  </soap:Envelope>
</Trace>
<Trace Tag="EwsResponseHttpHeaders" Tid="3" Time="2017-02-19 05:03:34Z">
HTTP/1.1 500 Internal Server Error
Transfer-Encoding: chunked
request-id: f3cf6625-66cd-49cc-a5c6-de8a53b31fc2
X-CalculatedBETarget: MWHPR02MB2877.namprd02.prod.outlook.com
X-BackEndHttpStatus: 500
X-DiagInfo: MWHPR02MB2877
X-BEServer: MWHPR02MB2877
X-FEServer: DM5PR12CA0067
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Date: Sun, 19 Feb 2017 05:03:34 GMT
Set-Cookie: exchangecookie=xxx; path=/
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET

</Trace>
<Trace Tag="EwsResponse" Tid="3" Time="2017-02-19 05:03:34Z" Version="15.00.084
.030">
  <?xml version="1.0" encoding="utf-8"?>
  <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
      <s:Fault>
        <faultcode xmlns:a="http://schemas.microsoft.com/exchange/services/2006
types">a:ErrorInternalServerError</faultcode>
        <faultstring xml:lang="en-US">An internal server error occurred. The op
ration failed.</faultstring>
        <detail>
          <e:ResponseCode xmlns:e="http://schemas.microsoft.com/exchange/servic
s/2006/errors">ErrorInternalServerError</e:ResponseCode>
          <e:Message xmlns:e="http://schemas.microsoft.com/exchange/services/20
6/errors">An internal server error occurred. The operation failed.</e:Message>
        </detail>
      </s:Fault>
    </s:Body>
  </s:Envelope>
</Trace>

I have read in a few places that changing from a Public Folder to a Shared Inbox (or vice versa) might be a potential fix? Any ideas? The error in the trace is simply not helpful.

[davster]

Different issue actually. I pulled your logs and it is a bug on our side. I have a fix that should go in later today. Sorry for the inconvenience.

[donfmorrison]

Thank you, sir. I opened this as a new issue (#107) -- sorry for the dup.

[davster]

Just curious (for my own benefit) - is this call a user accessing their own mailbox or accessing another mailbox that they have rights to?

[Ellistine1]

In my case it was a public folder. It also stopped working for me earlier but then started working again.

Keith

From: David Sterling [mailto:notifications@github.com] Sent: 20 February 2017 16:47 To: OfficeDev/ews-managed-api Cc: Keith Ellis; Mention Subject: Re: [OfficeDev/ews-managed-api] GetAttachment broken (#103)

Just curious (for my own benefit) - is this call a user accessing their own mailbox or accessing another mailbox that they have rights to?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OfficeDev/ews-managed-api/issues/103#issuecomment-281128395, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWiVP5FDNkP8dVJYZz3FuplJeC4_TLcwks5recONgaJpZM4K1W46.

.

Keith Ellis Henry Ling Limited The Dorset Press Dorchester Dorset DT1 1HD

Tel: 01305 251066 Fax: 01305 251908

http://www.henryling.co.uk

Henry Ling Limited is a limited company registered in England and Wales. Registered number: 224715. Registered office: 23 High East Street, Dorchester, Dorset, DT1 1HD

Please note that Henry Ling Limited may monitor email traffic data and also the content of email for the purposes of security and staff training.

This message contains confidential information and is intended only for the intended recipient. If you are not the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify keith@henryling.co.uk immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Keith Ellis therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

[donfmorrison]

It's a service account accessing another inbox it has access to.

[davster]

Thanks @donfmorrison & @Ellistine1 for the confirmation. That is the issue that I am seeing on this side as well (and that my fix is geared toward).

[donfmorrison]

@davster any updates on this fix?

[davster]

Fix was checked in and backported to earlier branches. Per our rollout schedule, we should see saturation in the datacenter by EOD tomorrow (Thurs). I will double check though to see if there are any issues with that.