Office 365 Groups will now have unique mailNickname


Hi all,


We've completed an enhancement with the Azure Active Directory team which will now enforce mailNickname to be unique across all Office 365 Groups within a tenant. This will help ensure resiliency across the tenant and facilitate smooth sync scenarios to on-premises.


When Office 365 Groups are created, the name provided is used for mailNickname as well as the first portion of SMTP Address. Previously, Office 365 Group creation did not enforce the mailNickname to be unique across Office 365 Groups. If multiple Office 365 Groups contain the same mailNickname, customers can encounter collisions when these groups are sync’d to on-premises via AAD Connect. In Azure Active Directory, an enforcement has been placed on the mailNickname property so that it will be unique across Office 365 Groups.


Previously created Office 365 Groups that have duplicate mailNicknames will not be affected. If a user attempts to modify the mailNickname property through PowerShell or other means, the service will verify whether the new mailNickname being specified is unique. If not, the modification will be rejected. Additionally, a user can create an Office 365 Group that has the same mailNickname as an Office 365 Group that has been soft deleted. If a user attempts to restore the soft deleted group, they will be prompted to change the mailNickname.


Mike McLean

Office 365 Groups

Senior Program Manager

17 Replies

thanks for the heads-up.

Super a lot of people were waiting for this!

Shouldn't Groups make sure that the mail nickname is unique across all types of mail-enabled objects rather than just inside its own set? Having a synchronisation clash with a DL (for instance) could also be a problem...

Exactly. The alias should be unique across all mail-enabled objects in the tenant.  If I have an ADFS replying party passing mailnickname/alias as a claim for example, any dups will cause problems, just to give another example beyone Tony's .

This is a great observation. For this first step, we're mainly focusing on enforcing uniqueness across cloud-managed Office 365 Groups. One approach we've seen customers use is to build a universal Alias Reservation List that guarantees uniqueness across all their services that create mail-enabled properties, including on-premises.

I really don't think you need anything more complicated than to check all mail-enabled objects (rather than just Groups as you do today) to detect duplicate aliases...

Is it possible to create Office 365 groups created via Team Sites, Planner, Yammer, Stream and Teams with a unique display name? If yes, How?


We would like to prevent the creation of Office 365 groups with duplicate display names in the organization.

Microsoft has committed to delivering a naming policy for Office 365 Groups that might help. Hopefully, we will see news of this at Ignite.


For now, if you want to be sure that Office 365 Groups created using Outlook, OWA, the Outlook and Groups mobile app, or the New-UnifiedGroup cmdlet have names that meet a certain standard, you can use the Exchange Online distribution group naming policy.


This policy does not apply to groups created by admins or those created by Teams, Stream, or other Groups-enabled applications.

This change is messing with some of our provisioning techniques. The MailNickName / Alias was a 'sure thing' property to use across ecosystems. In the Azure AD, Exchange Online and SharePoint Online realms that single property was unifying everything. All of a sudden this property is changed to a guid behind the scenes with no apparent rhythm to it.


Question: What unifying property should now be used that can be created and queried in Azure AD, Exchange Online and SharePoint Online? BTW It was suggested to me to use the Exchange Online ExtensionAttribute1-15 properties, but these are not queryable (to my knowledge) in Azure AD.


Question2: Can we disable the automatic changing of MailNickName / Alias by backend processes to guids and be in charge ourselves? Ie. manage the Alias ourselves?



@SjoerdV You're right that the Exchange extension properties are unavailable in Azure AD. They're very much an Exchange construct.


It seems to me that GUIDs are the only way to ensure uniqueness across Office 365, and that's why the developers use GUIDs everywhere.

@TonyRedmondThanks Tony.

I love guids as well ;) if they are used consistently....


Consider the fact that a MS Team consist of (among others) 1) a Azure AD Group, 2) Office 365 Group (EXO) and 3) a SharePoint Online site. Where can I find the guid when in SPO context? You would not suggest using it as part of the Uri? (ie. https://[tenant]


The fact that if I create a Group/Team by specifiying the Alias (forcefully) and it gets overriden by backend processes that is running irregularly is scary, we now never know when the alias will be changing and if I had specified it in the first place, why is it being overridden at all? Is the development team not trusting me in keeping the Aliases unique? If the development team want something unique why not create a new property for that and leave us our Alias/MailNickName? Btw. When I specify a guid myself 'on creation', will it stay that particular guid, or will the backend process change it to a different guid?


Finally, consider the DTAP question. We always create a Team in a totally seperate Azure+O365 TEST tenant programmatically first, check that the provisioning tool does not return any errors and checking Targetted Release compatibility, before creating it in the PROD tenant. If I just use the same guid in TEST as in PROD (to keep a reference between the groups), what is now the difference between creating them with a string as a unique characteristic and a duplicate guid? Absolutely nothing, right?

Will the product team eventually prevent duplicate guids across tenants? That would be something!


@SjoerdV If you run Get-SPOSite -Detail you'll get the Group identifier (GroupId) returned. That can be used to link to the team, Office 365 group, or Azure AD Group.


But I am interested in your assertion that background processes are overriding the Alias property for groups.


I just checked all the groups in my tenant, and I don't see a single "strange" alias, apart from one group created in Teams when the New-Team cmdlet was run without an Alias being specified. When this happens, Teams creates an alias based on a GUID.

@TonyRedmondOK, thanks for the tip about the Group Identifier on the Site object of a Group.. I checked but this identifier is an empty guid (for all Groups, tested on multiple tenants) as it seems (I use version '16.0.9119.1200' of the 'Microsoft.Online.SharePoint.PowerShell' module btw)


RelatedGroupId                              : 00000000-0000-0000-0000-000000000000
GroupId                                     : 00000000-0000-0000-0000-000000000000


We create Groups/Teams by using SPO CSOM from PnP, and the Alias is always used in this process. like so:


We have to do it like this because all other Team/Group creation endpoints do not create the SharePoint Site immediately, and we need some basic things configured in the Site as soon as the Group gets created.


We also set Azure AD settings/policies, Exchange Online settings/policies, Teams settings/policies and Compliance retention policies by using the object model during this provisioning process (using the Alias as an identifier)


After this has all been set, at a certain point in time (could be a day, or more) the Alias changes by backend processes to a guid, I have no idea why and how this is triggered (Maybe something with the Compliance Center Object Model that is triggering this after a certain time, perhaps when actually creation the Preservation Hold Library?). If you could find out I would appreciate it very much.


BTW. I just renamed the aliases all back to the ones I defined myself by using powershell (Set-UnifiedGroup [guid] -Alias [myownalias]), but I expect I will have to check for alias changes and repeat this for the time being. (Get-UnifiedGroup | select DisplayName,Alias).


Thanks for your continued assistance!


@SjoerdV Did you include the -Detailed parameter to Get-SPOSite? If you don't, you won't see the group identifier information.


Creating a group with New-UnifiedGroup or New-Team used to experience a delay in provisioning the SPO Site. That delay is minimal today. Perhaps you should revert to these methods where (AFAIK) the alias is preserved.

@TonyRedmondYes, I did, using both the MS Powershell and PnP Powershell, on multiple tenants, the show an emtpy guid only...


Thanks for the advice on changing the Creation call, I might consider it.


Thanks again for all your advice in this thread, much appreciated!