Monday, October 16, 2017

Using PowerShell with MFA to Administer US Government Tenants on Office 365

In this post, I will show you how to connect to a US Government GCC High Office 365 Tenant using PowerShell with credentials that have multi-factor authentication (MFA) enabled.


To meet the unique and evolving requirements of contractors who are holding or processing U.S. Department of Defense controlled unclassified information (CUI) or are subject to International Traffic in Arms Regulations (ITAR), Microsoft offers "GCC High" Office 365 tenants. These tenants are designed to meet special regulatory, compliance and audit requirements and are physically segregated from commercial environments. Currently, Microsoft also has similar setups configured specifically for Germany and China. GCC High tenants are different than the standard GCC tenants and contain a different set of features. The full service description can be found here:

The four service endpoints we will connect to are:
  • Azure Active Directory
  • Exchange Online
  • Skype for Business Online
  • SharePoint Online
The instructions below demonstrate how to connect to the endpoints using PowerShell with an account that has MFA enabled. In each case, the command to connect to the tenant will trigger a modern authentication screen that will prompt for credentials and facilitate authentication with other factors (e.g., text, app notification, etc...)

Azure Active Directory

Follow the steps below to connect to Office 365 using the Azure Active Directory PowerShell module:
 Install-Module AzureAD
  • Run the following PowerShell command in the Azure Active Directory PowerShell window to connect to your tenant. Note that the command includes a parameter: "AzureEnvironment" which is set to "AzureUSGovernment". This identifies it as a GCC High Tenant and directs the request appropriately.
  Connect-AzureAD -AzureEnvironment AzureUSGovernment

Exchange Online

Follow the steps below to connect to Office 365 using the Exchange Online PowerShell module:
  • Navigate to the Exchange Online Administration Center for your GCC High Tenant here:
  • In the Exchange Online Administration Center, navigate to the Hybrid section. Under "Setup", click the appropriate Configure button to download the Exchange Online Remote PowerShell Module for MFA.
  • Follow the prompts to install the Microsoft Exchange Online PowerShell Module
  • Run the following command in the Exchange Online PowerShell window to connect to your GCC High tenant with MFA enabled credentials. Replace <name@domain> with your login admin credentials. Note that the ConnectionUri is what redirects the login to the appropriate hardware for GCC High Tenants.
 Connect-EXOPSSession -UserPrincipalName <name@domain> -ConnectionUri

Skype For Business Online

Follow the steps below to connect to Office 365 using the Skype for Business Online PowerShell module:
  • Download and install the Skype for Business Online Connector Module:
  • Run the following commands from any PowerShell window to import the connector module and connect to Skype for Business Online. Replace the <OnMicrosoft Domain Name> with the tenant domain name that was created when you setup your tenant (e.g., Do not use a custom tenant domain name.
Import-Module LyncOnlineConnector
$session = New-CSOnlineSession -verbose overrideAdminDomain <OnMicrosoft Domain Name>
Import-PSSession $session

SharePoint Online

Follow the steps below to connect to Office 365 using the SharePoint Online PowerShell module:
  • Download and install the SharePoint Online PowerShell Module:
  • Run the command below from the SharePoint Online PowerShell window to connect to SharePoint Online. Replace <TenantName> with your tenant name (e.g., The URL, combined with the region directs the request to your GCC high tenant.
 Connect-SPOService -Url https://<TenantName> -Region ITAR


The above instructions will allow you to connect to the various admin components of a GCC High US Government Office 365 Tenant with an MFA enabled account.

Thursday, July 27, 2017

Getting Started with PowerShell for Administering Office 365

Why Use PowerShell for Administering Office 365?

PowerShell is a powerful and convenient tool for administering Office 365. There are a variety of reasons why you would use PowerShell, including:
  • Adding or editing a large number of records (e.g., users, list items, documents, etc...)
  • Sifting through a large amount of data using filters
  • Exporting data. A common scenario is keeping more than 90 days of audit log data. Audit logs are only kept for a rolling 90 days. One way to keep the data for a long period of time is to export it using PowerShell. For a detailed walkthrough of how to do that, see Paul Hunt's post here: Keeping Office 365 Audit data beyond 90 days with the Microsoft Graph
  • Sometimes PowerShell is the only option. For example, enabling or disabling Office 365 Group creation is done through PowerShell. Also, some government tenants (L4 and L5) do not have an Admin UI and configuration is only done through PowerShell.
This post is meant to be an introduction. It will help you get started with some PowerShell basics for Office 365.

Download The Appropriate Installation Files

First, download and install the Microsoft Services Sign-In Assistant For IT Professionals RTW

Next, download and install the Windows Azure Active Directory Module for PowerShell

There are several different PowerShell modules for the Office 365 workloads. Below are a couple more to download and install:

Connect to Azure Active Directory for Office 365

Open up the Azure Active Directory Module for Windows PowerShell in Administrator mode. To connect to Azure AD in Office 365, type this command:


Enter your username/password and click Enter. If no error comes back, then it connected successfully. Note: you are only connected to Azure AD in your Office 365 tenant. You are not connected to Exchange Online or SharePoint Online.

Get A List of Users and Assign Licenses

Run the following commands:

Set-MsolUser -UserPrincipalName "" -UsageLocation "US"
Set-MsolUserLicense -UserPrincipalName "" -AddLicenses "dough:ENTERPRISEPACK"

The Get-MsolUser command gets a list of all users in the tenant. You can filter the set of users returned to only include unlicensed users by adding the "-UnlicensedUsers" parameter

The Get-MsolAccountSku gets the Office 365 Tenant License SKU.

The Set-MsolUser command sets the user's location

The Set-MsolUserLicense assigns a license to the user.

Enable or Disable Office 365 Group Creation

Frequently, when companies first migrate to Office 365, they don't want users to be able to create their own least not initially. The following PowerShell scripts turn off the ability to create Office 365 groups for all users.

First, connect to Exchange Online. Exchange doesn't have a separate command module for PowerShell. So, open up the standard PowerShell Window in administrative mode and enter the follow commands:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $creds -Authentication Basic -AllowRedirection
Import-PSSession $Session

Then, to turn off group creation for all users, run the following command

Set-OwaMailboxPolicy -Identity\OwaMailboxPolicy-Default -GroupCreationEnabled $false

Additional Resources

There are lots of additional resources to help you get started with PowerShell for Office 365:

Thursday, February 9, 2017

MinRole for SharePoint 2016 and the November 2016 Public Update

The Beauty of MinRole

SharePoint 2016 introduced a host of new features, including MinRole. MinRole promised easier administration of SharePoint servers. You can read about how it was touted to simplify deployment, improve performance and reliability, and simplify capacity planning and farm scalability here, All you had to do when you installed SharePoint 2016 was select one of the predefined roles in the configuration wizard:

If you selected "Front-end", "Application", "Distributed Cache", or "Search", SharePoint would take care of installing the appropriate bits and turning on the appropriate services on the server.

Microsoft had learned a lot from running SharePoint at a massive scale in Office 365. They were passing that learning on to us.

The Problem with MinRole

The problem with MinRole at RTM was that it was generally more beneficial for companies that ran large farms (much like Microsoft did in the cloud). If you wanted to run a highly available MinRole farm that also runs workflow and office online server, you would generally need about 15 servers for just one environment:

For many small to mid-size organizations that want to keep their SharePoint environment on premises, this is a lot of infrastructure, especially considering that most organizations need at least two more environments: Staging and Disaster Recovery. MinRole, just wasn't an Custom was the option to select in the Configuration different than how it would be done in SharePoint 2013.

The Solution

Starting with the November 2016 Public Update for SharePoint Server 2016 Microsoft introduced the concept of Shared roles. Instead of each server having 1 of 4 distinct roles, servers could now share roles. So, Front End and Distributed Cache could be combined and Application and Search could be combined. The new configuration wizard now looks like this:

A fully built out, highly available SharePoint 2016 farm using shared min roles was now 11 servers instead of 15, which is a little easier to swallow, especially considering many small organizations don't implement the workflow functionality and would only have 8 servers

Lessons Learned

I really like that Microsoft is leveraging its experience with cloud technologies to bring them to on-premises or hybrid installations. I would love to see more of that. I also like that Microsoft quickly reacted to customers' feedback about the number of servers required for a fully scaled out MinRole environment and made adjustments to suit the needs of the small to mid-size businesses.