Home » PowerShell » #PowerShell and WMI to Determine OS Architecture for Automation

I’m in the process of writing some of the more complicated PowerShell code I’ve ever written to automate some laborious tasks at my new job.  The process I generally like to take when writing something like this is to modularize parts/steps of the automation as standalone components to be reused and consumed elsewhere.

Part of what I’m automating requires running installation of software.  This software comes in 32-bit and 64-bit flavors, so picking the correct install bits is very important.  In searching for “the best” way to determine installed OS Architecture, it became very apparent that Admins out there were relying on, what I would characterize as, error prone methods.  I needed something that would work on Windows Server 2003, 2008, 2008 R2.  Yes I’m aware that 2008 R2 is x64 only, that makes things easier, but I need to have a streamlined and solid method of checking, regardless of what system is running the install task.

Starting with the Vista/Server 2008 , a new property was introduced to the win32_OperatingSystem class, called OSArchitecture which makes this relatively trivial.  However, I want something that will work on 2003 if needed.

I started looking at other WMI classes to find a reliable way to determine, without having to rely on parsing text strings of a Caption property or other various methods.  I ended up finding the win32_Processor class and found a quick and easy solution – the AddressWidth and/or Architecture properties.  The Architecture property would be ideal if looking for Architectures other than 32/64-bit.

Below is the extremely simple snippet to perform this check against the first and sometimes *only* CPU installed. I know I had very limited reliable information out there on this, so I hope this helps someone in the future.