In this blog post I’m going to discuss how to track admin user backend actions in the new SharePoint audit feature, Administrative Actions Logging, with the help of SPDocKit.
For some time, SharePoint administrators have complained that they wanted more out of Central Administration—for instance, audit admin actions logs and track admin changes. Well, we finally got it with the SharePoint Feature 2016 PU Feature Pack 1. Administrative Actions Logging was announced last November and it is intended to help SharePoint administrators keep track of admin changes in Central Administration.
SharePoint 2016 Feature Pack 1 novelty: Administrative Actions Logging
What this feature brings to SharePoint is the ability to audit SharePoint changes since their logs are stored. These changes track actions such as when one of your admins creates a new Web App, deletes a site, and more. In fact, it logs every change a SharePoint admin made in the farm so you know exactly:
- Who performed a certain action,
- What was the action in question,
- What was the target of the action,
- The timestamp when it happened.
Track SharePoint admin changes with SPDocKit
Someone changed the admin settings in the Central Administration and you have no clue who or what changed? How do you investigate admin changes and updates?
We at Acceleratio have decided to incorporate this new SharePoint addition into SPDocKit and make the whole logging business easier. So what’s going on?
Here’s the thing—in your SharePoint environment, you always have more than one SharePoint admin taking care of your farms, for sure. There’s a way to use PowerShell scripts to track which admin did what on a particular farm to get a glimpse of what’s going on and find out who’s making those annoying changes that you keep getting errors on, making you bang your head against the wall as you troubleshoot.
Now let me get to the point.
You can still use PowerShell to audit these administrative actions logs (this is where your smile stretches into a yawn), or to trace them by going through the logs from the SharePoint Usage Database which you can enable in the Central Administration. Here’s a TechNet article on how to use Administrative Actions Logging, if you want to check it out and see for yourself that’s it not as intuitive as one would imagine.
The third option is to use a third-party tool such as SPDocKit to track admin user backend actions. And you can use SPDocKit in more ways than just generating the Administrative Actions Logging report. It’s a tool to administer the entire SharePoint environment, along with permissions.
To stay up-to-date with SharePoint 2016, we’ve created the Administrative Actions Report, which can be found under the permissions section: Permissions Reports > Security Audit > Administrative Actions.
SPDocKit’s Administrative Actions report contains a list of the following:
- Action Type
- Timestamp when the action happened
- Username that made the change and in which domain (target)
- Correlation ID
- Further action details
What SPDocKit does is offer a centralized overview of all administrative actions. Here’s what the report looks like:
Now here’s some more good news; if you’re worried about SharePoint data retention, you can leave your worries behind. The Administrative Actions logs are kept in the SharePoint Usage Database for a maximum of 31 days, so you see how this might be troubling. However, in SPDocKit, once gathered, the data from this report is stored in the SPDocKit database and your logs will be stored for as long as you like.
Also, this report can be exported in PDF, DOC, and XLSX. Refer to the Report Examples page to see what the report looks like once exported.
Download a 30-day free trial and check out all of SPDocKit’s capabilities and if this is the feature you’re looking for, test out the tool and share your experience with your colleagues. If you’re interested in finer details, our team can arrange a personalized demo.
Want to read more posts from us? Subscribe to our blog and stay updated!