src: https://github.com/chgeuer/mybookmarks/blob/master/skype-for-business.md / http://tinyurl.com/s4bimc
- Long-running test tenant (type E3) via http://www.microsoftofficedemos.com
- Regular (shorter) test tenant (type E3) via http://go.microsoft.com/fwlink/p/?LinkID=403802&culture=en-US&country=DE
- When appending
?sl=1
query string to a meeting invitation URL (e.g.https://join.microsoft.com/meet/demouser120/FF66XXQ?sl=1
, it forces anonymous users into the web app. See also this - "UCWA" (Unified Communications Web API) not supported by O365
- Install Windows PowerShell for single sign-on with AD FS
- Manage Azure AD using Windows PowerShell
- Manage licenses and subscriptions for Office 365
- http://www.powershellmagazine.com/2012/04/23/provisioning-and-licensing-office-365-accounts-with-powershell/
- Access Azure AD graph API from C#
- Azure Active Directory Code Samples / code
- Managing users and user account properties in Skype for Business Online
- Install Microsoft Online Services Sign-In Assistant for IT Professionals - Beta 7.250.4551.0.
- Install Azure Active Directory Module for Windows PowerShell (64-bit version).
- Install Skype for Business Online, Windows PowerShell Module
Make sure to install the Beta sign-in assistant, not the RTW 7.250.4303.0. Azure Active Directory Module for Windows PowerShell has a launch condition MSOIDCRLVERSION >= "7.250.4358"
, which is not satisfied by the RTW version. If you are a smart guy and use something like Orca or SuperOrca to remove the launch condition, running Connect-MsolService
creates stuff like The type initializer for 'Microsoft.Online.Administration.Automation.ConnectMsolService' threw an exception
. So just use the beta.
When you plan to use all the MSOnline and Powershell bits from within a C# app, the Powershell Runtime in your .NET app is most certainly a 32bit runtime. The MSOnline Powershell Module is only in the 64-bit folder (C:\Windows\System32\WindowsPowerShell\v1.0\Modules
), so copy the bits over:
Copy-Item -Recurse -Destination "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules" -Path "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline"
Copy-Item -Recurse -Destination "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules" -Path "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnlineExtended"
After that copy operation, loading the modules should work:
PS C:\> Import-Module MSOnline
PS C:\> Import-Module "C:\Program Files\Common Files\Skype for Business Online\Modules\SkypeOnlineConnector\SkypeOnlineConnector.psd1"
PS C:\> Get-Module
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 3.1.0.0 Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con...
Manifest 3.0.0.0 Microsoft.WSMan.Management {Connect-WSMan, Disable-WSManCredSSP, Disconnect-WSMan, En...
Manifest 1.0 MSOnline {Add-MsolAdministrativeUnitMember, Add-MsolForeignGroupToR...
Script 6.0.0.0 SkypeOnlineConnector {New-CsOnlineSession, Set-WinRMNetworkDelayMS}
$credential = Get-Credential "[email protected]"
Connect-MsolService -Credential $credential
Get-MsolUser -UnlicensedUsersOnly
New-MsolUser -UserPrincipalName demo1@chgeuerimcdemo.onmicrosoft.com -DisplayName 'Demo User 1' -FirstName "Chris" -LastName "Geuer-Pollmann" -LicenseAssignment chgeuerimcdemo:ENTERPRISEPACK -UsageLocation DE
Password UserPrincipalName DisplayName isLicensed
-------- ----------------- ----------- ----------
Hogo3136 demo1@chgeuerimcdemo.onmicrosoft.com Demo User 1 True
$session = New-CsOnlineSession -Credential $credential
Import-PSSession $session
Get-CsTenant | select DisplayName, TenantId, DomainUrlMap
Get-CsOnlineUser | select UserPrincipalName
Enable-CsUser
- STS Integration Paper using WS-* Protocols: These documents detail the agreement for STSs to Interop with Azure Active Directory using the WS-Federation and WS-Trust protocols
- Azure Active Directory federation compatibility list: third-party identity providers that can be used to implement single sign-on (http://aka.ms/SSOProviders)
- Use a SAML 2.0 identity provider to implement single sign-on: All other clients are not available in this sign-on scenario with your SAML 2.0 Identity Provider. For example, the Lync 2010 desktop client is not able to login into the service with your SAML 2.0 Identity Provider configured for single sign-on.
- For debugging your own STS, use the Microsoft Connectivity Analyzer Client
- Announcing support for SAML 2.0 federation with Office 365
- Office 365 - User Account Management
- Single sign-on roadmap
- When rolling an own STS as IdP for Azure AD, the vendor needs to be onboarded through "'Works with office 365' for Identity Providers".
- STS must talk WS-Trust / WS-MetadataExchange
- Lync Online requires a WS-MEX Endpoint at the IDP.
- Skype for Business