SharePoint Server 2016 Administrative Actions Log

One of the top feature requests from day one on sharepoint.uservoice.com is Administration Auditing. The idea behind administrator auditing was that actions administrators took against the farm, creating a new Web Application, deleting a site via Remove-SPSite, changing property bag values, and so on, would be logged by SharePoint. This would allow a team of SharePoint Administrators to know who is doing exactly what and when. I’ve managed quite a few farms where there multiple SharePoint Administrators, from “tier 2” to SharePoint Architects. There are quite a few instances where it would have been helpful to know who did what, exactly. The SharePoint Server 2016 Administrative Actions Log, formerly announced for release in the November PU with Feature Pack 1, is a start in the right direction for my feature request. We’ll see a couple examples of how you might use this.

To start with, to use this functionality you will need two things: The November PU and a Usage Service Application. Administrator Actions logging stores the data in the Usage database using the 31 day retention period. Like other data written to the Usage database, the Administrator Actions logging has 32 tables; dbo.AdministrativeActions_Partition0 through dbo.AdministrativeActions_Partition31. These tables can be queried directly or query the view AdministrativeActions directly, which provides a condensed view of all tables.

Let’s move onto SharePoint. When an administrator action event occurs, it is first logged to the file system of that particular SharePoint server. This will be at the location where your Usage log files are under the AdministrativeActions folder. By default, this is located under C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\. When actions take place, they’re logged to a .usage log. For this example, SP05-20160926-1542-20160926-15420.usage is the name of the log. It is actually just a plain text file with human readable information. But this isn’t the way we’ll interact with it.

The SharePoint Management Shell offers a way to query and sort Administrative Actions via the Merge-SPUsageLog cmdlet. This is a generic cmdlet for querying Usage logging information, but is fairly easy to use. To query the Administrative Actions log, simply use:

From there, we can also pass in the -StartTime, -EndTime, or -Servers parameters. If you do not pass in the -StartTime parameter, the cmdlet will query data from the previous hour only. So let’s look at an example of creating a new Web Application. Now, this process creates a lot of entries in the Administrative Actions log, so I won’t show all of them, but this will give you a general idea of what the data looks like.

Based on this, we can see the User who performed the action (me!). There are a lot of filters we could use here, such as Merge-SPUsageLog -Identity "Administrative Actions" | ?{$_.User -match "trevor"} or Merge-SPUsageLog -Identity "Administrative Actions" -StartTime 9/20/2016 -EndTime 9/27/2016 | ?{$_.ActionName -match "UserPolicy"}. Pretty simple to use and get relevant data out of the logging.

What does it cover? This is a very high level list of what is covered as not all actions that you may think flow under these high level actions are logged, but a great portion of them are.

And the verbs associated with one or more of the above actions.

In the above example I provided, we can see Administration.WebApplication is the action with New as the verb, giving us Administration.WebApplication.New as the Administrative Action.

Hopefully this post helps with understanding what the Administrative Actions Logging is as well as how to use it. While Administrative Actions Logging doesn’t exactly match up with my original request, I’m sure the SharePoint Product Group will get there!

4 Comments

  1. Hi,
    have you already seen this feature in some insider preview? Will it not have a manager-friendly UI (it’s better to show nicely looking logs in central admin than some mumbo-jumbo in powershell to prove you didn’t do the thing)?

  2. Hi Trevor,

    Doesn’t seem to work for me.
    I’ve created a new site collection on my SPS2016 test farm (September 2016 CU installed) and when running Merge-SPUsageLog -Identity “Administrative Actions” I got nothing back from the cmdlet.
    Here are my settings:

    Get-SPUsageDefinition

    Name Retention Enabled
    —- ——— ——-
    Administrative Actions 7 True
    Analytics Usage 7 True
    App Monitoring 7 True
    App Statistics. 7 True
    Bandwidth Monitoring 7 False
    Content Export Usage 7 True
    Content Import Usage 7 True
    Database Wait Statistics 7 True
    Definition of usage fields for microblog t… 7 True
    Definition of usage fields for service calls 7 True
    Definition of usage fields for SPDistribut… 7 True
    Definition of usage fields for workflow te… 7 True
    Feature Use 7 True
    File IO 7 True
    Page Requests 7 True
    REST and Client API Action Usage 7 True
    REST and Client API Request Usage 7 True
    RUM Global Provider Description 7 True
    Sandbox Request Resource Measures 7 True
    Sandbox Requests 7 True
    Sandbox Requests (new) 7 True
    Sandbox Site Resource Measure 7 True
    Sandbox Solution Resource Measure 7 True
    Simple Log Event Usage Data_RUMUsage 7 True
    Simple Log Event Usage Data_SPUnifiedAudit… 7 False
    Simple Log Event Usage Data_UserEngagement 7 True
    SQL Exceptions Usage 7 False
    SQL IO Usage 7 False
    SQL Latency Usage 7 False
    Task Use 7 True
    Tenant Logging 7 False
    Timer Jobs 7 True
    User Profile ActiveDirectory Import Usage 7 True
    User Profile to SharePoint Synchronization… 7 True
    Web Part Use 7 True

    Am I doing something wrong or am I missing something ?

    Thanks,
    Andrei

Leave a Reply