Skip to main content


Getting Started With PSEncryptedData

When I was trying to figure out how my team or other dev teams could start using DSC I had a couple goals I wanted to try to achieve:

Highly privileged credentials will be required and must be securedSource control will be used to track changes and to automate buildsProvide both the admins and dev teams a way to bring their configurations together
These goals gave rise to a number of possible options, from simple to complex. If you have used DSC beyond a sample configuration then you know that eventually you need to use PSCredential in your configuration and that you can specify in your configuration how you want those PSCredential values encrypted at rest in the MOF file.

But how do you get those PSCredential objects into your configuration file if there is no human to provide input to Get-Credential? Sure you can use ConvertTo-SecureString -String 'secret' -AsPlainText -Force and if you can guarantee where you store the configuration script is secure then that may be fine.

Recent posts In 2016 And Beyond

I have been neglecting this blog for nearly three years. PowerShell has changed a lot in three years from workflow to desired state configuration and classes. PowerShell is well on its way to becoming the must know language for the Microsoft automation platform. Even that may change as Microsoft continues to push into providing their frameworks and tools for non-Microsoft platforms PowerShell will be usable everywhere. But if you are still following this blog, you probably already know that so I digress...

Even though I haven't shared on this blog what I have been doing with PowerShell, I am still using it almost daily. Even as my job changed from a sysadmin/engineer to a solutions architect I still find myself using PowerShell to either analyze data or implement a proof-of-concept idea. I still evangelize to anyone that will listen the importance of automation and the capabilities PowerShell brings in this DevOps culture.

I will start sharing snippets of some of the work I have …

PowerShell 3.0 Workflow Secret Sauce

I was poking around in workflows and stumbled across this when I looked at a workflows definition and saw a large PowerShell scriptblock. I'm sure some of you will find this as interesting as I did. Actually, this explains a lot about workflows and how and why they behave the way they do. Enjoy!

Note: fu was the actual workflow name I used just to look at an empty defined workflow, e.g. workflow fu {}; then use this to see the properties of the workflow: gci function:fu | fl *

Below is what is in the ScriptBlock property.
[CmdletBinding()]                  param (                      [hashtable[]] $PSParameterCollection,                      [string[]] $PSComputerName,                      [ValidateNotNullOrEmpty()] $PSCredential,                      [uint32] $PSConnectionRetryCount,                      [uint32] $PSConnectionRetryIntervalSec,                      [ValidateRange(1, 2147483)][uint32] $PSRunningTimeoutSec,                      [ValidateRange(1, 2147483)][uint32] $PSE…

PowerShell Error Handling Behavior Debunked

Note: I am using simple error messages as an example, please reference the best practices and guidelines I outlined on when to use custom error messages.

I have been churning in my mind for the last few days all the entries in the 2013 Scripting Games and how they handle errors, or lack thereof.

I am coming to the conclusion through some testing that the simple fact of seeing a try..catch or throw statements does not mean there is proper error handling.

I've been testing several variations and forms of error handling, so lets start with the basics.
function Test-WriteError {      [CmdletBinding()] param()  "Test-WriteError::ErrorActionPreference = $ErrorActionPreference"Move-Item -Path 'C:\Does\Not\Exists.log' -Destination 'C:\No\Where'"Test-WriteError::End"}   Test-WriteError::ErrorActionPreference = Continue
Move-Item : Cannot find path 'C:\Does\Not\Exists.log' because it does not exist.
At line:6 char:5
+     Move-Item -Path 'C:\Does\N…

PowerShell - 2013 Scripting Games Advanced Event 1 - Error Handling

One more suggestion I received on my entry was better error handling. If you didn't get this already, but I am a naturalist when it comes to PowerShell, e.g. let PowerShell do the heavy lifting and what it does naturally best.

Though, thinking through possible error conditions in my script, I do have opportunities for improvement. Namely around the scenario where the target directory could not be created by New-Item, the script continues on when that really is a terminating error and should stop.

I've been reading peoples feedback and other blog posts about how to handle errors with this event. I saw a few people very passionately advocate for Write-Warning as a better solution than Write-Error. Write-Warning is not a suitable replacement for Write-Error, they have two very specific meanings for the user.

While I agree, the implied usage of each could leave this error gray, I think it is easy to set a few best practices I think everyone could agree with.

Write-Warning should be…