Exchange Online

Users Managing Email Groups and Exchange Online

For a very long time, users have been able to manage email group members via the Outlook client. Going into the Address Book, finding the group in the Global Address list, going into Properties and choosing ‘Modify Members’:

From there, someone can add or remove members as long as they’d been added to the “Managed By” field against the object in Active Directory, as well as ticking the box “Manager can update membership list” below it.

Easy! Except, that no longer works if the user is in Exchange Online, and the Email Group is from on-premises AD rather than Azure AD/Office 365. It’s not supported. This problem has been around for a while, back in 2015 Perficent wrote about this same topic. The options given for managing these groups are:

  • Exchange Admin Center
  • Exchange Management Console
  • Exchange Management Shell

None of those are what you want your standard users touching in my opinion – although you can give someone access to the Exchange Admin Center and only see the distribution groups they own – but for me, I’m still on Exchange 2010 so this isn’t an option.  This leaves you with a few options:

1. Change all your email groups to Cloud based groups. If this makes sense for you, doing this will let the manager of a cloud based group add/remove members via the Outlook Address Book.
You can also look at changing distribution groups over to Office 365 Groups (which are also cloud based), which give a whole bunch of different features beyond a what a distribution group can do, while giving the same standard DG experience.

2. Make all requests come through to IT so you can make the changes yourself. Not great for anyone involved, as it’s double/triple handling something where the user could quickly do it themselves.

3. Create Dynamic Distribution Groups and let automation do it’s thing – which will work for some, but exceptions to rules and the inability to see who’s in a group can make this frustrating for some.

4. Provide another way for staff to change group members themselves.

I’ve gone with option 4 – as I’m a big fan of Adaxes which I’ve written about a few times on my blog before, and they have a nice way of giving users a web interface that only lets staff manage the groups they’re the owner of.

There’s other ways to do this as well of course and other 3rd party solutions that can expose ways of adding/removing members of a on-premises distribution group – but remember there could be up to a half hour delay in syncing the change from AD to AAD via Azure AD Connect. If possible, look at adding a trigger at the end of a group change to do a delta sync:

Start-ADSyncSyncCycle -PolicyType Delta

That’ll be the quickest way to get the change up quickly, as staff may be used to the change working immediately.

There’s a lot to consider on how you’ll manage this, so make sure it’s sorted before you migrate – or expect a lot more tickets going through your helpdesk.

Migrate a Single Mailbox Out of a Exchange Online Migration Batch

A few posts on this since it’s what I’m working on :)

It is possible to sync all your mailboxes from Exchange On-Prem to Exchange Online as a single batch, and then complete individual items – but it’s not obvious that this is even possible.

Normally if you start a migration, you can choose multiple mailboxes or use a CSV file to specify which accounts to start migrating – while specifying the option to manually complete the batch, so the actual migration happens when you want it to:

The problem is, once you’ve fixed any problems that arise and mailboxes are in a ‘synced’ state, there’s no visible way to complete a single mailbox – just the whole batch. That may not be what you want to do. You could work out a way to create a separate batch for every single mailbox you’re migrating, but there’s also a way to complete one mailbox at a time.

In PowerShell, once you’ve connected to Exchange Online, you can run the a command to see all the mailboxes syncing, and their status:

Get-MoveRequest

If a mailbox is ready to be finalised, it should have the status of ‘Synced’. This is different to the status of ‘Completed’, which occurs once the mailbox has been fully migrated across.

To trigger the completion of a single mailbox in a batch, use this PowerShell command:

Set-MoveRequest -Identity “mailbox name” -CompleteAfter 1

The mailbox will then do it’s final syncing and complete, without affecting the other jobs in the same batch. The -CompleteAfter parameter is supposed to set the delay before the request is completed in date/time format, but using the value ‘1’ seems to immediately trigger this.

Now you can do a single batch job, and selectively complete mailboxes as you choose – easy! 

(Note that there was an old method of doing the above by setting the variable SuspendWhenReadytoComplete to $false which no longer works)

Exchange Online Mail Enabled Security Groups

One of the things I’ve found out while migrating to Exchange Online was around access to shared mailboxes, and having to alter my methods slightly.

For Exchange On-Prem (Exchange 2010), whenever I created a shared mailbox I would control access with a security group. If the mailbox was called “Finance”, then I’d have an Active Directory Security Group called “Finance Mailbox Full Access” and give that group full access to the mailbox. Then, I’d add the staff that needed access to that group – meaning it was easier to track and manage who had access to what, particularly with nested group support so I could add a whole department in.

The extra win on this approach was around applying logic to the groups. When someone joined or left Finance, the user management process would ensure the user was added to a group for Finance. That would then feed into all the access that Finance were granted through the groups that single group was inside – and it works great. 

The good news is that this is still possible going to Exchange Online, my nested and automated systems can continue to work. However, some changes were required to make this work.

Firstly, any security group that is going to be added to an Exchange Online mailbox for access must be mail enabled. This goes against my personal best practice as I liked complete seperation of security groups and email groups, because I didn’t want to deal with scenarios where ‘All Finance need this resource, but I don’t want them to get the emails about the same resource’. Still, having a descriptive security group name should avoid that happening. 

This leads to another catch – to mail enable a security group, it has to be ‘universal’. In turn, that means every other group that those groups are inside also need to be universal.

For me this was easy, since all my security groups were cleanly in a single OU, and there was no impact to me on changing them to universal (check this for yourself though!)

Get-ADGroup -SearchBase 
“ou=Security Groups,ou=ABC,dc=com” | Set-ADGroup -GroupScope DomainLocal

After that, ,ail enabling an existing security group is easy with the PowerShell command:

Enable-DistributionGroup

I was actually able to mail enable all my Security Groups that granted mailbox access at once, by getting all the groups and filtering them down to only ones that contained the word ‘Mailbox’

Get-Group -resultsize unlimited | where {$_.name -like “mailbox“} | Enable-DistributionGroup

You’ll also need to mail enable any groups inside the groups, and you should be able to work this out based on the above commands.

Keep in mind you’ll probably want to hide all these groups from the address book so users can’t see them – in Exchange 2010 the GUI lets you mass select and change this option, but it’s also easy to do from PowerShell (but you’d need to 


Get-Group -resultsize unlimited | where {$_.name -like “mailbox“}| Set-DistributionGroup –HiddenFromAddressListsEnabled:$true

Note that if you use PowerShell to give a non mail-enabled Security Group access to a mailbox, it will appear in the Exchange admin center, but it won’t work. As far as EAC knows, it has no members because it’s not mail enabled. I found this out the hard way!

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.