UPDATE: I have created a module to make the process more streamlined. The post has a link.
Office 365 (O365) Groups have existed for a while now and have began to reach a level of maturity that supports broader usage. In addition, many newer features in O365 depend on O365 Groups.
What are Office 365 Groups
O365 Groups are a Service-only capability that is very reminiscent of the Site Mailbox integration that was found in Exchange and SharePoint. Each Group has an Exchange mailbox and a SharePoint document library along with Group members and owners. In many ways, an O365 Group behaves like a distribution list. What O365 Groups are is what I would call a Secondary-service in O365; beyond Secondary-services, there are also Tertiary-services. So, what does this mean? Well, the Primary-services are the “flagship” products in O365: Exchange, SharePoint, and Skype for Business. O365 Groups are a Secondary-service because they rest on the foundation of the Primary-services of Exchange and SharePoint. OneDrive for Business is also a Secondary-service as it is dependent upon SharePoint. Tertiary-services are emerging that are dependent upon Secondary-services and Primary-services, namely Microsoft Teams that rest upon O365 Groups and Skype for Business, and Planner that also uses O365 Groups:
So, O365 Groups are very important and should be well understood in order to properly implement the dependent services.
Like many new capabilities in the Microsoft Cloud, O365 Groups are enabled by default. From Microsoft’s perspective, this can help with adoption of these new capabilities and is quite necessary when you begin considering their desire to increase adoption of not only O365 Groups, but its dependent services, as well. However, having Groups enabled by default creates many challenges. First and foremost, Groups can just be created by end-users without the need to consider how they should be used within the organization. Also, since Groups have an Exchange mailbox, they have an email address. The other challenge is that Groups are Service-only and do not have an associated object in on-premises Active Directory, even when using directory synchronization, by default. This means that on-premises mailboxes, devices, and applications cannot send to O365 Groups.
Beyond the collaborative offerings that O365 Groups creates, there are other benefits to Groups. One significant challenge when implementing O365, specifically in deployments with directory synchronization, is that distribution group owners cannot manage membership from within Outlook/OWA, as they might be accustomed from on-premises Exchange. The reason for this is that group membership changes must happen in on-premises Active Directory when using directory synchronization and Outlook does not make changes to on-premises Active Directory from Exchange Online, it attempts to update the Exchange Online Directory Service (ExODS) that is fed from Azure AD. One reaction might be to eliminate directory synchronization or to make cloud-only distribution groups. Eliminating directory synchronization is not a good practice in most situations because of the advantages that it offers, and in many situations is simply not possible. Creating cloud-only distribution groups could be prudent, but it doesn’t have an on-premises counterpart, unless one is manually created, which is possible, but is administratively burdensome.
Other options for managing distribution groups is to use other tools for group owners to manage them, including delegated permissions with Active Directory Users and Computers (difficult and uneasy at best), RBAC permissions for group membership in Exchange Admin Center on-premises (not bad, but requires implementation and training), Microsoft Identity Manager Service (very heavy implementation), or a 3rd party product (numerous considerations and challenges).
O365 Groups address some of these challenges out of the box. Since they are Service-only (at least to start), they are created as cloud-only entities that can be managed by owners from Outlook, just as they are accustomed. This creates a very low barrier to entry for end-users.
So, this leaves us with remaining challenges:
- Restricting access to group creation
- Groups create email addresses that could collide with future email addresses
- Groups do not have an on-premises counterpart
Restricting the Creation of Office 365 Groups
Preventing the creation of new O365 Groups is a prudent tactic to pursue until the proper framework is implemented to effectively manage the groups.
In addition, there are limitation to the creation of O365 Groups:
- A user can create up to 250 O365 Groups, except for administrators who can create an unlimited number 
- By default, only a total of 500,000 O365 Groups can be created, but a ticket can be submitted to increase the limit in the tenant 
NOTE: The Get-AzureADDirectorySetting cmdlet is only available in the AzureADPreview module and not the GA AzureAD module, at the time of this writing. In order to follow these instructions, the AzureADPreview module will be required. This module cannot co-exist with the GA AzureAD module and must be uninstalled to accommodate the installation of the preview module.
- Create a security group to control who may create O365 Groups (I prefer an on-premises security group that gets synchronized up) and add pilot members
- Allow Azure AD Connect to synchronize the group (can be forced with
Start-ADSyncSyncCycle -PolicyType Delta)
- Sign into Azure AD PowerShell (with the AzureADPreview module) and set the group:
- Verify success with:
Further control with the Azure AD module .
UPDATE: In my new post, Controlling Office 365 Groups Creation, I have created a module that provides a single command to do all of the work above.
Create an Office 365 Groups Domain
To avoid potential collisions and issues with O365 Groups being created, dedicated domains can be created for O365 Groups. Commonly, this can be established with a subdomain, like “groups.domain.com”. This offers a great solution to a fundamental structure in O365 and Azure AD; if Identity Federation is used, this is done on a per-domain basis, so cloud-only security principal cannot be created with a federated domain. By having another domain, this limitation is bypassed. Other intuitive options could be shortened versions, like “g.domain.com” or “grps.domain.com”.
How Can Office 365 Groups Create Collisions?
When operating with hybrid co-existence, most mail recipients in Exchange Online (mailboxes, groups, mail users, and contacts) are managed on-premises. This is great because it allows you to continue using many of your processes and management tools and still facilitates the operation of email address policies that aren’t available in Exchange Online; and more importantly, it keeps a unified identity solution which is better for administrators and users, alike. This is where the issue arises. Your email address policies create standard addresses for mail recipients, like FirstName.LastName@domain.com. This is done automatically and Exchange keeps track of things so that you only create unique addresses. Creating an O365 Group also prevents you from creating a duplicate address in the cloud, but it isn’t synchronized back on-premises, by default. Since any user can create an O365 Group, by default, users could do things like create a group named in the format of a user or a group that may come in the future and on-premises Exchange is completely unaware of this group, so it wouldn’t prevent an email address policy from using the same address. When directory synchronization runs, it will encounter an error.
Creating a group domain  has numerous steps:
- Add the group domain in O365 Admin Center
- Add the group domain as an accepted domain in on-premises Exchange (as internal relay, not as authoritative)
- Create a DNS MX record for the domain (e.g.
@ MX groups-domain-com.mail.protection.outlook.com)
- Create an Autodiscover DNS CNAME record (e.g.
groups CNAME autodiscover.outlook.com)
- Add the group domain to the Send Connector created by the Hybrid Configuration Wizard.
- In Exchange Online PowerShell, create a new email address policy to assign the groups domain to O365 Groups (e.g.
New-EmailAddressPolicy -Name Groups)
-IncludeUnifiedGroupRecipients -EnabledEmailAddressTemplates "SMTP:@groups.domain.com" -Priority 1
Email Address Policies in Exchange Online?
Don’t get too excited here, the Email Address Policies in Exchange Online are only available for O365 Groups. This provides support for using different domains (i.e. domain1.com and domain2.com) and assigning the domain based on other criteria (e.g.
Department -eq "Domain1")
This solves one management challenge of creating O365 Groups. However, it does not create an on-premises counterpart, yet.
Enable Group Writeback in Azure AD Connect
Azure AD Connect (AAD Connect) has a growing number of “writeback” options. Normally, synchronization flows from on-premises Active Directory to Azure AD, but writeback capabilities allow bi-directional synchronization in some cases, or just synchronizing from Azure AD to on-premises Active Directory, in the case of Group writeback. One key consideration is where you would like these groups to be written in your on-premises Active Directory. Since Azure AD is a flat directory without organizational units, it must be explicitly defined. My recommendation would be to dedicate an OU for these groups.
Enabling writeback  has numerous steps:
- Execute the AAD Connect wizard and select “Customize synchronization options”
- Follow the steps through to the “Optional features” page and select “Group writeback”.
- On the “Writeback” page, choose the OU where you want groups to be written.
- Follow the steps through to the end of the wizard and have it configure the settings.
- Find the “AAD_” or “MSOL_” WBAccaccount that AAD Connect will use to write to Active Directory
- In the Exchange Management Shell, run the following commands:
$WBAcct = "AAD_e3uajshg452fvgh"
$GroupsOU = "OU=Groups,DC=domain,DC=local"
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1"
Initialize-ADSyncGroupWriteBack -ADConnectAccount $WBAcct
Creating New Groups
Creating new groups through the Exchange Admin Center in Exchange Online will let you select any domain name for new O365 Groups. However, using the
New-UnifiedGroup command without specifying the domain name allows the Email Address Policy to assign the domain.
This same experience is found in Outlook and will prevent users from selecting just any domain.
Converting Distribution Groups to Office 365 Groups
Microsoft has a process for “upgrading” distribution groups to O365 Groups , but there are numerous limitations for groups that cannot be upgraded:
- On-premises managed distribution groups
- Nested distribution groups
- Groups with recipient types besides UserMailbox, SharedMailbox, TeamMailbox, and MailUser
- Distribution groups with more than 10 owners
- Distribution groups without any owner
- Distribution groups with invalid characters
- Dynamic distribution groups
- Room lists
While potentially useful, it is rather limited because of the restrictions. Please see “Update distribution lists to Office 365 Groups in Outlook”  for more information.
Azure Active Directory Naming Policies
A new feature on the roadmap is Naming Policies for Azure AD. These will require Azure AD Premium licensing and will allow you to establish standards to the creation of names for O365 Groups, such as – – .