I have recently been working on node configuration for PowerShell Desired State Configuration (DSC) involving the requirement for creating an external virtual switch without a virtual network adapter in the management OS. Unfortunately, the DSC resource called xHyperV contains a bug preventing to create a Hyper-v virtual switch without a vNIC:
In one of my posts about PowerShell Desired State Configuration, I presented several methods for assigning and managing GUIDs to pull nodes. The PowerShell team replied in their blog explaining the security issues with pull servers. But finally a solution is available to secure access to #PSDSC node configuration.
If you are using Machine Creation Services (MCS) extensively, you strongly depend on the hosting infrastructure. But sometimes it becomes necessary to reorganize the structure inside the hosting infrastructure. In my case, a customer needed to rename clusters, datastores and virtual networks inside VMware vCenter. Unfortunately, machine catalogs cannot be reconfigured to accomodate for those changes. The only way to repair machine catalogs is to recreate them. That’s why I have created the following PowerShell cmdlets.
After describing how to inject a Desired State Configuration into virtual machines or virtual hard disks, I started wondering what I need to do to a newly created VM to configure it to use a pull server. Not only will I outline the steps necessary to achieve this, I will also publish the code for this.
When you are designing node configuration of increasing complexity, you will soon realize that some elements should be easily reusable to clean up your code and prevent duplicate code. Although Microsoft provides an introduction to reusing configurations, it does not properly document the poor state of nested configurations in PowerShell 4.0. In this post I will explain how those work and what caveats to expect from them.
In 2009, Ruben Spruijt ([@rspruijt]https://twitter.com/rspruijt)) and Jeroen van de Kamp ([@thejeroen(https://twitter.com/thejeroen)) started Project Virtual Reality Check (Project VRC). Since then, they have published numerous, valuable whitepapers with performance results and best practices with regard to different hypervisors, application virtualization solutions, Windows operating systems, antivirus solutions and Microsoft Office versions.
In the announcement of wave 9 of the resource kit for PowerShell Desired State Configuration, the PowerShell team states that improvements will be published to the individual resources instead of waiting for the next wave. This got me thinking whether I really wanted to check the growing number of DSC resource individually. That’s why I created a download script to fetch all of them from TechNet.
You are probably using a regular PowerShell script to compile your node configurations into MOF files. If you are using configuration data instead of parameters, you need to pull it into your script to pass it on to the node configuration. There are two very different approaches to this.
The Meta Configuration in PowerShell Desired State Configuration (DSC) contains the parameters for the Local Configuration Manager (LCM). Before a meta configuration can be injected into a virtual machine a small section must be removed from the MOF file. This post contains two functions automate this process
In large deployments using PowerShell Desired State Configuration (DSC) it is inevitable to implement a pull server because of the centralized configuration management. The nodes connecting to a pull server are identified by a globally unique identifier (GUID). Those GUIDs are - for a start - entirely independent from the hostname. I will present several approaches to managing the GUIDs used for DSC nodes.