Is there any way to send files using the Microsoft Communicator API/SDK?
No, sending files is not supported by the Automation API.
If upgrading to Lync Server 2010 is an option, the Lync SDK supports file transfers
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 ?
Is there a minimum requirement for a server hosting an outlook add-in? I am trying to use SSO for our Outlook Add-in and the error "API is not supported in this platform." is being returned when using the Add-in hosted in a Windows Server 2016.
Interestingly, when the same Outlook Add-in is hosted in a Windows Server 2019, the error is not happening and SSO is working ok.
The part of the code throwing this error is on this line:
let tokenData = await OfficeRuntime.auth.getAccessToken({ allowSignInPrompt: true});
Thanks in advance.
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.
First post here. Facing a problem where on Windows 10 an Oracle Identity Access Management (IAM) Windows Native Authentication (WNA) protocol fallback to a form-based logon page always fails whenever the Microsoft Online Services Sign-In Assistant (SIA) is installed. Whenever we remove the SIA, the WNA fallback to a form-based logon page always succeeds. This error is reproducible 100% of the time. We have not tested on Windows 8 or Windows 7. I've researched it, and there is not much out there to read about the SIA; it does not look to be configurable on the client end. Really want to avoid changing up code on the IAM WNA side.
Anyone out there seen this before? This is a large enterprise network, using all Windows 10 computers, which has both Oracle IAM running for some applications as well as Microsoft Windows 2008 R2 Active Directory, to which all the Windows 10 computers are joined. We are also standardized with Office 2016 with all back-end servers supporting Office apps such as Outlook, Lync, etc. in the cloud (Office 365).
Please let me know if I need to show the Oracle IAM/WNA SSO fallback code.
The Microsoft Online Services Sign-In Assistant is not configurable. But, if all your computers are running Office 2016 you do not need it anyway and it can be safely uninstalled, which as you said will make the fallback to form-based logon page work. If you were running Office 2013 you would need it however. Office 2016 apps such as Outlook and Lync can go direct with ADFS whereas previous versions could not do this. I don't have a URL reference for you, this is based on my experience.
I am planning to develop an communication apps based on Lync SDK. I understood that in order to run my application, i have to install lync client in the computer. This is where the following question arises
Is it possible to develop advanced features (that is available when installing Lync advanced) by using Lync SDK with Lync basic as client?
What is the difference between Lync basic and Lync advanced when using Lync SDK?
Should i install Lync Advanced to use the advanced features using Lync SDK?
It would be helpful if someone could tell me the difference?
Regards,
Raja
There is pretty much no difference between the Lync Basic Client and the Lync Client when using the Lync Client SDK.
I've only found one very small difference that hit me, Lync Basic doesn't support the "PIN to Gallery" feature. If you call the "PIN to Gallery" API, it will throw and the API doesn't tell you it's not supported.
The only other limitation of Lync Basic I've hit is that you can't configure any forwards. But this is more of a client configuration rather than API access limitation.
Everything else I've done with the Lync Client SDK has worked fine between the Lync Basic and the Full Lync Clients.