This chapter is from the book
This chapter is from the book
This chapter is from the book
DSC Authoring Environment
As you saw in Figure 18.2, DSCSERVER01 represents our DSC authoring environment. It is on this box, which must be equipped with at least Windows Management Framework v4 or later, that we construct our configuration script.
){kind=link}
The configuration script is a bread-and-butter Windows PowerShell file that contains the configuration instructions for one or several target systems. The configuration script is compiled into the vendor-neutral MOF and then transferred to the target systems for ingestion.
DSC Production Environment
A component of Windows Management Framework (WMF) 5 called the Local Configuration Manager (LCM) running on the target system is what receives the MOF and applies its configuration settings to the box.
DSC supports two modes for getting the MOF configuration file to the target computer. In the push model, we use the Start-DSCConfiguration cmdlet to initiate the MOF push.
In the pull model, the client computer polls an Internet Information Services (IIS) website running on your DSC deployment server and requests any MOF files that are specified for it.
In terms of query intervals, target nodes query the pull server every 30 minutes by default. In the push architecture, nodes reevaluate their MOF file settings every 15 minutes by default if the configuration file had autocorrection enabled. As with anything else in Windows PowerShell, you can edit those query defaults.
Finally, as you observed in Figure 18.2, something called “DSC resources” exist on both the authoring and production servers. We can consider DSC resources to be specialized Windows PowerShell modules that actually form the imperative “engine” that nodes use through their LCM to apply their desired state configurations.
Differences Between DSC and Group Policy
Some Windows systems administrators wonder, “What’s the difference between DSC and Group Policy?” One difference is that DSC permanently “tattoos” the configuration settings of target nodes. You’ll recall that once a Group Policy Object (GPO) no longer applies to a machine, those settings can revert to their pre-GPO values.
Another difference is that a single node can have only a single MOF file defining a particular configuration (installing and configuring IIS, for instance). By contrast, we can link multiple GPOs to each of the various Active Directory levels (site, domain, organizational unit, and local computer). Finally, GPOs grant management access principally to the computer’s registry, while DSC MOF resources can “touch” any computer subsystem that’s accessible by PowerShell and, by extension, the .NET Framework.
The bottom line is that DSC won’t necessarily replace GPOs for systems configuration. Remember the focus with DSC, at least at this point, is to declaratively configure our servers such that “configuration drift” and deviation from compliance is no longer an issue for us.
Before we can test out DSC, we need to first prepare our environment.