Outlook web add-in deployment options. Exchange Admin Center vs Office store, Which one to pick? RRS feed

  • Question

  • I am currently working on an outlook web add-in based on Office 365.

    This add-in would be used by enterprises which would have their own web servers. This implies that < SourceLocation > tag of manifest file needs to be modified by different enterprises to point to their server.

    From deployment point of view, I am thinking of providing web server components in the installer. I also want to bundle manifest file with the installer so that the admin user could:

    1) Modify the manifest file to point to the web server in their enterprise.
    2) Deploy the manifest file using Exchange Admin Center option. This option would allow admin to set up the add-in for user accounts for which add-in is applicable.

    Given my requirements, is it possible for me to use Office Store? How one would modify the manifest file if I put my add-in to the store?

    To me it appears that Exchange Admin Center option is better as it allows modification of the manifest file and allows setting the add-in for many user accounts at once.

    However, I am not sure if Exchange Admin Center option looks professional enough from the deployment perspective. Is it or not?

    Friday, March 24, 2017 10:55 AM

All replies

  • The is nothing wrong with "Exchange Admin Center" deployment option. In fact this is one of the eligible option to consider. Please refer to Deploy and publish your Office Add-in. Office store deployment option may be considered as well. And you ask me how is it possible with your requirements? Let's discover ...

    • You nave single application which you would like to deploy in house (your company server) and/or distribute it to your customers. The customers may deploy the copy of the app on their own server or use your deployment. What's the difference, as you said, is slight modification of manifest file. There is nothing wrong to provide your customers with modified version of manifest file which would point to your deployment server or their own. You may even simplify the life of your customers by hosting in the single location (your company location) your app and provide your customers with unique URL pointed to "custom" manifest.xml, hosted with your app. In this case you would have benefit of updating your application at the central point as well as your distribution will be nothing else as providing your customer with URL to "custom" manifest.
    • I mentioned you may consider Office store option as well. What I mean is if you have direct customers (not through enterprises), customers who uses your service, instead of their own services. In this case you may publish your app into the Office store with manifest.xml pointed to your company service. In this case people who would use the app from Office store will be working directly with your service and your app will get exposure through the Office store; In same time enterprises who need their own service would distribute the app via "custom" manifest provided directly as the file or hosted at your/their environment and provided as URI.

    Bottom line: Publishing your application via Exchange Admin center doesn't look unprofessional, indeed. For your requirements it is the perfect fit.

    Note: If you find out hard to understand what is the app and what is the manifest (the terms I used through) please refer to https://dev.office.com/docs/add-ins/overview/office-add-ins#anatomy-of-an-office-add-in

    Slava Ivanov

    Friday, March 24, 2017 1:49 PM