Example of Ongoing Changes in Microsoft 365

I guess we all knew it was coming (after all, Microsoft published message center notification MC477013 in December 2022), but the news that the Microsoft Entra admin center (Figure 1) will replace the Azure AD admin center from April 1, 2023 is yet another example of the ongoing and constant changes in Microsoft 365. Those changes range from a massive introduction of fundamental new functionality, like Microsoft 365 Copilot, to a small update to how something appears.

In this instance, Microsoft portraits the replacement of the Azure AD admin center as a unification of its identity management platform (Azure AD) with its identity and access solutions. Another way of looking at the move is that it allows Microsoft to bring those identity and access solutions to the attention of some organizations who wouldn’t otherwise consider them. Every time you open the Entra admin center, identity governance and other solutions will be there to discover. To be fair to Microsoft, if you access Azure AD from the Microsoft 365 admin center, the link goes direct to the Azure AD section of the Entra admin center.

Microsoft says that the old Azure AD admin center will continue to function until May 2023. Azure customers who don’t use Microsoft 365 can manage Azure AD through the Azure portal.

Many Rebranding Campaigns

Microsoft is well known for its love of rebranding campaigns. Microsoft 365 has steadily embraced a huge ecosystem, including the subscription version of the Office apps, and we’ll probably have to rename the next version of the Office 365 for IT Pros eBook to use Microsoft 365 instead. Microsoft Purview is another example, albeit one that at least collected together a bunch of different compliance solutions under a common banner. Defender did the same for security solutions, and so on.

Sometimes, Microsoft makes changes for what appears to be no good reason. Take the announcement in MC532194 (March 23) that Teams now uses an “EA” indicator instead of “P” when users run the preview version of the software. I’m still wondering why “Early Access” is any better than “Preview.” The change appears to deliver zero added value except that it aligns with the nomenclature Microsoft uses in places like the Office Insider program. From my perspective, the change meant that we needed to update Chapter 15 in the Office 365 for IT Pros eBook and our article about Teams preview.

Naming Changes Affect the Wider Technical Community

Microsoft makes naming changes for its own reasons. I doubt that they take the wider community into consideration when they decide on these updates but the effect of a naming change or rebrand ripple through documentation and training. For instance, video training companies that have a program telling people how to use the Azure AD admin center must now update their collateral and perhaps even reshoot some or all of their video. That’s a big cost for the production company.

The same is true for books that cover Azure AD or any of the other topics affected by naming or branding changes. Switching references from the Azure AD admin center to the Entra admin center isn’t quite as simple as doing a search and replace. Microsoft often takes the opportunity to rename options in administrative consoles when they change things. Data lifecycle management is now the place in the Purview compliance portal that was once known as the location for the management of retention labels and policies. The justification is that the section of the portal now spans additional options such as adaptive scopes, policy lookup, and legacy Exchange mailbox retention policies and tags (both of which are still very useful).

Changes in Microsoft 365 Will Keep on Happening

I don’t expect Microsoft to poll the technical community before they change the name of anything inside Microsoft 365. It won’t happen and would be unreasonable. Microsoft will continue to make changes how and when they like, even if the outcome displeases some. Their decision to stop accepting inbound email from old and vulnerable on-premises Exchange servers to protect Exchange Online is a good example of a change that inflamed many opinions. However, we don’t get to vote.

Content producers like Office 365 for IT Pros simply need to be proactive and respond to Microsoft changes the best way we can. In that respect, being able to publish a complete new book every month is a major advantage, even if it takes a lot of hard work. Now back to the task of looking for all those references to the Azure AD admin center – a change that we’ll probably make in the May 2023 update.

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.

Changes to Close Off Creation Gaps in Administrative Interfaces

Message center notification MC275349 (August 3) informs tenant administrators of the need to check the group creation settings in the Azure AD admin center. Previously, these settings governed the ability of users to create new security groups and Microsoft 365 groups through the Azure AD admin center. However, the setting did not govern other administrative interfaces such as PowerShell or the Microsoft Graph Groups API. The new settings (Figure 1) cover all administrative interfaces and are now in place.

Microsoft advises checking your tenant settings to make sure that the change has not affected the way your organization manages group creation. I haven’t seen any issue in any tenant I use, but it’s good to be sure.

Groups-Specific Controls

Azure AD settings apply to administrative interfaces. Other controls exist at an application level. The best example of this is Microsoft 365 Groups, which use an Azure AD directory policy to store settings used to control different aspects of groups. The default value for the EnableGroupCreation setting is True, meaning that any user can create a new Microsoft 365 group. If False, the GroupCreationAllowedGroupId setting comes into play. This defines the GUID of a group whose members are allowed to create new groups.

Controlling group creation in this way requires Azure AD P1 Premium licenses. Many large organizations have Microsoft 365 plans which include these licenses so the requirement not usually an issue.

What’s a little more problematic for some is the lack of a GUI to control most of the policy settings (the naming policy and blocked words settings are available in the Azure AD admin center). Six years or thereabouts since the introduction of the directory policy for Teams, the lack of a complete GUI means that administrators must use PowerShell to access and update the other policy settings, including group creation.

For instance, to find out the set of users allowed to create groups and the name of the group defined in the policy, we can use this code:

$Values = Get-AzureADDirectorySetting | ?{$_.DisplayName -eq "Group.Unified"}
$GroupId = $Values.Values |?{$_.Name -eq "GroupCreationAllowedGroupId" } | Select -ExpandProperty Value
Write-Host ("The name of the group defined by policy to control group creation is {0} and its object identifier is {1}" -f (Get-AzureADGroup -ObjectId $GroupId).DisplayName, $GroupId)
Get-AzureADGroupMember -ObjectId $GroupId

The name of the group defined by policy to control group creation is GroupCreationControl and its object identifier is 12cb915b-2365-4bed-baf6-6257b3543273

ObjectId                             DisplayName                 UserPrincipalName                     UserType
--------                             -----------                 -----------------                     --------
bff4cd58-1bb8-4898-94de-795f656b4a18 Tony Redmond                Tony.Redmond@office365itpros.com      Member
edc6b121-44b8-4261-9ca7-3603a16caa3e Andy Ruth (Director)        Andy.Ruth@office365itpros.com         Member
43d08764-07d4-418c-8203-a737a8fac7b3 Global Tenant Administrator GblAdmin@office365itpros.com          Member

To modify the group used to control group creation, we must update the directory policy. For example, this code retrieves values for the group we want to use and the current settings and uses the values with the Set-AzureADDirectorySetting cmdlet to update the directory policy.

$ObjectId = (Get-AzureADGroup -SearchString "Group Creation Allowed").ObjectId
$Settings = Get-AzureADDirectorySetting | ? {$_.DisplayName -eq "Group.Unified"}
$Settings[“GroupCreationAllowedGroupId”] = $ObjectId
Set-AzureADDirectorySetting -Id $Settings.Id -DirectorySetting $Settings

Outlook Creation

The GroupCreationEnabled setting in the OWA mailbox policy assigned to mailboxes was the original control mechanism for group creation (OWA was the first client to support Office 365 Groups, as they were named in 2014). This setting persists today and must be True to allow users to create new groups with an Outlook client.

This article contains a more comprehensive treatment of the steps to control the creation of Microsoft 365 Groups.

Not Much Impact?

I suspect that the changes being made won’t affect many of the tenants who control group creation. Tenants that allow users to create groups and teams as they wish probably won’t be affected either, but they have other issues to cope with like a higher proportion of aging and obsolete groups. In any case, the change is a reasonable one to introduce, even if I wish Microsoft would spend some time on other obvious deficiencies, like the lack of a GUI for the Groups directory policy.

Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Deny Guests from Some Domains or Use an Allow List

Updated: 5 September 2023

The ability for applications to use Entra ID B2B collaboration to add guest users is governed by external collaboration settings, aka the Entra ID B2B collaboration policy (previously the Azure AD B2B Collaboration policy). The settings are available through the External identities section of the Entra ID admin center, where they are found under Collaboration restrictions (Figure 1).

Three options are available:

• Allow guest accounts from any external domain. This is the default.
• Deny access to guest accounts from specified domains (deny list).
• Allow access only to guest accounts from specified domains (allow list).

The total size of the policy must be less than 25 KB (25,000 characters). Each domain in an allow or deny list counts against the limit as do other policy settings. Allowing 1,000 bytes for all other settings, an average of 15 characters per domain means that an allow or deny list can accommodate up to 1,600 domains. You can only choose to have a policy with an allow or a deny list and cannot have some domains in a deny list and others in an allow list.

In my case, I use the middle approach to block guest accounts from certain domains. For instance, these might be domains belonging to direct competitors or domains used for consumer rather than business purposes. In Figure 1, you can see that I’ve decided to block access to guests with Google.com and Yahoo.com email addresses.

Entra ID Blocks Bad Guests

Entra ID applies the block rather than applications. For example, in Figure 2, I’ve tried to add a new guest account to Teams, which doesn’t object when I enter tredmondxxxx@yahoo.com to identify the guest. The block descends when Teams tries to create the new guest account in Entra ID. The “Something went wrong” is an uncertain error, but it should be enough for the administrator to know what’s going on when they learn where the guest comes from. OWA doesn’t object to the email address for a new guest but is no more definite in its error (Figure 3). Again, this is because the application fails to create a new guest account in Entra ID.

Knowing What Domains Guests Come From

Before going ahead to update your external collaboration settings, it’s a good idea to understand where current guest accounts come from. This code scans down through guest accounts found in Entra ID to capture details of each user’s home domain. It then populates a hash table with the domain information to create a count for each, followed by sorting in descending order to discover the most popular domains:

$Domains = [System.Collections.Generic.List[Object]]::new()
Connect-MgGraph -NoWelcome -Scopes Directory.Read.All
[array]$Guests = (Get-MgUser -All -Filter "UserType eq 'Guest'" | Select-Object Displayname, UserPrincipalName, Mail, Id | Sort DisplayName)

ForEach ($Guest in $Guests) {
   $Domain = ($Guest.UserPrincipalName.Split("#EXT#")[0]).Split("_")[1]
   $Domains.Add($Domain)
}

$DomainsCount = @{}
$Domains = $Domains | Sort-Object
$Domains | ForEach {$DomainsCount[$_]++}
$DomainsCount = $DomainsCount.GetEnumerator() | Sort-Object -Property Value -Descending
$DomainsCount


Name                           Value
----                           -----
microsoft.com                  59
outlook.com                    11
quest.com                      6
hotmail.com                    5
gmail.com                      4
emea.teams.ms                  4

Now you know what domains are actively in use, you can decide which you might like to ban. Remember that putting a domain on the deny list stops only the creation of new guest accounts. Existing guest accounts remain in the membership of groups and teams. If you want to purge accounts from unwanted domains, you need to find the groups (teams) with guest members and examine each guest to decide if they can stay or be removed. It’s easy enough to find guests from banned domains with PowerShell, or so the saying goes…

The Office 365 for IT Pros eBook is packed full of practical information like this. Learn from the pros by subscribing to Office 365 for IT Pros and receive monthly updates during your subscription period.