The Odd Azure AD Selected Visibility is Not Allowed Problem

Azure AD Admin Center Doesn’t Respect Sensitivity Label Settings

Last June, I tested the preview of nested dynamic Azure AD groups and encountered an odd “Per label policy, the selected visibility is not allowed” error when attempting to create new groups in the Azure AD admin center. Pressure of time forced me to ignore the problem and create the groups I wanted with PowerShell, but time allowed me this week to return to the problem.

It didn’t take long to reproduce the problem and track down the root cause (Figure 1).

Visibility Set to Private for New Microsoft 365 Groups

I used the Graph X-Ray tool to look at the PowerShell generated by the Azure AD admin center when it adds new Microsoft 365 groups. Here’s what Graph X-ray reported:

$params = @{
	DisplayName = "Viva Topics Management"
	MailEnabled = $true
	SecurityEnabled = $true
	GroupTypes = @(
		"Unified"
	)
	Description = "People who manage Viva Topics"
	MailNickname = "VivaTopicsManagement"
	AssignedLabels = @(
		@{
			LabelId = "e42fd42e-7240-4df0-9d8f-d14658bcf7ce"
		}
	)
	Visibility = "private" }}

I copied the command and ran it interactively and saw this error:

New-MgGroup -BodyParameter $params
New-MgGroup : Property visibility is not compliant with the assigned label.
At line:18 char:1
+ New-MgGroup -BodyParameter $params
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: ({ body = Micros...ftGraphGroup1 }:<>f__AnonymousType1`1) [New-MgGroup
   _Create1], RestException`1
    + FullyQualifiedErrorId : Request_BadRequest,Microsoft.Graph.PowerShell.Cmdlets.NewMgGroup_Create1

Changing the command to set the visibility property in the parameters to “Public” allowed the command to run successfully and create the group. This is what I expected because the container management settings for the sensitivity label chosen for the new group sets its visibility to Public.

The root cause is that the command generated by the Azure AD admin center sets the access type for the new group incorrectly. Instead of reading the group’s access type (visibility) from the sensitivity label, the command uses “Private” for the value. This means that the command works for any group created with a sensitivity label that sets the access type to Private but fails for public groups.

The Azure AD admin center UI doesn’t include a field to allow the visibility to be selected for a new group, so some overhaul of the UI is needed to display the visibility inherited when a sensitivity label is selected. In addition, Microsoft’s documentation for creating a new group in the Azure AD admin center doesn’t mention visibility at all, so there’s no hope in interpreting the error message.

Inconsistent Microsoft 365 Group Management

I’m unsure of how many new Microsoft 365 groups are created in the Azure AD admin center. My feeling is that most administrators create new groups through the Microsoft 365 admin center or a workload-specific portal like the Teams admin center or SharePoint Online admin center, or even a client like OWA or Teams. All these interfaces (and PowerShell) respect the container management controls imposed by sensitivity labels. If the Azure AD admin center was heavily used, I’m sure Microsoft would have heard about the problem before I reported it on August 15.

In any case, this is not the only example of inconsistency between the Azure AD admin center and the workload portals. Take the security enabled property for a group. This is set to $True by the Azure AD admin center and $False by the Microsoft 365 admin center. That doesn’t sound too serious, but it means that groups not created in the Azure AD admin center can’t be used for purposes like group-based license management. This is where you manage license assignments by allocating them to members of a group. It’s a convenient way to manage licenses (Figure 2).

The security enabled property isn’t exposed in the Azure AD admin center UI, so if you want to update a group to make it available for group-based license management, you need to use PowerShell. The steps are simple using the group management cmdlets from the Microsoft Graph PowerShell SDK. The first command finds the group to use. The second updates its SecurityEnabled property.

$Group = (Get-MgGroup -Filter "DisplayName eq 'HR Working Group'")
Update-MgGroup -GroupId $Group.Id -SecurityEnabled:$True

After the Update-MgGroup cmdlet runs, you should be able to use the group for group-based license management.

Small But Irritating Issues

Neither of the issues described here are earthshattering. Both can be worked around by competent tenant administrators who understand how Microsoft 365 works. The problem is that issues like this cause grief to inexperienced administrators and complicate the learning curve for cloud services. That’s a great pity.

---

Learn more about how the Office 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.