sharepoint sucks




12/11/2014 Updated the script to version 1.1 and provided a download link (see end of this blog post for more details).



PowerShell is a great automation language. What is nice about it, is that it is present in (almost) all of Microsoft palette. As a powerShell developer (Did some one said Devops?) we can technically work on anything as long as it has Powershell underlying on it. And that is really one of our strength! In today’s topic, we will discuss Powershell in Sharepoint.

Knowing the PowerShell language and syntax pretty well is really a strong asset. We can easily go from one (infrastructure) field to another. This implies that we often need to adapt to new technologies and learn their basic architecture components in order to be able to write a script that will not blow up the complete production environment.

Sharepoint is one these Microsoft technologies that is present EVERYWHERE. A lot of the huge companies out there use it for various different business scenarios. It really must be a great collaboration tool (I cannot give a strong opinion for my self, but that will come soon I guess). Yet every body seem to hate it. If you google “Why sharepoint sucks”, you will receive huge amount of results back. Anyways, ignoring all of this, I just start my day, with the task of adding a Specific AD group to several all of our Web site collections.

Ok, seems easy right?

I know that the architecture for a site is (in a very basic shape) like this:

  • Web Application
    • Site Collection
      • Site

It is pretty much comparable to standard file system hierarchy, so nothing to complicate there!

But when you take a look in the powershell cmdlets, it seems like they haven’t really respected the same naming convention (or at least, It is not as clear as I am used to with other products).

The three main cmdlets that will be used here are :

  • Get-SPWebApplication
  • Get-SPSite
  • Get-SPWeb

But, when I looked at their parameters I got confused. I created the following small mind map which helped to link which cmdlet was actually needed for what part of sharepoint.


Sharepoint Hiearchy powershell


Why is that important ? Well, what I actually needed to do, is to set read and write rights to all of the child sites of a specefic site collection.


[stextbox id=”note”]Since I never worked with Sharepoint before (besides ‘clickingly’) I needed to learn (again) something new.[/stextbox]


The logic and the technicity behind this script is really not that high. But I simply want to share it with the community since I have had a small learning curve here.

Writing about it actually helps me to actually better understand what and why I have done things. So why not give it out to everybody and see what will come back out of this? 🙂

PowerShell and Sharepoint:


Big learning points:

  • Sharepoint architecture.
  • PowerShell cmdlets


The sharepoint cmdlets are not based on a module, but on PsSnapin. (yep, a PSSnapin).

[stextbox id=”note” caption=”PSSnapin”]

A PSSnaping work just like a regular PowerShell module. We first have to load the cmdlets into memory, and only then we can start really work in the sharepoint automation activites.

If we look at the cmdlets available for “PSSnaping” we will have the following results back.


Run on my Windows 10 Machine

We can use the following line to see what PSSnapins are available on the system:

To see the ones that are currently loaded use Get-PSSnapin

Now to be able to load the sharepoint PSSnapin, the following will need to be called prior to any Sharpeoint code execution:






As mentionned by  ØYVIND KALLSTAD, I did a small mistake in the script. Actually, the version I first published, was not the final version that we used in our production environment. I have updated this blog post and added the latest version (1.1) in the scripting list section. I have also left the version 1.0, just to see the differences that resides in between the scripts, which are resumed in the following points (or should I say learning points?).


[stextbox id=”note” caption=”$Changes -eq “new learning points””]


  • The most import of all “EnsureUser”

The most significant change I did between version 1.0 and 1.1 is located at line 102 (and has been showed to me by our sharepoint specialist):

In version 1.0, I would use the following logic in order to first verify if the account is already created in Sharepoint, and if not, create it.


.ensureUser does exactly that! It verifies if a user is present in sharepoint already, if not, it will add it into sharepoint (AD users / groups first need to be imported into sharepoint before that can actually be used used in sharepoint!). If the user is present, it will simply continue to the next line.
  • -match is not -contains

For some reason, the -contains I used didn’t worked as expected. The link that was present in the exlusionlist file was never skipped. This mostly came because of the fact that the if condition was always false. (So testing in a test environment is really not done only for peanuts!).Changing the -contains to -match fix that issue and allowed us to be able to filter out some specific sites that we didn’t want to be affected by the script.

  • ValidateScript parameter for $fileexlusionlist parameter

If a FileExlusionList is specified we want to be sure that it actually exists and is present. I have added this validateScript parameter to “test-path $_” simply to be sure that the file actually really exists.
Of course, we could have added more validation, but this script was a one-shot script, and the public that was going to use it had sufficient knowledge in order to make these checks enough.

  • Comment based help update

I have also updated the comment based help, just to be sure that I remember what this script actually was about when I will take a look into it again in 6 months.

Do you add comment based help to your scripts also? No time for that you say ? Sure, nobody does. But you might rewrite a script that you already had somewhere (or a function), or will need some time to search in your logic and try to understand what exactly happens in there. And who has time for that?



Download final Script:


[stextbox id=”download” caption=”Download script”]If you want to download the script, you can get it from technet right here (don’t forget to rate it by clicking on the yellow stars ) –> download link[/stextbox]




Script listing:

Version 1.1:



Version 1.0


Dig more deeper into it!

Technet Powershell references –>