Posts Tagged "powershell"

I’m very proud to have contributed the xPfxImport DSC Resource to Microsoft’s xCertificate module. This resource is included in version 1.1.0.0 of xCertificate which was released on December 2, 2015.

xCertificate on GitHub
xCertificate on PowerShell Gallery
ServerFault thread that pushed me to publish (thanks in particular to jscott).

The purpose is to distribute SSL certificates (and optionally the private key) to nodes via PowerShell Desired State Configuration. The PFX is loaded from a network share or file path, and is typically encrypted with a password. DSC Encrypted Credentials are used to store the PFX extraction password securely in the configuration.

My primary use case in writing this concerned distribution of commercially purchased SSL certificates; particularly something like a wildcard cert which needs to be distributed to many nodes and will be need to be updated periodically as renewals happen.

This will also be nice for use with shorter term certificates like 90-day certs offered for free by Let’s Encrypt.

I came across this question on StackOverflow about throwing when a parameter is not supplied by pipeline . There have been many questions about this (without so much emphasis on the pipeline), so it seems to be a common request that PowerShell not prompt on a missing mandatory parameter, but instead throw an exception.

The short answer is that there is no way to do it if the parameter is in fact mandatory, so what we usually settle for is a simulation of required-ness that’s usually handled with a default value expression that throws an exception, like so:

function Get-Thing {
[CmdletBinding()]
param(
    $MyParam = $( throw 'MyParam is required' )
)
}

But this approach has its disadvantages.

Every PowerShell Desired State Configuration resource must have at least one Key property that’s used to uniquely identify it within a single configuration. For the DSC Script Resource the keys are the GetScript, TestScript, and SetScript properties. Basically this means that each Script resource can’t contain the same content. Makes sense on the surface, but when you consider variable substitution, and looping through collections in $ConfigurationData, it’s easy to come up with a configuration that ends up with this error:

Add-NodeKeys : The key properties combination ‘your script here’ is duplicated for keys ‘GetScript,SetScript,TestScript’ of resource ‘Script’ in node ‘nodename’. Please make sure key properties are unique for each resource in a node.

This is quite annoying, but there are ways around it so you don’t have to resort to manually unrolling your loop.

Sometimes we run web services internally that don’t use a trusted SSL certificate. It’s not good practice, but in the real world this will be encountered.

In PowerShell, we often see this error come up when using Invoke-WebRequest or Invoke-RestMethod or even the [System.Net.WebClient] class. All of these rely on the .Net framework which is set up to validate SSL certificates, so an exception gets thrown when we try to connect to a site over SSL that isn’t trusted.

For a while, a lot of people created a class that implemented the ICertificatePolicy interface, provided a method that always returned true, and then set System.Net.ServicePointManager.CertificatePolicy to an instance of the new class. This is also the method I have used for a while, and in PowerShell it didn’t seem to complain. But I’ve recently found that this method is in fact deprecated .

It seems the correct way is to set the ServicePointManager.ServerCertificateValidationCallback property to a callback function. Ok, no problem. It’s almost the same thing.

I was looking for a way to determine whether I was in Verbose mode in Powershell. My web searches came up with various solutions that all suffer from problems. Most of them use $PSBoundParameters. The most obvious problem with this is that it only works when -Verbose was called directly on the script or function whose context you’re currently in. Since the Verbose state is inherited by child scopes, this is less than ideal.

Splatting is a really great feature in PowerShell that lets you take a [hashtable] of parameters and call a function or cmdlet with the hash instead of having to type out every parameter name and value. It seems natural then that if you’re writing a wrapper or proxy function, where your function takes the same or nearly the same parameters as the function you’re calling, you could use $PSBoundParameters to do the heavy lifting (this special variable contains all of the parameter values passed into the function).

The problem comes when your proxy function has defaults for its optional parameters. $PSBoundParameters only includes the values of parameters that were explicitly supplied by the caller. There is no such variable that contains the default values.

I finally got DNS scavenging configured in our environment. It’s working great, no big disasters. I was browsing the DNS manager (so much faster now that we got rid of those 6,000+ resource records we didn’t need) and I noticed two TXT records that I created as a test last week. I didn’t need them anymore, but instead of deleting them I thought I’d just set them to expire and let scavenging take care of it. Funny thing is, the setting just wouldn’t stick. No errors, nothing preventing me from doing it, it just kept reverting to static.

While writing a PowerShell script to fix some DNS records, I came across some very strange behavior. I was calling Get-DnsServerResourceRecord and it was returning duplicate results for every record. One result was correct, and the other one looked like it was the fully qualified domain name. The results made no sense to me, and I couldn’t figure out how now to return these extraneous records.

As I wrote in a previous post, I began using the new DFS Replication database cloning technique to speed up initial sync. Thanks to Ned Pyle’s great How-To on the subject, I was able to tell exactly which events to look for in the event log to get an idea of progress: 2412 for the start of the process, 2416 for progress, 2404 for successful finish, and 2418 for an unsuccessful end (found that one out on my own, whoops!).

Since I clearly had a few hours to kill while the import happened, I wrote up a quick script to show the progress, with estimated time remaining.

Windows 2012 R2 introduces a great feature for speeding up DFS Replication initial sync: Database Cloning. The details are covered very well by Ned Pyle’s excellent blog posts, especially this one. Seeing as how this is pretty new stuff, there doesn’t seem to be a lot of documentation about the possible errors, and I encountered the one in the title.

In my environment I push out a scheduled task which runs a PowerShell script. The PowerShell script sits on a network share. Recently, we changed the share where our scripts are stored, and as a result we updated the task to point to the new script location. The task used to work, but now it throws a Last Run Result error, with the return code 0xFFFD0000.

The new installer for Confluence and JIRA on Windows simplifies upgrades, but it also overwrites added or modified files in your program directory. If you have added or modified a lot of files, it can be tedious to restore those modifications after the upgrade. To that end, I’ve written a simple powershell script which will back up all of the modified files and then optionally restore the files once the upgrade is complete.

Powershell really is a game changer when it comes management and scripting on Windows, but one of the areas where it really shines is in its remoting capability. Powershell remoting lets you connect to a remote system and run commands locally, then returns the results to the calling machine. This can be done as an automated block or as an interactive session.

Remoting requires Powershell 2.0 which comes built-in on Windows 7 and Windows 2008 R2, but it needs to be installed on Windows Vista / Server 2008 and below. The WinRM service will also have to be configured and enabled.

I’ll show you how to accomplish this with group policy for the range of operating systems that can run it.

Update 2013/02/20: I have confirmed that this method is working on Server 2012 (core and GUI) as well.

Update 2013/05/07: With the help of Jacob in the comments below, I was able to fix a problem in the VB Script. Since Powershell requires the .NET framework, this whole process will fail on Windows 2003 / XP if .NET is not installed. The VB Script now installs .NET as part of the process. The GitHub Gist has been updated. Thanks Jacob!

Update 2013/10/09: Updated the name of the WinRM policy setting based on user comments. Thanks to Micahel M. of Miller Computers and Giorgi Gordeziani.