We have a VSTO add-in for Outlook, that supports booking of resources managed by our cloud system.
In addition we support resources that are also available in Exchange as rooms to support integration with other systems.
When we perform a booking of such a room, the add-in adds the corresponding Exchange email address for the room to recipients, so it will also be booked in Exchange.
This used to work fine, but now we have received a report from a customer that they can no longer create bookings for resources with Exchange integration. The error they receive is completely unhelpful:
System.ArgumentException: Der gik desværre noget galt. Du kan prøve igen.
ved Microsoft.Office.Interop.Outlook._AppointmentItem.Save()
(in English: "Something went wrong. You can try again")
This happens when add-in attempts to save the item after adding some custom properties. I think the error is triggered by the add-in adding the Exchange rooms to recipients, since it does not happen for resources without Exchange integration.
Here is the code we use to add recipients:
var rec = ...; // custom DTO with recipient info
string recipientInfo = string.IsNullOrEmpty(rec.Email)
? rec.OutlookName
: rec.Email;
var recRecip = appointment.Recipients.Add(recipientInfo);
recRecip.Type = rec.RecipientType;
if (Current.Settings.IsEnabled(FeatureFlag.ResolveAddedRecipients))
{
using (LogHelper.TimedTask($"resolving recipient [{rec}]", Log))
{
recRecip.Resolve();
}
}
I can see from the logs, that the room recipient has email address, so above code will add by email. Also, the feature flag to resolve recipients is enabled, so the code will call resolve afterwards.
What could be going wrong here?
EDIT: Their Outlook version is 16.0.0.5071.
If the problem is isolated to the user's computer, we always recommend our IT staff to share the O365 Outlook Diagnostics Tool which analyses the outlook install, data files, plugins, cache and performs checks to identify source of issues on client computers.
Related
I'm working on an Outlook Add-in, using office.js, where users can send secure emails using backend service.
In compose mode, when the user sends the email, using the add-in of course, the add-in will then move the message to "Sent Items" folder using the Outlook API /message/{id}/move and everything goes OK with the exception that the message in question still being marked as "Draft" by Outlook which is really annoying and does confuse the user who just sent the email by telling him that "this message hasn't been sent"
I searched through the API to see if there is a way to mark an email as "SENT" in order to prevent Outlook from showing this RED hint but with no luck so far!
So, My Question Is: Is there any way to overcome this misleading msg by marking the email as it was sent by Outlook?
Thanks in advance.
Finally, I was able to achieve a perfect solution for this challenge.
Based on:
#BrianClink's comment
This answer (Which uses Graph API but Outlook REST API): Microsoft Graph API mail office 365: Is any option create inbox message NOT as Draft?
The approach/steps I followed to mark a mailItem as "SENT" (and not shown as 'draft') and put it in "SentItems" Folder are as follow:
First, Save the mailItem as "draft" using Office.context.mailbox.item.currentMail.saveAsync then retrieve its ID
Clone this draft mailItem properties eg: 'Sender', 'Subject', 'Body', 'ToRecipients'..etc so you get an exact copy of it.
With the newly cloned mailItem, add '[SingleValueExtendedProperties]' property with this value :
[
{
PropertyId: 'Integer 0x0E07',
Value: '1'
}
];
Serialize the new item as JSON and POST it to "sentitems" folder as follows:
xhr.open('POST', restHost + '/v2.0/me/MailFolders/sentitems/messages/');
xhr.send(clonedEmailJson);
On success, with xhr.status=201 [created], Remove the draft mailitem using a [DELETE] request
And you will end up having a new mail item created in your "sentItems" folder which appears as it was sent by Outlook :)
This was a very helpful solution to me because my users are using my add-in to send secure emails (using 3rd party API) and NOT Outlook, So, I wanted them to have the same UX/feeling as when they use Outlook.
Note:
Although the solution worked for me perfectly, it came with a price!
On slow internet connections or in case emails containing large attachments, the process can be remarkably slow, because the addin will first save the draft to the remote Exchange Server, get its ID, then duplicate it and send it again to the server, then remove the draft-ed one.
Found a very similar question here: Email aliases not returned as "To" address in logic app
TLDR: From within a logic app "When a new email arrives" trigger, How do I get the original alias that the email was sent to?
I have a logic app that creates a ticket based off an email sent to an outlook box. Now I want to be able to choose aspects of the ticket based off of whether or not the email was sent to the mailbox itself or an alias of the mailbox. The problem I'm having is that by the time logic apps gets a hold of the email, the alias address has already been replaced with the actual box's address ("alias1#place.com" -> "actualbox#place.com").
The actual mail in the inbox has the original email's alias information in the headers, but I can only get them by looking at the properties in outlook. I've tried to get the original "To" internetheader information both within logic apps (by exporting the email to blob storage and looking at headers there) and with the Microsoft Graph API. Sadly, the email exported by logic apps doesn't have the alias information and Graph API has pretty much every header but "To". At least one other person has lamented the lack of To
That said, the actual email still has the original alias information. Can someone help me get that information in logic apps without jumping through too many hoops? A many hoop solution is welcome if none other can be found though.
Use the Export email (V2) action from the Office 365 Outlook connector. This will give you the full message with original headers (including the actual To address)!
The flow here is, trigger on the incoming email, as you already are, then add the export email action providing the message id from that trigger to pull this specific email.
From there, you you'll have one big "body" property which you'll need to interrogate to find the To address.
Caveat on this though, it doesn't work when emails are sent between mailboxes in the same Office 365 tenant. Exchange Online will "helpfully" go, "I know that address... this is the address you wanted!"
What API are you using? In Outlook Object Model / MAPI / EWS, you need to retrieve the PR_TRANSPORT_MESSAGE_HEADERS MAPI property (DASL name http://schemas.microsoft.com/mapi/proptag/0x007D001F)
We arrived at a many hoop solution.
The "Primary" email box now has some rules that look at the internet headers mentioned above (Message -> Properties -> look for 'To:').
If it finds an alias there, it will put the email in a corresponding folder for each alias.
Then we have logic apps listening to each of the alias folders which will then send the email's information to the _Core logic app that does the actual processing.
We have server-side synchronisation set up for our Dynamics 2016 on-premise instance, and it is correctly sending emails from a Case, and tracking replies from the customer. However, when an internal user replies using Outlook (without the CRM add in), their responses aren't being tracked. This means that the email conversation consists of an initial "outgoing" email, followed by only incoming responses.
The full scenario is:
Internal user sends an email from a CRM Case. Email tracked in CRM
Customer replies to email. Reply tracked in CRM and goes to internal user's Outlook
Internal user sends a reply from their Outlook. Reply is not tracked in CRM
Customer replies to email. Reply tracked in CRM and goes to internal user's Outlook
Is it possible to allow the Internal user's replies (point 3) to be tracked in CRM without installing the Outlook add in (i.e. so it also works from the Web/mobile versions of Outlook)?
I believe you cannot do this without Outlook client as per Jukka.
Without the CRM Outlook client you can’t get the information into CRM without copy-pasting it from one window to another in the aforementioned scenarios. No synchronization technology will help you here, since CRM is unaware of the item until it has been brought into its world. The “Track” button is a client-side feature that you can’t utilize with any server-side solution, which means there’s no way for a user to select an email, appointment, task or contact from the Exchange server that he or she would like to promote into a record in CRM. Since the the record wasn’t “born in CRM”, it just can’t find its way there.
Last resort would be Smart matching with Tracking token, which may help you in this scenario.
Update:
Customer reply is going to reach CRM through a monitored queue. You can read a lot & get clarity from the above link.
Deploying a solution like the CRM 2013 the server-side synchronization will take care of moving items like calendar appointments and contacts back and forth between the end-user client device and the central CRM database, but it only applies to items that already exist in the realm of CRM. What I mean by this is that the item was either originally created directly in the CRM application or it was received via a monitored location like an email queue.
Your expectation is right, it should be tracked. I would open a ticket with MS & solve this.
Once the item is in CRM, server-side sync can take care of tracking the subsequent updates to it. A re-scheduled tracked appointment will get updated with the new date, regardless of whether you change the date via CRM or your mobile phone calendar that’s linked to Exchange. An email thread with a tracked message and a tracking token ID injected into the email subject line will have the next replies automatically synchronized into CRM
I have heard back from our Microsoft Partner, and they say that this scenario isn't possible. By design, it'll only track incoming emails to CRM, or outgoing if sent from within CRM itself.
I'm working on an Outlook 2010 add-in that needs to prompt users before following a link found in an email. During the process I'd like to offer the user the choice to trust or block the sender of the email, thus I need to access both lists. I realize that Junk/Spam email options are not exposed by Outlook OM. Although I was successful in accomplishing the task using Redemption, unfortunately I'm not allowed to use it by my employer, so I need to find another way. I found this post (Get Safe sender list in Outlook 2007 C# Add in) that points in the direction of either MAPI properties or registry keys.
My preference would be MAPI props, but I'm not sure what object that property belongs to. Would it be the property of the default store?
Outlook.Store obj = Application.Session.DefaultStore;
const string PR_SPAM_TRUSTED_SENDERS_W =
"http://schemas.microsoft.com/mapi/proptag/0x001f0418";
Outlook.PropertyAccessor pa = obj.PropertyAccessor;
string list= pa.GetProperty(PR_SPAM_TRUSTED_SENDERS_W).ToString();
Unfortunately I'm getting an error message (translated to English) like 'Object doesn't have such property'. In production it would have to work with Outlook clients connected to Exchange 2007 mailboxes.
Ok found it. The actual property is called PidTagExtendedRuleMessageCondition and the Blob format is described here MS-OXCSPAM and in MS-OXORULE respectively.
I belong to a email group in the company I work for, such as for example, researchteam#company.com. My personal email is raulmercado#company.com. I want to send emails from researchteam#company.com instead of raulmercado#company.com. I'm using Microsoft Outlook and Exchange as a Email Server.
Thanks for your help!
If you using Outlook 2010 then you could try MailItem.SendUsingAccount property.
Here is an example
Exchange always sends out all emails coming from the default email address. And for each Exchange mailbox this default address is fixed and can not be changed in Outlook. You can use one of two options:
You can create an additional mailbox in Exchange for the second address (as the default email there of course) and then give your normal account "Send-As" rights for that new account. Then you can switch on the "FROM" field in Outlook (right-click options > Show Fields > From) and use that field to select the account you want to send from. In Outlook 2013 you can also just connect to the additional Exchange account and might get slighly easier switching.
You can use a 3rd party tool like ChangeSender (http://www.servolutions.com/changesender.htm) to get automatic switching of the accounts when you answer email (answered automatically with the account the email was received under).
Hope this helps - Claus