Last month I presented a session on how to Recreate MOF based DSC resources as Class based DSC resources at the PowerShell + DevOps Global Summit in Seattle, Washington. The session seemed to be well received by the audience based on the feedback that I received from the attendees. The video from this presentation is now available. The code and slides used during the demonstration can be found in my presentations repository on GitHub.

I’ve previously written a blog article titled Use a certificate with PowerShell DSC to add a server to Active Directory without hard coding a password where I had created a certificate that was used to encrypt the password in a PowerShell version 4 DSC (Desired State Configuration) MOF file. The same procedure in PowerShell v5 generates an error stating the certificate cannot be used for encryption: ConvertTo-MOFInstance : System.ArgumentException error processing property ‘Password’ OF TYPE ‘MSFT_Credential’: Certificate ‘6EBFB5C88AB4B8C9E3B8E30E88A5D071D6735464’ cannot be used for encryption.

Last week I wrote a blog article about a PowerShell Desired State Configuration Class Based Resource for Configuring Remote Desktop. Since then I’ve discovered and learned a couple of new things about enumerations in PowerShell that can be used to simply the code even further. My original code used a couple of enumerations which I’ve removed to show how they can be used to further simply the code: class RemoteDesktop { [DscProperty(Key)] [string]$UserAuthenication [DscProperty(Mandatory)] [string]$Ensure [RemoteDesktop]Get() { $this.

Prior to PowerShell version 5 being released, I had written a PowerShell version 4 compatible DSC (Desired State Configuration) resource named cMrRDP for configuring Remote Desktop. It can be found in my DSC respository on GitHub. The recommendation at that point was to use the letter “c” as the prefix for community created DSC resources. The current recommendation is to no longer use the “c” prefix for DSC resources. Steven Murawski wrote a blog article titled DSC People - Let’s Stop Using ‘c’ Now that I recommend taking a look at.

Last week, on Monday (April 4th, 2016), I presented a session at the PowerShell and DevOps Global Summit 2016 on “Creating a Custom PowerShell Toolkit to Demystify the Intricacies of Desired State Configuration”. The video from that presentation is now available: Here’s the abstract or synopsis for this presentation: “DSC (Desired State Configuration) can be very complicated when working in an environment where nodes are set to retrieve their configuration from a pull server.

I recently ran into a problem with DSC on Windows 10 when trying to create MOF files with DSC configurations that work on other operating systems. An error is generated when the friendly name for a DSC resource contains a dash and that friendly name is specified as a dependency for another resource. I know that only certain characters are allowed in the name that’s specified for DependsOn and I’ve run into similar problems with things such as IP addresses due to the dot or period, but the dash works in other operating systems at least with the production preview of PowerShell version 5, but not with the version of PowerShell version 5 that ships with Windows 10:

This past Friday, I presented a session titled Using PowerShell Desired State Configuration in your On-Premises Datacenter at Atlanta TechStravaganza 2015. Fellow PowerShell MVP Stephen Owen took this photo as I was preparing for my session: Another fellow PowerShell MVP, Jonathan Walz of the PowerScripting Podcast, recorded all of the sessions in the PowerShell track which can be found on their YouTube channel. Several presentations are included in each of the videos and mine is approximately the first 43 minutes of this video:

So you’ve either downloaded DSC resources from GitHub or you’ve created some DSC resources of your own and the LCM (Local Configuration Manager) on the servers in your environment is set to use an SMB based DSC pull server. To automatically deploy those custom resources with an SMB pull server, they need to be zipped up including their base directory and named ResourceName\_Version.zip. For example, the xSmbShare DSC resource that can be download from GitHub would be named xSmbShare\_1.

The machines used in this blog article are running Windows 8.1 and Windows Server 2012 R2. Both have the default version of PowerShell installed that shipped with those operating systems which is PowerShell version 4. The following configuration uses the xSmbShare and the PowerShellAccessControl DSC resources which can be downloaded from GitHub. These resources must exist on the machine where you’re authoring the DSC configuration and on the node that the configuration is being applied to.

You’ve configured one or more DSC (Desired State Configuration) SMB pull servers in your environment. You’ve also configured the target nodes appropriately. One problem that seems to be a constant problem in your environment when authoring and updating DSC configuration files (MOF files) is keeping track of what GUID belongs to which machine and it’s also a common problem to forget to update the corresponding checksum when a configuration file is updated.

If you’re a frequent reader of the blog articles on this site, then you know that I’ve been working on using Desired State Configuration to build my test lab environment that runs as Hyper-V VM’s on my Windows 8.1 computer. If you would like to know the current state of my test environment, see the previous blog article: Creating a Desired State Configuration Resource for Self Signed Certificates. The certificate created in last week’s blog has been exported and copied to the Windows 8.

For those of you who follow my blog, you know that I’ve been working on using DSC (Desired State Configuration) to fully automate the build of my test environment that runs as Hyper-V VM’s on my Windows 8.1 computer. Last week in my blog article titled Automate the installation of DSC Resource Kit Wave 9 resources with PowerShell Desired State Configuration, I demonstrated how to do just that, automate the installation of the Microsoft created DSC resources that are part of the most recent DSC resource kit (wave 9).

Last week, in my blog article titled Creating Hyper-V VM’s with Desired State Configuration I left off with a newly created Hyper-V VM named Test01 that was created with DSC and the specific IP address of that VM was added to my trusted host list. For more details on the current state of this test environment, see that previous blog article. Today I’ll begin configuring the Test01 VM with DSC. This virtual machine will become the first Active Directory domain controller in my test environment.

I’m looking to automate the build of my test environment that runs as Hyper-V virtual machines on my Windows 8.1 Laptop computer. To get started, I thought I would take a look at the xHyper-V DSC resource to create the actual VM’s. There’s also no reason this shouldn’t work on a Windows Server that’s running the Hyper-V role. The Hyper-V role has already been added to my Windows 8.1 computer. I also have a previously created virtual hard drive (vhdx) file that has been loaded with the Windows Server 2012 R2 operating system and all of the available Windows updates.

A new Windows Server 2012 R2 machine has been brought online and needs to be joined to your Active Directory domain. All machines used in this demonstration are running either Windows Server 2012 R2 or Windows 8.1 with PowerShell version 4. You’ve decided to use DSC (Desired State Configuration) to join this new server to the domain because it’s a prototype for many more servers to come. You plan to automate their deployment along with the majority of their configuration with DSC.

The scenario in this blog article is that you’ve created a DSC configuration on a computer that’s running a preview of PowerShell version 5. The machine itself could be running Windows 8.1, Server 2012 R2, or the Windows Technical Preview version of Windows 10. Here’s a simple configuration that I’ll use to demonstrate the problem. This DSC configuration uses a custom DSC resource to rename a computer. This configuration is being created on a machine running the Windows Technical Preview version of Windows 10 with PowerShell version 5 build 9860 (the most recent build as of this writing).

Recently while working on configuring a new server with DSC (Desired State Configuration), I discovered that there wasn’t a DSC resource for configuring the jumbo frames setting on network cards so I decided to write my own. This blog article steps you through the process of creating a custom DSC resource, specifically one that is used to configure the jumbo frames setting on network cards. The specific settings for jumbo frames can vary depending on your network card manufacturer and the specific driver.

I’m continuing on my series of blog articles on the new features in the preview version of PowerShell version 5. Today I’ll be discussing the existing DSC (Desired State Configuration) cmdlets in PowerShell version 4 that now have new parameters as of the May 2014 preview version of PowerShell version 5. To begin, I’ll define a DSC configuration that’s parameterized so that it’s reusable: configuration iSCSI { param ( [Parameter(Mandatory)] [string[]]$ComputerName ) node $ComputerName { WindowsFeature MultipathIO { Name = 'Multipath-IO' Ensure = 'Present' } Service iSCSIService { Name = 'MSiSCSI' StartupType = 'Automatic' State = 'Running' } } } Run the configuration specifying the computer names to create MOF files for:

A couple of months ago I wrote a blog about a PowerShell Function to Unzip Files Using the .NET Framework 4.5 with Fallback to COM. I’ve since discovered that the new Desired State Configuration (DSC) feature in PowerShell version 4 can unzip files. You probably wouldn’t use this feature just to unzip a single file to a single server, but it does open up some interesting possibilities. This blog article is not meant to be an all inclusive tutorial on DSC, it’s only meant to give you a peek inside the built-in DSC Archive Resource capabilities.