I know I keep posting stuff, but I have so much to get out I hardly have time to get my PowerShell formatted!
Don’t worry – this post will be short and sweet. I simply wanted to get a quick script in front of you, something that you can execute either from PowerShell ISE as straight PSv3 Workflow, or from as a SMA Runbook.
Many of us work with Beta, Preview, Pre-Release software. Here at MSFT, it seems that I “live in Beta” – always “dogfooding” the next big thing. We do this to be on the bleeding edge, but also to get the best possible product in front of you, before it arrives. That said, if you are reading this post, you likely have some to all components of System Center 2012 R2 Release Preview installed on Windows Server 2012 R2 Release Preview. This means you have a specific version of each component installed.
Do you know which version of each R2 component you have installed?
Sure, at this point you may know AND they likely all line up – But what happens after updates, patches, etc. to the various components? Then it gets a bit more complicated.
For this reason (and for my own, living in a pre-build world), I put together the PowerShell script that you will find below.
Scope of Example
This script does not gather every version of every component of System Center. Instead, it focuses on the bits that were most important to me for troubleshooting purposes. I hope that it can be used as an example of how to quickly and easily gather this type of information – while at the same time illustrating some pretty nifty PowerShell for retrieving data from registries on remote machines.
- Windows Azure Pack
- Service Management Automation
- Service Provider Foundation
- Virtual Machine Manager
Before we get to the example, here are a few notes about its functionality and script example setup:
- The script walks the Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ path for each of the stored values related to each product/component above (on each of their respective machines).
- The script leverages an array of “:” delimited data which is parsed (split), assigned to variables by specific array placement, and passed to the remote InlineScript call. You can certainly generate and pass data any way that you would like, this was just my way to encapsulate all the data necessary for the examples provided.
- $Products is used to store the component/product data. It is stored as “:” delimited array data, and uses the following format:
“Component Name from Registry:Field Name for Version:Component Server Name”
Note There is an array entry (like above) for each of the component/products.
- $Creds is leveraging a built in SMA Credential Variable call. Other methods of getting credentials to this PowerShell v3 Workflow / SMA Runbook are certainly acceptable, I just wanted to be consistent with other example SMA Runbook posts.
Note This script has been modified based on “Comment” feedback below by @alexandair. Thank you for helping improve our content!
Example Output from PowerShell
Example Output from SMA
Note The versions you see here will differ from what you have installed.
That’s it! I hope this Get-SC-Product-Versions post provided you with another useful gadget in your SMA Runbook / PowerShell v3 Workflow utility belt!
Oh, and if you want more examples for SMA and PowerShell v3 Workflow, be sure to check out this list (to be updated as more examples are provided):
- Automation–Service Management Automation Runbook Spotlight–Exchange Distribution List Creation
- Automation–Service Management Automation Runbook Spotlight–Virtual Machine Startup by Priority (Part 1)
- Automation–Service Management Automation Runbook Spotlight–Virtual Machine Startup by Priority (Part 1.5)
- Automation–Service Management Automation–Utility Runbook Spotlight–VMM Custom Property Management
- Automation–Service Management Automation Runbook Spotlight–Virtual Machine Startup by Priority (Part 2)
- Automation–Service Management Automation–Utility Runbook Spotlight–Get-SC-Product-Versions
And for more information, tips/tricks, and example solutions for SMA, be sure to watch for future blog posts in the Automation Track!