Exchange Online

Exchange Online Service Account Options

Going from Exchange On-Premises to Exchange Online can be a bit of a learning curve. One of the changes is having to worry about licensing a lot more; on-prem you can have as many service accounts as you need (e.g. a ticketing application may need access to a mailbox to send and receive emails, or to create IT Helpdesk jobs from emails) and you’re good to go.

With Exchange Online however, every single account needs to be licensed. As per Microsoft’s FAQ on the topic:


Exchange Online is licensed via a subscription model in which each user needs a User Subscription License (USL). Three types of subscriptions are available: Exchange Online Kiosk, Exchange Online Plan 1, and Exchange Online Plan 2. These subscriptions can be purchased on their own or as part of an Office 365 plan that includes SharePoint Online, Skype for Business Online, and Office ProPlus.


Here’s a breakdown of all the license options for Exchange Online, and what features each license has.

Your normal users are probably going to have some sort of business package applied to each user – one of the most common is Office 365 Enterprise E3, but generally not value for money for a single purpose service account.

The Exchange Online Kiosk plan is the cheapest, but limited.  Also note that there’s the Office 365 F1 plan which includes Exchange Online Kiosk, but again is a more expensive package with features you probably don’t need. Although this license can also be used to access another mailbox, there are many limitations such as “Exchange Online Kiosk does not provide access rights for utilization with on-premises servers.” and the ability to access the mailbox using Microsoft Outlook. It also can’t use Exchange Web Services (EWS) which is one of the more modern ways that a developer will read or manipulate emails.

Exchange Online Kiosk has the brief description of “Basic messaging and calendaring plan with Web email and POP access.” If you purely want to send emails via SMTP using Office 365’s SMTP connector, then this is what you need.

For most other functions, you’ll need at least Exchange Online Plan 1. This is the next cheapest option, and gives you a standard fully working Exchange Online account with a fully functional mailbox.

There is another option around all this; if you’re happy to run Exchange Hybrid but have all your mailboxes in Exchange Online, you’re entitled to a free Exchange Server license. With that in place, you can use SMTP relays to allow your on-premises accounts to use that connecter without a license, and have that relay back to Office 365. It’s also possible to do ignoring  Exchange Hybrid if you build your own IIS server and SMTP Relay. Both of these options are great for devices like printers that may be sending emails anonymously, or to avoid changing configuration of all your devices with the new Office 365 SMTP server smtp.office365.com .

As you’ll need to do license management and probably be looking at month to month charges, it’s important to understand licensing and allocate in the most cost effective way. Of course, all this may change so please check official Microsoft documentation to ensure you’re getting what you need.

Exchange Online and Exchange On-Premises Security Groups

I had a requirement come up where I needed a list of Exchange Online users as well as Exchange On-Premises users. If you’re hybrid or going through a long migration, there’s many scenarios where you want certain products or settings applied against the users and accounts based on where their mailbox is.

You could maintain that manually, but why do that when you can automate it!

Thankfully there’s two easy commands that will return accounts based on where they are – get-mailbox and get-remotemailbox. As long as you’re in Exchange Hybrid mode, you can run both of these commands against your local Exchange server.

Here’s the quick script I wrote up:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exchange server name/Powershell -Authentication Kerberos
Import-PSSession $session
$remoteusers = Get-RemoteMailbox -resultsize unlimited
$onpremusers = Get-mailbox -resultsize unlimited
$remotegroup = "Exchange Online Users"
$onpremgroup = "Exchange OnPrem Users"

Get-ADGroup $remotegroup | Set-ADObject -clear member
Get-ADGroup $onpremgroup | Set-ADObject -clear member

foreach ($user in $remoteusers){
Add-ADGroupMember -Identity $remotegroup -Members $user.SamAccountName
}

foreach ($user in $onpremusers){
Add-ADGroupMember -Identity $onpremgroup -Members $user.SamAccountName
}

Remove-PSSession $Session

All I’m doing here is getting the two user types and putting them into variables – $remoteusers and $onpremusers. I’ve also used the group names as variables, so you can create whatever AD groups you like and put them into the $remotegroup and $onpremgroup variables.

Also I’m clearing out all members of the group before adding users, which means if someone gets migrated or leaves, they’ll be cleaned up from the old group properly.

Finally I’m going through the two users lists and using ‘foreach’ to add each user to the relevant group, using the SamAccountName value of each result to identify them.

It’s only a basic script, but you can easily add extra filters to the Get-Mailbox and Get-RemoteMailbox commands to do things such as only getting users from certain OUs.

This was tested on Exchange 2010, so if you get different results on Exchange 2013 or 2016 please let me know.

Connect to all Office 365 services via PowerShell

I found this great TechNet article and wanted to share:

Connect to all Office 365 services in a single Windows PowerShell window

It’s a greatly described article about how to connect to each Office 365 service – MSOL itself, Exchange Online, Skype For Business, SharePoint Online and the Compliance Center.

If you go through the article, you can set up a script to prompt you once for Office 365 administrator credentials, and connect to each service for a one stop shop on managing your Office 365 environment from PowerShell.

One catch (which is mentioned in the article) is that you’ll need to run PowerShell in Administrator mode, or you won’t be able to import modules. You’ll see an error like:

The specified module 'Microsoft.Online.SharePoint.Online.PowerShell' was not loaded because no valid module file was found in any directory.

If you aren’t sure if you’re in Administrator or User mode, the default path prompted in the PowerShell window will be “PS C:\users\username>” for User mode, and “PS C:\Windows\system32>” for Administrator mode (along with the word “Administrator” in the PowerShell window title.

I’m only new to Office 365, but I’ve found the GUI via the web for user management rather basic – I can’t do simple tasks such as search for users on a specific domain, then add them to a group. PowerShell is absolutely necessary if you want to manage Office 365.