PowerShell ROBO

Picture this – you are a systems administrator working at a major banking institution. The security team walks into your office and lets you know that a major update needs to be applied to all of the servers within the institution – not a problem for most organizations, but in the case of a bank, you could have hundreds if not thousands of remote and branch offices.  Sure, we can write scripts to copy out the update files and even execute them remotely from our head office – but the problem most ROBO scenarios are ever-changing – with new offices being created and others closing down all the time.  Keeping track of server names, IP schemes, etc. can be quite a time-consuming process.  Naturally, we want the same updates, patches, and fixes to be deployed everywhere, in the same manner, in order to provide consistency – so having this up to date list available when we need it is key to driving success within our environment.

So what does this have to do with PowerShell?

Since PowerShell’s first birth into the enterprise back in 2006, we have seen many third party and windows applications adopt the simple scripting language.  With such a wide range of support it may make sense for you to keep this “location” listing stored within a PowerShell module – allowing you to access the information you need about locations and simply “pipe” other commands to its metadata – allowing us to essentially convert our branch locations into PowerShell objects that we can retrieve from a PowerShell module.  Sometimes it’s easier to simply see how this works before it makes sense, so let’s take a look at a simple example…

If we think back to our banking example we can imagine that we may have a lot of branch offices – and offices of different types as well; think of a fully-fledged bank in a city, small bank kiosks in grocery stores, etc.  Our first goal will be to take all of the information about our banking locations, their location codes, server names, IP schemes, bank types, etc. and build a cmdlet which will allow us to quickly retrieve this information from a PowerShell Module.  To do so we will first need some sort of database or file containing this information.  Today I’ll simply use a CSV file, however, you could use any type of data store you like (MSSQL, Txt, etc.) so long as you change the code below in order to get the data out of the file.  Below you can see my CSV file and how I’ve structured this data – try to envision your ROBO environment within this structure…

As you can see above I have a lot of metadata built around all of the different bank locations, however this data as it is isn’t that useful to me when trying to run other PowerShell cmdlets against it– so let’s take this data and create PowerShell module around it, with a Get-BranchLocation cmdlet to return the data to us…

Today we will just be using a simple script module, however, you could use any PowerShell module type you wish – but to get up and running quickly simply create the folder structure shown inside of your C:\Windows\System32\WindowsPowerShell\v1.0\Modules directory, complete with our PSM1 file (the module file) and our locations.csv location listing.

Once the structure is ready it’s time to get started on the code.  Our example for today only contains one function (Get-Bank Line 2 through 32) but will give us the foundation for building other types of cmdlets within our module.  For simplicity sake, we can see all of the code below – with the line by line explanations below it…

Line 4 through 9 – These are our function/cmdlet parameters – meaning we define these in order to allow our users to pass information into our cmdlet.  Here we have 5; LocationID, Type, City, Province, and Country – all matching with column headers in our CSV file.  It’s the values of these parameters that can be passed in order to filter our result set.

Line 12 – This simply imports our CSV file of our branch locations into the banks variable.

Line 14 – Here we establish the beginning of our filtering sequence.  Since the parameters of this function are not required, meaning we can pass a city value, a province value, a city and province value, or in fact no parameters at all, we have to dynamically build our filter.  By beginning our filter with an always true “1 –eq 1” sequence we can make the remaining code much easier to write.

Line 16 – This line is used to gather all of the parameters which were passed to the cmdlet.

Line 18 through 31 – This loops through the passed parameters and if it finds a parameter with a value it is appended to our filter string on Line 26.

Line 32 – This takes the command which we would like to run and appends the filter string to it.

Line 33 – Here we complete our function and return the evaluated expression of our command string.

Line 36 – In order to use our Get-Bank cmdlet outside of this module, we need to ensure we export it as a module member.

Now if we head into our PowerShell console and run our new cmdlet, you should see some similar output as that below…

So by now, you might be thinking “How can such a small little function help me with managing my branch locations?”  Well, take for instance our example of copying out a patch to all of the domain controllers –  In order to do this utilizing our new cmdlet we could do the following

Get-Bank | foreach-object { Copy-Item c:\super-patch.exe \\$($_.DomainControllerName\share$\ }

Need to enable ssh on your ESXi hosts which are located only in kiosk branches – no problem

Get-Bank –Type Kiosk | foreach-object { Get-VMHost –Name $($_.ESXHostName) –User username –Password password | Start-VMHostService –HostService ($_ | Get-VMHostService | Where {$_.Key –eq “TSM-SSH”} }

How about restarting all of the Transaction Services located in Quebec?

Get-Bank –Province Quebec | foreach-object { Restart-Computer –ComputerName $($_.TransactionServerName) }

By now we can really see the efficiencies and consistencies that bundling up our remote/branch offices into a cmdlet with a PowerShell module can bring – and this is just with one simple cmdlet.  Certainly, this opens the doors for much more.  If we take more of the mundane, repetitive tasks we perform at each location, script them into PowerShell, and simply add them into a function/cmdlet into our PowerShell module we not only make our lives easier by automating our work but down the road when things go wrong, we should be left with a more consistent environment – which we all know makes troubleshooting easier!  For now, give PowerShell a shot at managing those remote locations for you, stop wasting time looking up hostnames and IPs, and just Get-Scripting!

Related materials:

PowerShell Modules – Why bother?

5 tips to help you explore the world of PowerShell scripting