When a meeting invitee proposes a new meeting time, in outlook this information can be found in the "Scheduling Assistant" (outlook 2007):
Is there any way to access this information programmatically through the EWS API? The RequiredAttendees and OptionalAttendees collections of the Appointment allow me to find out whether and when the attendee has responded, but how can one access the actual proposed new time?
I haven't tried this before but here is how I think you'd go about getting this information. The EWS service and the EWS Managed API don't have this implemented as first class functionality. To be more precise, the propose new time functionality is currently available as first class functionality with Exchange Online. For Exchange Online, you will need to inspect the meeting response message XML for the ProposedStartTime and ProposedEndTime elements. So if you are using Exchange 2007, 2010, and currently 2013, you will need to do what I state in the next paragraph. You should be able to access this information by using extended properties.
An attendee that proposes a new meeting time will always result in the organizer getting a meeting message. When the organizer performs a GetItem request for the meeting message sent by an attendee, the request should request the PR_RECIPIENT_PROPOSED property. A value of true indicates that the recipient proposed a new time. This should trigger a request to get the PR_RECIPIENT_PROPOSEDENDTIME and PR_RECIPIENT_PROPOSEDSTARTTIME property values.
Here is an example of getting this type of property with the EWS Managed API;
Here is a quick property definition:
ExtendedPropertyDefinition PidTagRecipientProposed = new ExtendedPropertyDefinition(0x5FE1, MapiPropertyType.Boolean);
You cannot get this information using the EWS from the Appointment, I'm afraid. It's part of the PR_MESSAGE_RECIPIENTS property, which is a MAPI table (or Object, if you will), and EWS does not support retrieving this. Technically, you could probably get it if you want to build out the ExportItem functionality (a supported function serverside that is not built into the EWS Managed API) and pick through a massive binary stream to find the information, but that's hardly feasible. I haven't tried it myself. The other alternative would be to use something other than EWS to access the data.
Related
Our solution needs to understand Exchange Fast Transfer Stream like the m:data at below for calendar:
<m:ExportItemsResponseMessage ResponseClass="Success">
<m:ResponseCode>NoError</m:ResponseCode>
<m:ItemId Id="AAMkAGYzZjZmRiUsidkC+NAAAAY89GAAA=" ChangeKey="FwAAAA=="/>
<m:Data>
AQAAAAgAAAAAAAAALgBlAHgAdABlAHMAdAAuAG0AaQBjAHIAbwBzAG8AZgB0AC4A
YwBvAG0AAABTAE0AVABQAAAAVQBzAGUAcgAyAEAAYQB1AGoAaQBuAGcALQBkAG8AbQAuAGUA
eAB0AGUAcwB0AC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAAALCE/jlMAAAAVQBzAGUA
cgAyAEAAYQB1AGoAaQBuAGcALQBkAG8AbQAuAGUAeAB0AGUAcwB0AC4AbQBpAGMAcgBvAHMA
bwBmAHQALgBjAG8AbQAAAAMAADkAAAAAAwD+DwYAAAADAARAAwACQAMADkA=
</m:Data>
</m:ExportItemsResponseMessage>
I found out that MS protocol document around this [MS-OXWSBTRF]: Bulk Transfer Web Service Protocol, however it doesn't talk about how to parse the m:Data element. I did base64 decoding on it and it would become partially readable although not all the information though. I also found this link Exchange 2010 EWS ExportItems Data field where a parser was written by Glen Scales although it is not available at CodePlex any more. I also found out outlook redemption could import this into outlook although I didn't see if it could parse it and make it available for our program to use. Plus it would require outlook installation.
Any insights would be highly appreciated.
[Update on Aug 27]. Our goal is to be able to move calendars from other platforms such as google and yahoo into Exchange Online. When we created the appointment for both organizer and attendee via EWS, we are facing some challenges in reestablish the relationship and we are seeing this issue when organizer sends update to attendee.
Basically attendee would see the message "The meeting request was updated after this message was sent. You should open a later update or open the item on the calendar" for both update and cancel message. Any insights here for what MAPI properties to fix would be greatly appreciated as well.
However we are able to move calendars successful with Exchange Web Services export and import via FTS and that is why we are looking for how to generate FTS stream via Outlook Redemption and then use EWS to import those FTS data into Exchange Online side.
However if outlook redemption could allow us to import ics file directly into end user mailbox, that would be even better where we found out that service account needs full access to all mailboxes. From my manual testing, manual importing ics files into both organizer and attendee mailbox are able to re-establish the relationship. Again, it would be really appreciated for any suggestions for above "The meeting request was updated after this message was sent. You should open a later update or open the item on the calendar".
The format is indeed undocumented. It is essentially a list of properties separated by page breaks (to be able to send/receive it in chunks while parsing).
Redemption (I am its author) supports that format through RDOMail.SaveAs / Import; the format type is olFTS.
You can also see the FST data in OutlookSpy (I am also its author) - click GetItem button on the EWS section of the OutlookSpy ribbon, go to the ExportItems tab. To import an FTS stream, click GetFolder | UploadItems.
The add-in I'm working on makes an getItem EWS request using Office.js to get certain fields otherwise unavailable. Mainly recurrence data, the all day flag, and the the body for older Exchange versions.
Depending on the environment the fields are incorrect when composing an appointment. Once the appointment is sent (if it has attendees) or saved (if it does not have attendees) then the fields are correct.
The start date and end date are a year ahead, the subject and body are empty when they shouldn't be, and the item class is always IPM.Appointment or null regardless of whether the it's a recurring appointment. Saving the appointment via Office.js before making the ews request does not make a difference. I even tried making the ews request a few minutes after I saved the appointment.
This seems to occur for some Outlook on the web users, but not for users using the Windows clients. I tried Outlook on the web with an Office 365 account, on-premise 2016, and on-premise 2013. Only the Office 365 account seems to have this issue.
My question is, is there something I can check, like the Exchange Server version, to find out if a user will run into this issue? I want to prevent using incorrect data if possible.
This scenario occurs when calling Office.context.mailbox.item.saveAsync on a new Calendar item that has not been sent yet. We are aware of this issue and are looking into a solution to resolve this so that the API can be used as designed. The API should behave as designed in Mail and on Existing Calendar items. Note that for existing Calendar items, an update may be sent out to attendees depending on the changes that the user or the add-in made in the compose form.
I used Windows 10 email app to connect to my exchange server, i.e. I have instance of UserDataAccount for my exchange server already set up.
I want to write another app that will use this account to talk to Exchange, and I would like to use only WinRT API.
First I need to get Exchange info from UserDataAccount. if it's hosted in cloud, I think I will need URL, tenant ID and username. The problem is that UserDataAccount does not have this info. There is class DeviceAccountConfiguration that seems to have it all, but I cannot find a way to get instance of this class.
Once I can get info about Exchange connection, I can use Office356 REST to talk to Exchange. The reason I want to talk to Exchange directly is because I did not find WinRT API that can use UserDataAccount to retrieve Exchange specific info, for example full info from Exchange about Contact.
So I have UserDataAcccount, and from this data account I need to get credentials and info about Exchange API (EWS, or REST). After that it should be easy, see Adam's answer with link to office356 sample code.
I spent some time poking around WinRT API, but it's poorely documented, and it's hard to discover relationships between different objects, and some methods throw NotImplemented exceptions.
Is WintRT API ready to be used? It looks like a lot of things are disconnected and missing.
Please help!
Thank you
We have sample code for WinRT to access contact.
See:
https://github.com/OfficeDev/O365-Windows-Start
**Contacts**
Get contacts
Create contacts
Update contacts
Delete contacts
Change contact photo
Also we have just plain REST api examples including calling into a test sandbox at https://dev.outlook.com/RestGettingStarted
Is that possible to get a list of room mailboxes available on an Exchange tenant?
I've been searching for a method to get that information and although I found that method by using SOAP I've been unable to find a way to do it using REST.
Thanks for your question! Office 365 REST APIs for Calendar don't yet support this functionality. It is on our roadmap, but the timeframe isn't decided. Can you please tell me a little bit about your scenario?
You can use Exchange Web Services (EWS) SOAP APIs for now to get set of room lists and individual rooms within a room list. See here for more info on using the .NET EWS Managed API or directly make EWS SOAP requests for this scenario.
Let me know if you have any questions or need more info.
Thanks,
Venkat
I'm using Exchange web services, trying to create a calendar entry in another user's mailbox. My account in EWS has rights to do this, and I can successfully use Impersonation to create thes appointment in any mailbox.
However, some examples I've seen of doing this, use an instance of DistinguishedFolderIdType, not impersonation, to set the mailbox for the appointment.
Problem is, this class simply isn't appearing in my installation of the EWS SDK for Visual Studio. It's v1.1, obtained here, but can't be found in Object Explorer. What am I missing?
The type DistinguishedFolderIdType is not part of the EWS Managed API.
If you do not use the EWS Managed API but generate your own SOAP client proxy manually from Visual Studio by adding a reference to the EWS .asmx service, the generated proxy will contain DistinguishedFolderIdType.
However, depending on what you are trying to accomplish, you should be able to do it using the classes provided på EWS Managed API 1.1 and you won't need DistinguishedFolderIdType.