Is it possible for an Exchange admin to disable thick client access using Outlook Anywhere to an Exchange 2010 box (or to otherwise achieve that)?
I'm wondering whether that might explain the following symptoms:
I can access Exchange from an iPhone or Android, and also through the Windows 8 native mail app, but Outlook 2013 refuses to connect using Outlook Anywhere.
It is possible to limit Access to a mailbox using EMS:
Set-CASMailbox -Identity "mailbox" -MapiEnabled:$false
Your iPhone, Android and Windows 8 Mail App all are using Exchange ActiveSync protocol.
Please check also, whether your Outlook Provider is correctly configured for your SSL certificate:
Get-OutlookProvider
The Parameter CertPrincipalName should contain a value like msstd:sslcertifcate_cn like msstd:example.com.
Also make sure the Outlook Anywhere Virtual Directory (Get-OutlookAnywhere) is configured with the right settings for Hostnames.
I spent hours trying to figure this out but it ended up being the opposite apparently MAPI is required for outlook anywhere in exchange 2013 sp1 it also disabled for all mailboxes by default. to turn it on you need to use ECP and select recipients then mailbox and then edit the mailbox. Then go ot mailbox features on the left. scroll down to MAPI and if its disabled enable it. That fixed it for me. alternatevely you can run the command Set-CASMailbox -Identity "mailbox" -MapiEnabled:$true
Related
Currently I am developing my custom add-in for outlook 365/
Then I am trying to use it for testing for example it shows me error. I investigated and found what it opens addon in iframe in edge browser. So question is how to add certificate/s to edge to allow my app to work in it?
I am using :
Outlook 365 desktop edition
What I tried
Switching flag in Edge browser to allow not certified certificates to "work"(same thing was done in chrome and it worked there)
As suggested in comments to use office-addin-dev-certs. Well I installed them on my project by using npm install office-addin-dev-certs and then I am trying to verify it by this command office-addin-dev-certs verify it throws error in console see image 3
exported certificates from chrome and imported them in edge browser and also on my machine . It did not helped.
The easy solution that worked for me was remove .office-addin-dev-cer from User folder. Then by running my Add-Ins by npm start I got popped by a message box to remove existing certificates (ca.crt, localhost.crt). After clicking on Yes for 3 messages I have been asked to install new certificates and all certificates re-installed and my Add-Ins works fine now.
While not strictly required in all add-in scenarios, using an HTTPS endpoint for your add-in is strongly recommended. Add-ins that are not SSL-secured (HTTPS) generate unsecure content warnings and errors during use. If you plan to run your add-in in Office on the web or publish your add-in to AppSource, it must be SSL-secured. If your add-in accesses external data and services, it should be SSL-secured to protect data in transit. Self-signed certificates can be used for development and testing, so long as the certificate is trusted on the local machine.
See Server requirements for more information.
This may be an old issue which has resurfaced. You can see more info here
Well I found the solution. solution was to create and add certificate to app. In desktop outlook aka office outlook for desktop it uses Edge browser as sidebar for Add-ins.
Reason is what browsers need Subject Alternative Name in certificate.
So need to create a trusted self-signed SSL cert for localhost (for use with Express/Node) . So the solution was found in this post.
We are working on an Outlook add-in that uses the On-send feature (https://learn.microsoft.com/en-us/outlook/add-ins/outlook-on-send-addins?tabs=unix). We want to know what our options are when it comes to deploying this add-in to actual users, with the focus being on users running Outlook on Mac. Per documentation, On-send Add-ins are not allowed on AppSource. The ideal flow we are looking for is one where there's little to no manual action required on behalf of either the end-users or the Admins.
Is there a way to deploy the add-in automatically on the end-user device (running Mac), with neither any admin-side action required, nor any manual action required by the user -- e.g., by downloading the Add-in manifest, and running a script on the device?
I'm aware user can sideload the manifest once the manifest is downloaded, but this is not acceptable in our case; we are looking for a way where the installation of the add-in is automated, without requiring any manual action on behalf of the user.
If the above is not an option, what is the recommended way to deploy the add-in? I found two links from MS, with possibly conflicting info; which of these two is the right one to try?
The first one is "Publish Office Add-ins using Centralized Deployment via the Office 365 admin center" from https://learn.microsoft.com/en-us/office/dev/add-ins/publish/centralized-deployment#end-user-experience-with-add-ins. Looks like this is supposed to be done from the O365 Admin Console --> Settings > Services & add-ins.
This approach requires (from https://learn.microsoft.com/en-us/office365/admin/manage/centralized-deployment-of-add-ins?view=o365-worldwide) the following as pre-requisites; are all of them actually required?
"have Exchange Online and active Exchange Online mailboxes" -- is there a difference between "Exchange Online" and "active Exchange Online mailboxes"?
"Version 1701 or later of Office 365 ProPlus." -- does this apply for Mac as well? If so, is there such a version for Mac?
"Your subscription'd directory must either be in, or federated to Azure Active Directory."
Looks like there's a Powershell-based alternative to this: https://learn.microsoft.com/en-us/office365/enterprise/use-the-centralized-deployment-powershell-cmdlets-to-manage-add-ins. Is this subject to the same requirements as the above?
The second flow, which is more geared towards Outlook (rather than the other Office apps) is https://learn.microsoft.com/en-gb/exchange/clients-and-mobile-in-exchange-online/add-ins-for-outlook/specify-who-can-install-and-manage-add-ins?redirectedfrom=MSDN. This is to be initiated from Exchange admin center under Organization > Add-ins > New Add Icon
Does this work with a non-ProPlus O365 subscription as well?
Does this work outside of Azure AD?
(Assuming Bullet 1. is not an option so we have to go with 2.) After deploying add-in from admin, is further action required to activate it on the end-user device?
Per https://learn.microsoft.com/en-us/office/dev/add-ins/publish/centralized-deployment#end-user-experience-with-add-ins:"For Outlook 2016 or later, users can do the following: In Outlook, choose Home > Store. Choose the Admin-managed item under the add-in tab. Choose the add-in, and then choose Add."
(Again assuming Bullet 1. is not an option so we have to go with 2.) Is there API support to help automate bullets 2 and 3?
I am working on outlook addin. But to add addin to outlook I need to see store icon. See image 1.
but when I switch to exchange mail server inbox i start seeing store icon. See image 2.
I am using outlook for mac 16.16.4. please let me know if this is mandatory requirement or I am doing something wrong.
Store functionality is only available for Exchange accounts, just the way Outlook works. Keep in mind that installed web addins are account based, so for multiple Exchange accounts you will have different addins, and for non-Exchange account you will have none.
I'm working on an Outlook addin using the new Office-JS apis, and in building out the authentication flow, I've found that in the Outlook 2016 for Mac case, the dialog system seems to not work properly.
To be clear, we're using the Office Insider Fast Track build as it has much improved support for the Office-JS API.
I've been through several iterations of this particular piece (most of which worked fine both in the Windows client and the web client on Mac and Win), and have had no luck. The scenario is:
List item
Open up the task pane in outlook.
Hit the sign in button
A new window opens, pointed at our authentication portal
User signs in.
On auth completion, the window redirects to a page in the office add-in scope, and calls back to the parent frame with the auth token, where it can be further processed.
Steps 1 through 5 work fine on all platforms. Step 6 refuses to work on Outlook for Mac. Initially, this flow was built using the native js window.open and window.postMessage apis. As mentioned above, this worked everywhere but Outlook Mac, where, the API seemed to ignore the window options and just open the url in a new tab in whatever browser was open and never setting the child window reference (result of window.open being null).
Failing this, I followed the advice found here on SO to use the Office functionality, displayDialogAsync and messageParent. After some initial hurdles, this too was setup and working on every platform save Outlook Mac.
As there is no dev tools or JS console support in Mac Outlook, I followed the advice found here Howto: Outlook 2016 for Mac - Debugging/View Console Logs in Outlook Add-in and setup Vorlon to attempt to get some context, adding numerous logging points to try and get some context. Unfortunately, while Vorlon does pick up my auth landing page as a client, and sees the Office interfaces, none of my console outputs are presented, making it seem as though the JS isn't running at all.
At this point I'm not sure what to try next. Has anyone run into this issue, or gotten this to work on the Outlook 2016 for Mac client?
Clarifying context:
All auth pages are listed in the AppDomains section of the Manifest.
While initial versions pointed directly at our auth service (this worked on not Mac), the current version first opens up an in scope pre-auth page that redirects to the auth service.
The Office-JS api's block alerts, preventing their use in displaying useful information.
Authentication through all versions of this app have worked on both Outlook 2016 on Windows and OWA on both Win and Mac.
Thank you.
This issue in Outlook Mac has been fixed a few months ago. If anyone still encounters this issue with a recent Outlook Mac build, please reply with the build number.
The Office.context.ui is undefined in v16.17 (180909) build of Outlook for Mac 2016 using the following OfficeJS dist:
https://appsforoffice.microsoft.com/lib/1/hosted/office.js
I am building apps with the new technology of Office add-ins (formerly app for Office).
The add-ins activate well when registered globally for the Office 365 tenant or individually by user (mechanical gear > manage add-ins).
I would like my add-in to work with Office365's shared mailboxes. The add-ins do not load in Outlook desktop or in OWA when the shared mailbox is open alone.
However, I managed to make it work when setting the shared mailbox as a shared folder displayed under my primary mailbox, as explained here (see picture below). It is better than nothing but not an acceptable solution, I would like my add-ins to be displayed when consulting my mailbox in Desktop client and in OWA when using the "Open another mailbox" (see link above).
My question is then: how to make add-ins working with shared mailboxes? A possible solution is: a shared mailbox seems to be related with a special kind of user. Would it be possible to install the add-in for this special user in order to have the add-ins always working with shared mailboxes?
Edited:
Not supported for now. I created a feature request in Office365 User Voice. Consider bringing your vote to it.
There is a new feature request to cover this functionality.
This feature request has theoretically been implemented and is in public preview.
Theoretically if you add the following under <DesktopFormFactor> it enables this feature:
<SupportsSharedFolders>true</SupportsSharedFolders>
However, people are having issues with this throwing Schema errors. See GitHub or StackOverflow. (NOTE: StackOverflow has a solution, but I didn't find it actually worked).
It maybe there is some undocumented magic so it could work now.
Outlook add-ins are not supposed to activate outside of your primary mailbox. This is intentionally disabled. What you're seeing with it displaying when opened under your primary mailbox there Benoit is likely a bug.
The office add-in can be configured to show on a mail item. it does not matter the type of mailbox, if the item you are viewing is a mail message, your add-in should show.
The simple test you can do, does your add-in show in your mailbox mail messages? if yes, this means it should show in mail messages from the shared mailbox. It is divide and conquer issue we need to resolve.
Let me know if you have more questions or need clarifications.