Why should I use PowerShell to define my SharePoint site structure?

SharePoint is really a great tool. We can easily create lists and libraries with all the columns for metadata we need. All just with using the web interface of SharePoint. When we need to create content types to build some more structure for our lists and libraries, we can do it via the web interface, too. And, when I need to do any other setting in my site, do any regional or language setting or activate any additional feature, just do the necessary clicks in the site settings in the web interface. So, why the hell should I use PowerShell or any other automation tool to create the site structure?  

When preparing a simple proof of concept, or a really simple site structure, without any other needs, using the web interface is the right choice, because it is the fastest way to show proper results. But what, when any additional development is needed? What, when we need to implement any HTML and JavaScript (via a Content Editor Webpart)? What, when we need to implement a remote timerjob to do any regular tasks? Or when we need an additional web application that needs to work with the data stored in our SharePoint site? In these cases, it is necessary that we have object names and object id’s, we can rely on, because our development must work in our development environment and in any other stage (integration, test, production, …). To be sure, we have always the same object id’s and object names, we need to automate the creation of the site structure. And that is, where PowerShell (best with the PnP extensions) will be our best friend. Especially with the PnP Extensions, it is very easy to create columns (and site columns), content types and also lists and libraries. Creating views is not the strength of the PnP extensions, but with PowerShell we also can use any function available of the SharePoint Client Side Object Model (CSOM). And because we need to script the creation of the objects (or artefacts) in our SharePoint site, we have full control about the id’s for fields or content types and the names (for fields, content types, lists and libraries). So, when it comes to development (eg. timerjobs), we know the names or id’s of all the objects in our site. Especially, when we use id’s, when using these objects, any user can rename an object in the user interface, but our solution will still work properly. 

When we work in iterations (a good practice today), our automation scripts easily can make modifications or extensions to our former development. Because we know the id’s, the internal names of the artefacts and the structure, we can easily reconfigure the site to our needs. 

And, when we at first do not know how we can do something with scripting, because we do not know, where and how a setting is stored, we can first configure in the web interface and then investigate in tools like the SharePoint Client Browser

So, what are the pro’s and con’s for automation with PowerShell? 


  • Full control on id’s and internal names 
  • Ability to provide an iterative approach for the solution deployment 
  • Providing additional development is easy, because all objects are well known 
  • The solution is reproduceable in any other environment or tenant 


  • Scripting means typing in files and for some SharePoint objects that is time consuming 
  • Because it’s so easy, to configure a site structure in the web interface, most customers won’t believe that defining a site structure will cost that time 

My advice from my own practical use and all my former SharePoint projects is, whenever you need to transport your solution from your development environment to any other stage (eg. the environment of your customer), use a PowerShell script to automate the creation of the site structure. Reduce the manual steps for a deployment to a minimum (the same as when we do any other development and need to deploy our solution). When you have developed any other kind of software that works with your SharePoint environment, also use automation to do the deployment.  

And, have in mind, there is another advantage, when using scripts and automation: you can reuse the objects and code you have developed. The strength, when developing today is, to reuse anything we have already done in any other project. Doing this, when defining a site structure via the web interface, is impossible. 




PowerShell PnP – Register Custom Action to Content Type

It seems, when registering a custom action with the Add-PnPCustomAction cmdlet, we need to use uppercase characters for the content type ID, as shown in the following example.

I took some time to figure this out, when my tab was not shown in the ribbon.

How does OneDrive for Business synchronize files?

One pager, provided by Microsoft, about the OneDrive for business client. It is using an installed Office application (2016 or newer) to synchronize Office files and it uses the Background Intelligent Transfer Service (BITS) for larger files.

How does OneDrive for Business synchronize files?

Add choice to choice field in SharePoint Online

To add a new choice value to an existing choice field in SharePoint Online, this small PowerShell code snippet could be used. To run the script, a connection to the SharePoint site must be established and the PowerShell PnP Extensions must be available on the computer. Then we can use this simple code (remember to use another fieldname 😉 ).

Run Rest call against SharePoint Online from PowerShell

To run a Rest call against SharePoint Online from PowerShell, we can use this simple script, inspired from https://blog.vgrem.com/2014/02/27/working-with-the-sharepoint-online-rest-service-via-powershell/.

All you need to do first is, install the SharePoint Online Client components or the SharePoint Online PowerShell extensions and copy the files Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll to the same directory as the script below.

A sample could look like this: .\RestAgainstSharePointOnline.ps1 -Url https://{yourtenant}.sharepoint.com/_api/web -UserName {youruser} -Password {yourpassword}

Make Microsoft Teams Team Visible in Outlook

By default, when a new team is created in Microsoft Teams, this team is not visible in Outlook, even when the team has an underlying group. Additionally the team is not shown in the address list, when you want to add a recipient for an email. The reason for this is that the properties HiddenFromExchangeClientsEnabled and HiddenFromAddressListsEnabled are set to true, when the group for the team is created.

To make the team visible in Outlook we can use some PowerShell. First we need to connect to Exchange Online. Here is a simple script to do this connection:

When that is done, we just have one single line of code to run, to make the team visible in Outlook:

Set-UnifiedGroup -Identity MyTeam -HiddenFromExchangeClientsEnabled:$False

Now, you can discover the group for the team in Outlook/Outlook Online.

Remove NuGet packages from local machine

When working in Visual Studio and downloading packages from NuGet to the projects, a copy of these packages is stored on the local machine. When using virtual machines for development, like I do, the free space on the harddisk minimizes by time.

To remove these packages, we can use the NuGet.exe tool (see https://docs.microsoft.com/en-Us/nuget/consume-packages/managing-the-global-packages-and-cache-folders).

So first run

.\nuget.exe locals all -list

And with the output run

.\nuget.exe locals {section} -clear