My DSC works from PowerShell ISE but not from Release Management

If you are like me you learned Desired State Configuration (DSC) before trying to incorporate it with Release Management.  I recommend this because you get a pure understanding of DSC and its full capabilities. The only caveat to learning DSC this way is certain things are different when used with Release Management.  One of which came up today, which is the way we identify the nodes.  Using pure DSC you have many choices on how you identify the nodes to target.  You can use Configuration Data, hardcode the values or even parameterize your DSC script.  However, I have had the most success when I use $env:COMPUTERNAME.  You could also use 'localhost'. When you learn DSC outside of Release Management you use a developer workstation to create the MOFs and push them from there to the target nodes.  However, when Release Management runs a DSC script it is first copied to the target machine.  Then the script is executed to create the MOF file to be pushed to the node.  Because the script is being copied to the target the use of $env:COMPUTERNAME eliminates the need to hardcode any values in your script and reduces the chance for error.

Never forget -Verbose again

Working with DSC I am constantly having to type –Verbose on my Start-DscConfiguration calls.  However, I stumbled across this cool feature of PowerShell that I thought I would share that will set the –Verbose switch on all your calls for you. PowerShell has a collection of Preference Variables that allow you to customize its behavior.  One such variable is named $VerbosePreference. By default the value of $VerbosePreference is “SilentlyContinue” which requires you to supply the –Verbose switch to see any verbose messages written by the cmdlet or function calls.  However, if you simply set: $VerbosePreference = “Continue” You can now forego passing the –Verbose switch but all the verbose messages will be displayed.  This combined with the positional Path parameter can drastically reduce the amount of typing for Start-DscConfiguration call. Before: Start-DscConfiguration –Wait –Verbose –Path .\Test After: Start-DscConfiguration .\Test –Wait Or you can go that extra mile and create a new Alias for Start-DscConfiguration: New-Alias –Name sdsc –Value Start-DscConfiguration Then all you have to type is: sdsc .\test -Wait Like all variables, the values that you set are specific to the current Windows PowerShell session. However, you can add them to your Windows PowerShell profile and have them set in all Windows PowerShell sessions.

Track current location in PowerShell Title Bar

CLIs or Command-line interfaces are great tools but can become difficult to use when you are buried deep into the file system.  The prompt becomes so long that your commands begin to wrap onto additional lines making it hard to identify errors. However, with PowerShell you can move the current location into the title bar leaving your command prompt nice and neat. To do this simply create a PowerShell profile.ps1 file that contains the following line:    function Prompt{ $host.ui.rawui.windowtitle = "$pwd" } Place this file in the %UserProfile%\My Documents\WindowsPowerShell\ folder and the next time you start PowerShell your prompt will remain PS> regardless of the folder you navigate too. You can read more about PowerShell Profiles here. Below is a profile.ps1 file you can use. profile.ps1 (57.00 bytes)

Start-DscConfiguration access denied

Problem: When I try and execute Start-DscConfiguration I get the following error message: The WS-Management service cannot process the request. The WMI service returned an 'access denied' error. + CategoryInfo : PermissionDenied: (root/Microsoft/...gurationManager:String) [], CimException + FullyQualifiedErrorId : HRESULT 0x80338104 + PSComputerName : VSALM Solution: Make sure you are running ISE as Administrator