When I recently discussed the confusion that I see how Office 365 Groups (or “modern groups”) and Yammer appear to serve much the same purpose (albeit in different ways) might be taken as overly critical of Yammer. It’s certainly true that I described some common issues that users and administrators have noted with Yammer – issues that have been around for quite a while – but in the end I concluded that work is ongoing within Microsoft to weave these threads of collaboration software into a common fabric within Office 365. At least, I hope it is.
Part of that work will hopefully address some of the known flaws within Office 365 groups. It’s totally unsurprising that these flaws exist for two reasons. First, Microsoft traditionally has been much better at developing user-centric features than it has in completing things with complementary management functions. In other words, you can use the software but don’t expect to manage whatever is generated. Anyone who doubts that this is true can reflect on the continued lack of reporting functionality within Exchange after a mere 20 years of development. And I won't even mention public folders...
Second, it seems like Office 365 groups were rushed to tenants in a most unseemly manner. Not only were no management functions provided but some obvious function gaps existed too, plus a security issue had to be fixed to enable proper access to the SharePoint-hosted document libraries that hold shared group files. Not that any of this is mentioned in Microsoft's recently issued "An end-to-end experience with Groups" white paper, but that's OK because it's intended to tell the story of how Microsoft sees these groups being used.
On the other hand, you can argue that the rapid development approach now being used for cloud platforms allows functionality to be expanded on an ongoing basis. Just this week Microsoft upgraded Office 365 groups by adding a shared OneNote notebook to each group (the feature is now available to First Release tenants). I rather like this addition as I consider a shared notebook is an excellent way to capture ideas and concepts for discussion by group members.
In any case, I've been thinking about what needs to be done to make Office 365 groups work well for large enterprises so that modern groups can replace (some) traditional distribution groups and be a fulcrum for group collaboration that eventually displaces public folders. Here's my list.
No support for external users: Oddly, an external user can email a contribution to a group, but they can’t be added (or subscribed) to a group. Many distribution groups contain mail contacts, if only to be able to accommodate people who belong to the same company but use a different email system.
Lack of management and control over the creation of new groups. For instance, there isn’t the equivalent of the group naming policy that controls how user-created distribution groups are named. No management is available in SharePoint to control the sites that hold document libraries. Large enterprises like control, especially when confidential information might be stored in group libraries. It would also be nice to have some reports on what happens within groups, like how many members belong to each group, what groups are being used and what are not, how much information is being accumulated in groups, whether calendars and document libraries are in use or just conversations, and so on.
It's also inconceivable to me that we should allow a situation where users are able to create groups without asking permission. All that means is the potential for the same kind of anarchy that existed when public folders first came out and administrators didn't realize that they had to control folder creation. This is the reason why some companies still struggle today with folder hierarchies containing thousands of unwanted and unused folders, a legacy that is usually only faced when the time comes to migrate old-style public folders to modern public folders. Yes, you can create an OWA mailbox policy to control the users who are allowed to create groups, but wouldn't it have been wiser to restrict creation from the start rather than having to close the door afterwards?
No migration facilities exist to transfer distribution group archives built up in public folders to modern groups. Likewise, no migration facilities exist to transfer the shared calendars or shared contacts that are also found in public folders to modern groups. It would be nice if the Mailbox Replication Service (MRS) was enhanced to be able to deal with these scenarios.
No migration facilities exist to convert distribution groups to modern groups. I accept that it is a simple operation (in concept) to convert a single standalone group. Matters become more complex when you consider nested groups, or groups that contain mail contacts and public folders, or dynamic distribution groups. But if Microsoft wants to break the habit of using distribution groups for communication, then some way to move work is necessary. And by the way, modern groups can’t act as security principals so they can’t replace mail-enabled security groups. Perhaps modern groups will be able to serve this role in the future.
You can’t nest a modern group within another modern group. OK, I know this is somewhat bizarre, but given that people nest distribution groups, will they want to nest groups? They might do!
Rather bafflingly, the files held in the document libraries used by private groups are inaccessible to search. I hear that this might be a known permissions issue that is being solved, but for now the documents stored in group libraries can't be found, even by Delve. And more importantly, they remain invisible to eDiscovery searches, which is a serious flaw in anyone's compliance strategy.
Also in the world of compliance, you can't currently apply Exchange retention policies to group mailboxes. Conversations and calendar items will continue to accumulate until someone cares to clean them up. Which means that they'll stay there undisturbed for the remainder of time.
The group directory can't scale. It's nice to see all the pretty group logos but I would prefer to have good search facilities to allow me to locate groups that I might be interested in joining – or to be able to search across conversations, calendar, and files in all groups to locate information that is of interest and available. Private groups would be excluded from the search, but there's no reason why I shouldn't be able to search across all public groups.
Interoperability with on-premises Exchange: No version of on-premises Exchange has any knowledge of Office 365 Groups. On-premises users can contribute to group conversations via email but there's no way for these users to be able to use the shared calendar or shared document library. And because the group mailbox object type is unknown to on-premises deployments, it is difficult to see how these groups can be used in a hybrid environment. This is an obvious gap that needs to be addressed in the near future.
I have other things on my list too, such as expansion of PowerShell management for groups, better granularity for access to files in the document library (for instance, so members can read but not edit files), and so on. But these are secondary to the items mentioned above.
These missing features are all symptoms of a feature that was launched in an incomplete but still pretty usable form. I use Office 365 groups daily to organize some projects that I work on and think they work pretty well now, but it is frustrating to encounter the shortcomings.
I can see how Office 365 Groups can be so much better. I believe that Microsoft shares that view. It will be interesting to see what Microsoft can do by the time Ignite comes around.
Follow Tony @12Knocksinna
