Yorick Kuijs edited this page Sep 14, 2018 · 29 revisions

Welcome to the SharePointDsc wiki!

Here you will find all the information you need to make use of the SharePoint DSC resources, including details of the resources that are available, current capabilities and known issues, and information to help plan a DSC based implementation of SharePoint.

Please leave comments, feature requests, and bug reports in the issues section for this module.

Getting started

To get started, download SharePointDsc from the PowerShell Gallery and then unzip it to one of your PowerShell modules folders (such as $env:ProgramFiles\WindowsPowerShell\Modules). To install from the PowerShell gallery using PowerShellGet (in PowerShell 5.0), run the following command:

Find-Module -Name SharePointDsc -Repository PSGallery | Install-Module

To confirm installation, run the below command and ensure you see the SharePoint DSC resources available:

Get-DscResource -Module SharePointDsc

DSC requirements

To run PowerShell DSC, you need to have PowerShell 4.0 or higher (which is included in Windows Management Framework 4.0 or higher). This version of PowerShell is shipped with Windows Server 2012 R2, and Windows 8.1 or higher. To use DSC on earlier versions of Windows, install the Windows Management Framework 4.0. It is strongly recommended that PowerShell 5.0 (or above) is used, however, as it adds support for the PsDscRunAsCredential parameter. The logic behind this is explained on the page "Remote sessions and the InstallAccount variable" page. PowerShell 5.1 includes significant improvements in Desired State Configuration and PowerShell Script Debugging.

Supported SharePoint versions

SharePointDsc currently supports SharePoint Server 2013 with Service Pack 1 (or a higher update level) installed, running on Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2. It also supports SharePoint Server 2016 RTM (or higher) running on either Windows Server 2012 R2 or Windows Server 2016 TP4 (or higher).

For SharePoint 2013 to ensure correct provisioning of the User Profile Service and the User Profile Sync Service, the February 2015 Cumulative Update is also required. If you are installing SharePoint via the DSC resources, you can slipstream it in to the update directory so it is applied during the initial installation.

SharePoint Foundation is not supported.

Multilingual support

Where possible, resources in SharePointDsc have been written in a way that they should support working with multiple language packs for multilongual deployments. However due to constraints in how we set up and install the product, only English ISOs are supported for installing SharePoint.

Resources' structure

Resources inside the SharePointDSC module are categorized into 4 main groups: Common Components, Specific Components, Distributed Components and Utility Components.

Common Components

These components need to be defined within every node in the farm. The parameters specify for the resources associated with Common Components should be the same for each server (e.g. the same language packs need to be installed on all servers in the farm). As an example, the SPInstall resource, which installs the SharePoint binaries on a server, needs to be present within every node in the farm. It is not enough to have only one server with the binaries installed on in a multi-server farm. Common Components are identified in the list below with the mention ** Common **.

Specific Components

Just like the Common Components, the Specific Components need to be included within every node in the farm. Their only difference, compare to Common Components, is that the resources' parameters may differ from one node to another in the farm. As an example, the SPServiceInstance resource, which allows us to enable specific services on a SharePoint Server, will be specified for each server in the farm, but with different "Ensure" value to allow certain services to be started on specific servers, but not on others. Specific Components are identified in the list below with the mention ** Specific **.

Distributed Components

This category englobes the major part of the resources. Distributed Components should ONLY be defined within ONE node in the farm. As the name states it, those are distributed which means that components of this type are normally stored in a central database. Specifying these components on more than one node in the farm may introduce unexpected behaviors (race condition, performance issues, etc.). For example, if you wanted to create a new Web Application using the traditional PowerShell approach, you would pick one server and run the New-SPWebApplication cmdlet on it, you would not run it on each of the servers in the farm. To define these components, identify one server in your configuration (e.g. the first server to create/join the farm), and define all the Distributed Components within it. Distributed Components are identified in the list below with the mention ** Distributed **.

Utility Components

Utility Components are components that do not generate an artefact per say. Their sole purpose is to help you initiate a check or apply a patch. As an example, the SPMinRoleCompliance resource simply returns true or false (in its Test-TargetResource function) if the services running on a server correspond to the services that are associated with its assigned MinRole. It does not enable, disable or even create any service instances. Utility Components are identified in the list below with the mention ** Utility **.

Included resources

The SharePointDsc module includes the following DSC resources

Known issues

There are some known issues (and their solutions/workarounds) with SharePointDsc or PowerShell:

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.