We saw previously on the blog some of the great features that you have at your disposal when using Office 365 Groups in conjunction with Dynamics CRM/Dynamics 365 for Enterprise. When deployed prudently, they can massively enhance what is traditionally possible via distribution groups and give internal/external users a better way to collaborate with content, as opposed to a mountain of email attachments. As I cautiously hinted towards in the above post, some thought should go into how you go about rolling out Office 365 Groups across your organisation, which should inevitably include internal testing. By doing this, you can highlight a particular functionality quirk that you will more than likely need to address before issuing a general rollout.

When you first go to create an Office 365 Group, you will notice that the domain address of the newly created group mailbox has defaulted to the onmicrosoft.com domain for your Office 365 tenant, instead of any bespoke domain you may have setup on your tenant:

You would think that this is caused by the fact that the Default Domain for the tenant is still set to the onmicrosoft.com domain, as we can see below:

However, after changing this accordingly, we are still forced to create a Group email address that utilises the onmicrosoft.com domain:

Rather frustrating! Fortunately, there is a way in which we can get around the issue, which involves two steps if you have existing Office 365 Groups that need renaming:

  1. Modify the Email Address Policy for your tenant via PowerShell to force new Groups to use your desired domain.
  2. Update the SMTP address of all existing groups via PowerShell.

Both of these steps will now be demonstrated, but be sure to have PowerShell installed on your machine first before you begin.

Connecting to your Office 365 tenant

Start your PowerShell client as an Administrator (Run as Administrator option on Windows) and execute the following command first to ensure all subsequent scripts run correctly:

Set-ExecutionPolicy RemoteSigned

You should receive a prompt similar to the below:

Press to proceed

Now we are ready to connect to Exchange Online, using the following cmdlets:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

You’ll be prompted to enter credentials to authenticate:

Make sure the credentials used have the relevant privileges on Office 365 and then hit OK. After a few moments, you should see a window similar to the below, which indicates that you have successfully connected and have all the Exchange Online cmdlets at your disposal:

Set Default Email Policy for Office 365 Groups

Modifying Office 365 to use a different domain when creating Office 365 Groups requires invocation of the New-EmailAddressPolicy cmdlet, a broad brush command that is useful for a number of different Exchange management scenarios. The command can be specifically tailored to create a policy applicable to Office 365 Groups, basically telling your tenant which SMTP domain to use when creating new Groups:

New-EmailAddressPolicy -Name Groups -IncludeUnifiedGroupRecipients -EnabledEmailAddressTemplates "SMTP:@mydomain.com" -Priority 1

You can tell if the command has executed successfully if you see something similar to the below in your PowerShell window:

Next, we can then verify that Office 365 has detected the change by creating a new Group and verifying that the Email address value reflects our desired domain:

Rename Existing Office 365 Group

Assuming you are just starting out with Office 365 Groups, the simplest way of renaming your existing groups would be to recreate them. This may not work if they are already being utilised, given the level of effort involved in migrating existing content across to a new group. In this scenario, there is an additional cmdlet we can rely upon to change the SMTP address of our group to our desired domain:

Set-UnifiedGroup -Identity "Test Office 365 Group" -PrimarySmtpAddress test@mydomain.com

PowerShell will only return a message in case of an error, so to verify our changes have taken place, we must again return to Office 365 to confirm that the new SMTP address is in place:

With this now updated, email messages should flow successfully to the new Group SMTP address.

Conclusions or Wot I Think

It is rather strange that there are no obvious means of specifying which default domain should be used with newly created Office 365 groups, nor at the fact that there is any way for the user to override their choice so they can select a domain that is available on the tenant. As discussed at the start of this post, this situation provides an excellent argument for ensuring that proper processes are followed for the introduction of all new technologies within the business. Whilst exciting and innovative solutions should always be duly considered and not hampered from being rolled out, it is crucial that an appropriate amount of time is allocated for thorough testing. The last thing you want to do, in reference to this situation, is to cause irritation to end users by not giving them the ability to present a professional and correct domain name for their Office 365 Groups; by running through some test scenarios and involving end users as part of this process, where possible, you can help to prevent issues resulting from a roll out and (hopefully!) enthuse colleagues within your organisation at the new piece of technology that is being introduced.

It is sometimes desirable to grant Send on Behalf permissions in Exchange for users who are accessing another mailbox in order to reply to email messages. Some typical scenarios for this may include a personal assistant who manages a company directors mailbox, a group of users who manage a central support mailbox or for ad-hoc scenarios, such as when a colleague is out of the office. Send on Behalf permissions provide the best level of courtesy when responding to an email by letting the person know that someone else is answering an email addressed to an individual, and I would say it is generally the more recommended approach compared to granting Send As permission.

Within Office 365/Exchange Online, we can very easily grant Send on Behalf permissions for a standard user mailbox (i.e. a user that has been granted an Exchange license on the Office 365 portal) via the user interface; just go into the mailbox in question, navigate to mailbox delegation and then simply add in the users who need the required permissions:


Then, give it twenty minutes or so and then the user can then send as this user from the From field in Outlook successfully – nice and easy, just the way we like it 🙂

But what happens if we wanted to grant the very same permissions for a shared mailbox? Say that we had an IT support help desk with a shared mailbox that several different users need Send on Behalf permissions for. Within the Office 365 GUI interface, we have options only to grant Send As and Full Access permissions:


So, in order to accomplish our objective in this instance, we need to look at going down the PowerShell route. Microsoft enables administrators to connect to their Office 365 tenant via a PowerShell command. This will then let you perform pretty much everything that you can achieve via the user interface, as well as a few additional commands not available by default – as you may have already guessed, granting Send on Behalf permissions for a shared mailbox is one of those things.

Microsoft have devoted a number of TechNet articles to the subject, and the one found here is an excellent starting point to get you up and running. The salient points from this article are summarised below:

  • Ensure that the latest versions .NET Framework and Windows PowerShell are installed on your 64 bit Windows machine. These can be added via the Turn Windows features On or Off screen, which can be accessed via the search box on your Windows Start Menu or in Control Panel -> Programs and Features -> Turn Windows features On or Off,
  • Download and install the Microsoft Online Services Sign-In Assistant
  • Download and run the Azure Active Directory Module for Windows PowerShell

Once you’ve got everything setup, open up PowerShell and run the following script, altering where appropriate to suit your requirements/environment:

# Remove result limits due to console truncation


# Connect to Office 365. When prompted, login in with MSO credentials

Set-ExecutionPolicy Unrestricted -Force 
Import-Module MSOnline  
$O365Cred = Get-Credential  
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection  
Import-PSSession $O365Session -AllowClobber  
Connect-MsolService –Credential $O365Cred

# Add additonal users to Send on Behalf permissions for mailbox. add= list if a comma seperate list. Each email address should be in double quoted brackets

Set-mailbox ‘MySharedMailbox’ –Grantsendonbehalfto @{add="john.smith@domain.com"}

# Confirm that user has been succesfully added to send on behalf permissions for mailbox

Get-Mailbox 'MySharedMailbox' | ft Name,grantsendonbehalfto -wrap

# Display exit script (to keep window open in order to view the above)

Read-Host -Prompt "Press Enter to exit"

The nice thing about this code snippet is that you can grant multiple users Send on Behalf permissions at the same time, which is really handy.

Based on my experience, the above has been a pretty regular request that has come through via support in the past. I am unsure whether this is common across different organisations or not; if it is, then I am really surprised that the Office 365 interface has not been updated accordingly. The important thing is that we can ultimately do this in Office 365, as you would expect via an on-premise Exchange Server. As such, organisations can be assured that if they are planning a migration onto Office 365 in the near future, they won’t be losing out feature-wise as a result of moving to the platform. And, finally, it is always good to learn about something new, like PowerShell, so we can also say that we’ve broadened our knowledge by completing the above 🙂