Forum Discussion
MicrosoftOffice 365 Groups will now have unique mailNickname
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?
Thanks!
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].sharepoint.com/sites/42e985d2-e9a3-49fd-a0b8-96a8169461bb).
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.
