Slight change of pace with this week’s blog post, which will be a fairly condensed and self-indulgent affair – due to personal circumstances, I have been waylaid somewhat when it comes to producing content for the blog and I have also been unable to make any further progress with my new YouTube video series. Hoping that normal service will resume shortly, meaning additional videos and more content-rich blog posts, so stay tuned.

I’ve been running the CRM Chap blog for just over 2 years now. Over this time, I have been humbled and proud to have received numerous visitors to the site, some of whom have been kind enough to provide feedback or to share some of their Dynamics CRM/365 predicaments with me. Having reached such a landmark now seems to be good a time as any to take a look back on the posts that have received the most attention and to, potentially, give those who missed them the opportunity to read them. In descending order, here is the list of the most viewed posts to date on the crmchap.co.uk website:

  1. Utilising SQL Server Stored Procedures with Power BI
  2. Installing Dynamics CRM 2016 SP1 On-Premise
  3. Power BI Deep Dive: Using the Web API to Query Dynamics CRM/365 for Enterprise
  4. Utilising Pre/Post Entity Images in a Dynamics CRM Plugin
  5. Modifying System/Custom Views FetchXML Query in Dynamics CRM
  6. Grant Send on Behalf Permissions for Shared Mailbox (Exchange Online)
  7. Getting Started with Portal Theming (ADXStudio/CRM Portals)
  8. Microsoft Dynamics 365 Data Export Service Review
  9. What’s New in the Dynamics 365 Developer Toolkit
  10. Implementing Tracing in your CRM Plug-ins

I suppose it is a testament to the blog’s stated purpose that posts covering areas not exclusive to Dynamics CRM/365 rank so highly on the list and, indeed, represents how this application is so deeply intertwined with other technology areas within the Microsoft “stack”.

To all new and long-standing followers of the blog, thank you for your continued support and appreciation for the content ūüôā

Office 365 groups have been a recurring topic of the blog in recent months –¬†we’ve seen how we can force Office 365 to use custom domains when creating groups for the very first time¬†and¬†how you can straightforwardly integrate an Office 365 Group within Dynamics 365 for Customer Engagement. With this in mind, there is little point in providing a detailed description of what they are and how they can be used; suffice to say, if you are wanting to collaborate closely with internal/external colleagues for a particular project or department, Office 365 Groups are an excellent candidate to consider.

One of the cornerstones of Office 365 Groups is the ability for all conversations to be tracked via the use of a dedicated shared mailbox. This perhaps explains why the Office 365 portal will refuse to let you add any user within your organisation who does not have an Exchange Online license assigned to them. Case in point – let’s assume we have a user account with no such license assigned to them on the Office 365 portal:

When attempting to add this user into an Office 365 group, we get a message to let us know No match was found for the user account entered and, as a consequence, it cannot be added to the group:

From this, you can perhaps make the assumption that Office 365 groups are not supported at all for users who do not have a mailbox. This is notwithstanding the fact there are several different business scenarios that may necessitate this requirement:

  • A kiosk/”light-use” account may require access to the group to upload documents and manage the SharePoint site.
  • Integration with external applications may be required, stipulating the need for a service account to authenticate with the group to retrieve/add content dynamically.
  • The need to configure an account for external users to access, that is sufficiently locked down and inexpensive to maintain.

Fortunately, as with many other things relating to Office 365, we can get around this limitation within the Office 365 portal by resorting to PowerShell and adding the John Doe user account above to the Group.

The first step towards achieving this is to boot up a PowerShell window. Make sure you have access to this on your machine of choice then, after opening the application using the Run as administrator option, execute the following script:

##Set Execution Policy to Remote Signed - required to fully execute script

Set-ExecutionPolicy RemoteSigned

##Connect to Exchange Online. Enter administrator details when prompted.

$UserCredential = Get-Credential

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

Import-PSSession $Session

##Add the non-mailbox user to the Office 365 Group. Substitute the Links value with the username of the account to add.

Add-UnifiedGroupLinks -Identity "Test Office 365 Group" -LinkType Members -Links john.doe@domain.com

##Confirm that the user has been added successfully by returning the Group member list

Get-UnifiedGroupLinks -Identity "Test Office 365 Group" -LinkType Members

##Cleanup by disconnecting from Exchange Online

Remove-PSSession $Session

The penultimate command will make something similar to the below appear in the console window. Interestingly, note that the John.Doe test user has a RecipientType value of User:

Now that the user has been added successfully, they will be able to access the SharePoint site for the group by navigating to the SharePoint library URL. This will look similar to the below and can be grabbed by logging in as another user who has the RecipientType value of UserMailbox and navigating to the Groups SharePoint site:

https://<Your On Microsoft domain prefix>.sharepoint.com/sites/<Your Office 365 Group Name/

Note that this will be on the only way the non-mailbox user can access the site. For example, there will be no link to SharePoint within Office 365 to guide you to the above location. After logging in, you should be greeted with a window similar to the one below:

The John Doe “light-use” account, as referenced above, will have full access to everything that is accessible within SharePoint concerning the Office 365 Group, such as:

  • The Home/News Page
  • Shared Documents Folder (“Documents“)
  • Shared OneNote (“Notebook“)
  • All Site Pages
  • Planner (navigated to via the following link:¬†https://tasks.office.com/<Your Office 365 Primary domain>/en-GB/Home/Planner/)

Conversely, the following features will be inaccessible (due to requiring a Mailbox):

  • Conversations
  • Shared Calendar

If for example, you attempt to navigate to Conversations within SharePoint, you will get the following error message:

This is, perhaps, a small price to pay for what ends up to be a pretty feature-rich experience that can be given to additional users within your organisation at virtually no cost. Perhaps another good excuse to start rolling out Office 365 Groups across your tenant in the near future ūüôā

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 Y 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:

1

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:

2

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

$FormatEnumerationLimit=-1

# 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¬†ūüôā