We have a client that uses SCCM to deploy Excel to their users and according to them, they package other add-ins with Excel so that when it's installed they have access to these add-ins.
We have an Office Add-in (specifically Excel), not the VSTO or COM add-ins, a web Office Add-in.
I've done some research and I'm struggling to find a solid answer as to if it's possible to deploy the add-in with SCCM? So far my deduction is no, but I thought let me confirm with the professionals.
And then is there any other solution on how to deploy the add-in otherwise?
Please note the following restrictions on their end
Locked the Office store, users cannot install an add-in from the Office store
Don't have access to the Admin Center to deploy the add-in
Related
What I have tried ?
I have tried using Power Shell to upload office add-in by referring following link,
Use the Centralized Deployment PowerShell cmdlets to manage add-ins
but I ended up receiving,
PS C:\WINDOWS\system32> New-OrganizationAddIn -ManifestPath 'D:\Manifest\manifest.xml' -Locale 'en-US'
Extracting Add-In's manifest...
**The Add-In you are trying to upload supports Single Sign On and to upload the Add-In you need to use Office 365 Admin Center.
Press Enter to consent to the Add-In in Office 365 Admin Center.**
If there are any issues you can go to
https://portal.office.com/adminportal/home?assetid=lob&mktcmpid=powershell#/Settings/ServicesAndAddIns
And go to Settings > Services & Add-Ins
Also, the URL mentioned in above message, which is, https://portal.office.com/adminportal/home?assetid=lob&mktcmpid=powershell#/Settings/ServicesAndAddIns is old. We no longer upload add-in from this endpoint.
Additionally, I do have referred,
Deploy and publish Office Add-ins
As, since it is an Outlook add-in, it cancelled out uploading it via SharePoint app catalog.
Is there any other way that I can do it using command shell or rest APIs ?
Additionally, is there any restriction to upload add-in which supports Single sign on via PowerShell ?
We´ve created a sharepoint-hosted Addin and want to authenticate to our enterprise Azure Active Directory. We tried to migrate the AADTokenProvider from the sharepoint webpart, to get our AccesToken from our AAD.
Following is the dependency which provides the AADTokenProvider
- microsoft/sp-http
Unfortunately the dependencies aren´t standalone packages.
What´s the correct way to accomplish the authentication from sharepoint addin to a Azure AD?
SharePoint Add-in is an identity principal just like a user, and it must be authenticated and authorized to use SharePoint resources. There are three authorization systems that an add-in can use. They are not mutually exclusive.
Three authorization systems and when to use them
Low trust-
A provider-hosted SharePoint Add-in can register with Microsoft Azure Access Control Service (ACS), which issues an access token to the add-in that allows the add-in access to the resources in the SharePoint tenancy or farm on which the add-in is installed. Azure ACS is the trusted token issuer in an OAuth 2.0 Framework "flow" that includes SharePoint and the remote components of the add-in. Add-ins that use this system can be sold in the Office Store. The low-trust system is primarily intended for add-ins whose remote components are hosted in the cloud.
For more information about creating a SharePoint Add-in that uses the low-trust system, see Creating SharePoint Add-ins that use low-trust authorization.
High trust - A provider-hosted add-in can establish trust with SharePoint by using digital certificates. The high-trust system is primarily intended for add-ins whose remote components are hosted on-premises. The add-in can be installed to a SharePoint farm that is not connected to the Internet. The add-in cannot be installed on SharePoint Online or sold in the Office Store.
For more information about creating a SharePoint Add-in that uses the high-trust system, see Creating SharePoint Add-ins that use high-trust authorization.
Cross Domain Library - When the add-in's business logic is in JavaScript, you have the option of using the SharePoint cross-domain library either in place of, or as a supplement to, the low-trust and high-trust systems. The library is also intended for scenarios where the add-in has cloud-hosted components, but the customer's corporate firewall makes it difficult to use the low-trust system. The user's browser blocks scripts from other domains, but the library encapsulates a secure system for working around this restriction. Add-ins that use the library can be sold in the Office Store and can be installed to either SharePoint Online or on-premises SharePoint.
For more information about creating a SharePoint Add-in that uses the cross-domain library, see:
Creating SharePoint Add-ins that use the cross-domain library
Solving cross-domain problems in SharePoint Add-ins (blog post)
Hope it helps.
I developed an add-in for Word.
The Microsoft docs state that
To sell Office Add-ins to organizations, you need to create a licensing database. This is necessary because:
...
Centralized deployment does not allow users to buy add-ins from AppSource and deploy them. AppSource paid add-ins today only work with personal identities (Microsoft accounts), not work or school accounts.
So, if I want an organization to adopt my Office Add-in I have to handle the licensing workflow myself. And if I understand this correctly, an organizational user would not download/install my add-in thorough the AppSource(AS). So...
How does an organizational user actually get the add-in? They don't purchase it from the AS—their organization already purchased the add-in. So how does the user "find" the add-in and install it in their Office instance?
When an add-in uses Centralized Deployment, the add-in is automatically installed for all users. For example, if it has ribbon buttons, they will automatically appear on the ribbons of the users for whom the add-in has been deployed. So, the user doesn't do anything to install the add-in. For details about how this works, see Centralized Deployment.
I recently implemented an Outlook plugin for my enterprise and now I want to deploy it to all of the users on the enterprise. Is there a way to deploy the add-in installer to all of the users on the Active Directory, maybe using Outlook Exchange?
I checked this page, and looks like the guys at commvault nailed that.
Any ideas?
You can't deploy add-ins via email with Exchange, if that's what you are hoping for. If your add-in is packaged in a Windows Installer setup file, then you can use traditional Windows Desktop Application deployment methods to distribute your add-in.
Is it possible to place an application using vsto if the office is not installed? It doesn't appear to be so, but I was wondering if anyone had a work-around.
VSTO wraps Office's Automation interfaces. Office is doing the work under the covers, so must be installed.
Just to compare with Web Office Extensions, did it also need Office installed on the server?