Geek of All Trades: Manage Office 365 with Windows PowerShell
If you never thought you’d need to use Windows PowerShell to manage cloud apps such as Office 365, here’s a QuickStart for the complete newbie.
Greg Shields
My company, Concentrated Technology, recently completed a transition from Google Apps for Business to Microsoft Office 365. Our migration was remarkably painless. Using a simple third-party solution, we migrated our data to the new platform with little more than two passwords and one mouse click per user.
Suddenly, we found ourselves atop a completely new infrastructure with a whole new set of rules. For a group of people fairly experienced with Microsoft technologies, we were caught unaware of the scope of exposure of Windows PowerShell in Office 365. The idea of Windows PowerShell and Office 365 can seem somewhat at odds. People seek solutions such as Office 365 in part because they’re seeking simplicity.
While completing tasks with Windows PowerShell isn’t necessarily complex, it’s certainly not trivial. Just getting started is perhaps the hardest part. So this month, I’ve drawn up a tidy Windows PowerShell for Office 365 QuickStart for the complete newbie. Follow these steps and learn a few key cmdlets, and you might discover that “powerful” and “simple” needn’t be mutually exclusive.
Step #1: Get Comfortable with (Really) Remote Execution
Windows PowerShell is indeed powerful. There’s a point on the learning curve, however, where the complete newbie often gets lost. That point is usually after learning the most basic cmdlets, but before having a full understanding of how to create useful solutions. It’s one thing to run Get-Process and see the processes running on your local computer. It’s quite another to pipeline a series of cmdlets against some remote computer to complete some real-world action.
My advice is to spend some quality time understanding how PowerShell remoting works in your local LAN. Explore how the –computerName parameter works with some cmdlets, while Invoke-Command is necessary with others. Get comfortable with Get-Help and its immensely useful -exa switch for viewing examples.
You’ll need these skills because Office 365 expands on them in ways that require a solid foundation. With Office 365 cmdlets, you’ll be executing against Microsoft servers instead of your own, sending commands over the Internet instead of your LAN. It’s that concept that requires some rewiring of how you think, but that’s a good thing. Getting comfortable with these concepts will pay dividends of some impressive power once you hit that “a-ha!” moment.
Step #2: Prep Your PowerShell
Windows PowerShell doesn’t speak Office 365 language right out of the box. Getting your Windows 7 desktop to talk in Office 365 tongue requires a few preparatory tasks.
Navigate over to the Use Windows PowerShell to manage Office 365 page and install the Office 365 cmdlets. These are installed as part of the Microsoft Online Services Module for Windows PowerShell. They come in x86 and x64 editions. Before installing these, you’ll also need the Microsoft Online Services Sign-In Assistant, as well as Windows PowerShell and the .NET Framework 3.5.1 installed and enabled on your desktop computer.
Step #3: Import Module, Create Session, Import Commands
Installing Windows PowerShell cmdlets only sets the stage. This does nothing for actually connecting them to the Microsoft Office 365 cloud. Connecting to the cloud requires a cumbersome—but straightforward—five-step process:
1. Import your newly installed Online Services module
2. Enter Office 365 credentials
3. Create a remote session
4. Import that session’s commands into your local Windows PowerShell session
5. Connect to Office 365 services
Those five commands to accomplish this procedure look like this:
Import-Module MSOnline
$O365Cred = Get-Credential
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Connect-MsolService –Credential $O365Cred
This structure might look complicated at first blush, but remember: Windows PowerShell is designed to be everything for everyone. As a result, some commands are just larger than others. You should recognize that this structure accomplishes five things: First, it uses Import-Module to add the Office 365 cmdlets into your session, which enables your local session to speak the language of Office 365.
Second, a dialog box is launched to ask for your Office 365 username and password (which will look something like: username@domain.onmicrosoft.com). This credential information is stored in the variable $O365Cred, which lets you use it again later.
Here’s where things get impressive. The third and fourth commands create a new Windows PowerShell session in the cloud at https://ps.outlook.com/powershell. Then they import the cmdlets from that session into your local session. Think of it as using PSExec to access some remote server’s command prompt. The big difference is that remote server exists somewhere in the cloud. Its remote session is actually merged into your local session (see Figure 1).
.jpg "Creating a remote Office 365 session")
Figure 1 Creating a remote Office 365 session.
Now take a second look at the yellow text in Figure 1. You’ll see something similar to:
WARNING: Your connection has been redirected to the following URI:
"https://pod51018psh.outlook.com/PowerShell-LiveID?PSVersion=2.0"
WARNING: Your connection has been redirected to the following URI:
"https://sn2prd0702psh.outlook.com/PowerShell-LiveID?PSVersion=2.0"
The URI you see will be slightly different than what I’ve shown here. Connecting a remote session to https://ps.outlook.com/powershell automatically redirects it to whatever servers host your Office 365 resources. In my case, those servers are pod51018psh.outlook.com and sn2prd0702psh.outlook.com.
Yours will be different. These are the servers with which you’ll be directly interacting when you later invoke the Office 365 Windows PowerShell commands.
Step #4: Respect Your New Command Library
Once you’ve initiated a connection, you’re ready to manage your Office 365 assets. At this point, Windows PowerShell exposure is limited to Office 365 and Exchange resources only. Exposure to SharePoint is coming soon.
You can see a list of the Office 365 cmdlets now available by entering Get-Command -module MSOnline. You’ll also find a convenient table of these commands along with short descriptions here.
Here’s a particularly useful cmdlet that will change an Office 365 password. It resets the password to P@ssword!. You can also omit the -NewPassword parameter to automatically generate a random password:
Set-MsolUserPassword -UserPrincipalNameusername@domain.onmicrosoft.com-NewPasswordP@ssword!
These cmdlets are all related to Office 365 objects. Adding to them is a second set that manages the Exchange resources those objects interact with. There are a seemingly overwhelming number of cmdlets, but there’s a handy reference to them here.
Step #5: Profiles Make Life Easier
The five commands in Step #3 that connect you into the cloud are indeed a big block of text. Retyping that text block every time you log in can make working with Windows PowerShell seem more effort than it’s worth. But Windows PowerShell—and indeed shell scripting in general—is all about doing things once and then forever benefitting from the effort.
Every time a Windows PowerShell session begins, it will run whatever commands it finds in a special file referenced by the variable $profile. You can view where that file exists by running dir $profile in the shell.
My $profile is the file Microsoft.PowerShell_profile.ps1 (see Figure 2), which is in the folder C:\Users\gshields\Documents\WindowsPowerShell. You can edit this document in your favorite text editor to add to the five connection commands. Now every time you launch Windows PowerShell, you need only enter username and password to be automatically connected into Office 365, as well as everything else on your network.
.jpg "The $profile view")
Figure 2 The $profile view.
With Power Comes Responsibility
You can follow these steps to create a seamlessly merged workspace in which you can manage your local and remote resources. That same workspace can be just as dangerous as it is useful.
If you chuckled when you first learned the results of running Get-Process | Stop-Process (here’s a hint: don’t do it), you’ll shudder when realize what Get-MsolUser | Remove-MsolUser might do. So be careful with your newfound power. Be ever mindful of the accompanying responsibility.
.jpg "Greg Shields")
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.