I’ve just been reading on Mike Pfeiffer’s blog this article about connecting Remote Powershell to Office 365. I’ve not yet got my beta account on Office 365, but do use Live@EDU/Outlook Live and had been wondering how similar administration is. It turns out that it’s exactly the same (even down to the server names) therefore I thought it might be worth sharing a method I’ve been using for some…

Because there is such a big overlap of cmdlets between your On Premises Exchange 2010 environment and Office 365/Outlook Live, it can be a bit of a pain when you want to write a script that performs actions on both. I’ve documented how to do this in a previous post, but when you are disconnecting/connecting between environments, it can get pretty confusing. A simple error in a script can mean you create mailboxes in the wrong environment.

The solution is to use the -Prefix parameter when you’re connecting to each environment. This means that, for example, Get-Mailbox can appear as Get-OnPremisesMailbox and Get-CloudMailbox. Your scripts can now easily target either environment, or both in the same script and you won’t need to keep on checking whether you’re performing actions against the local Exchange server or your “cloud” environment.

To demonstrate how simple this is, here’s a quick example of connecting to both environments:

This should connect us to both environments and even allow us to combine On Premises and Cloud Powershell cmdlets together. For example, to get a total of all your mailboxes, both On Premises and in Office 365 / Outlook Live:

You can also combine commands via the pipeline. In the next example, we will get all On Premises mail-enabled users that have an External Email Address (eg they are synced using OLSync/DirSync) in our Office 365 / Outlook Live domain, then start a foreach loop (using the % shorthand) and then retrieve details about the mailboxes from Office 365 / Outlook Live:

Finally, a few notes for those who are just starting to play with Office 365 or Outlook Live via Remote Powershell. Firstly, you might need to set your Powershell execution policy (at an elevated command prompt) the first time you connect:

And if you are developing/testing and you find the Get-Credential part above tiresome, you can  replace the line with a hard-coded plain text username/password. Be wary of using this in your production environment, due to the security implications of hard-coding an admin password in clear text into a script:

Hope this helps!