PowerShell licensing example

 # Disabled Plans

$disabledPlans= @()

$disabledPlans +="OFFICESUBSCRIPTION"

$disabledPlans +="SHAREPOINTENTERPRISE"

$disabledPlans +="EXCHANGE_S_STANDARD"

 # Disable all services with the exception of Lync

$LyncOnly = New-MsolLicenseOptions -AccountSkuId contoso:ENTERPRISEPACK -DisabledPlans $disabledPlans;

# Loop through all unlicensed users

$unlicensedUsers = Get-MsolUser -All -UnlicensedUserOnly;

foreach ($msolUser in $unlicensedUsers) {

     # Distinguish between users. Common variations include UPN (!$msol.User.Department)

if ($msolUser.UserPrincipalName.Contains("accounting.contoso.com")) {

# Set usage location. This is required for every individual user.

Set-MsolUser -UserPrincipalName $msolUser.UserPrincipalName -UsageLocation "US";

# Apply Lync-only license to all unlicensed users

Set-MsolUserLicense -UserPrincipalName $msolUser.UserPrincipalName -AddLicenses contoso:ENTERPRISEPACK -LicenseOptions $LyncOnly;

}

}

}

# Optional scenario involving changing from one license to another (E3 to E4)

Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -AddLicenses contoso:ENTERPRISEPACKLRG -RemoveLicenses contoso:ENTERPRISEPACK;

NOTE   

To get the AccountSkuId and included ServicePlans for your tenant, do the following:

Enter Get-MsolAccountSku

which will return something like this:

As you can see this command returns your MOD (Microsoft Online Domain), AccountSkuId, and licensing stats.

Now that we have the AccountSkuId (here mine is ENTERPRISEPACK), we can enter the following to get the included Service Plans.

Get-MsolAccountSku | Where-Object {$_.SkuPartNumber -eq "ENTERPRISEPACK"} | ForEach-Object {$_.ServiceStatus}

 Office 365 Service Plan SKU's

If anyone has a more complete list or would simply like to add to mine, please let me know in the comments!

Before we begin, let's take a moment and plan our AD FS farm topology. It is recommended practice to deploy AD FS with redundancy/high-availability, as well as a secondary Disaster Recovery site, if possible. Standard AD FS configurations opt for a 1:1 ratio of federation servers to proxy servers. For these reasons, the minimum recommended configuration of servers would be two federation servers and two proxy servers, with each fed/proxy pair hosted on separate physical servers. Below is an example of a high-level topology for a 2 & 2 farm:

Now on to the real fun.

Contents

1. Requirements

2. Install and configure the primary federation server

3. Install and configure the federation proxy server

4. Establish the Relying Party Trust

5. Supplemental

6. Resources

1. Requirements

• At least one verified "vanity" domain in your Office 365 tenant
• Active Directory synchronization
• SSL certificate from a trusted Certification Authority
• Internal/external DNS records pointing to your respective federation and proxy servers
• AD FS requirements

2. Install and configure the primary federation server

Prerequisites

1. Update server with all required patches
2. Install the Microsoft Online Services Sign-In Assistant (SIA)
3. Install the Windows Azure Active Directory (WAAD) module for PowerShell
4. Enable Group Managed Service Accounts (optional but recommended)

	1.	From the Server Manager Dashboard, click 'Add roles and features'.
	2.	Review prerequisites and click Next.
	3.	Select Role-based or feature-based installation and click Next.
	4.	Verify the server you will be adding the role to and click Next.
	5.	Check the box for Active Directory Federation Services and click Next.
	6.	We don't need to install any features, so click Next.
	7.	Review the AD FS info and requirements, then click Next.
	8.	Leave the Restart the destination server automatically if required box unchecked, since AD FS will not require a restart. Verify that the AD FS role is shown, then click Install.
	9.	Once installation has succeeded, click Configure the federation service on this server.
	10.	In the AD FS Configuration Wizard, select Create the first federation server in a federation server farm, then click Next.
	11.	Choose the domain admin account you intend to use to perform the configuration, then click Next.
	12.	Click Import... to add the SSL certificate you will use for encrypted server authentication. NOTE: If you have not yet obtained a certificate in the .pfx file format, cancel the configuration wizard and jump to Create a Certificate Request in IIS 8.5.
	13.	Select the certificate and then click Open.
	14.	Enter the password you created if you previously exported the certificate, then click OK.
	15.	Review the certificate and federation service names, then enter the display name that will be presented to users on the default AD FS sign in page. To see an example of how this will look, click here. When finished, click Next. NOTE: Here I've gone with the naming scheme of sts.domain.com, where 'sts' stands for Security Token Service. Another popular option is fs.domain.com, where 'fs' stands for Federation Service.
	16.	Enter the dedicated service account that will be used for each federation server in the farm, then click Next. This account is necessary for the Kerberos authentication protocol to work and to allow pass-through authentication from the proxy server. Use this account only for the purposes of the federation server farm. NOTE: If you plan to use an existing domain user account, make sure that the password is set to never expire. This action ensures that the service account's function is not interrupted as a result of domain password change requirements.
	17.	Select Create a database on this server using Windows Internal Database, then click Next. NOTE: The Windows Internal Database (WID) allows a maximum of 10 AD FS servers for the farm (if you have 5 or fewer relying party trusts), and 5 AD FS server if you have more than 5 relying party trusts. If your organization is large and will require more than 10 servers, choose the SQL Server database option. For more information on the differences between WID and SQL, click here.
	18.	Review the configuration options selected, then click Next.
	19.	Ensure that all pre-checks passed, then click Configure.
	20.	Once configuration has completed, click Close to exit the wizard.

To verify operation of the primary AD FS server, we can access the IDP Initiated Sign In page by going to https://sts.domain.com/adfs/ls/idpinitiatedsignon.htm

As you can see, the page will prompt you to sign in using Windows Integrated Authentication (WIA). This is the default sign in method assigned to internal AD FS servers in order to provide SSO functionality. You'll see an example of Forms-Based Authentication (FBA) on the proxy server later on.

3. Install and configure the federation proxy server

Prerequisites

1. Update server with all required patches
2. Import the SSL certificate into the Personal store using the Certificates MMC snap-in
3. Credentials of a local administrator account on the internal federation servers
   
4. Unfettered Internet access

	1.	On the AD FS proxy server, start the 'Add Roles and Features Wizard' as we did before. At the Server Roles step, check the Remote Access box, then skip straight to the Role Services step.
	2.	Check Web Application Proxy box, then click Next.
	3.	Review the list of roles and features to be added, then click Install.
	4.	Wait for the installation to complete, then click Open the Web Application Proxy Wizard.
	5.	At the Welcome step, click Next.
	6.	Enter the federation service name. For the user name and password, enter the credentials of a local administrator account on the internal federation servers.
	7.	Select the SSL certificate that we used on the federation server, then click Next.
	8.	Review the PowerShell command that will be run to configure the Web Application Proxy, then click Configure.
	9.	Click Close. The Remote Access Management Console will automatically open.
	10.	In the Remote Access Management Console, click Publish.
	11.	At the Welcome step, click Next.
	12.	Select Pass-through, then click Next.
	13.	Designate a publishing name for the web application, then enter the external URL that will be used to access the AD FS proxy server from the Internet. Next, choose the SSL certificate that we've been using all along, then enter the internal URL that will be used to access the AD FS federation servers. Note that both URL's should be identical and use the standard web address notation (example: https://sts.treybyday.com). When finished, click Next.
	14.	Here you can optionally copy the PowerShell command if you are planning to automate deployment in a large farm. Verify the publishing settings, then click Publish.
	15.	Your AD FS proxy server is now published and ready to accept external authentication requests.

At this point we can verify the proxy configuration by going to https://sts.domain.com/adfs/ls/idpinitiatedsignon.htm

Notice that the sign in page reflects Forms-Based Authentication, and provides fields for users' UPN and password.

4. Establish the Relying Party Trust

It's now time to federate your domain environment with the Microsoft Office 365 Identity Platform. After this step is complete, all Office 365 authentication requests will redirect to on-premises AD FS.

To start, return to the primary federation server where the Azure AD PowerShell module is installed. You can optionally perform this process from your local workstation by running Set-MsolAdfscontext -Computer "NetBIOS Name of primary federation server".

1. Open the Windows Azure Active Directory Module for Windows PowerShell with elevated administrator permissions. (There should be a shortcut on the desktop)

2. Run the following command to store your Office 365 global admin credentials.

$cred = Get-Credential

3. Connect to Office 365

Connect-MsolService -Credential $cred

4. Establish the Relying Party Trust with Office 365 by converting the domain from Managed to Federated.

Convert-MsolDomainToFederated -DomainName treybyday.com

NOTE: If you plan to federate more than one top-level domain now or in the future, append the -SupportMultipleDomain parameter to the end of this command.

Here is an example of how the commands will look in PowerShell:

You can test authentication by going to https://login.microsoftonline.com and entering a User Principal Name (UPN) with the now-federated domain suffix, e.g. trey@treybyday.com. A useful shortcut for accessing Outlook Web App (OWA) which bypasses the Office 365 sign in page is https://outlook.com/treybyday.com.

5. Supplemental

Create a Certificate Request in IIS 8.5

	1.	First we need to install the IIS server role. In the Add Roles and Features Wizard, skip to the Server Roles step and check the box for Web Server (IIS).
	2.	Review the required features that will accompany the IIS role and make sure the box to Include management tools (if applicable) remains checked. We will need the IIS Management Console to complete the certificate request. Click Add features.
	3.	Verify that the Web Server (IIS) role is now checked, then skip to the Confirmation step.
	4.	Review the roles and features to be added, then click Install. Once installation has completed, exit the wizard and return to Server Manager.
	5.	From Server Manager, click on Tools and select Internet Information Services (IIS) Manager. If this is your first time launching IIS, you'll notice a Web Platform Components prompt. Click No to exit and optionally check the box to not show the message again.
	6.	Double-click Server Certificates.
	7.	Click Create Certificate Request... from the right-hand Actions menu.
	8.	Enter the required information for the certificate, making sure to provide the intended SSL URL value for the Common name. Click Next when ready.
	9.	Choose Microsoft RSA SChannel Cryptographic Provider, and set the Bit length to a minimum of 2048 (recommended), then click Next.
	10.	Click on the ellipsis to create the certificate request file.
	11.	Choose an appropriate filename for the .txt file, then click Open.
	12.	Make note of the filename and location of the certificate request, then click Finish. You will now need to provide this certificate request file to your DNS provider. Once accepted, they will issue you a .cer file to be used to complete the request in IIS.
	13.	After being issued the SSL certificate, return to IIS and click Complete Certificate Request... from the right-hand Actions menu.
	14.	Click on the ellipsis to browse for the certificate you downloaded.
	15.	Select the certificate and click Open.
	16.	Enter the friendly name for the certificate. This will be value shown in the URL that points to your on-premises AD FS servers. E.g. https://sts.treybyday.com/adfs/ls Choose Personal certificate store and click OK.
	17.	Your SSL certificate is now available for import in the AD FS Configuration Wizard. You can export the certificate to a .pfx file for use on each additional federation server & proxy.

6. Resources

Verify and manage single sign-on with AD FS

Methods to attain SSO behavior

Customizing the AD FS Sign-in Pages

Customizing the AD FS URL using SmartLinks

Configuring Client Access Policies

Client Access Policy Builder

Multi-Factor Access Control

AlternateLoginID Feature

HowTo: Install the Windows Azure Active Directory Sync Tool

Deployment Scenarios for Office 365 single sign-on and Windows Azure

Microsoft Remote Connectivity Analyzer

 patches