5443headpatchswitch_851x315_wordpress (2)

Be the Hottest It Person on the Planet!

Fans of the “Patch and Switch” podcast that occurs regular Fridays can now own a really cool T-shirt

Details are here! http://teespring.com/patchandswitch

Reserve price is all of $15 but as more people place orders… the price can drop

Check it out now and don’t forget to check out the Patch and Switch podcast!

Patch and Switch – It’s Friday.  Do you know where your IT Guys are?

(also known as Robert Plant is going to kick my butt for messing with a Classic)

Lyrics to the "Cmdlet Song"

Cmdlets,
Cmdlets,

We come the land of the .Net Code,
Our methods run with Overloads

The Land of Monad gods
Data going Stacks Overflowing
Automate the clusters
Typing and Piping
Redmond now is calling home

Onward we go, modules in hand,
Workflows and CIMs we handle the data land

Cmdlets,
Cmdlets,

We come the land of the .Net Code,
Our methods run with Overloads

The glowing of the screen,
It calls us out for more
One Shell to link the Cloud and floor
We are your Azure lords….

Onward we go, modules in hand,
Workflows and CIMs we handle the data land

We live within the Shell
and the Cmdlets do we trust
And Cim and data objects
our Infrastructure is growing

One Shell to Rule them all
One Shell to Find them
One Shell to see the Objects and Bind them

One Shell to Rule them all
One Shell to Find them
One Shell to see the Objects and Bind them

This all came to me as I was drumming my fingers on the keyboard for an idea to Share at Teched for Speaker Idol.   The idea was simple.

I remember in my last job at we would have Developers create solutions, then fill out a Change Request form (or some type of paperwork, I can never remember WHICH one, there were so many floating about the desk) to bring a Development solution into production.

The typical request might have been something along the lines of

  • Server 2008 R2 Web Edition
  • 1 gb ram
  • 30 GB Hard disk
  • IIS installed

Then of course Infrastructure would spin it up, the application was deployed and inevitably something would fail in the Production solution.

Emails would fly back and forth.

“Hey you didn’t include this feature so that’s why the App doesn’t work!” is something I might hear from our Developer friend.

“Well you didn’t ask for that feature” IT would fire back.

Fingers would point back and forth until finally we all sat down and spoke and got the exact requirements for the application.   By Now all our feathers are ruffled up and Devs and IT Pros are launching Small projectiles created from paperclips and the Odd Co-op student over the wall in anger.

This is of course, not very productive.

I think to now with life in Windows PowerShell and how this could have been different.   In PowerShell we have actually two pretty cool and simple options in a modern Server 2008 R2 and higher environment.

Option 1 – Capture Server Features as an XML and reimport.

This one is the simple of the two to perform but still requires both sides to understand PowerShell.  You can use the Get-WindowsFeature Cmdlet and obtain a list of installed features, and then export them out to a CLIXML file like so

Get-WindowsFeature | Where { $_.Installed } | Export-CLIXML C:\Foo\config.xml

With this one script your Developer could at LEAST capture the presently installed features in his server he was Developing and capture that a Deserialized XML Object.

With this captured object you have a few options.  One is to pull down the exact list of names of all the installed Features and place it into a Text file to paste into the Documentation to aid Infrastructure with a long but detailed list of the very features the server needs.

The other interesting option would be to use this XML file on the Destination server and just simply execute the Install-WindowsFeature using the piped in data like so.

Import-CLIXML C:\Foo\config.xml | Install-WindowsFeature

This would at least create a mirrored feature configuration, limiting some of the mistakes.

Option 2 – Capture Features and build a DSC configuration AND the Change Request document

The other option which is a bit more interesting is to create a very basic DSC configuration file for PowerShell 4.0.    Similar to the first idea, we capture the WindowsFeature as an XML file but we parse and process this data and produce a simple Desired State Configuration File.   At the same time we do this, we can leverage a very interesting concept where we can build an RTF (Rich Text Format) file which contains this detailed list.

Why the document?   In larger environments, process must be followed and it often includes paperwork to match the process.   What you could look into doing is building an RTF file which matches the details of the original Change Request document but have the computer fill out as much of those details as possible.

So here is a sample script that could do this very setup.   Granted there are many ways to improve upon it’s design but it’s process is simple

  • Capture the Get-WindowsFeature Object
  • Parse the information and build a simple PS1 file as a Desired State Configuration
  • Build a Change Request document as an RTF file with Windows PowerShell with an EXACT list of the features needed

# Obtain Name of Server
$Servername=(hostname)

# Use Present Date and Time as part of the filename for output

$DateTime=(get-date -Format 'MMddyyyy-hhmmss').tostring()

$DSCFile="$Servername-DSC-Config-$DateTime.ps1"

$ChangeReqFilename="$Servername-ChangeReq-$DateTime.rtf"

$Features=Get-WindowsFeature | Where { $_.Installed }

# Header for the DSC file

$DSCHeader=@"
Configuration NewDevServer$DateTime
{
    Node $Servername
    {
"@

# Header for our RTF document

$RTFHeader=@"
{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1033{\fonttbl{\f0\fnil\fcharset0 Consolas;}}
{\*\generator Riched20 6.2.8102}\viewkind4\uc1
\pard\sl276\slmult1\f0\fs22\lang9 \par
"@
 
# Our beginning header for the Message

$MessageHeader=@"
This is a Request for a Deployment of a New Server into Production.\par\par
\par
We need the following features enabled in the server.\par\par
"@

Add-Content $DSCFile -Value $DSCHeader -Force
Add-Content $ChangeReqFilename -Value $RTFHeader -Force
Add-Content $ChangeReqFilename -Value $MessageHeader

# Get the list of features

Foreach ($Feature in $Features)
{
$FeatureDisplayName=$Feature.Displayname
$DSCFeatureDisplayname=($Feature.DisplayName).replace(" ","").replace("-","")
$FeatureName=$Feature.Name

# Build the Block in DSC for the Feature.  Each description must be unique

# We will use the Feature’s own name as the Description

$DSCFeatureBlock=@"
        WindowsFeature $DSCFeatureDisplayName
        {
        Ensure = `"Present`"
        Name = `"$FeatureName`"
        }
"@

# The line below is where we add lines to an RTF file. 

# the cool part is an RTF file is Just 100% raw ASCII with special

# Characters to produce the pretty letters.  (Did I just say Pretty?)

$ChangeReqDescription=@"
$FeatureDisplayName\par
"@

# Add Content to each individual file

Add-Content $DSCFile -Value $DSCFeatureBlock
Add-Content $ChangeReqFilename -Value $ChangeReqDescription
}

# Add the necessary terminators for  both the DSC file and the RTF Document

Add-Content $DSCFile -Value '}'
Add-Content $ChangeReqFilename -value '}'

If you run this script on any Server 2008 R2 or higher box it will capture the configuration, build a simple RTF document with a detailed list of features and the necessary DSC file to allow the IT Pro to deploy the server Easily and matching his Developer friend’s configuration much more closely.

The advantage (or than it’s PowerShell and it’s free) is a smoother process and happier times for IT Pros and Devs alike.   

…. and perhaps more nights together playing Titanfall rather than tossing CoOp students over the cubicles at each other