If you have been developing OfficeJS add-ins for Outlook Online (or Exchange 2016 Outlook Web Access) you might not know that you now have the ability to create OnSend add-ins. That is add-ins that can trap the send of an email, test for conditions (such as getBodyAsync() or getSubjectAsync() to look for content) and if they fail, prevent the message from being sent. I recently blogged about it here:
First thing to note about these add-ins is that they cannot be created for or uploaded into the store. The second thing to note is that they MUST be configured first in order to run. The third thing to note is that if you are building an on-prem Exchange based solution, you have to have Exchange 2016 CU6 installed and a bit more. The full details of how to configure the environments (either Office Online or On-prem) are detailed here:
If you look this over, there is quite a lot to do. How would you like one single PowerShell command to type? Maybe something like this:
[code type=”powershell”]
Set-OwaOnSendPolicy
[/code]
Well, I just published the first version of this script on GitHub:
All the details you need to know about it are there in the README.MD. However, if you have any questions or issues, please let me know.
I have developed and tested an On-Send Outlook Addin using Visual Studio to debug, and tested in Outlook and OWA. Now it is finished, I am confused how to organise/package the manifest and web files to my IT Manager so they can install it on the server. I would be very grateful of you could point me to some instructions! Thanks, John.
If you used VSCode and the default Yeoman template, compile/webpack the add-in into a dist folder by typing (npm run build). Then send the contents of the DIST folder to your admin. For a full Visual Studio add-in, you would need to run the PUBLISH option from the Build menu. This will create a PUBLISH folder which you will give to you admin.
Now, it sounds like you might not know the name of the server you will be publishing these to. So, you will need to supply the admin with instructions to modify your manifest as well. For example, you manifest might have the path https://localhost:5431/content/taskpane.html (or similar) … You will need to have them change that to the server, so if they place it on “CORPSERVER”, you would have them change it to the full path where it is stored: https://corpserver.corp.com/john/addin/content/taskpane.html… as an example. If you DO know the name of the server and the folder where they will place the add-in, you can edit the manifest yourself and send it to them. But this is a bit of an iterative process I have found in that IT folks are not at all certain what you are doing or why and how to get things deployed correctly. So, expect some back and forth to get it right.
Finally, the manifest file will need to be installed by the admin in the Office 365 control panel. There are a lot of articles on the web about this, they would just follow that process and assign the users that needs access to your add-in.
That makes a lot of sense. I have used ~remoteAppUrl for my location in testing, but I didn’t know this will have to be changed, so I will specify this when I publish it. Thanks very much for your help!
Hi, we are trying to install the add-in now, but I am very confused. Do we need to host the add-in web files first, then point the manifest at the hosted add-in, or does the installation process take a copy and publish it and host it automatically? If we need to host it first, where is the default location for Outlook add-ins to be hosted in an organisations office 365? Thanks!
The manifest.xml file is nothing more than a pointer. If you look inside, there is a URL location for the add-in. This URL can be any webserver you want. As a matter of fact, you might need to change this path it sounds like.
Office 365 only loads the XML file as a pointer for users’ accounts. Where the add-in lives is up to you. So, you can install all the JS/HTML files for your solution on any web server you have available to you as long as it is HTTPS (and not SharePoint).
One good example to follow is my 5entences add-in (https://kryl.com/?page=5entences). This is hosted on my DBA’s webserver at https://kryl.com/apps/office/5entences/index.html (will load a blank page in the browser, but this is where the add-in has been published). My steps, on the page I linked to above would have you take the XML file and side-load it into Office 365 – Outlook Online, but you could just as easily take the URL to my manifest.xml and load it into the Office 365 Admin Panel and publish it to your uses as well.
You will do essentially the same. Publish your code (HTML and JS) on any HTTPS serviced website you desire and then make sure all the links in the manifest.xml are pointing to that URL and then you can load that manifest into Office 365 admin panel, assign the users you want and viola – it should load for them the next time they log into Outlook.
Thanks, I understand now, we have some webspace we can use. One final question if that’s OK (I appreciate your help!) If the add-in is hosted in the cloud, what is the mechanism for restricting access to it, if any, since all the scripts run client side? I can only think of keeping the URL private, but this may end up being shared by a user. Thanks again.
If you keep the manifest private (meaning, it does not have to reside on the site with the rest of the code), you can limit who can gain use of the add-in. If you want to protect the code itself, and your users are always coming from a specific IP range, you can setup your web server to restrict access to the site only from those IP address ranges (in Azure this is done with Network Security Groups, not sure but certain other cloud offerings provide similar). If you are afraid of your users sharing the manifest and you need the website out on the public internet you can limit access to the add-in itself by instigating some sort of login mechanism into the add-in, so only users that you approve of can access it. If you are concerned additionally (or only) about someone accessing your code and reverse engineering it, you can limit that ability by “minifying” your code (see: https://marketplace.visualstudio.com/items?itemName=MadsKristensen.BundlerMinifier). There is not a perfect way to prevent unintended access or users sharing the manifest and/or credentials, but you can use the above options to make things more difficult for sure. Please let me know if this helps.
I have never written an add-in before, and the Microsoft help always seems to omit some knowledge they consider ‘obvious’, so your help has been invaluable! Thanks again đŸ™‚