I'm trying to move messages between folders in an Exchange Online account (which is Office 365 without Office).
This can (and does, based on my observations) cause message ItemId values to change.
According to the documentation for MoveItem, there is a XML tag, ReturnNewItemIds that aks for the new ItemId values to be returned:
http://msdn.microsoft.com/en-us/library/exchange/aa564512(v=exchg.150).aspx
This tag is documented as supported by Exchange Online:
http://msdn.microsoft.com/en-us/library/exchange/ff709497(v=exchg.150).aspx
When I include this tag in my request, the server always returns HTTP status code 500, Internal Server Error (this as I've seen means that it didn't like the request).
Removing the ReturnNewItemIds tag makes the operation succeed, but of course I don't get the new ItemId values.
This is a sample request:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<soap:Body>
<MoveItem
xmlns="http://schemas.microsoft.com/exchange/services/2006/messages">
<ToFolderId>
<t:FolderId Id="...[snip]...AAUBzh5AAA="/>
</ToFolderId>
<ItemIds>
<t:ItemId Id="...[snip]...da2BGjjDAAAUBziGAAA=" />
</ItemIds>
<ReturnNewItemIds>true</ReturnNewItemIds>
</MoveItem>
</soap:Body>
</soap:Envelope>
I've tried different ways to specify ReturnNewItemIds, capital True, just including the tag... makes no difference. Pretty sure the way shown above is correct, though - it's what's documented and it also passes XML schema validation.
There are various ways I can work around this issue to get the new ItemId values, but they require additional EWS operations, which is time and traffic consuming.
Has anyone ran into this?
Is this maybe an Exchange Online specific issue? Perhaps the documentation is wrong about ExchangeOnline support?
Or am I missing something and there a way to get ReturnNewItemIds to do its thing?
My test environment is wget with XML files containing the requests and a shell script that sets proper HTTP options. No issues with any other EWS requests that I've needed to execute.