Introduction SharePoint site designs are powerful tools for automating site configuration, but they’re typically applied during site creation. What if you need to apply Microsoft’s out-of-the-box site designs to existing sites using automation? The PnP PowerShell, CLI for M365 and other PowerShell module cover applying custom site designs only. We can leverage a PowerShell hack using REST API calls to achieve this functionality. Thanks to Arash Aghajani who pinpointed on feasibility and requested for it to be natively available within PnP PowerShell.

Introduction One of the most frustrating experiences for SharePoint users is when a document link that worked perfectly yesterday suddenly returns a 404 error today. This scenario is all too common, especially after migrations or when documents are renamed or moved. Understanding how SharePoint links work and their limitations is crucial for effective document management. The Problem: Broken Links After File Changes This raises an important question: Why do SharePoint links break when files are renamed or moved?

Client secrets have traditionally been the go-to method for deploying Power Platform solutions from Azure DevOps, utilizing app registrations from the Azure platform. However, my personal experience has shown that this approach can be problematic, especially when you are not an application admin. It often involves wasting time figuring out why deployments have failed due to expired or missing client secrets. Even when reaching out to someone with application admin rights, they might generate a new client secret but forget to update the service connections for each service connection within Azure DevOps or the application admin does not have access requiring to reach out to someone else who have access, causing further disruptions.