Hands on with AvePoint Policy Enforcer

I should preface this review with the statement that I do not work for AvePoint, nor am I being compensated in any way for this article. I like to state that since some of the reviews that I have read by other SharePoint experts are actually paid reviews which to be honest sometime cause me to question the truthfulness.

As a SharePoint Administrator for a Fortune 50 company I am constantly faced with trying to retrofit our hundreds of site collections with the most current set of security rules and governance policies. Up until this point I had spent quite a few hours writing ad-hoc scripts to tweak changes here and there, but as the number of site collections have grown, so have my concerns for making a mistake and causing harm to our production sites.

As part of their SP3 for the DocAve 6 platform, AvePoint introduced their new Policy Enforcer engine. I think a really easy way to explain the power of this new functionality is to walk you through a busines case.


Many large enterprises scale out their implementation into farms based on the role in which they will serve – for example you could have a Project Farm and then an Intranet Website farm. Each farm has its own unique sets of Governance policies based upon the content that is being hosted. To be more clear, the Portal Farm is likely established to host published content – such as the user homepage and departmental sites. The rules behind sites going into that farm is that content approval must be enabled on all lists & libraries.

Now, take that one particular Governance ruling.. All lists & libraries must have content approval enabled. As a Farm Administrator with 1,000 site collections – how exactly do you intend on enforcing that particular policy? I’m sure the Developers reading this article will probably begin whiteboarding a timer job that will iterate through the web application site collections, read the lists, and iterate through. The IT Pro’s reading the article are probably thinking about a powershell script, likely doing the same thing, set to run via a scheduled task. Both are correct in their thinking – surely you can accomplish the task either way, but it becomes fun when it comes time to support/make changes to that code. For us as a large enterprise, code deployments can only happen during certain maintenance windows. And in regards to the PowerShell script, absolutely this is less intrusive, however that means you as the ITPro are now responsible for maintaining and running that particular script. And oh, by the way, now your manager wants reporting to find out which sites are out of compliance.

The first step to accomplishing this with Policy Enforcer would be to create a new profile at the defined scope.. For this example I’m blanking it out on the left hand side but I’m going to set this policy at the Web Application level. You could also drill down and scope it at the site collection, site, or even down to the list & library level.


As part of that profile, you will want to setup a new data collection job which will go out and look at the scope specified. For this example, I’ll give the name “Content Approval”. For the same of brevity I’ll leave all the Auditor Mode & Scan Mode options enabled and not monkey with the default scan of every 30 minutes. Basically, the purposes of those at a high level are to narrow down the scope of what you’re scanning for. Example: if you just want to different rules for different farms at different levels, you could specify different data collection jobs.. Since it is also all based on the SharePoint object model so basically you can do ANYTHING and EVERYTHING. 🙂


Once you click save you will arrive back at the Profile, I’m going to create a new rule to make sure Content Approval is turned on. So I’ll click the Create Rule, and select the List Versioning Settings.


The rule will get added to the profile – and then I’ll configure it by clicking the Configure Rule button in the middle of the profile manager window. I’ll then check off Content Approval.


If you scroll down to the bottom of the configuration screen you’ll see that there’s a check box that says “Automatically revert to the settings above.” You also have the option of sending a notification to someone that the action is being taken.


Click the save button and you’re done. Now, the next time your scan policy (mine was called Content Approval) kicks off – it will go ahead and touch all lists & libraries and enable content approval!

The first time you run through this it might seem like a few steps, but to be honest after you setup all of your data collection jobs it is really simple to blast through a couple of different policies. You can setup this same type of policy for all sorts of things such as features. More information about what you can target is below.

I’m probably going to put out a few more posts on some of the cool things I come up with but for now but I think the above example shows just how easy it is to quickly propagate a simple change to hundreds or thousands of site within your environment.

More information can be found on AvePoint’s site along with this Feature Spotlight:


2 comments on “Hands on with AvePoint Policy Enforcer”
  1. jthake says:

    Thank you so much for the write up. Our team worked hard on Policy Enforcer to make sure it met the needs of our customers. We have a ton of new rules that we’ve written already for the next release too. If you want to be part of a preview of these rules please ping me http://www.linkedin.com/in/jeremythake

  2. So glad to see Policy Enforcer is geting the job done in your organization. We’re adding another 14+ rules in the next SP, if you’ve got suggestions for more rules we’d love to hear them and incorporate into our next package 🙂

Leave a Reply to Shyam Oza (@ShyamOza) Cancel reply