Reporting on admin changes made to your SharePoint environment is important for several reasons. It helps you keep track of who made changes and when they were made. This can be useful for auditing purposes and can help you identify any unauthorized changes that may have been made, or changes that don’t align with your current governance strategy. By generating and reviewing these reports, you will be able to better troubleshoot issues that may arise in your SharePoint environment.
Requirements
Roles & Licensing
- SharePoint Admin – To generate the Change History reports you will need to have the SharePoint Administrator or above role assigned to your account. If you are a consumer of the report, the Report Reader role will be enough.
- SharePoint Advanced Management P1 – To generate Change History reports, you need to roll out the SharePoint Advanced Management (SAM) P1 license for all your users.
Our Scenario – External Sharing Report
We have recently created a sensitivity label that can be applied to selected Microsoft Teams and SharePoint sites to restrict external sharing. For our report, we would like to see when the policy to apply the label was added to our site - SAM Change History Reports - and if it has subsequently been changed, to help us better understand these reports for future scenarios.
Step 1 – Generate the Change History report
From the SharePoint admin center (https://[tenant name]-admin.sharepoint.com), open the Change history reports page by clicking on Reports and then Change history.
If you haven’t generated any reports previously you will be able to click on the Create report prompt in the middle of your page, alternatively, you will be able to click on the + Create report button at the top left of the list area of your previously generated reports.
Once selected, a flyout will appear on the right of your page where you will be able to add the details for your report, such as the name, report scope, which sites will be audited, and which SharePoint Admins and site admins will be included in the report. For this demonstration, we will be generating a report with the following details:
- Name – Sensitivity Label Report.
- Scope –8/7/23 – 8/14/23.
- Sites included – SAM Change History Reports.
- Changes made by – All SharePoint Administrators and site admins.
It’s important to note that the reports will only be generated for up to 180 days ago. Any audit data beyond that is automatically deleted by Microsoft.
With the report requirements configured, we can begin the report generation. This stage will take some time, depending on how broad your scope is and how many sites have been included in the report.
Step 2 – Change Management report overview and in-depth review
Once the report generation has completed, we can review the report findings. On the Change History page, we can see how many admin actions were performed within the scope of our report. We can also download a detailed CSV of these actions:
Once downloaded, we see a spreadsheet like the one below, detailing the admin actions on our chosen scope (we have formatted our report into a table to improve readability):
In this report we can see the following:
- Date (UTC) – When the admin action was performed.
- Resource – Which site the change was made on.
- Action – What the change relates to.
- Users – The account used to make the change.
- Previous value – What the original value for the setting or configuration was before the change was made.
- New value – The value the setting or configuration has been changed to.
Once you have finished interpreting the report, you will be able to confirm the actions taken on a particular site or sites and ensure that the governance of your SharePoint environment matches up with your organization’s broader governance strategy.
Final Considerations
The reports supplement your governance strategy
Whilst these reports are useful to help unearth and better understand changes made within your environment, they are only a supplement to a proper governance strategy, as they only allow you to respond reactively; as opposed to policies, sensitivity labels, and processes that allow governance to be applied proactively.
Limit the number of admins within your environment
It’s always a good idea to limit the number of admins within your organization. With fewer admins, there should also be fewer changes made to your environment that fall outside of your governance strategy, making it easier to enable consistency for your users.
