Exchange administrators have known since the release of Exchange 2007 that only wimps seek the soft comfort of the GUI-rich Exchange Management Console (EMC) when they attempt to manage servers, mailboxes, or other objects. Exchange Online, part of Office 365, doesn’t provide EMC as a management option. It’s possible to connect EMC to an Exchange organization running as part of Office 365, but not as well documented, so we won’t discuss it here… maybe in a future post.
The focus for Office 365 management is all web-based so instead of EMC, you get to use the splendor of the Exchange Control Panel (ECP). In fact, one of the obvious inconsistencies of Office 365 is the differences in web-based management that pertains across SharePoint Online, Lync Online, and Exchange Online. For example, why should I have to navigate through Outlook Web App (OWA) to access ECP and manage Exchange Online options instead of being able to go direct from the Office 365 Admin screen? I guess this is evidence of Office 365 being somewhat of a work in progress at the moment as Microsoft integrates interfaces generated by three different engineering groups into hopefully what will eventually be a cohesive whole. But that’s a story for another day.
As an administration interface ECP is OK. In fact, for an Exchange on-premises deployment you find that some management tasks only appear through ECP and not EMC. Amongst the options that are unique to ECP are discovery reports, audit reports, ActiveSync device rules, and multi-mailbox discovery searches, all of which are new features that appear for the first time in Exchange 2010. On the other hand, some other new Exchange 2010 features don’t show up in ECP, such as anything to do with Database Availability Groups (DAGs) or mailbox creation.
Why are we in the situation where management options show up in one interface and not the other and how does Microsoft select which interface to use to reveal a new management option? I think the selection comes down to a simple guiding principle: if an option needs to be exposed to Exchange Online administrators, it should appear in ECP. If not, EMC is the target. Think about it – Exchange Online administrators couldn’t care less about databases and the other components of a DAG because Microsoft takes care of all of that high-availability stuff behind the scenes. On the other hand, Exchange Online administrators care very much about mailboxes and their properties, so the ability to manage these objects is revealed through ECP.
Note however that the ability to create new mailboxes is not revealed in ECP. This feature existed in ECP until relatively late in the beta releases of Exchange 2010 but disappeared for the final release. As shown below, Office 365 allows administrators to manage users and mailboxes through the overall Office 365 Admin screen.
Office 365 Admin
ECP is perfectly functional in its own way in terms of day-to-day management of Exchange Online but it’s a tad restrictive too because you’re limited to the decisions made by the development group as to what options appear in the “slabs” that compose the ECP interface. Just like a deployment of on-premises Exchange 2010, ECP knows what “slabs” to reveal by reference to role-based access control (RBAC). Users that have been assigned more powerful roles (such as Organization Management for on-premises deployments or TenantAdmins or Organization Management for Exchange Online) see more options revealed by ECP than less privileged users. Such is the way of the world.
In any case, to return to the overall theme of this post, ECP will eventually frustrate you because some of the things you might want to do to manage an Exchange Online deployment are simply unavailable. It’s at this point that you decide that the shell is the only way to get work done. It’s also when you might realize that the change made in Exchange 2010 to move from a focus on local PowerShell to channel all PowerShell commands through remote connections is far more strategically important to the long-term technical direction of Exchange. In a nutshell, while remote PowerShell might seem like overkill and a royal pain in the rear end for an on-premises deployment, it is the fundamental building block for management in the cloud – or for hybrid deployments where some objects run on-premises and some exist in the cloud.
Creating a remote PowerShell connection to Exchange Online is much easier than you might realize, especially if you do it from a Windows 7 workstation where all of the necessary components (like PowerShell 2.0) are available. The sequence required to connect is broadly similar to the way that you’d hand-construct a session to an on-premises deployment of Exchange 2010. Of course, few people bother to do this because Microsoft provides the warm comfort of a script to make the connection and build the necessary environment for administrators. That script is run when you select the “Exchange Management Shell” (EMS) option, which is how administrators generally run remote PowerShell for Exchange 2010.
We want control so we’ll do everything manually! First, run Windows PowerShell (running as an Administrator seems to be best). Once PowerShell loads, we run the Get-Credential cmdlet to collect the credentials that will allow us to connect to Exchange Online. You’ll need to provide the SMTP address and password for an administrator for an Exchange Online domain to be able to do anything useful.
$Cred = Get-Credential
Next, we create a new remote PowerShell session. There are two differences in the command that we use when compared to an on-premises deployment. First, the connection point is https://ps.outlook.com/powershell rather than the FQDN of an Exchange 2010 server that supports your mailboxes. You don’t know what servers your objects are stored on in Exchange Online, (and logically, the names of these servers are not revealed outside Microsoft) so the target is a general-purpose connection point that services all incoming requests for PowerShell sessions. The other magic is provided by the -AllowRedirection parameter. This instructs Exchange that it should redirect the connection to a server that can access data for your Exchange Online domain. In the screen below, you can see the name of the server to which I’ve been redirected.
$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection
Once we have a connection, we can import the connection into our session. The second command here is simply to satisfy my curiosity and to know just how many cmdlets are available to me during my remote PowerShell session with Exchange Online.
$NewSess = Import-PSSession $s
$NewSess.ExportedFunctions.Count
You can make things easier on yourself by creating a function containing these commands and inserting it into your personal PowerShell profile. This will allow you to simply execute one function to connect to Office 365 each time you use PowerShell, which seems like a good thing to do. For more information, see Brian Desmond’s blog.
As you might recall, part of the initialization processing that occurs when you connect to Exchange 2010 or Exchange Online is an RBAC evaluation to determine exactly what cmdlets (and indeed, what parameters for cmdlets), a user is allowed to run. My recent experience with Exchange Online shows that I generally am allowed to run 216 cmdlets. This is far fewer than is the case for an Exchange 2010 on-premises administrator who can expect to be able to run over 600 cmdlets, which means that you can’t assume that any script code developed to run against an on-premises deployment of either Exchange 2007 or Exchange 2010 will run against Exchange Online. Not only is it likely that some cmdlets will be missing, you can run into difficulties if you attempt to run code that expects to access system data such as the registry. Obviously, the cloud doesn’t have a registry!
On the other hand, the whole point of using Exchange Online is to allow you to devolve a large percentage of day-to-day mundane work to Microsoft so there’s no need for you to access cmdlets such as Get-ExchangeServer, Get-ClientAccessServer, or New-SendConnector that deal with issues that you will never concern yourself with, such as interrogating server information or creating new connectors.
Connecting to Office 365 with remote PowerShell
At this point, we have a functioning remote PowerShell session that is ready to run any of the cmdlets that we are permitted. Standard stuff that focuses on mailbox management such as Get-Mailbox or Get-MailboxStatistics work and it’s possible to do things like extract mailbox move reports. It’s also possible to manage mailbox settings with Set-Mailbox. For example, to set Single Item Recovery for a mailbox (not an option revealed by ECP), you run:
Set-Mailbox -id TRedmond -SingleItemRecoveryEnabled $True
Note that Set-Mailbox is one of the cmdlets that Exchange regards as “potentially destructive” and therefore comes under the control of the PowerShellMaxDestructiveCmdlets setting applied through a client throttling policy. The setting used in Office 365 seems to be more restrictive than in on-premises Exchange and if you attempt to run commands that change a lot of data you may be throttled back. For example, depending on the number of mailboxes you have, if you use Get-Mailbox to form a collection of all mailboxes and then use Set-Mailbox to change a setting, Exchange might tell you that it needs to delay things a little as it processes each mailbox. I guess the idea is to give you the chance to realize that you might be making a mistake (as if that would happen) and hit CRTL-Z before too much damage was done…
The properties returned by Get-Mailbox are quite interesting as they cast a light into how Exchange is deployed within Office 365. For example, I see that Microsoft keep archive mailboxes in the same database as primary mailboxes – probably following the KISS principle and keeping the deployment as simple as possible. You can also see some new cmdlets that Microsoft activates for cloud deployments. For instance, Get-MailboxPlan reveals the various mailbox plans that are available to apply to mailboxes. Think of a mailbox plan as a template of properties to apply to a mailbox to control how it functions. It would be nice if mailbox plans were also available for on-premises deployments.
So good so far and we’ve found out some esoteric but interesting information. Some additional poking around with PowerShell will reveal the boundaries that Microsoft has set on tenant administrators and determine just what is possible in terms of changing the environment to meet business requirements. For example, in the sequence of commands shown below, I list the set of retention policy tags defined by Exchange Online and the tags used by the default policy that Exchange Online automatically applies to all mailboxes. Then I create a new retention policy based on the set of tags plus an additional personal tag (Keep 10,000 days) and assign the new retention policy to my mailbox.
Adding a new retention policy to Exchange Online
New retention policy tags aren’t exposed in clients until the Managed Folder Assistant (MFA) processes a mailbox, so we force MFA to run to make the magic happen:
Start-ManagedFolderAssistant -Identity TRedmond
The next time we start a client (in this case OWA), we see the new personal tag show up.
New 10,000 retention tag appears in OWA
Interestingly, unlike with an on-premises deployment, some of the properties that can usually be set with Set-Mailbox are inaccessible with Exchange Online. For example, you can’t set a retention comment.
Amongst the other things that I have done so far with PowerShell is to create a discovery search mailbox (for some reason, Office 365 had not done this for my domain) and manipulate role assignments to assign my account the Discovery Management role so that I could perform searches. PowerShell allows an administrator great latitude in terms of getting real work done but it’s also got to be said that you can also do damage by running a naked PowerShell command if you don’t know what you are doing. The solution is to read up on the commands that you’re interested in (see the book reference below) and to test commands if at all possible before you run them for real.
Of course, if Office 365 is your production environment, you’ll want to maintain a separate instance of an Exchange 2010 on-premises test environment for this purpose. You can easily create such an environment with a couple of virtualized servers. Although it’s true that the two environments won’t be the same, you’ll learn a lot by playing with PowerShell in your testbed and so reduce the potential for making mistakes when you manipulate live data through the shell.
The conclusion therefore is that PowerShell is a very real weapon in the armory of the Exchange 2010 administrator whether you run on-premises or in the cloud. Sure, you can do less to manage Exchange in the cloud, but isn’t that the reason that you signed the contract with Microsoft?
– Tony
Note: If you need to manage both on-premises and cloud data in a single PowerShell session, you might like to consider applying a prefix to each connection so that you can identify the data you’re dealing with. See this post for more information.
Learn more about topics such as remote PowerShell (chapter 3), RBAC (chapter 4), and ECP (chapter 5) in Microsoft Exchange Server 2010 Inside Out
