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 ?
Related
is it possible to delete a SharePoint site redirect through the Graph PowerShell SDK? I recently changed the SharePoint site URL of an existing MS365 group and now the old URL (e.g. https://domain.sharepoint.com/sites/GroupA) acts as a redirect to the new SharePoint site URL (e.g. https://domain.sharepoint.com/sites/GroupB). Since I want to reuse the old URL, I need to delete the redirect first.
The Microsoft docs state that this is possible through the SharePoint Online Management Shell. Unfortunately the Shell requires a Windows-based machine, which I cannot use. Therefore, I am trying to do this via the Graph PowerShell SDK.
Unfortunately, Microsoft does not seem to offer any functionality to delete SharePoint sites via the MS Graph API
The Sites API Reference shows that MS Graph is only capable of deleting a permission object on a site rather than a site itself.
As MS Graph API doesn't expose any endpoint to delete sites, it will not be possible with the Graph Powershell module either.
It's unfortunate that the SharePoint Online Management Shell doesn't support Powershell core and that the SharePoint admin center offers no ability to delete these site redirects.
If you're not able to use a Windows machine to achieve this, I suspect a support call to Microsoft may be your only other alternative.
As NiMux mentioned, it's not possible to delete SharePoint sites resp. site redirects via the MS Graph API. But another alternative is the PnP PowerShell module, which among other things provides several SharePoint Online cmdlets. I was able to remove the redirect with the cmdlet Remove-PnPTenantSite.
The module is open-source, community-developed, officially recommended by Microsoft and cross-platform which means it works on an Azure Ubuntu VM (tested it myself).
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
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 am trying to deploy an add-in with add-in commands on the desktop version of office 365, using the Centralized Deployment method.
I followed the instructions for Centralized Deployment and the addin appears as "on" in the Office 365 admin center. I used both "Everyone" and "Specific User/Group", but when I open the Word application and go to Add-ins, under "Admin Managed" I see no addins , and the message "No add-ins currently available." The addin is'nt visible neither on Word 2016 Desktop (with subscription) nor Word Online. I have also tried deploying addins from office store using the same method (Centralized Deployment) but they also don't show up.
I have Word version 1708 (8431.2270), and I am using a developer subscription.
Do you have any suggestions to fix it or know why it is not working? Thank you.
Also,
I noticed that I am getting a 403 Error when refreshing the Admin Managed tab (when calling https://euc-word-edit.officeapps.live.com/we/AddinServiceHandler.ashx)
I solved, by enabling Exchange, and my manifest had an issue.
I changed <CustomTab id="HelloWorld" x:type="CustomTab"> to <CustomTab id="HelloWorld"> and it worked.
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.