Stop Using Azure AD Security Groups in SharePoint Online

With SharePoint Server, it was strongly recommended to use Active Directory security groups to secure SharePoint resources, i.e. add users to the security group and nest the security group in the SharePoint group. This was primarily for search performance and query freshness for the newly added users. When assigning users to a SharePoint group, they may not see content until search has performed a security crawl on that content to update security scopes, and visa versa, a user may see content when they’re removed from the object until a security crawl has completed.

If using Continuous Crawl, that guidance isn’t recommended for on-premises either, however I have seen that practice continue to be carried forward on-prem and in SharePoint Online.

I strongly recommend against using Azure AD Security Groups outside of very specific scenarios for SharePoint Online and here’s why:

  • Search performance is Microsoft’s domain
  • Search architecture in SPO is vastly different from on-premises
  • Using Azure AD Security Groups prevents end users from managing their own resources
    • And the iron fist of IT has made more than one SharePoint implementation underutilized or DOA
  • You can’t nest, as of this post, Azure AD Security Groups into Microsoft 365 Groups
    • This means access to certain resources, i.e. Microsoft Teams, has to be managed independently of Azure AD groups

The very specific scenarios I do recommend using Azure AD Security Groups are when you need dynamic groups to be added to SharePoint Online sites, i.e. you want a subset of users to have Visitor access to a SharePoint site and do not want to maintain group membership. For Team sites or Microsoft Teams, you can also do this with Microsoft 365 Groups which will prevent Owners from managing the Group membership, though they can manage who is an Owner.

Otherwise, let users get their work done – it will reduce the workload for IT significantly with your help desk no longer needing to field permission requests. Even in an SMB sized org, this can mean you have a lot of time to do more important tasks.

If you need to add users to a number of sites at all once, look into Azure Access Packages. This does require a P2 or EMS+E5 license for your users, but it has some other fancy functions as well, such as auto-removal of users after a time period or self-service via the Azure My Profile portal.

Think hard before using Azure AD Security groups for access management to Microsoft 365. There are often times better solutions available that allow end user flexibility to get their work done and free your time up for more important tasks.

Microsoft Q&A Replacing SharePoint TechNet/MSDN Forums

The TechNet/MSDN SharePoint forums are on their way out and being replaced by the Microsoft Q&A discussion boards.

The current schedule for retirement of the SharePoint TechNet/MSDN forums is:

  • As of this post, you can post in either TechNet/MSDN forums or Microsoft Q&A.
  • July 27th, 2020 through August 10th, 2020 you can continue to comment, propose or mark answers, and vote on posts in the SharePoint TechNet/MSDN forums. For new posts, you must use Microsoft Q&A.
  • August 10th, 2020 onward the SharePoint TechNet/MSDN forums will be read only.

Microsoft Q&A is a bit more like the StackExchange network in terms of functionality, that is, less of a classic forum experience with a back-and-forth discussion instead favoring the Q&A style of discussion where each top-level comment can be marked as an answer and (potential) answers can be replied to in a threaded format. For technical content where one needs to tease out details prior to answering, this isn’t the best format for non-developer questions, in my personal opinion.

Microsoft Q&A does not use a forum-per product format. It instead uses tags for each discussion item. The tags I personally follow (so far) are:

All of the Office-related content, including Office Client, Microsoft Teams, SharePoint Online/Server, and Exchange Online/Server content in Microsoft Q&A can be found at the Office products page.

See you on the forums!

SharePoint 2019 July 2020 Updates

The SharePoint 2019 July 2020 Updates have been released.

Product KB Article
SharePoint Server 2019 (sts-x-none)
SharePoint Server 2019 (wssmui)
Office Online Server
Office Updates

For all SharePoint updates, visit SharePoint Updates.

SharePoint 2016 July 2020 Updates

The SharePoint 2016 July 2020 Updates have been released.

Product KB Article
SharePoint Server 2016 (sts-x-none)
SharePoint Server 2016 (wssmui)
Office Online Server
Office Updates

For all SharePoint updates, visit SharePoint Updates.

Hide Modern Team Sites From the Global Address List During Provisioning

Microsoft announced an addition to the Graph API beta endpoint for Groups that allows administrators and developers to hide Microsoft 365 Groups from the Exchange Online Address Book at any time, including provisioning of Groups via SharePoint Online Team site creation. This extends to any service that creates a Team site, such as provisioning a Microsoft Team.

This script is designed for Azure Automation, which I would encourage all IT Pros to look at when Site Designs and Power Automate don’t cover a particular provisioning scenario. You can attach a Site Design to a site template, including the default Team site template, to call a Power Automate flow which in turn calls Azure Automation to apply any settings you wish.

This does require a registered App in Azure AD with the Group.ReadWrite.All API permission. The script has a couple of variables that need to be created in the Azure Automation account Variables section. The script input requires the Power Automate flow to send the Group ID as a variable.

I will have a step-by-step guide for this coming in the near future that covers this script.

Here’s the script you would use, in Azure Automation, to hide the Microsoft 365 Groups from the Global Address List in Exchange Online.

  [Parameter (Mandatory=$true)]
  [String] $groupId

$connectionName = "AzureRunAsConnection"

#Get the connection "AzureRunAsConnection"
$servicePrincipalConnection = Get-AutomationConnection -Name $connectionName

    "Logging in to Azure..."
    Add-AzureRmAccount `
        -ServicePrincipal `
        -TenantId $servicePrincipalConnection.TenantId `
        -ApplicationId $servicePrincipalConnection.ApplicationId `
        -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint 
catch {
    if (!$servicePrincipalConnection)
        $ErrorMessage = "Connection $connectionName not found."
        throw $ErrorMessage
    } else{
        Write-Error -Message $_.Exception
        throw $_.Exception

try {
    ### Microsoft 365 Group Hide from GAL
    $ClientSecret = Get-AutomationVariable -Name 'ClientSecret' #from Azure AD registered App
    $loginURL = ""
    $tenantName = Get-AutomationVariable -Name 'TenantName'
    $scope = ""

    $body = @{grant_type="client_credentials";scope=$scope;client_id=$servicePrincipalConnection.ApplicationId;client_secret=$ClientSecret}
    $oauth = Invoke-RestMethod -Method Post -Uri $("$loginURL/$tenantName/oauth2/v2.0/token") -Body $body
    $token = $oauth.access_token

    # Note we're using a _beta_ endpoint! Update to 1.0 when this API is updated.
    $Uri = "$($groupId)?`$select=hideFromAddressLists"
    $Header = @{"Authorization" = "Bearer $token"}
    $Body = @{hideFromAddressLists = 'true'}
    $ApiBody = ConvertTo-Json -InputObject $Body

    Invoke-RestMethod -Uri $Uri -Method PATCH -Headers $Header -Body $ApiBody -ContentType "application/json"
catch {
    Write-Output "Error occurred: $PSItem"

I’ve waited for years for this property, so I’m glad Microsoft has finally released this capability. It will make your Exchange Online administrators very happy!