M365 Archive: Graph call to unarchive an archived Site Collection returns 423

Question

M365 archiving works fine. Reactivating consistently returns the exception.
This is consistently happening with both delegated and application permissions.
When using delegated permissions, the user has access to the tenant administration site, as well as the Site Collection that we are trying to unarchive.

This has worked fine in the past until recently when the Graph API endpoint started throwing the exception.

I have already raised a service ticket but was told that this is not supported by the channels I was communicating with and to send the request here.

Details of the latest request made to reactivate an archived site using a composite site id:

• "date": "2026-03-03T16:32:45"
• "request-id": [Moderator note: personal info removed]
• "client-request-id": [Moderator note: personal info removed]
• "code": "notAllowed"
• "message": "Access to this site has been blocked. Please contact the administrator to resolve this problem."

The application and the identity that the delegated permissions were used under all have access to the Site Collection before being archived.

Answer 1

Hi Patrik Gerthofer

As far as I know, the error "Access to this site has been blocked" with the notAllowed code occurs because Microsoft 365 places archived sites in a locked state to halt storage consumption, preventing standard access. While you have the correct permissions and the manual reactivation via the SharePoint Admin Center succeeds, the failure occurring specifically through the Microsoft Graph API indicates a backend platform issue.

Additionally, because the site: unarchive endpoint is currently in beta, it is subject to undocumented changes, instability, and transient service disruptions that do not affect production Admin Center workflows. Since beta APIs are not fully supported for production use and are currently experiencing a platform-side issue, you should pause use of the Graph API for this specific operation.

As an immediate workaround, you should either continue reactivating sites manually via the SharePoint Admin Center or automate the process using the fully supported SharePoint Online Management Shell cmdlet Set-SPOSiteArchiveState -Identity <SiteURL> -ArchiveState Active

Hope my answer will help you.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.  

Answer 2

The 423 response and notAllowed error come from the SharePoint/Microsoft 365 Archive platform, not from missing Graph permissions. For archived sites this is expected behavior until the site is successfully reactivated.

Key points from the current behavior and documentation:

1. Unarchive endpoint and permissions
   Reactivating an archived SharePoint site via Graph uses the beta endpoint:

      POST /sites/{site-id}/unarchive
   

   Required Graph permissions are:
   • Delegated: Sites.Archive.All (least privileged) or Sites.FullControl.All
   • Application: Sites.Archive.All or Sites.FullControl.All
   In delegated scenarios, the signed‑in user must also have a supported Microsoft Entra role; SharePoint Administrator is the least‑privileged role for this operation.
2. Supported scenario and national clouds
   The site: unarchive API is supported in all national cloud deployments listed in the documentation and is the documented way to reactivate an archived site via Graph. There is no indication in the documentation that the API has been deprecated or replaced; however, it is a /beta endpoint and therefore subject to change and not supported for production use.
3. What 423 / notAllowed indicates
   For archived content, the platform returns 423 Locked (or similar content unavailable errors) when access is blocked because the content is archived and must be reactivated first. The guidance for files is to treat these failures as expected when content is archived and not as transient outages. For sites, the same underlying archive state controls whether operations are allowed. The error message in the response:

   Access to this site has been blocked. Please contact the administrator to resolve this problem.

   indicates that the site is in a blocked/archived state from the service’s perspective. Even if the app and user had access before archiving, the archive state can prevent operations until the site is successfully reactivated.
4. Alternative supported reactivation paths
   Since the beta Graph endpoint is returning notAllowed, use one of the supported admin paths to confirm that the site can be reactivated at all and that the issue is not with the site’s archive state:
   • SharePoint admin center
     1. Go to Active sites in the SharePoint admin center with an account that has SharePoint admin (or higher) permissions.
     2. Select the archived site.
     3. On the command bar, select Archive.
     4. In the Archive pane, select Reactivate.
     5. Confirm the reactivation (for sites in the "Archived" state, a cost confirmation dialog appears).
     6. Wait for the site to move to Active sites and complete the "Reactivating" state.
   • PowerShell
     Use the SharePoint Online PowerShell cmdlet Set-SPOSiteArchiveState to change the archive status of the site. This is the documented way to archive/reactivate sites via PowerShell.
   • Graph PowerShell (beta)
     Use the Microsoft Graph Beta PowerShell cmdlet Invoke-MgBetaUnarchiveSite with the site ID:

          Invoke-MgBetaUnarchiveSite -SiteId <site-id>
     

     This calls the same beta API but via the PowerShell SDK. Ensure the calling identity has Sites.Archive.All or Sites.FullControl.All and the appropriate Entra role.
5. What to verify in this scenario
   Based on the documentation, the following checks are relevant:
   • Confirm that the site is one of the supported templates for Microsoft 365 Archive (for example, Team site, Communication site, Teams site, etc.). Unsupported templates (such as some channel sites) have limitations and may not behave as expected when archiving/reactivating.
   • Confirm that the site is in a reactivatable archive state ("Recently archived" or "Archived") and not in a state where the service has blocked access for other reasons.
   • Confirm that the token used for the Graph call actually has the correct permission type and scopes (delegated vs application) that the endpoint supports. The documentation emphasizes that many 4xx errors occur when the token’s permission type does not match what the endpoint supports.
   • Since /beta APIs are not supported for production and can change, validate whether the same operation succeeds via the SharePoint admin center or Set-SPOSiteArchiveState. If those succeed but /sites/{id}/unarchive continues to return notAllowed, this indicates a platform issue with the beta endpoint rather than with tenant configuration or permissions.
6. Recommended next steps
   • Use the SharePoint admin center or Set-SPOSiteArchiveState to reactivate one of the affected sites and confirm that reactivation works end‑to‑end outside of Graph.
   • If reactivation works via admin center/PowerShell but the Graph /beta site: unarchive endpoint still returns 423/notAllowed for the same site and identity, treat this as a regression in the beta API and continue to track it via the support ticket or Microsoft 365 Archive support channels, using the request IDs and timestamps already collected.
   • For production workflows, prefer the supported admin/PowerShell approaches until the beta Graph endpoint behavior is corrected.

---

References:

• site: unarchive
• Manage Microsoft 365 Archive
• Invoke-MgBetaUnarchiveSite
• Developer guidance for Microsoft 365 Archive
• Application and delegated permissions for access tokens in the Microsoft identity platform