SharePointDSC is a community driven PowerShell Desired State Configuration (DSC) module, managed on GitHub at https://GitHub.com/PowerShell/SharePointDSC and which lets you define the configuration of your SharePoint 2013, 2016 and 2019 farms using a declarative approach. Let us start by looking at a side-by-side example of how you would go about creating a new SharePoint Web Application in the “classic” PowerShell way compared to the DSC way.
| Classic PowerShell | SharePointDSC |
|---|---|
New-SPWebApplication -Name "Root Web Application" ` -ApplicationPool "SharePoint - 80" ` -ApplicationPoolAccount "contoso\sp_apppool" ` -Url "http://root.contoso.com" ` -Port 80 |
Configuration DSCDemo
{
Import-DSCResource -ModuleName SharePointDSC -ModuleVersion 2.3.0.0
Node WFE
{
SPWebApplication Root
{
Name = "Root Web Application"
ApplicationPool = "SharePoint - 80"
ApplicationPoolAccount = "contoso\sp_apppool"
Url = "http://root.contoso.com"
Port = 80
}
}
}
|
The two code samples above will produce the exact same result on the farm when executed. They will create a new SharePoint Web Application, on port 80 running under the same app pool with the same specified credentials. Under the cover, DSC is just a wrapper around “classic” PowerShell code. Somewhere in the DSC code for the SPWebApplication resource, we are making a call into the New-SPWebApplication cmdlet. The following figure shows the various layers that make up the SharePointDSC module.
The question then becomes “Why do we even want to use DSC if it adds yet another layer of logic to our deployment?”, and that is a very fair question. To answer this question, it is very important for us to understand what the PowerShell Desired State Configuration engine is in the first place. DSC not only allows you to configure machines in a given way; it also allows the machine to stay configured that way by providing configuration monitoring capabilities. Once a machine is configured with DSC, the engine known as the Local Configuration Manager (LCM) will preform frequent routine checks to verify that the machine is still is its “Desired State” (defined by our DSC script). By default, if it detects that the machine’s configuration drifted from the configuration we specified in the first place, it will report errors in the Event Viewer, and can even attempt to automatically repair itself. This is known as the PowerShell DSC Configuration Modes.
Assume that you were to deploy your new web application using the classic PowerShell way (left column in the above table). Running this cmdlet will create the Web Application just fine, but the moment it is created, you have no real control over what users with sufficient permissions will do to its configuration. If a user somehow decides to change the port of the Web application for whatever reason and breaks the environment, you’ll only figure this out when your users start calling you to complain. With DSC however, if you had deploy your web application, the LCM would have automatically picked up the configuration drift, reported it in the Event Viewer (maybe even triggering an email to notify the administrators) and could even have automatically fixed the issue by changing the Web Application’s port back to being what it should have been.
The key takeover from this article is that SharePointDSC is not just about creating and configuring SharePoint farms. It is also about making sure that we have automated ways to keep those farms healthy and in their desired state. On top of offering great monitoring capabilities, the DSC engine also allows you to use what we call Pull Mode to centrally managed the configuration of your farms and allows you to make a single change in configuration to automatically have all the farms you manage get this change. While DSC Pull Mode is not the focus of this article, you can read more about it in the following article.
