Creating Configuration Files
PowerShell DSC allows for a single configuration file to be applied to a server to describe what is should 'look like' - what services will run, what products are installed, and how they are configured. In the context of deploying a SharePoint farm this gives us a number of options for how to go about deploying the farm with a number of different configurations based on roles, with a number of components that are common across all deployments.
When describing a configuration for a SharePoint server, there are a number of common components that are likely to exist in every configuration. Namely the components related to the installation of the product - xSPInstallPreReqs and xSPInstall.
It is also important to understand how the xSharePoint resources impersonate and communicate with the SharePoint PowerShell cmdlets, and this is done through CredSSP authentication This means you are likely to want to use the xCredSSP resources also (see [Remote sessions and the InstallAccount variable](Remote sessions and the InstallAccount variable) for more information on this).
Lastly based on the use of these remote sessions, you will also likely want to include the xSPClearRemoteSessions resource at the start of your configuration to clear previously used sessions. Again, see the remote sessions article mentioned above for more information on how this is used and why it is needed.
The single server deployment is the most straightforward - you will have one configuration file that will describe all of the components that you want to have on that server. This is not likely to be a production deployment, but more a development or testing server. The specifics of what you put in to this configuration are largely up to what you want this server to be running, but you will always include xSPCreateFarm to create the farm, and xSPDistributedCacheService to enable the distributed cache service in the farm. The rest can be as little or as detailed as you need it to be in order to achieve your desired configuration.
When we begin to explore scenarios that include more than one server, the implementation of our configuration changes significantly. There can no longer be a single configuration that applies to all servers, you need to start looking at what "roles" a server will fulfill within your farm. Common roles would include "application server", or "front end server", perhaps in a large deployment you might have a "distributed cache server" or a "search server". The individual roles you have within your architecture will dictate the number of unique configurations that you need to create.
For example, consider a farm that has the following architecture:
- 2x Web Front End Servers
- 2x Application Servers
This is a typical "small" SharePoint deployment, as it separates out the services to the two layers to handle the different workloads, and still provides redundancy through having at least 2 servers in each "role". In this case, I would need to have two configurations, one for the front ends and one for the application servers. Each configuration would describe what a server in that role would look like, since I would expect all of my front end servers to have the same services and configuration applied, and again for the application servers. Then if I decide I need to scale out to accommodate more load and add a new front end server, I would just apply the same configuration to it based on its role.
Continuing with the above example of a small server farm, we have two configurations for each role. There is a need for a third configuration though, and this is referred to as a "farm" configuration. This configuration is planned to be applied to one server only (and typically this will be a back end application server, so its configuration will be very similar to the other application server). There are some differences though, the farm configuration will:
- Be responsible for creating the farm (with xSPCreateFarm, where as all other configurations will use xSPJoinFarm).
- Also be responsible for provisioning and configuring logical components in the farm
It is important to understand the difference between a logical component and a physical component in our configurations. For example, a SharePoint web application is a logical component in a SharePoint farm - you create it on one server, configure it from one server, but all the other servers in the farm know about it. The physical component for a web application is the IIS website, which exists on specific servers and can be configured per server (such as making changes to bindings). So I would use my "farm server" configuration to provision logical components like web applications and service applications, and my individual role configurations to validate the components that apply to a server specifically as opposed to something that exists logically within the farm.
The other factor here is around how the DSC is going to be run from every server - if I have a SharePoint web application that exists in a large server from (let's assume 10 servers), I don't need all 10 servers checking for it every 30 minutes. Even if it was just a handful of front end servers, it is still unnecessary for them all to be managing this when it does not map directly to a physical thing that has to happen on each server. This means that the farm server configuration will likely be much larger than any other role configuration, but it also provides more flexibility in the implementation as all logical components are in one spot on one server.
In the module is an examples directory which demonstrates both a single server deployment, as well as the three configurations needed for the above mentioned multi-server example (so one "farm" configuration, then an app server and a front end server). These examples demonstrate the concepts discussed here and can be used as as starting point for your own configurations.
