Site Collection Auditing

Using auditing setting you determine what to track and how often you need this logs to be saved. Monthly is a good choice in most cases. What’s important to remember is that you want your audit report logs in your site collection and not on the system drive. You can quickly run into trouble if you save logs on the system drive and eating disk space or if you for whatever reason need to switch servers, your audits will be gone. That’s why we should use a Document Library which we name something like AuditLogs. But we don’t want our members or owners of the site to access the audit logs, just the farm admin or IT-personnel. We solve this by breaking permission inheritance, remove everyone and only add the farm account and the group of IT-professionals I’m sure you have in your organization.

In the audit log settings, we hit the browse button to point to our newly created AuditLog library. When we have our AuditLog document library present, we need to set what we want to track. As a test, we can track items being deleted (and restored). 

That’s it! We’ve set a location, and what type of action we want to track – and how often we want the report to be created. At this stage we need to test our Auditing. So head over to a document library, and delete some documents. Preferably documents you’ve uploaded that doesn’t contain much. We don’t want to lose data just to prove Auditing.

And with the documents deleted, we turn back to site settings and hit Audit Log Reports. When we’re there we the Deletion link and press OK. If everything works as expected, the Audit Log is now present in our Audit Log document library.

Opening the spreadsheet, we’ll see both an overview and the details on different sheets.

And that concludes the powerful auditing of SharePoint 2013/2016. Enjoy!

This an annoying error message which can happen in various scenarios. I got this one trying to assign a SPWeb object. I knew the SPWeb existed since it was the root site collection. The complete error message was:

There is a compatibility range mismatch between the Web server and database "WSS_Content", and connections to the data have been blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and build level to return to compatibility range.

Searching the web get many answers, but none that linked to the source. There isn’t any reference (yet) on SharePoint 2013, but it works just as well for 2013 as well. The command-line you run is

PSConfig.exe -cmd upgrade -inplace b2b -wait

Running the GUI-version of “SharePoint 2013 Products Configuration Wizard” doesn’t help, so you really need to run the script using SharePoint 2013 Management Shell as administrator. But you need to do so with your SP_Install or SP_Farm account which shouldn’t be local administrator on the machine. To overcome this problem temporarily add SP_Install or SP_Farm as local administrator and proceed with the script. You may need to run the script several times, as the script does a lot of magic on your content database. I needed four times to make it work all the way without warnings. All four upgrade sequences need to be successful before you’re done.

The -cmd is a mandatory parameter where you specify which action you want to perform. Here we’re using the upgrade command to fix our error of compatibility mismatch.

With the –inplace parameter we specify whether to use version to version upgrade or build to build. This can be quite confusing since when we look at our Configuration database version in the Servers in Farm page in Central administration (<CentralAdminURL:Port>/_admin/FarmServers.aspx) and it specifies a build number on SharePoint Foundation 2013 only. Every time you install a Cumulative Update (CU) or Public Update (PU) you need to run PSConfig. Most of the blogs use b2b parameter value, because you are patching the server, not changing version (i.e. SharePoint 2010 to SharePoint 2013). So we’re using the b2b parameter value in this scenario. See SharePoint Build Number vs Version? for more information.

Using –wait parameter is important to use since it specifies that SP Management Shell doesn’t return until the upgrade process is completed. And we want to wait and see that our failing content database is really upgraded.

There may be things to do after the upgrade i successful. Please check out the log:

Reference: PSConfig command-linereference (SharePoint Server 2010)