In outlook, the admin can force all users to endure a spell check for each email.
Can Outlook be set to enforce spell check only for emails that are outbound from the company domain, so that "in-house" emails would not be spell-checked, but all emails going out from the domain would be checked?
The setting comes you are seeing probably comes from the standard Outlook group policy which toggles the outlook setting (tools->options->spelling->always check before sending).
Group policies are applied per computer, or per users. Outlook doesn't appear to offer anything in its configuration pages, and there is nothing in the group policy to make that setting depend on the recipient.
I guess, that it may be possible to build some kind of add-on to accomplish this, but the functionality doesn't appear to exist right now.
Related
I would like to automatically put incoming emails which are not from certain domains go to a specific folder in outlook. For example I want any emails that are not from xyz.com and personname#gmail.com to go into a folder outside emails .
I found this link but it is not useful as i dont know the exact domains from where I would get those emails
I have Microsoft office 16
While creating filtering rules, MS Office doesn't provide filtering for NOT conditions. However, this can be achieved by adding exception to the rule. You'll be able to find it after you set the conditions and the actions.
I would suggest to process all messages with an exception of Sender address includes as the domain you want to whitelist (xyz.com). Similarly, you can add more exceptions to this rule.
You can refer to this article.
I have a customer with multiple users, they have two emails accounts on two differents domains.
One is managed by Office365 : Teams / Calendar, example : #my-business.com
Second is for "secure" communication, exemple : #my-secure-email.com
The second one is really not used very often but the emails sent or received must absolutely not go on Office365 (legal reason)
I want to force user to send emails to *.#my-secure-email.com with second account.
With "on-send Feature" i think i can "block" emails but ideally it should be possible to dynamically change the account used in Outlook according to the recipient's address ?
EDIT to clarify :
Is it possible to change sender account with office-js and "on sender" feature on office365 ?
Is it possible to change sender account direclty in Outlook for Windows based on recipient address ?
Thanks
Guldil
Is it possible to change sender account with office-js and "on sender" feature on office365 ?
No, it is not possible. OfficeJS doesn't provide anything for that.
Is it possible to change sender account direclty in Outlook for Windows based on recipient address ?
Yes, you can choose the sender's account in Outlook manually or by using a VSTO add-in instead. The MailItem.SendUsingAccount property is available in the Outlook object model (available for VBA macros and COM based add-ins). The property allows setting an Account object that represents the account under which the MailItem is to be sent.
But web add-ins work under the context of currently selected item only (or in case of UI-less add-ins what they activated for) and don't provide access to application-wide features like choosing email account to send from.
You can post or vote for an existing feature request on Tech Community where they are considered when the Office dev team go through the planning process. Use the github label: Type: product feature request at https://aka.ms/M365dev-suggestions .
I developed an office.js add-in using the ItemSend event. Everything works fine if external service available. But when i was testing send email operation for "unavailable service scenario" get an error like bellow:
"We're sorry, we couldn't access [Add-in Name]. Make sure you have a network connection. If the problem continues, please try again later."
and
"The add-in [Add-in Name] has prevented this item from being sent."
So the question is how to ignore add-in for this situation?
I am testing on web browser.
Thanks.
The group policy Disable send when web extensions can't load must be set to Disable on each applicable machine if you want to let users send emails if the add-in is not available. Read more about that in the Install Outlook add-ins that use on-send section of MSDN.
This is not possible at this time. The Item Send Add-ins are currently meant for mission critical and compliance apps, and if your add-in is not available then mail can not be sent. We are aware of the demand for a "softer" Item Send add-in that will allow for send to occur if your add-in is not available, but we do not have anything to announce at this time.
Note that the Group Policy "Disable send when web extensions can't load" does not affect this scenario, and is actually even stricter. If Outlook cannot retrieve manifests from the Exchange server, then all send will be disabled. That GPO is also meant for deploying compliance Item Send Add-ins and to ensure all your users have the latest manifests that you have uploaded.
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.