Category Archives: Uncategorized

Blog update Sept 2015

What’s going on right now?

  • Well, right now, I’m in Singapore for the summit. We’ve just had a keynote delivered by Jeffrey Snover, Big Daddy of PowerShell, and we’re about to get into the meat of the conference.
  • I’m hosting a fork of PoSHServer here at my github – it’s altered to allow a few capabilities that the basic PoSHServer doesn’t have.
  • My team were recently declared DevOps Poster Boys recently by ITNews.
  • Domain just moved into new premises and things are all over the place, but it’s possible that we’ll be hosting the Sydney PowerShell User Group once a month.

More to follow

Using Octopus Deploy? Push out code on Fridays?

I made a “Friday Deploy?” step template just for you, based on this famous snippet

DrillSergeant – a simple UserData manager for provisioning EC2 Windows instances

There’s a more full announcement due over at the Domain Tech Blog, however I figured I’d drop one here too.

Ever tried to automatically provision Windows EC2 instances in AWS and run into the “Windows needs a reboot” problem? Needed to run some more code after the reboot and been stuck for a decent solution? Had to Join to AD and then carry on installing things? Rename a server? Reload the registry after a change before continuing? Tearing your hair out working with Scheduled tasks and the RunOnce registry key?

Worry no more.

DrillSergeant, a PowerShell UserData manager derived from Domain’s Robot Army, is now available on GitHub.

Yes, I went through all the pain and came out with something that works, and works well, so we released it into the wild for everyone to use. Do feel free to grab a copy and try it out, and send in a Pull request if you have useful changes to add.

Future releases from the Robot Army will include DSC resources to manage S3 and EC2 resources, and some CloudFormation tools, and maybe, eventually, the Robot Army itself. If I can make it a tad more generic.


Uploading an SSL Certificate to IAM for use with ELB or Cloudfront using PowerShell

Because I only do this once or twice a year, I can never quite remember how to get it done. So consider this post an aide-memoire of sorts.

Generally, your SSL cert will turn up as one or (preferably) more *.crt files – one the actual certificate, and the other the verification chain – and you should also have a private key, probably as a *.key file.

Step one: convert these to PEM format using openssl.exe at the PowerShell prompt. Don’t have openssl? Download it here or use chocolatey, as follows

Now, down to the business of conversion. Hopefully, you have an x509 format cert and chain. Convert them into the AWS-friendly PEM format like so:

Next, we do the same to the Private Key

Now, how do we get these into AWS?

We use the Publish-IAMServerCertificate cmdlet, of course

For use in ELBs, we use this

And to do the same for AWS CloudFront, well you need the /cloudfront/ path, like so

And your certificates will be uploaded to IAM and squirrelled away in the certificate store. You can check that it’s there by using


Side Note: There’s a command called Get-IAMServerCertificate and another called Get-IAMServerCertificates – note the ‘s’. This breaks the powershell convention of a single command to operate on singular or multiple values. I would hope AWS would eventually fix this flaw and bring the SDK into line with published PowerShell conventions, but we will see.

Now, when you go to your CloudFront distribution or your ELB’s listeners tab, you should be presented your new Certificate in the dropdown for available certs, and you’ll have your content nicely secured.

The -AcceptEula Gotcha

Maybe we’re an edge case, but our ‘legacy’ Deployments through OctopusDeploy are based on an older batch process, which uses Junction.exe from Sysinternals to refer IIS from a ‘current’ folder to an “application.version.x.x.xx” folder. It’s a pretty common, if a little old-school technique. The original was a batch file, which was replaced by some powershell, which was enhanced a lot end then ended up ported into Octopus. It now deploys the new code, removes the box from the load balancer, switches to the new code using Junction.exe, resets IIS, warms up the new code and finally adds the box back to the load balancer. It’s pretty seamless, if a bit convoluted.

Well recently we had a little change pushed through which rolled back a few system settings on the web servers. And when it came to deploy with Octopus, we saw multiple catastrophic failures. Continue reading →

Snippet: Getting stuff installed

I sent this little snippet around my team after my aforementioned PowerShell Ninjas training session. It’s an easy way to get a bit of software painlessly installed onto someone’s machine. I just said “Hey, if you need the Powershell commuity extensions, just run this in your powershell prompt”

And now my team have PSCX installed, via this little snippet. There are of course some considerations to be made here. It’s not going to work without having unrestricted scripting permissions, and it might not be great to get your users into the habit of running random code off the internet, but hey, Chocolatey do it, so why can’t you?

This is actually a great technique for power scripters to make your modules and profiles portable. Get them on a server you trust, run a one-liner, hey presto you have a fully configured environment, ready to use. Neat.

Supercharging your PowerShell Profile

ise $profile; Remember this command

One of the things that would separate a true ninja of the PowerShell world from a mere dabbler may be the intelligent use of Powershell’s Profile features to save work.

After all, the whole point of an automation language like PowerShell is to cut down on unnecessary work. I mean, who wants to type Import-Module a hundred times a week when they can type ipmo?

Indeed, who needs to type ipmo at all? And if you use your profiles smartly, you don’t have to.

Continue reading →