Modifying Windows images

The Deployment Image Servicing and Management (DISM) tool is a command-line tool that you can use to manage images in an offline state. You can use Dism.exe to perform the following tasks:

• Enable or disable roles and features

• List roles and features

• Add, remove, and list software updates

• Add, remove, and list software drivers

• Add, remove, and list software packages in .appx format to a Windows image

For example, you can take the Install.wim file from the Windows Server installation media and use Dism.exe to mount that image, add new drivers and recent software updates to that image, and save those changes to an image all without having to perform an actual deployment. The advantage is that when you do use this updated image for deployment, the drivers and updates that you added are already applied to the image and you won’t have to install them as part of your post-installation configuration routine.

You can use the Microsoft Update Catalog (https://catalog.update.microsoft.com) to search for drivers for images that you use with physically deployed servers. This site stores all the certified hardware drivers, software updates, and hotfixes published by Microsoft. Once you download drivers and software updates, you can add them to your existing installation images by using Dism.exe or the appropriate PowerShell cmdlets in the DISM PowerShell module.

Servicing Windows images

As an IT professional responsible for deploying Windows Server, you need to ensure that your deployment images are kept up to date. The latest software updates should be applied to the image, and any new device drivers for commonly used server hardware should be included.

The main goals of an image servicing strategy are the following:

• Ensure that the latest software updates and hotfixes are applied to the image before the image is deployed to new servers.

• Ensure that the latest drivers are applied to the image before the image is deployed to new servers.

If you don’t take these steps, you’ll have to wait until after you’ve deployed the operating system before you can apply updates and drivers. While Windows Server updates are cumulative now, and you won’t need to spend hours updating an image from RTM, it’s quicker to have the most recent update already applied to the image than it is to wait for the server to deploy, retrieve the latest update, and then wait for it to download and then install. Having updates apply after deployment has occurred consumes a significant amount of time and also substantively increases network traffic. One of your aims when performing a deployment should be to get the server operational and hosting workloads as quickly as possible.

You can use the DISM (Deployment Image Servicing and Management) utility or the associated PowerShell cmdlets in the DISM PowerShell module to service the current operating system in an online state or perform offline servicing of a Windows image.

Servicing images involves performing the following general steps:

1. Mount the image so that it can be modified.

2. Service the image.

3. Commit or discard the changes made to the image.

Mounting images

By mounting an image, you can make changes to that image. When you mount an image, you link it to a folder. You can use File Explorer, Windows PowerShell, or Cmd.exe to navigate the structure of this folder and interact with it as you would any other folder located on the file system. Once the image is mounted, you can also use Dism.exe or PowerShell to perform servicing tasks, such as adding and removing drivers and updates.

A single WIM file can contain multiple operating system images. Each operating system image is assigned an index number, which you need to know before you can mount the image. You can determine the index number using Dism.exe with the /Get-wiminfo switch. For example, if you have an image named Install.wim located in the C:Images folder, you can use the following command to get a list of the operating system images it contains.

click here to view code image

Dism.exe /get-wiminfo /wimfile:c:imagesinstall.wim

Figure 3-2 shows the result of this command and lists the images contained in Windows Server 2019. The Standard Evaluation Edition of Windows Server 2019 with the Server Core installation option is assigned index identity 1, the Standard Evaluation with Desktop Experience is assigned index identity 2, the Datacenter Evaluation with the Server Core installation option is assigned index identity 3, and the Datacenter Evaluation with Desktop Experience is assigned index identity 4.

You can accomplish the same task using the Get-WindowsImage PowerShell cmdlet. For example, to view the contents of the image Install.wim in the C:Images folder, run the following command, as shown in Figure 3-3.

click here to view code image

Get-WindowsImage -ImagePath c:imagesinstall.wim

Once you have determined which operating system image you want to service, you can use the /Mount-image switch with the Dism.exe command to mount that image. For example, to mount the Standard Edition of Windows Server 2019 from the Install.wim file that is available with the Evaluation Edition in the C:Mount folder, issue this command:

click here to view code image

Dism.exe /mount-image /imagefile:c:imagesinstall.wim /index:2 /mountdir:c:mount

Alternatively, you can accomplish the same goal using the following Mount-WindowsImage command:

click here to view code image

Mount-WindowsImage -ImagePath c:imagesinstall.wim -index 2 -path c:mount

Adding drivers and updates to images

Once you have mounted an image, you can start to service that image. When servicing images used to deploy Windows Server, the most common tasks are adding device drivers and software updates to the image. You can use the /Add-Driver switch with the Dism.exe command to add a driver to a mounted image. When using the switch by itself, you need to specify the location the driver’s .inf file. Rather than adding a driver at a time, you can use the /Recurse option to have all drivers located in a folder and its subfolders added to an image. For example, to add all of the drivers located in and under the C: Drivers folder to the image mounted in the C:Mount folder, use the following command.

click here to view code image

Dism.exe /image:c:mount /Add-Driver /driver:c:drivers /recurse

Similarly, you could use the Add-WindowsDriver cmdlet to accomplish the same objective by issuing the command:

click here to view code image

Add-WindowsDriver -Path c:mount -Driver c:drivers -Recurse

You can use the /Get-Driver option to list all drivers that have been added to the image and the /Remove-Driver option to remove a driver from an image. In PowerShell, you use the Get-WindowsDriver cmdlet and the Remove-WindowsDriver cmdlets. You can remove only the drivers that you or someone else has added to an image. You can’t remove any of the drivers that were present in the image when Microsoft published it. You might choose to remove an existing driver if the driver you added in the past has since been updated.

You can use Dism.exe with the /Add-Package switch to add packages that contain updates or packages in .cab or .msu format. Software updates are available from the Microsoft Update Catalog website in .msu format. For example, you can download an update from the Microsoft Update Catalog website named Cumulative Update For Windows Server 2019 for x64-based Systems (KB4505056) to the C:Updates folder on a computer, as shown in Figure 3-4.

If you mounted a WIM image of the Windows Server 2019 operating system in the C:Mount folder, you could apply the update to the image by using the command:

click here to view code image

Dism.exe /image:c:mount /Add-Package /PackagePath:"c:updateswindows10.0-kb4505056-x64_09c6216e684ce667fc0c07cc30e84ef21f04c6f1.msu"

You can accomplish the same thing with the following Add-WindowsPackage command:

click here to view code image

Add-WindowsPackage -path c:mount -packagepath "c:updatesAMD64-all-windows10.0-kb4505056-x64_09c6216e684ce667fc0c07cc30e84ef21f04c6f1.msu"

Adding roles and features

You can determine which features are available in a mounted operating system image by using the /Get-Features switch. Features include both Windows Server 2019 roles and features. For example, to learn which features are available in the image mounted in the C:Mount folder, use this command, as shown in Figure 3-5:

click here to view code image

Dism.exe /image:c:mount /Get-Features

You can enable or disable a specific feature using the /Enable-Feature switch. For example, to enable the NetFx3ServerFeatures feature, which enables the .NET Framework 3.5 server features in an image, use this command.

click here to view code image

Dism.exe /image:c:mount /Enable-Feature /all /FeatureName:NetFx3ServerFeatures

Some features in the Windows Server image are in a state in which they are listed as having their payload removed, which means that the installation files for that feature are not included in the image. If you install a feature that had its payload removed when the operating system was deployed, the operating system can download the files from the Microsoft update servers on the Internet. You can also specify the location of the installation files. The installation files for the features that have had their payload removed in Windows Server are located in the Sourcessxs folder of the volume in which the installation media is located.

You can add these payload-removed features to an image by using Dism.exe and specifying the source directory. For example, to modify an image mounted in the C:Mount folder so that the Microsoft .NET Framework 3.5 features are installed and available, issue this command when the installation media is located on volume D, as shown in Figure 3-6:

click here to view code image

Dism.exe /image:c:mount /Enable-Feature /all /FeatureName:NetFx3 /Source:d:sourcessxs

Committing an image

When you finish servicing an image, you can save your changes using the /Unmount-Wim switch with the /Commit option. You can discard changes using the /Discard option. For example, to make changes and then commit the image mounted in the C:Mount folder, use this command.

click here to view code image

Dism.exe /Unmount-Wim /MountDir:c:mount /commit

You can use the Save-WindowsImage PowerShell cmdlet to save changes to an image without dismounting the image. You use the Dismount-WimImage cmdlet with the Save parameter to save the modifications that you’ve made to an image and then dismount it. For example, to dismount and save the image mounted in the C:Mount folder, run the command:

click here to view code image

Dismount-WimImage -Path c:mount -Save

Once you have committed the changes, the .wim file that you originally mounted is updated with these modifications. You can then import this .wim file into WDS, use it to build a virtual hard disk, or use it with bootable USB installation media to deploy Windows Server 2019 with these updates and modifications already applied.

Build and capture

When you perform a build and capture, you deploy an operating system; provision that operating system with updates, applications, and drivers; and then capture that operating system for deployment. Build and capture is used less often with server operating systems because they rarely require the same sort of application deployment that is required for client operating systems. If you can just pull a container with an updated application down onto an operating system after deployment, there is little reason to include it in the image. Additionally, with tools such as Desired State Configuration, Chef, and Puppet, many post-installation and configuration tasks can be completely automated, reducing the hassle of post-installation configuration.

If your deployment strategy does involve the deployment and capture of Windows Server 2019, you need to remember that you’ll need to generalize the image prior to capture, removing any configuration information that is specific to the installation. You can perform this task using the Sysprep.exe utility. Sysprep.exe is included with Windows Server 2019 and is located in the C:WindowsSystem32Sysprep folder. When you use Sysprep.exe to prepare the image, you can configure the image to return to the system Out-of-Box Experience (OOBE), as shown in Figure 3-7. This is the same experience you get when Windows Server boots for the first time, though in this case all the updates, applications, and drivers included in the captured image are included in the newly deployed image.

You can use Dism.exe with the /Capture-Image switch or the New-WindowsImage PowerShell cmdlet to capture an image.

WDS requirements

WDS clients need a PXE-compliant network adapter, which is rarely a problem because almost all modern network adapters are PXE-compliant. You can also use WDS to deploy Windows Server 2012 and later to virtual machines running under Hyper-V. The trick to doing this is to use a legacy rather than a synthetic network adapter when creating the virtual machine as a Generation 1 virtual machine. This isn't necessary when using Generation 2 virtual machines because the Generation 2 virtual machine network adapters support PXE booting.

If you have a computer that does not have a PXE-compliant network adapter, you can configure a special type of boot image known as a discover image. A discover image boots an environment, loading special drivers to enable the network adapter to interact with the WDS server. You create the boot image by adding the appropriate network adapter drivers associated with the computer that can’t PXE boot to the Boot.wim file from the Windows Server installation media.

WDS has the following requirements:

• A Windows Server DNS server must be present on the local area network (LAN).

• Prior to Windows Server 1810, an authorized Dynamic Host Configuration Protocol (DHCP) server must be present on the network. You can host WDS and DHCP on the same computer as long as you configure the options shown in Figure 3-10. Versions of Windows Server after 1810—including Windows Server 2019—can be used with third-party DHCP servers. Because this limits your ability to use IP address tracking through IPAM, using a third-party DHCP server if you are using WDS is not a recommended strategy.

  

If you install WDS from the Add Roles And Features Wizard, you can configure these settings automatically. Although the WDS server does not require a static IP address, it is good practice to ensure that infrastructure roles such as WDS always use a consistent network address. You can install WDS on computers running the Server Core version of Windows Server.

When installing WDS on Server Core, you have to specify the location of the source files or ensure that the server has a connection to the Internet, which enables them to be downloaded automatically. Although it is possible to manage WDS from Windows PowerShell, most administrators use the graphicsal WDS Remote Server Administration Tools (RSAT) from a computer running Windows 10, Windows Server 2016, or Windows Server 2019 with Desktop Experience.

Managing images

Images contain either entire operating systems or a version of a special stripped-down operating system known as Windows PE. Windows PE functions as a type of boot disk, enabling a basic environment to be loaded from which more complex maintenance and installation tasks can be performed. WDS uses four image types: boot image, install image, discover image, and capture image.

• Boot Image. A special image that enables the computer to boot and begin installing the operating system using the install image. A default boot image, named Boot.wim, is located in the sources folder of the Windows Server installation media.

• Install Image. The main type of image discussed in this chapter. Contains the operating system as well as any other included components, such as software updates and additional applications. A default install image, named Install.wim, is present in the sources folder of the Windows Server installation media. Install images can be in .vhd or .vhdx format, though you can only manage install images using the WDS console in Windows Server 2012 R2, Windows Server 2016, or Windows Server 2019.

• Discover Image. This special image is for computers that cannot PXE boot to load appropriate network drivers to begin a session with a WDS server.

• Capture Image. A special image type that enables a prepared computer to be booted so that its operating system state can be captured as an install image. You add capture images as boot images in WDS.

To import an image into WDS, perform the following steps:

1. Open the Windows Deployment Services console.

2. Click Install Images. From the Action menu, click Add Install Image.

3. Choose whether to create a new image group or to use an existing image group.

4. Specify the location of the image file.

5. In the Available Images page of the Add Image Wizard, select the operating system images that you want to add. When the image or images are added, click Next, Finish.

Configuring WDS

The installation defaults for WDS are suitable when you deploy the role in small environments. If you are deploying WDS in larger environments and do not choose to implement System Center Virtual Machine Manager for server operating system deployments, you might want to configure the options discussed in the following sections, which are available by editing the properties of the WDS server in the Windows Deployment Services console.

PXE response settings

With PXE response settings, you can configure how the WDS server responds to computers. As Figure 3-11 shows, you can configure WDS not to respond to any client computers (this effectively disables WDS), to respond to known client computers, or to respond to all computers but require an administrator to manually approve an unknown computer. Known computers are those that have prestaged accounts in Active Directory. You can prestage computers if you know the MAC address of the network interface card (NIC) that the computer uses. Vendors often supply a list of MAC addresses associated with computers when you purchase those computers, and you can use this list to prestage computer accounts.

You use the PXE Response Delay setting when you have more than one WDS server in an environment. You can use this setting to ensure that clients receive transmissions from one WDS server over another, with the server configured with the lowest PXE response delay having priority over other WDS servers with higher delay settings.

Client Naming Policy

The Client Naming Policy enables you to configure how computers installed from WDS are named if you aren’t using deployment options that perform the action. You can also use the settings on the AD DS tab, shown in Figure 3-12, to configure domain membership and organizational unit (OU) options for the computer account.

WDS boot options

In the Boot options tab of the WDS server’s Properties dialog box, shown in Figure 3-13, you can configure how clients that PXE boot interact with the WDS server. You can also configure a default boot image for each architecture supported by WDS. By default, once a client has connected to a WDS server, someone must press the F12 key to continue deploying the operating system. In environments in which you are performing a large number of simultaneous deployments, requiring this level of manual intervention might substantially delay the deployment.

Multicast options

The default settings of WDS have all computers that join the multicast transmission receiving the installation image at the same speed. If you frequently deploy operating systems, you are aware that sometimes there are one or two computers that have network adapters that slow transmission; transmissions that should take only 15 minutes now take half a day. You can configure the transfer settings on the Multicast tab, shown in Figure 3-14, so that clients are partitioned into separate sessions depending on how fast they can consume the multicast transmission. You still have those slow computers taking a long time to receive the image, but the other computers connected to the transmission can complete the deployment quicker.

Configuring transmissions

You use WDS transmissions to set WDS to transfer the operating system image to PXE clients. When configuring a WDS transmission, you need to decide what type of multicast transmission you are going to perform in the Multicast Type page of the Create Multicast Transmission Wizard, as shown in Figure 3-15.

The difference between these options is as follows:

• Auto-Cast. A transmission starts when a client requests the image. If another client requests the same image, the client joins the existing transmission, caching data from the current transfer and then retrieving data that was transmitted before the client joined the transmission. This is the best option to use when you are performing one-off deployments.

• Scheduled-Cast. You choose either to start the transmission when a specified number of clients have joined, or you start the transmission at a particular date and time. Scheduled-Cast is the best option to use when you are deploying the same operating system image to a large number of computers.

To configure a WDS transmission, perform the following steps:

1. Open the Windows Deployment Services console, expand the WDS server from which you want to perform the deployment, and click Multicast Transmissions. In the Action menu, click Create Multicast Transmission.

2. Provide a name for the multicast transmission.

3. On the Image Selection page, specify which operating system image you want to deploy using the transmission.

4. On the Multicast Type page, specify whether you use Auto-Cast or Scheduled-Cast. If you choose Scheduled-Cast, select the number of clients or the transmission start time.

Driver groups and packages

You can stage device drivers on a WDS server by importing the device driver as a package. A driver package contains the extracted driver files. You can import the driver package into WDS by locating the driver's .inf file. When using the WDS console, you can either import individual driver packages or all the drivers in a set of folders.

In the WDS console, you can organize drivers into driver groups. A driver package can be a member of more than one group, and deleting a driver group does not delete the associated driver packages. You can use driver groups with filters to limit which driver packages are available to WDS clients.

Virtual machine templates

A Virtual Machine Manager VM template allows you to rapidly deploy virtual machines with a consistent set of settings. A VMM VM template is an XML object that is stored with a VMM library, and it includes one or more of the following components:

• Guest Operating System Profile. A guest operating system profile that includes operating system settings.

• Hardware Profile. A hardware profile that includes VM hardware settings.

• Virtual Hard Disk. This can be a blank hard disk or a virtual hard disk that hosts a specially prepared—sysprepped, in the case of Windows-based operating systems— version of an operating system.

You can create VM templates based on existing virtual machines deployed on a virtualization host managed by VMM, based on virtual hard disks stored in a VMM library, or by using an existing VM template.

VM templates have the following limitations:

• A VM template allows you to customize IP address settings, but you can only configure a static IP address for a specific VM from a pool when deploying that VM from the template.

• Application and SQL Server deployment are only used when you deploy a VM as part of a service.

• When creating a template from an existing VM, ensure that the VM is a member of a workgroup and is not joined to a domain.

• You should create a separate local administrator account on a VM before using it as the basis of a template. Using the built-in administrator account causes the sysprep operation to fail.

VMM storage

VMM can use local and remote storage, with local storage being storage devices that are directly attached to the server and remote storage being storage available through a storage area network. VMM can use:

• File storage. VMM can use file shares that support the SMB 3.0 protocol. This protocol is supported by file shares on computers running Windows Server 2012 and later. SMB 3.0 is also supported by third-party vendors of network-attached storage (NAS) devices.

• Block storage. VMM can use block-level storage devices that host LUNs (Logical Unit Numbers) for storage using either the iSCSI, Serial Attached SCSI (SAS), or Fibre Channel protocols.

VMM supports automatically discovering local and remote storage. This includes automatic discovery of:

• Storage arrays

• Storage pools

• Storage volumes

• LUNs

• Disks

• Virtual disks

Using VMM, you can create new storage from storage capacity discovered by VMM and assign that storage to a Hyper-V virtualization host or host cluster. You can use VMM to provision storage to Hyper-V virtualization hosts or host clusters using the following methods:

• From available capacity. Allows you to create storage volumes or LUNs from an existing storage pool.

• From writable snapshot of a virtual disk. VMM supports creating storage from writable snapshots of existing virtual disks.

• From a clone of a virtual disk. You can provision storage by creating a copy of a virtual disk. This uses storage space less efficiently than creating storage from snapshots.

• From SMB 3.0 file shares. You can provision storage from SMB 3.0 file shares.

VMM supports the creation of a thin provisioned logical unit on a storage pool. This allows you to allocate a greater amount of capacity than is currently available in the pool, and it is only possible when:

• The storage array supports thin provisioning

• The storage administrator has enabled thin provisioning for the storage pool

VMM 2019 supports balancing of virtual disks across cluster-shared volumes to ensure that no single cluster shared volume is over-committed.

VMM networking

A VMM logical network is a collection of network sites, VLAN information, and IP subnet information. A VMM deployment needs to have at least one logical network before you can use it to deploy VMs or services. When you add a Hyper-V based virtualization host to VMM, one of the following happens:

• If the physical adapter is associated with an existing logical network, it remains associated with that network once added to VMM.

• If the physical adapter is not already associated with a logical network, VMM creates a new logical network, associating it with the physical adapter’s DNS suffix.

You can create logical networks with the following properties:

• One Connected Network. Choose this option when network sites that compose this network can route traffic to each other, and you can use this logical network as a single connected network. You have the additional option of allowing VM networks created on this logical network to use network virtualization.

• VLAN-Based Independent Networks. The sites in this logical network are independent networks. The network sites that compose this network can route traffic to each other, though this is not required.

• Private VLAN (PVLAN) Networks. Choose this option when you want network sites within the logical network to be isolated independent networks.

You create network sites after you have created a VMM logical network. You use network sites to associate IP subnets, VLANs, and PVLANs with a VMM logical network.

Adding a WDS to VMM

In a scalable environment, you'll need to add additional Hyper-V host servers on a frequent basis as either a standalone server or as part of a failover cluster to increase your capacity. While it's possible to use another technology to deploy new Hyper-V host servers to bare metal, the advantage of integrating virtualization host deployment with VMM is that you can fully automate the process. The process works in the following general manner:

1. Discovery of the chassis occurs. This may be through providing the chassis network adapter’s MAC address to VMM.

2. The chassis performs a PXE boot and locates the Windows Deployment Services (WDS) server that you have integrated with VMM as a managed server role. When you integrate WDS with VMM, the WDS server hosts a VMM provider that handles PXE traffic from the bare metal chassis started using the VMM provisioning tool.

3. The VMM provider on the WDS server queries the VMM server to verify that the bare metal chassis is an authorized target for managed virtualization host deployment. In the event that the bare metal chassis isn't authorized, WDS attempts to deploy another operating system to the chassis. If that isn't possible, PXE deployment fails.

4. If the bare metal chassis is authorized, a special Windows PE (Preinstallation Environment) image is transmitted to the bare metal chassis. This special Windows PE image includes a VMM agent that manages the operating system deployment.

5. Depending on how you configure it, the VMM agent in the Windows PE image can run scripts to update firmware on the bare metal chassis, configure RAID volumes, and prepare local storage.

6. A specially prepared virtual hard disk (in either .vhdx or .vhd format) containing the virtualization host operating system is copied to the bare metal chassis from a VMM library server.

7. The VMM agent in the Windows PE image configures the bare metal chassis to boot from the newly placed virtual hard disk.

8. The bare metal chassis boots into the virtual hard disk. If necessary, the newly deployed operating system can obtain additional drivers not included in the virtual hard disk from a VMM library server.

9. Post-deployment customization of the newly deployed operating system occurs. This includes setting a name for the new host and joining an Active Directory Domain Services domain.

10. The Hyper-V server role is deployed, and the newly deployed virtualization host is connected to VMM and placed in a host group.

The PXE server needs to provide the PXE service through Windows Deployment Services. When you add the VMM agent to an existing Windows Deployment Services server, VMM only manages the deployment process if the computer making the request is designated as a new virtualization host by VMM.

To integrate the WDS server with VMM to function as the VMM PXE server, you need to use an account on the VMM server that is a member of the local Administrators group on the WDS server. PXE servers need to be on the same subnet as the bare metal chassis to which they deploy the virtualization host operating system.

VMM host groups

Host groups allow you to simplify the management of virtualization hosts by allowing you to apply the same settings across multiple hosts. VMM includes the All Hosts group by default. You can create additional host groups as required in a hierarchical structure. Child host groups inherit settings from the parent host group. However, if you move a child host group to a new host group, the child host group retains its original settings, except for any PRO configuration. When you configure changes to a parent host group, VMM provides a dialog box asking if you would like to apply the changed settings to child host groups.

You can assign network and storage to host groups. Host group networks are the networks that are assigned to the host group. These resources include IP address pools, load balances, logical networks, and MAC address pools. Host group storage allows you to allocate logical units or storage pools that are accessible to the VMM server for a specific host group.

DSC configuration files

DSC configuration files describe how a computer should be configured. Configuration files require at least one node and require at least one configuration item per node. A configuration file can have multiple nodes, with different configuration items in each node. Generally, you create one configuration for each different computer type in your organization. For example, you create one for computers that host the DHCP server role, and you create another for computers that function as file servers.

The following hypothetical configuration would ensure that the WINS and Windows Server Backup features were present on a computer.

click here to view code image

Configuration TestDscConfiguration {
Node “TEST-SVR” {
WindowsFeature InstallWINS {
Ensure = "Present"
Name = "WINS"
}
WindowsFeature InstallBackup {
Ensure = "Present"
Name = "Windows-Server-Backup"
}
}
}
TestDscConfiguration

When you run a DSC configuration script, it generates an MOF file. The MOF file is what the LCM (Local Configuration Manager) uses when determining which configuration to apply to a computer. You compile a configuration script by dot-sourcing it. For example, if you saved the above script as TestConfiguration.ps1 in the c:DSCTEST folder and .sourced it, the script would create a new folder named TestDscConfiguration; a new file named TEST-SVR.mof would be created in the same folder.

MOF files contain the configuration data that you want to apply to the Windows Server node. The MOF files are created by running DSC configuration files. You can deploy MOF files to the LCM on a Windows Server node by using the Push method to inject a file into a running computer, or you can configure a pull server from which nodes can retrieve MOF files and DSC resources.

Local Configuration Manager

The Local Configuration Manager (LCM) is present on each computer that uses DSC. The LCM is the component that takes a MOF file and DSC resources and uses them to enact a DSC configuration. You can view the current settings of the LCM using the Get-DscLocalConfigurationManager cmdlet, as shown in Figure 3-16.

DSC resources

DSC resources are used by the LCM. They can be PowerShell scripts or an item compiled into a DLL. Resources are stored in resource modules, which are distributed to the LCM to allow it to carry out the configuration instructions stored in the MOF. DSC resource modules must be present on any computer where they are used to create or apply a configuration script.

The PowerShell Gallery hosts a wealth of DSC resources that can form the basis of your DSC configuration scripts and configurations. DSC clients can obtain resources directly from DSC pull servers. If you are using another method of deploying configurations—such as the push method or copying method—you’ll need to ensure that the appropriate DSC resources are stored on the computer on which you want to configure using DSC.

DSC push model

You can push a MOF file to a target computer using the Start-DscConfiguration cmdlet and a PowerShell remoting connection. This is effective in smaller and test environments and can be used to push MOF files to target computers. For example, you might use this to push a MOF file to a test virtual machine running under client Hyper-V on your Windows 10 computer. The DSC push model requires that PowerShell remoting be enabled on each computer that is to be the target of a DSC push action. This is less of an issue with Windows Server 2019 because PowerShell remoting is enabled by default on this operating system.

Each time you use Start-DscConfiguration to push a new configuration to a node, the push action overwrites any existing configuration on the target node. Once you push the new configuration, the LCM on the target node begins immediately processing the MOF file. This makes the DSC push model a great way of testing configurations because you don’t have to wait for the DSC cycle to restart to process the update, something that is necessary when using DSC pull servers.

A substantial drawback to using DSC push is that any resources that are to be used by the MOF file must already be present on the node you are configuring through push. Should you wish to use new resources for a configuration, you’ll need to transfer them to the target node prior to pushing the new configuration.

DSC pull server

DSC pull servers are computers running Windows Server 2012 or later that function as central DSC repositories. Rather than push DSC configurations to each node, each node can be configured to poll a DSC pull server, downloading new MOF files and resources as they become available. DSC pull servers are almost always configured as web servers. It’s possible to use a standard file server as a pull server, but file servers lack some of the functionality of IIS-based pull servers, such as the ability to function as compliance servers. Compliance servers allow you to view a central repository of information about each node’s compliance with DSC configuration settings.

When you deploy a pull server, you specify a location to store MOF files and a location to store DSC resource files in zipped format. MOF files stored on a pull server use a Globally Unique Identifier (GUID) for identification. Each MOF file and DSC resource module zip file must be stored with an associated checksum file. You can generate checksum files using the New-DSCChecksum cmdlet.

Chef servers

Chef uses a client/server architecture. You manage the configurations that you want to deploy on a server as cookbooks, and the clients of those servers apply those cookbooks and recipes to Chef nodes to meet your configuration objectives. When deploying Chef, you have two primary options that you are responsible for managing: Hosted Chef and a Chef Server.

Chef Development Kit

You use the Chef Development Kit (ChefDK) to author recipes, cookbooks, and policies. You can install the Chef Development Kit by downloading the relevant files from Chef’s website; also, if you have Chocolatey configured, you can install the Chef Development Kit, as described later in this chapter, by running the following command from an elevated command prompt:

Choco install -y chefdk

Performing this installation gives you access to the ChefDK PowerShell prompt, which allows you to use PowerShell to interact with ChefDK.

Starter Kit

The Starter Kit is a package that you can download from your Chef server that contains all the information and files needed to connect to an organization hosted on your Chef server. You can find this package by clicking Starter Kit in the sidebar menu when you have the organization selected in the Administration tab, as shown in Figure 3-19.

The Starter Kit is a zipped file that has the basic structure of a Git repository. You can add this file structure to a Git repository if you want to implement source control. The file knife.rb, shown opened in Visual Studio Code in Figure 3-20, contains the settings of the organization on the Chef Server.

To use ChefDK with the Chef Server, you need to have the TLS certificates assigned to the server present on the workstation on which you have ChefDK installed. Even if your computer trusts the TLS certificate, you’ll still need a local copy of the public certificate to use the Knife utility in the ChefDK to interact with your organization’s Chef server. You can retrieve the TLS certificate that is assigned to the Chef server by running the following command in the chef-repo folder from the Chef Development Kit shell that becomes available when you install the ChefDK. The certificate is added to the trusted certificates area of the Chef Git repository folder structure that was created when you unzipped the Starter Kit, as shown in Figure 3-21.

You can verify that the certificate has installed correctly by running the following command from the chef-repo folder using the ChefDK PowerShell prompt:

Knife SSL check

Knife cookbook site download windows
Knife cookbook site download ohai

Deploying Chef agents

Deploying the Chef agent to a computer makes that computer a node in the Chef organization. The most reliable method of ensuring that a Chef node has all the relevant certificates and configuration settings required to communicate with a Chef Server is to perform a knife bootstrap deployment from a computer with ChefDK installed.

Prior to performing this deployment, you should update your tools to ensure that you have the latest versions of the deployment tools available. To do this, run the following command from the ChefDK prompt in the Chef-repo folder:

Gem update knife-windows

To deploy an agent to a Windows Server, you need to ensure that WinRM is configured on both the source and the target computer, and run the following command (where prodserver is the name of the target computer):

click here to view code image

Knife bootstrap windows winrm prodserver.company.pri --winrm-user Administrator --winrm-password P@ssw0rd --node-name prodserver

You can verify that the client is installed on a node and registered with the Chef server by checking the Nodes tab in the management console.

Deploying Chef cookbooks and recipes

By applying a role to a node, you deploy the contents of that role, including cookbooks and their associated recipes. You can apply a role or recipe directly to a Chef node using the console by selecting the node in the console, editing the node’s Run List, and then assigning a Recipe or a Run List, as shown in Figure 3-27.

The Run List will apply the next time the run applies. You can also manually trigger a run on the client by executing chef-client.bat from the C:WindowsSystem32 folder of an administrative command prompt. You can verify that the run has completed correctly by checking the Reports tab on the Chef console.

Puppet Master Server

The Puppet Master Server is only currently supported on hosts running a Linux- or UNIX-based operating system. If you are responsible for an environment that only has Windows servers, Puppet may not be a good fit because the Puppet Master Server can only be deployed on computers running the following operating systems:

• RedHat Enterprise Linux, CentOS, Scientific Linux, and Oracle Linux Version 7 and 6 (x86_64)

• Ubuntu version 16.04 (amd64)

• SLES 12 SP1 (x86_64)

The Puppet Master Server stores configuration for all Puppet clients on the network. The Puppet Master Server requires at least 6 GB of RAM, four cores, a hostname that is accessible to other computers on the network, and accessibility on port 3000. You’ll likely need to manually configure the firewall to be open on the appropriate port. The administrator of the Puppet Master Server must have root user or have Sudo privileges on the host server.

To install the Linux computer as a Puppet Server, first connect to the server with an account that has the ability to elevate privileges and verify the computer’s hostname. Then perform the following steps:

1. You’ll need to download a tarball that is specific to your Linux distribution from the Puppet website to the Linux computer. Extract the tarball downloaded from the Puppet website using the following command:

   Tar -xvf puppet-enterprise*

2. This extracts the Puppet installation files. Change to the directory that was created when you extracted the tarball, and start the installation script by typing the following command:

   click here to view code image

   Sudo ./puppet-enterprise-installer

3. When prompted, select the guided installation. Once the installation is complete, you’ll need to open a browser and navigate to port 3000 on the address of the newly deployed Puppet Server. You’ll need to ignore any certificate errors and click Let's Get Started, as shown in Figure 3-28.

   

4. On the Puppet Master Component page, provide:

   • The FQDN of the Puppet Master Server

   • Any aliases that will be used by Puppet clients

   • Choose whether to install a PostgreSQL instance for the PuppetDB, and provide a console admin user password, as shown in Figure 3-29.

   

5. After the validation occurs, click Deploy Now. Puppet Server is deployed on the Linux server.

You can now connect to the web-based administration interface using the username admin and the password provided in step 4. The Inventory node lists all computers that are currently being managed by the Puppet server.

Deploying Puppet agent to Windows Server

The first step in deploying a Puppet agent to a computer running Windows Server 2019 is to configure the Puppet Master Server so that it has the correct agent installation software for an x64 version of Windows. You can do this by taking the following steps:

1. In the Puppet administration console, click Classification under the Nodes menu, and in the PE Infrastructure section shown, click PE Master.

2. On the Classes tab, in the Add New Class text box, type Windows, and then click pe_repo::platform::windows_x86_x64, as shown in Figure 3-30. Click Add Class, and then click Commit Changes. Unless you run the Puppet agent -t command on the Puppet Master Server, you’ll need to wait up to 30 minutes for the Puppet agent to wake up.

   

3. On your Windows Server, open a browser and navigate to https://<YOUR PUPPET MASTER HOSTNAME>:8140/packages/current/windows-x86_64/puppet-agent-x64.msi.

4. Run the downloaded installer. On the Welcome page, click Next, and then accept the terms of the License Agreement.

5. On the Configuration page, ensure that the FQDN of the Puppet Server matches the address of your Puppet Server, as shown in Figure 3-31, and click Install. Click Finish when the installation completes.

   

6. Restart the computer, start an administrative PowerShell session, and run the following command, which initiates communication with the Puppet Master Server, allowing you to then trigger:

   puppet agent -t

7. You’ll then need to return to the Puppet console, navigate to the Unsigned Certificates tab under Nodes, and then sign the unsigned node of the newly detected certificate of your new Windows Server Puppet client, as shown in Figure 3-32.

   

Managing Windows Server configuration

Puppet manifest files describe a desired state of a managed server in terms of a list of resources and a set of attributes. You can use any text editor to write a manifest, though you might want to use a tool like Visual Studio Code because it supports syntax highlighting for Puppet syntax. Puppet manifests use the .pp extension.

You can use the Puppet Master web-based console to specify which manifests apply to particular Puppet clients, also termed nodes. Once Puppet is installed on a client, you can run Puppet commands from an elevated PowerShell session. Generally, you’ll build and test manifests on a development node using the command line tools. Then you can configure the manifests to be distributed and enforced by the Puppet Master Server.

You can perform the following tasks from an elevated PowerShell prompt on a computer that has the Puppet agent installed:

• You can validate the syntax on a manifest using the Puppet parser validate command. For example, run the following command to check the syntax of a manifest file named services.pp:

  click here to view code image

  Puppet parser validate c:	est_manifestsservices.pp

• Manifests are applied using the Puppet apply command. You can simulate a Puppet cycle using the --noop option, which runs Puppet in non-enforcement mode. For example, to simulate a Puppet cycle against the services.pp manifest, run the command:

  click here to view code image

  Puppet apply c:	est_manifestsservices.pp --noop

• Once you’ve checked a manifest in non-enforcement mode, you can enforce the configuration using Puppet Apply.

• Puppet agent allows you to retrieve compiled catalogs from a Puppet Master. By default, this cycle runs every 30 minutes.

Puppet Windows Module Pack

Puppet Forge is an online community for modules that are submitted by people in the Puppet community, as well as people who work for the organization. Because an extensive community exists around Puppet, it’s likely that someone has already written a module to perform a configuration task that you want to perform. You can take their hard work and use it to help configure the systems in your organization.

The Windows module pack is a collection of Puppet modules that you can use to perform common administrative tasks. To install the Windows Module Pack, open an administrative PowerShell prompt on a computer with the Puppet Agent installed, and run the following command:

click here to view code image

Puppet module install puppetlabs/windows

The Puppet Windows Module pack includes tools that allow you to use Puppet to manage the following:

• Read, create, and write registry keys with the registry module.

• Remotely manage the execution of PowerShell scripts with the powershell module.

• Manage PowerShell DNS resources using the dsc module.

• Configure fine-grained access control permissions using the acl module.

• Manage WSUS client configuration using the wsus_client module.

• Configure which roles and features are installed using the windowsfeature module.

• Download files from various locations using the download_file module.

• Build and manage IIS sites and virtual applications using the iis module.

• Manage the deployment of software packages using the chocolatey module.

• Configure environment variables using the windows_env module.

While not comprehensive, you should now have a foundation-level understanding of the functionality of what you can do with Puppet, and whether it is worthy of further investigation in terms of inclusion as a part of your Windows Server administration toolkit.

PowerShell Gallery

PowerShell Gallery is a provider that functions as a clearinghouse for PowerShell-related tools and content. The PowerShell team publishes content to the gallery, as do other PowerShell enthusiasts and MVPs. This means that it’s fairly likely that if there is a script, cmdlet, or a module that does something you think quite a few people would need to do, someone has probably already created it and published it to the PowerShell gallery. You can interact with PowerShell Gallery with the PowerShellGet module. You can use this module to access cmdlets that do the following:

• Use Find-Module and Find-Script to find items in the gallery.

• Use Save-Module and Save-Script to save items from the gallery.

• Use Install-Module and Install-Script to install items from the gallery.

• Use Publish-Module and Publish-Script to publish items to the gallery.

• Add a custom repository to the gallery using Register-PSRepository.

Chocolatey

Chocolatey is perhaps the most well-known package provider available for Windows operating systems. It has a very extensive collection of software packages, with anything from commonly used applications such as 7-Zip and Visual Studio Code, to administration platforms such as Windows ADK. Chocolatey can also be integrated with Puppet, Chef, and DSC.

Chocolatey also runs very well on the Server Core installation option of Windows Server 2019, as well as within Windows Server and Hyper-V containers. It can be substantially quicker to use Chocolatey to retrieve and install a package; for example, it is quicker to use Chocolatey to install the Windows ADK with all options in the default location on a computer running the Server with Desktop Experience option. To do so, run the following command:

click here to view code image

Choco install -y windows-adk-all

This requires substantially less time than searching the Microsoft website, downloading all the necessary prerequisites, and running the installation routine.

To install Chocolatey, you’ll need to set the PowerShell execution policy to unrestricted using the following command:

click here to view code image

Set-ExecutionPolicy Unrestricted

Then you’ll need to run the following PowerShell command:

click here to view code image

iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex

This installs Chocolatey and all its dependencies on the local computer.

Chocolatey has the following advantages when it comes to software deployment on servers:

• Makes the deployment of software extremely simple. Once Chocolatey is installed, further packages can be installed with one line of code.

• Packages are downloaded and installed with one command. You don’t need to download a file, unzip it, run the installer, and answer the questions of an inquisitive wizard.

• Package dependencies are automatically installed when you attempt to install a package.

• Maintainers often regularly update packages. This means that you can update all software installed via Chocolatey on a system by running the following command:

  Chocolatey update all

Chocolatey has the following disadvantages:

• Usually requires that the computer you are deploying software on be connected to the Internet. You can configure internal repositories, but you’ll have to manage and maintain them yourself, including validating the quality of the software found in those repositories.

• Packages are usually installed in default locations with default settings. You don’t get the installation customization options that you get when you install software manually.

• The provenance of the software isn’t clear. While it’s reasonable to assume that the software is safe, even large vendor app stores have apps that are infected with malware.

Using a simple script, you can install Chocolatey and then use it to download and install a common set of packages. You can also set up your own Chocolatey repository of packages that hosts only packages that you trust. You can then point a local Chocolatey instance at that repository and use it to quickly install software on newly deployed computers running a Windows operating system.