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:
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://.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):
- 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 :)