403 Forbidden: Saving Windows Update for Business reports configuration action failed

Error Message '403 Forbidden'
Error Message '403 Forbidden'

After re-enrolling Windows Update for Business (WUfB) reports, I've stumbled upon this error during enrollment via the Azure Portal. I intended to re-enroll when Microsoft released the production ready WUfB reports solution after the Windows Update Compliance preview ended. I simply deleted the old Log Analytics Workspace and tried to re-enroll in our production environment. I deployed a new Workspace and re-started the enrollment process.

Enrolling Windows Update for Business reports
Enrolling Windows Update for Business reports

During enrollment, I've encountered the following error:

403 Forbidden

{"error":{"code":"UnknownError","message":"...","innerError":{"date":"2023-01-12T20:48:38","request-id":"...","client-request-id":"..."}}}
Error 403 during enrollment of Windows Update for Business reports

I tried to analyze the problem myself and concluded that there were still some references to the old Log Analytics Workspace somewhere in the tenant configuration, e.g. the old Azure resources were still displayed in the M365 Admin Center, an alternative way to configure WUfB reports. After discovering this, I concluded that I probably needed support from Microsoft to resolve this. A Google search didn't turn up anything either, probably because WUfB reports are a very recent release. After some time consulting with Azure support, I was able to resolve this issue. In this article, I'd like to share the fix I used to resolve the error.

We are going to need a way to interact with the Graph API. There are multiple options, I'm going to show you a way using Graph Explorer and also PowerShell.

Using Graph Explorer

Navigate to Graph Explorer in your browser of choice.

  1. Sign in to your tenant

2. Chose method GET and enter the following URL

https://graph.microsoft.com/beta/admin/windows/updates/resourceConnections

You will be prompted to consent to the required permissions. When the required permissions are granted, you will get a response similar to this:

{
 "@odata.context": "https://graph.microsoft.com/beta/$metadata#admin/windows/updates/resourceConnections",
 "value": [
     {
         "@odata.type": "#microsoft.graph.windowsUpdates.operationalInsightsConnection",
         "id": "167f56b1-20ec-4233-98ef-f23228cf8d8c",
         "state": "connected",
         "azureSubscriptionId": "...",
         "azureResourceGroupName": "...",
         "workspaceName": "..."
     }
 ]
}

Now simply copy the returned id(s), select method DELETE and enter the following URL with your id

https://graph.microsoft.com/beta/admin/windows/updates/resourceConnections/{your_id_here}

To validate if the deletion was successful, simply run the GET method again.

Using PowerShell

Installing the Microsoft Graph PowerShell SDK

To use the Microsoft Graph PowerShell SDK module, you have to install it first. Alternatively, if you have Azure Cloud Shell set up, you can skip the installation step because it has the required module already installed.

Install the Microsoft Graph PowerShell SDK
Learn how to install the Microsoft Graph PowerShell SDK with PowerShellGet.

Connecting to the Graph

After installing, you have to change the Graph endpoint to the beta endpoint.

Select-MgProfile -Name 'beta'

Now you are going to import the required submodule.

Import-Module Microsoft.Graph.WindowsUpdates

Since the Graph API has a granular permission model and uses scopes, we need to look up which permissions are required to execute the following commands.

Find-MgGraphCommand -command Get-MgWindowsUpdatesResourceConnection | select -first 1 -ExpandProperty Permissions

If you manage or restrict application access in your M365 tenant (which you should!) you might have to add the required permissions to the Microsoft Graph PowerShell app. You should be able to find the app easily using its App ID: 14d82eec-204b-4c2f-b7e8-296a70dab67e

The Microsoft Graph PowerShell app in Azure AD

After granting the required permissions, we can connect to the Graph.

Connect-MgGraph -Scope WindowsUpdates.ReadWrite.All

Removing stale resource connections

After successfully connecting to the Graph, we are ready to resolve the issue. By using Get-MgWindowsUpdatesResourceConnection we can list all existing resource connections registered to our tenant.

Get-MgWindowsUpdatesResourceConnection | select * | fl

In my environment I actually discovered two resource connections directed at the old Log Analytics Workspace which I deleted prior.

All we have to do now is to delete these stale resource connections using Remove-MgWindowsUpdatesResourceConnection.

Remove-MgWindowsUpdatesResourceConnection -ResourceConnectionId 9e694528-8256-4c24-a940-016cbd4f76bc
Remove-MgWindowsUpdatesResourceConnection -ResourceConnectionId 9c75d93d-e265-4120-9500-8509576ac1b1

To validate the removal, we can execute Get-MgWindowsUpdatesResourceConnection again.

Get-MgWindowsUpdatesResourceConnection | select * | fl

After validating, we are done using the Graph and can disconnect.

Disconnect-Graph

To revert back to the production Graph endpoint, use the following command:

After removing the resource connections I decided to wait 24h to let the change propagate, it wasn't advised by Azure support, but it just felt right. Next day I tried to enroll WUfB reports again and voilà, the change went through!

If you found this write-up helpful, consider bookmarking my blog or subscribing.