I am creating an appointment in Exchange via WebDAV, but the UId created is not the same as if I create the appointment in Outlook. The UId I believe is the same as the GlobalObjectId and should be unique and not change.
The UId if created via WebDAV is:
CD0000008B9511D182D800C04FB1625DDD67374428B4C644A0A359A2586E30B3
The UId if created through Outlook is:
040000008200E00074C5B7101A82E008000000002005332BA3A8CA01000000000000000010000000DD67374428B4C644A0A359A2586E30B3
If I open the appointment created via WebDAV in Outlook and then save it again the UId changes which is annoying (The UId changes to one above beginning with 04).
The second half of the UIds are the same GUID {DD673744-28B4-C644-A0A3-59A2586E30B3} and never change. The document here http://msdn.microsoft.com/en-us/library/cc425490 (EXCHG.80).aspx explains how the GlobalObjectId is constructed. Outlook seems to follow these rules, but Exchange doesn't. I am using Outlook 2007 and Exchange 2007.
There seems to be a myriad of different ids that can be used to identify appointments and I'm just looking for one that stays the same so I can track the appointment over time.
If anyone can help to explain why this UId changes or a way of creating it so it doesn't change it would be much appreciated. My limitations are supporting Exchange 2003 SP2 and Outlook 2003.
Oh yes Id can change, it can depend on the client and the way that you access the items. It a right PITA
I think the link may should help you though , (not knowing excatly what you are doing).
There are mapi proerties that you can use as well but you may have to explain what you are doing a bit more ... are you only doing WebDav ?
How to use WebDav to match dav:href to Outolook Interop href value
Related
Short Version:
I want to open any specific Outlook email from my Java app, either locally through the Outlook app or through the website on a browser. I already have the email information like folder, message ID, UID, sender, receiver, etc but not the email ID used in the URL of the Outlook website. Does anyone know of a way to do either of these things through Java?
Long Version:
I'm creating a software for my company in Java that has a built-in email client for Outlook emails so the emails can be linked with jobs in various ways. So far I've been able to make good progress with the email client section in terms of displaying a list of emails and being able to display a chosen email, but recently I've realized creating a GUI for an email editor (keeping track of reply chains, dragging in images for inline attachments, etc) is quite the gargantuan task to do on my own(JavaFX's HTML Editor could use a lot of work).
My band-aid solution for now is to have my program open the chosen email up through either:
Some (Windows 10) system command by calling the Outlook desktop application to show the email by some sort of ID (maybe UID?). I know on some level that this is possible because our company has an old program written in C# that can indeed do that.
Opening up the system's default browser with a link to "https://outlook.office365.com/mail/folder_name/id/insert_id_here". This is my preferred solution.
Here are my problems with each option so far:
There doesn't seem to be any resource I could find that provides an answer to this. The closest I can find are threads that explain how to open the default mail application with options to pre-populate to/from/subject/body sections (not to mention you can't pre-populate the body with anything besides text! So much for reply/forward messages with HTML formatting and attachments!). Another problem is that the old program I mentioned displays emails by finding the Outlook application's files (presumably the local OST file). I have no idea how the old program's able to call Outlook to show emails and even then, there's a chance that there's no Java equivalent. I, however, am using JavaMail to load up my mail, as I think it's better to talk to the Outlook mail server to fetch/push mail updates rather than wait for the Outlook app to sync up. This creates a problem because even if I knew how to call Outlook, my application may be more up to date than the Outlook app (especially if Outlook is not already open) and if call before Outlook updates, Outlook wouldn't be able to show it.
Again, I can't seem to find a resource for explaining these URL IDs. They're not the same as the mail's UIDs, and they don't seem to be anywhere in the mail's contents when grabbing mail through JavaMail. The most I was able to get from research was that they were called "long IDs", as they were just long strings (seemingly non-sequential) but that might've just been a made-up name from the article as I've found no other references to it. There's a chance that they could be some sort of encoded UID but I didn't see any note of JavaMail having to decrypt to get UIDs in the documentation. I doubt I'd be able to make any more progress with this option, but if there's a solution similar to this (perhaps some sort of script that opens up Outlook online, searches by some identifier, like body contents, and pulls up the first result? Idk much about browser scripts) I'd be happy to hear it.
Note: This particular issue has significant impact on our customers, which translates to high business impact with direct consequences on revenue.
TL;DR.
How can our Office add-in for Outlook, when a user interacts with our add-in while composing an email draft, minimize the amount of time it takes before the EWS GetItem API will return an OK response for the itemId we receive from Office.context.mailbox.item.saveAsync()?
If it turns out that our add-in has no control over when the item will be persisted to EWS, then what could an end-user do to speed this up?
We are looking for either (a) a technical solution, or (b) messaging to instruct our customers on how to mitigate/fix/work around this issue.
End-User Impact
Some of our customers are unable to send emails using our Office add-in for Outlook, or have to wait an exceedingly long time (> 2 minutes) before their email will send.
Our Goal
We want all of our customers to be able to send emails using our add-in, without having to wait for an unreasonable amount of time.
Additional Context
Based on our logs and customer reports, this issue only exists in the Outlook 2016 for Windows desktop application. We have no evidence to suggest the issue is present in any other version of Outlook, including Outlook 2013 or Outlook for Mac, however it is possible that the issue may be present in those clients as well.
Overview of our add-in
Our add-in integrates with Compose mode to provide additional functionality while composing email messages, such as templates, follow-ups, open and click tracking, and scheduling.
Our add-in works in tandem with our SaaS product like this:
Our add-in sets EWS extended properties on the email message with metadata indicating which features are enabled on that message.
Our SaaS product, out of band, is configured to read from the customer's mailbox via the EWS API. When it encounters EWS extended properties our Office add-in has written, it triggers the code paths to satisfy the desired behavior.
Root Cause Analysis
The root cause of our problem is our interaction with EWS in Outlook 2016 for Windows. In order to successfully interact with EWS to read/write to a mailbox item, it must be aware of that item.
The documentation for Office.context.mailbox.item.saveAsync() says:
In Outlook Web App or Outlook in online mode, the item is saved to the server. In Outlook in cached mode, the item is saved to the local cache.
It goes on further to say:
Note: If your add-in calls saveAsync on an item in compose mode in order to get an itemId to use with EWS or the REST API, be aware that when Outlook is in cached mode, it may take some time before the item is actually synced to the server. Until the item is synced, using the itemId will return an error.
Thus, we have concluded that Office.context.mailbox.item.saveAsync(), although it does indeed return an eventually valid itemId, does not guarantee that any subsequent EWS interaction will succeed. So far, we have found no way to accelerate the process of the Outlook client actually making EWS aware of the mailbox item.
Mitigation
We have attempted to mitigate this problem by polling EWS GetItem to attempt to obtain a ChangeKey for the item with the itemId we receive from Office.context.mailbox.item.saveAsync(). While we have seen that this does eventually succeed, it may take a minute or longer before this occurs. That is simply far too much time for our customers to have to wait.
Understanding "online mode" vs "cached mode"
If the Outlook 2016 for Windows desktop client is in "cached mode", is there anything the user can do to:
…know whether the client is in "cached mode" or "online mode"?
…attempt to force the client into "online mode"?
There is no way to speed this up in cached mode. Unfortunately this is a limitation of saveAsync in compose mode. Some things of note:
1) The EWSId is only valid while the item is a draft. After it is sent, when the item is in sent items, it will have a new EWSId which is not obtainable from the Office.js
2) Could you save your information into the custom properties, instead of the EWS Extended Properties. (Office.context.mailbox.item.customProperties) https://dev.office.com/reference/add-ins/outlook/1.5/CustomProperties?product=outlook
These properties will be saved to the mail in the sent item, but will NOT be transmitted. Then could you find those properties
These are stored as a JSON dictionary on the item in Key/Value pairs. The name of the mapi property is "cecp-[extension id from manifest]" (in PS_PUBLIC_STRINGS)
https://msdn.microsoft.com/en-us/library/office/cc842512.aspx
3) It does kind of sound like a better way to solve this would be an Office.js function that gives write access to this? (though we don't completely understand your scenario). Request for new features should go through UserVoice:
https://officespdev.uservoice.com/forums/224641-general/category/131778-outlook-add-ins.
4) Being in Online Mode would greatly mitigate the time. A User can know whether or not he or she is in online mode, but an Add-in cannot.
https://support.office.com/en-us/article/Turn-on-Cached-Exchange-Mode-7885af08-9a60-4ec3-850a-e221c1ed0c1c
Additionally, the status bar will say "Connected to Microsoft Exchange" in cached mode, and "Online with Microsoft Exchange" in online mode.
Switching to Online mode, removes a lot of the benefits that cached mode has. Cached mode is default in Outlook 2016.
Is it possible to create a meeting or appointment on someone else's Exchange 2010 account, without them needing to accept the meeting? Ideally, we want to have a delegate account, or similar strategy, to place appointments/meetings onto people's calendars. We want to bypass the normal request/accept model, and force these meetings into the calendar.
I looked at CreateItem() in the Exchange 2010 documentation, but it is unclear as to what happens once the method is executed. Does the user receive a normal invitation? We don't want that. We want a model where our system has full control over the users' calendars, without them receiving a traditional meeting invitation, and with automatic acceptance. I would prefer not to have to use VBA hacks or plugins, also.
I think it's possible in case of usage ApplicationImpersonation (the usage of ImpersonatedUserId). It 's important that you have to configure the Exchange first. Then you can set NetworkCredential use ImpersonatedUserId to direct access to the destination calender. See here for more information and the code example.
What I would do is grab a copy of MFCMapi (mfcmapi.codeplex.com), and then create a meeting request in a traditional way and send it to a couple mailboxes. Accept it in a couple, mark tentative in a couple, etc.
Take a look at the resultant calendar item created in the invitee mailbox. I expect you should be able to create the appointment and then set the necesary MAPI properties to make it appear as accepted. You can set the arbitrary properties with EWS, it's just going to take a bit of digging to figure out which ones to set. MFC Mapi is a good tool for that.
On the organizer side, you'll need to make some tweaks so it looks like everyone accepted.
I'm wondering if there is any way to be able to include an arbitrary email address as the To:, From:, CC: or BCC: fields of a send email activity? It appears that they must be contacts in the CRM.
I ask this because I have a requirement to cc a known group email (no actual user associated with the email...something like support#mycompany.com...though it's not a queue at all). I'm concerned that if I create a CRM user for this email, that when I move to production, I'll have to change all the workflows using this email to point to the CRM entity on the production box (assuming GUID is saved with activity).
If an arbitrary email isn't possible, any other suggestions?
I'm not quite sure, if I have unterstood your question right:
You want to create a workflow which contains a send mail activity. You would like to set one of the address fields (To:, From:, CC:) to a plain mail address like 'foo#bar.org'?
It is possible if
you enter the mail address by hand (do not use the field assistant)
you have configured that e-mails with unresolved recipients are allowed to be sent.
See Settings -> Administration -> System Settings -> E-Mail Tab
you don't want to set the e-mail address with another workflow step
To my knowledge, the only way to do this would be to create a custom workflow assembly. This may be more trouble to you than it's worth.
I doubt it. Not without horrible SDK or Custom Workflow Activity machinations, which even then may not work. Unless you have a truly gargantuan number of workflows that must be altered, the manual approach may be the best.
It may be a terrible hack, but you might be able to replace instances of the development environment support account GUID with its production counterpart directly in SQL Server. Not in the SystemUserBase table, but in whatever workflow activities mention the support account as a CC field in an e-mail. But that is scary stuff.
You may also want to take another look at your process; a significant portion of Dynamics CRM is dedicated to handling support issues, and that includes fairly robust e-mail tracking and storage; there probably shouldn't be a need to CC this support mailbox to which you refer.
In summary: All of the options I've listed are terrible. Find a way to avoid them. :-P
I've had this requirement before, and even with workflow activities, there doesn't seem to be a way to handle this (even though CRM will allow it through the UI).
Your instinct is right that if you create a user separately in both environments and then try to move a workflow that references that user between the environments, that the workflow references will have to be updated.
The best solution, to me, would be to go with just creating the contact/user in one environment. But then, create the contact/user in your other environments with the same Guid. You can do this through the API quite easily, or for a no-code solution, there is a Microsoft provided CRM Configuration Data Utility (http://msdn.microsoft.com/en-us/library/dd442453.aspx) that you can use. (Note that the utility will want to migrate all records from the chosen entity, so you might want to export it to a file, edit the resulting file which is just XML, and then import to your target).
This is something that you can do with CRM 2011, CRM 2013, or CRM 2015 if you have a custom entity that is email enabled and then copy the email address from your core entity even if that email address is in a custom text field to it and relate it back via a lookup field. Doing that would require a plugin in Microsoft CRM 2011, but is possible to do with real-time workflows in Microsoft CRM 2013 and Microsoft CRM 2015. This method would allow you to have email addresses associated to the records and available for usage with the CRM workflows to send emails without needing to create an additional user or contact record. This is also handy if you are working with an entity like Incidents that is a core CRM entity and is not email enabled, yet you wish to be able to send emails related to that entity. You could use this method in conjunction with the steps ccellar provided.
I've got a blog post that goes through an example of this here: http://dynamicsuniversity.com/steps-to-send-emails-to-custom-email-address-text-field-from-a-workflow/
You can write custom workflow or you should go for plugin development.
You will get details for it on below blogs.
For custom-workflow
https://msdn.microsoft.com/en-us/library/gg334455.aspx
Blog:-
https://lakshmanindian.wordpress.com/2012/10/14/custom-workflow-activity-in-microsoft-dynamics-crm-2011/
more knowledge on your email sending requirement.
https://social.microsoft.com/Forums/en-US/375f5dad-0382-4112-ab0d-5b42ba235d96/crm-2011-workflow-sending-email-problem?forum=crmdevelopment
We are constructing an application that will be interacting with Exchange 2007 calendar functions. We will be using the Outlook Redemption Objects dll’s. Our design relies upon the outlook 2007 meeting Category features. We would like to ensure that specific mailboxes have a standard set of category names and colors.
We can’t rely on users to set these up. We also can’t rely on users running the exchange client, many users will be on MAC’s and will be using OWA to manage their calendar.
As I understand it the master category list is stored in each users mailbox in an hidden message in a property named IPM.Configuration.CategoryList. I haven’t found any reference on how to set this yet.
The only things that I have found to help us are:
Group policy objects: http://technet.microsoft.com/en-us/library/cc179073.aspx As I understand this, it won’t manage the color’s and relies upon the exchange client.
A third party tool - http://www.vboffice.net/product.html?id=2006063&cmd=detail&lang=en&pub=6 The enterprise edition appears to do what we want but is expensive for a once per mailbox operation on 100 or so mailboxes.
Basically, our preferred solution is to be able to produce a script that accepts a mailbox name and sets up a standard master category list.
we were able to accomplish our task using the code at http://gsexdev.blogspot.com/2007/08/adding-categories-to-master-categories.html
AFAIK, the categories for mail box items are stored in local outlook profile and not on the exchange server.Before Ol 2K7, these were stored in registry so I doubt if category master list can be set on E2K7.