Improve manageability of email alias of groups
Email alias does not support many characters that are common in email addresses (e.g. "dot"), and cannot be changed after initial configuration. Additionally, alias creates an email address using the tenancy's "default" domain--doesn't allow you to select a domain if a tenancy has multiple domains. Finally, can't be changed after creation. All three of these are painful!
Microsoft 365 Groups (formerly Office 365 Groups) now support the ability to update the primary email address of the group along with adding additional secondary email addresses. As mentioned in the previous update, the email address now can support dot as well. Thanks for the feedback!
Victor Ivanidze commented
You can manage SMTP aliases using UnifiedGroupManager tool:
Jens Jensen commented
Please allow managing aliases to groups through UI. Editing through Exchange powershell is cumbersome, and I understand they might not show up in the UI.
Don Buckley commented
Changing the group's primary email and adding aliases, +1000
Kari Vääränen commented
Being able to manage email aliases for an Office 365 group is really something that should exist in the UI. Being an admin with a Mac, I need to make special arrangements to be able to run powershell commands.
This is especially important as it is not possible to add an O365 group as a member in a distribution list (that would enable directing other email addresses to the O365 group email address).
[Deleted User] commented
It would be really nice to edit Mail-Aliases within the GUI. It should give you the same possibilities as a distribution group.
Nigel Gibbons commented
Further to my last post a quick update.
Instead of relying on the generic 'Get-Recipient' command I found the emails associated with the O365 Groups using:
'Get-UnifiedGroup -ResultSize Unlimited | select DisplayName,RecipientType,EmailAddresses | Out-GridView'
Thanks to Adam Drayer (http://online.platformscholar.com) for pointing this out to me.
This does not excuse the lack of visibility of these O365 secondary emails in the console or external routing that I still cannot get to work on the secondary aliases. Furthermore the fact that O365 Groups also seems to create additional undisclosed emails.
Nigel Gibbons commented
Add to which trying to ID email aliases configured on an Office 365 tenant. It appears O365 Group assigned email aliases do not to appear when enumerating all emails in Office 365. The strings I am using lists Distribution Groups, Contacts, Shared Mailbox's and normal users but NO O365 Groups.
Get-Recipient -ResultSize Unlimited | select DisplayName,RecipientType,EmailAddresses | Out-GridView
Get-recipient -resultsize unlimited | select Name -expand emailaddresses | Out-GridView
Also tried using the Parameter 'Alias' in the last string with little added benefit.
The more I dig the more I am finding anomalies in the way that O365 Groups seem to be implemented when it comes to email Aliases. For example, converting a Distribution List with multiple email aliases to an O365 Group renders all secondary aliases that were configured under the former Distribution List INVISIBLE. No end user warning nothing!
Consider the disappearing act of the DL aliases post conversion is not immediately obvious until users realise they no longer will accept externally routed emails (they will accept internally routed ones). Dig a little more and the mess gets worse, whilst it appears possible to create MULTIPLE secondary aliases via PowerShell for a single O365 Group again there appears to be no way of flagging them to accept external emails. Only the principle email aliases for the O365 group seems to be manageable with the '-RequireSenderAuthenticationEnabled $false' Parameter string.
So O365 Groups use of aliases seems poorly executed, apart from the naming convention support shortcomings already noted by users. User Experience 101 is to keep with the familiar and stay consistent. O365 Groups are doing everything BUT that. Why do they not conform with the same support for aliases (naming, secondary allocations etc) as Distribution Lists?
Its challenging enough keeping pace with the 'Ever Green' nature of Cloud SaaS solution new features without the manifesting of unique and illogical new ways of implementation for know elements ie: aliases.
Mohammad Sarosh commented
You can use Email Address Policies to change the domain of the group's email address. https://support.office.com/en-us/article/Multi-domain-support-for-Office-365-groups-Admin-help-7cf5655d-e523-4bc3-a93b-3ccebf44a01a?ui=en-US&rs=en-US&ad=US
David Schrag commented
Office 365 Support showed me how to edit aliases with PowerShell but there's still a lot of room for improvement. (Microsoft: see ticket #30126-5634323.)
Jeffrey David Marraccini commented
This is also important for us. For now we have worked around it by adding Contacts that reference the group, but this results in a lot of extra entries in the Global Address List and Active Directory.
Rob Nicholson commented
Is it still not possible to rename the email address after a group has been created? It's not unusual for a project to change it's name...
I would like use dot "." in alias group and manage not a single alias but many aliases like standard group. Thanks.
Coming within weeks! https://twitter.com/cfiessinger/statuses/668539799070900224
Kyle Duffy commented
This is why we have groups disabled. Not being able to change the address after initial creation set us up for failure.
Imran Masud commented
Alias aka MailNickName.
PrimaryStmpAddress aka proxyAddress with capital "SMTP: prefix".
Today when you create a group we try to use alias /groupid/ mailnickname to construct the primary smtp address. PrimarySmtpAddress is always unique. If firstname.lastname@example.org is not unique the system will append postfix make it unique such as email@example.com
Note alias and primary smtpaddress are usually used for ANR searches. You could potentially have a group with alias foo and primary smtp address as firstname.lastname@example.org. If you search for foo or bar you will find your group. Not a practical case just wanted to highlight that they are different.
Today group owners cannot add or update smtp address, however your Tenant admin could perform these operations via Set-UnifiedGroup. Note it is never a good idea to remove your original primary smtp address because it will break your mail routing of your previous messages . The recommendation for tenant admins is set a new PrimarySmtpAddress via Set-UnifiedGroup,
how was ictgroup got created. Was it created from outlook web access (OWA). There is a bug which has been fixed now where AzureActiveDirectory shows incorrect primary smtp address of exchange resource.
We understand that every org wants sanitized GAL; NamingPolicy and Blocked words could help. That said we are also taking in your feedback to further improve this experience.
Thank for your feedback.
this is very important because for some reason when we created our internal ICT Group it created email@example.com instead of firstname.lastname@example.org - and we cannot change it. And yes, our current default domain was companyname.com so it does not make any sense. MSFT tech support was not able to resolve and told me this was a feature coming in 2015
Claudio Torres commented
at bare minimum the email alias today should use the prefix/suffix added to the naming policy of dist lists in exchange admin. As of now the naming only applies to the group name whereas the email sticks to name without the added policy. This makes it possible to any user to create whatever group they want and "lock" the email adress within our total domain scope. I would really want to separate the group default email naming scheme from our manually created /admin/ groups/user emails.
Bob McCoy commented
I agree with Dan Holme, but I do not want my users to be able to select from a list of domains. I want, as a global admin, the ability to designate the default domain for Groups separate from the tenanat default domain. I want all tools that use a "default domain" to have a configurable setting as to what the domain is so each could be separate (IE: Groups = groups.rootdomain.com, Distribution Lists = lists.rootdomain.com, etc).