The content below is taken from the original (Microsoft’s Flawed Plan to Auto-Generate Office 365 Groups for Managers), to continue reading please visit the site. Remember to respect the Author & Copyright.

Coming Soon: Office 365 Groups for Every Manager

Microsoft’s March 16 announcement that they will auto-generate Office 365 Groups for managers came as a surprise to many, mostly because we all missed the roadmap item describing Microsoft’s intention. Perhaps it is unsurprising that we missed the news because the announcement did not appear until very recently. RSS feeds like the Office 365 Roadmap Watch did not pick it up. Even the redoubtable Christophe Fiessinger, on point for Microsoft at the recent Ignite Australia event (February 2017), did not mention auto-generated groups in the “What’s Next” part of his “Get the Latest on Office 365 Groups session.

The notification in the Office 365 Message Center (MC96611) says that these groups will help managers collaborate more effectively with their employees. There’s no sign that managers have asked for better collaboration, but that is another story. Cynics will say that this is yet another example where Microsoft is banging the drum to convince customers to make more use of Office 365 Groups. I like Office 365 Groups, but I am unsure of the wisdom behind this move.

What’s Happening

Beginning on April 13, 2017, Microsoft will automatically generate a private Office 365 Group for every manager who has between 2 and 20 direct reports. You have until then to make sure that your tenant is ready to create these groups or to take steps to prevent automatic creation happening.

Before Office 365 creates a group, the following conditions must be true:

• The manager must be able to create new Office 365 Groups.
• An Office 365 group for the manager’s direct reports must not already exist (Microsoft has an algorithm “to try and identify existing direct reports groups”). If an email distribution group exists for the direct reports, it is ignored.
• The tenant does not disable automatic group creation.

According to the admin guidelines, the automatically-created groups are named “Manager Name>’s direct reports”. For example, “Tony Redmond’s direct reports”. Of course, if you use a “Last Name, First Name” convention for accounts, you will end up with “Redmond, Tony’s direct reports”, which does not look quite so good. The format for group naming differs from language to language. Managers can rename the group after creation because they are the group owner. Their direct reports are the group members, who are auto-subscribed to the group to make it behave like an email distribution group.

On the upside, this seems like a sensible way to provide managers with a convenient platform for their employees to share information, including using Microsoft Teams. However, although the idea is fine in concept, some problems exist that make me believe that many tenants will opt-out of this feature.

The Directory is The Problem

Microsoft makes a big assumption that the reporting relationships recorded in Azure Active Directory are correct and can be depended upon to create the automatic groups. Relatively few organizations pay enough attention to the “ManagedBy” property of user accounts to be sure that this data is dependable enough to generate an org chart.

To prove this point, I asked Cogmotive, an ISV that manages millions of Office 365 mailboxes to generate reports for tenants if they knew how many of the mailboxes in their dataset had a blank ManagedBy property. Some number crunching revealed the answer: only 45% of all mailboxes have a defined reporting relationship. Cogmotive’s data is only one sample of the Office 365 user base, but it does not seem like a solid foundation for automatic group generation.

The problem is that Azure Active Directory is not usually the authoritative source for personnel information. My experience is that most large enterprises depend on HR systems to track managers and employees along with other information that a company never exposes to Office 365, like salary levels.

Inside large organizations, it is widespread practice to have account provisioning processes that take employee data and feed it to applications to ensure that users have access as needed. For instance, a feed to Azure Active Directory might create an Office 365 account and assign a license to a user. That feed could populate properties like ManagedBy along with the user’s phone number, address, and other HR data that you want to see in the GAL.

However, I know of few enterprises that depend on Azure Active Directory to track who works for whom, especially when heterogeneous IT systems are in use. Office 365 tenants often treat Azure Active Directory as a source for user authentication and email address validation.

The Missing Links

PowerShell makes it easy to check how many mailboxes are missing the ManagedBy property in your tenant. Running this snippet might generate some surprise when you discover quite how many mailboxes do not have this information (like the one shown in Figure 1):

[PS] C:\> $Mbx = (Get-Mailbox -RecipientTypeDetails UserMailbox | ? {$_.ManagedBy -eq $Null} )
[PS] C:\> $Mbx.Count

Many reasons exist why the ManagedBy property is null or inaccurate for a mailbox, including:

• The company does not populate the property as part of its normal account creation and ongoing management processes.
• The property existed at one time, but the manager has left the company and the link to the manager’s account disappeared when an administrator removed the manager’s account from Azure Active Directory
• The user moved jobs, but no one updated ManagedBy to point to the new manager.
• The manager moved jobs, but no one updated their employees to reflect this fact.
• No synchronization exists between Azure Active Directory and the company’s HR system.

For whatever reason, if inaccurate data exists in Azure Active Directory, you cannot depend on the membership calculated for the automatically created groups. The net result is that you could end up with a mass of inaccurate and potentially misleading groups cluttering up the tenant. At worst, you could have a situation where the use of these groups leads to sensitive documents ending up with the wrong people.

When You Populate Azure Active Directory

Office 365 places a heavy emphasis on a fully-populated directory. If you populate Azure Active Directory as completely as you can, including reporting relationships, Office 365 can expose that information to users in multiple ways, including people cards, Delve profiles, the Outlook GAL, and Teams (Figure 2). There is real goodness in making this kind of organizational insight available to users, but it does take effort.

Ongoing Care and Feeding Needed

Populating the directory is one matter. Keeping all those reporting relationships and other details updated is quite another. You might have an up-to-date directory now, but will the same state be true in a year’s time? And what happens to the membership of groups as managers change positions, new employees join, or people leave the organization?

Other questions are likely to occur as Microsoft rolls out these groups. For example, what happens if you rename an automatically-created group – will Office 365 then go ahead and create another group for the manager? (Apparently not.) Microsoft has clarified that if Office 365 creates an automatic group and the owner removes it, the group will not come back from the dead. In other words, no group zombies here!

Or what happens if a distribution group with the same name exists (cue GAL confusion)? How quickly does Office 365 create a group when someone gains two direct reports?

Microsoft’s says that the only automatic processing is when Office 365 creates the groups. After that, it is up to managers (the group owners) to keep group membership updated. This is a sensible approach. Any attempt to automatically update group membership based on changing reporting relationships recorded in Azure Active Directory would probably become a nightmare. In addition, managers often want to add extra people to their distribution lists, including those who are dotted-line reports. Indeed, some direct reports might not even have Office 365 accounts.

Although they manage group memberships through Azure Active Directory queries, Dynamic Office 365 Groups are not an answer to the maintenance issue. Apart from being dependent on directory data, these groups come with a cost as Microsoft licensing requirements mean that any user that comes within the scope of a query used for a dynamic group must have a premium license for Azure Active Directory.

Stopping Automatic Group Creation

Because most tenants cannot depend on the reporting information held in Azure Active Directory, I think that many tenant administrators will take a hard look at the prospect of many new groups appearing in their GAL and decide that automatic creation is a step too far. Which leads us to the question of how to stop automatic group generation.

You can control the automatic generation of these groups through the DirectReportsGroupAutoCreationEnabled setting in the tenant configuration for Exchange Online. By default, the setting is True, meaning that automatic group generation can proceed. To block creation, change the setting to False.

[PS] C:\> Set-OrganizationConfig -DirectReportsGroupAutoCreationEnabled $False

Microsoft is updating tenant configurations to prepare for this change. You can check your tenant configuration with the Get-OrganizationConfig cmdlet. If the DirectReportsGroupAutoCreationEnabled is present, you can stop automatic groups being created on April 13 by running the command shown above,

You can also implement an AAD policy for Groups and restrict the ability to create groups to a specific set of users. If managers are not included in the allowed list, Office 365 will not create the automatic groups. The downside of this approach is that it stops managers creating new groups, teams, and plans that you might, in fact, want to be created.

Finally, you can decide that Azure Active Directory is just a source of authentication and email addresses and do not populate the ManagedBy property for mailboxes. If this data does not exist, Office 365 will not auto-generate groups.

Cleaning Up Unwanted Groups

Once you clamp down on automatic group creation, you might want to clean up the groups that were created. Fortunately, there is an easy check because these groups are stamped with a specific property. We can find the groups as follows:

[PS] C:\> Get-UnifiedGroup | ? {$_.GroupPersonification -eq "Groupsona:AutoDirectReports" } | Format-Table DisplayName, ManagedBy

To remove the offending groups, you can change the command to add the Remove-UnifiedGroup cmdlet:

[PS] C:\> Get-UnifiedGroup | ? {$_.GroupPersonification -eq " Groupsona:AutoDirectReports" } | Remove-UnifiedGroup -Confirm:$False

Another way to deal with the problem is to leave the auto-created groups in place and then use techniques like those described in this article to remove the groups that no one uses.

The Good and Bad in Auto-Generated Office 365 Groups

Some goodness exists in how Microsoft wants to generate Office 365 Groups for managers, especially for small tenants that might not even realize that they can use groups as the basis for collaboration. Any organization that uses Azure Active Directory as an authoritative directory for employee-manager reporting relationships will also find value in the feature. And if you think automatic group generation is sensible, you now have fair warning to review and update Azure Active Directory to prepare for Office 365 to create the groups.

However, I can imagine problems for enterprise tenants where HR systems are the source for email distribution groups used for organizational communication. With this plan in place, you could end up with two sets of groups. One (from HR) uses correct membership information because HR knows who works for whom. The other (generated by Microsoft) is based on an aspiration that administrators populate Azure Active Directory with links between managers and employees. In my heart, I know full and accurate population of reporting relationships is an unlikely scenario for many companies.

The folks who sell Azure Active Directory monitoring and reporting tools like Hyperfish (who offer a free analysis of your directory) and Cogmotive will welcome this new feature with open arms. I am not sure that those charged with the administration of large tenants will be quite so happy. This should have been an opt-in feature instead of something forced by Microsoft on tenants.

So much for Microsoft’s statement in the Office 365 Trust Center that “you are the owner of your customer data.” If this were really the case, don’t you think Microsoft would ask before they use tenant data to create objects in tenant directories that tenants have not asked for?

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle

The post Microsoft’s Flawed Plan to Auto-Generate Office 365 Groups for Managers appeared first on Petri.