Series: Part 1 Part 2 Part 3 Part 4

Full Automation

Overview

So far in this blog series I’ve covered the basics of user licensing in Office 365 with PowerShell by demonstrating how to add and modify license skus. This is very useful in scripting the service entitlements for new users, but not all users are static and in many cases you’ll need to manage licenses as users move between positions and licensing needs change. This isn’t as easy as it sounds (or should be), and has a couple of obstacles.

Problem 1 - DisabledPlans

The biggest drawback to configuring user licenses via PowerShell lies in the design of the New-MsolLicenseOptions cmdlet. The problem is that the -DisabledPlans parameter is inherently the wrong approach to license automation. For example, let’s say we’ve set up a script that licenses users for the EnterprisePack and you’ve added Sharepoint to the disabled plans. In it’s original state, this would have enabled Exchange, Skype for Business, and Yammer. However, last year Microsoft added a new service plan to the license - Sway. This means that as soon as Sway became available as an assignable license in your tenant, Sway would have been assigned to your users because it hasn’t been explicitly added to the list of disabled plans.

Series: Part 1 Part 2 Part 3 Part 4

Modifying License Assignments

Overview

In the first two parts of this series I showed you how to find available licenses to assign to an Office 365 user, how to assign those licenses, and how to enable only selected service plans from those licenses. All of the guidance I have seen to date around this topic stops at this point, but this is not where the work actually ends. For instance, how do we manage licensing for a user whose role changes within the organization? For many companies using Office 365 this means a change in entitlements as well. They may get different security and distribution group membership, but what if your company’s needs also include a different set of services in Office 365? How can we achieve that?

Finding currently assigned service plans

The first step in modifying a user’s license assignments is finding out what services they currently has been assigned. To do this, we use the Get-MsolUser cmdlet:

Series: Part 1 Part 2 Part 3 Part 4

License Options

Overview

In the previous blog post I showed you how to connect to Azure Active Directory using PowerShell and assign a license sku to an Office 365 user which entitles a user for all the services contained therein. In many cases this is sufficient, but some organizations may have more specific needs regarding what services are available to its’ users. For instance, you may want to provision Exchange to your users after you’ve migrated from another mail service, but you want to wait a bit to deploy Sharepoint, Skype for Business, and Onedrive for Business until your users have gotten used to Office 365. To achieve this you’ll need to use selective license entitlement. This can be done in the Admin Center by deselecting the services that are included with a license sku,

but to do this in bulk we’ll need to use PowerShell.

Series: Part 1 Part 2 Part 3 Part 4

The Basics

Overview

Licensing users for Office 365 services is pretty easy in the administrative center using your web browser, but if you have more advanced needs or you’re automating your Office 365 tenant configurations, you’re going to need PowerShell. However, licensing users with PowerShell is complex and can be a bit of a pain. In this blog series I’ll go over how to assign licenses to users and how to selectively enable the service plans contained in each license sku. We’ll even go over some advanced scenarios that will help you fully automate all your user licensing as well as reactively change or update user licensing as user roles change within your company.

Connect to Azure Active Directory

The first step to using PowerShell for Office 365 licensing is learning how to connect to the Office 365 environment so that we can run commands against our tenant. There are a couple of prerequisites:

If you manage an Office 365 tenant then you may be interested in a new module I published to the PowerShell Gallery. The O365ServiceCommunications module can be used to retrieve messages regarding your tenant health status, incident closure, and general information about planned downtime or new features. The Office 365 Message Center lacks email alerting on incidents and this is definitely a gap that needs to be filled. You can use this module to script this automatic alerting and make your boss happy! You could even drop the event data returned into a SQL database and generate reports and track the health of your Office 365 tenant.

This module uses the Office 365 Service Communications REST API and you’ll need to be a global administrator for your tenant, or a delegated partner administrator in order to authenticate to the service.

Detecting Key Presses

I haven’t blogged in quite a while, but recently I was inspired by this PowerShell.com PowerTip that gives us a method to detect key presses using low-level Windows API methods. I took this just a bit further and created a function that allows us to specify exactly which key we’d like to test for and will even check for multiple simultaneous keys (a chord).

I recently ran into a problem when using Pester to test the validity of my PowerShell module manifests. My original idea for testing the manifest files came from Dave Wyatt’s tests for the Pester module itself. The first describe block he uses here runs several tests against the module manifest itself such as whether the manifest is versioned, has a valid GUID, and has a name.

One of the problems I sometimes run into when authoring a module is with exporting functions. Sometimes I’ll write a new function and think I’m all set to go but when I import the module the function doesn’t exist. After a few face-palms I’ll realize that I forgot to add the function to the FunctionsToExport array in the module manifest. With this in mind I wrote a test that checks if the functions that are exported from a module match the functions that are enumerated in the module folder itself:

The Scripting Games are back for another year and the format has changed quite a bit. This year we’ll be treated to several monthly puzzles with solutions submitted publicly on the PowerShell.org website. July’s puzzle can be found here.

The Challenge

The goal is to create a PowerShell one-liner that is as short as possible and creates the output given in the example:

PSComputerName ServicePackMajorVersion Version  BIOSSerial
-------------- ----------------------- -------  ----------
Win81                                0 6.3.9600 00261-80123-18417-AA816

I’ve been playing around with a trial version of PowerShell Studio 2015 an I must say it’s pretty nice! I don’t typically do GUIs with PowerShell, but if I did this would be an amazing tool. Overall there are some great features that really provide some value if you need to move up to a professional editor.

I thought I’d share the color scheme I’ve been using for the script editor:

Exchange Online Clutter

Clutter is a new productivity aid in Exchange Online that helps save you time by separating your important messages from the rest of the muck that you get on a daily basis. A description of how this feature works can be found here. Clutter is optional and can be enabled by users should they choose to use the service.

Microsoft believes in Clutter so much, however, that they have decided to make it available by default on all new Exchange Online mailboxes starting in June. If this timeline doesn’t work for your organization, or you would rather give your users the choice to turn Clutter on, there are some new PowerShell cmdlets that you can leverage.

First, some prerequisites: