Use PowerShell to Detect Your Microsoft Office Version

ScriptingGuy1

November 26th, 20100 0

  

Summary: Learn how to use Windows PowerShell to detect your version of Microsoft Office. Also learn about locating your Windows PowerShell installation location.

 

In this post:

·         Detect Your Microsoft Office Version

·         Locate Your Windows PowerShell Installation

 

Detect Your Microsoft Office Version

Hey, Scripting Guy! QuestionHey, Scripting Guy!  With reference to one of your previous blog posts, “How Can I Determine Which Version of Word is Installed on a Computer?” I liked how your approach to determine the version of Word is much faster than querying Win32_Product. Nevertheless, how do I use this same technique to query the version of Office? In our organization, we have a mix of different versions of Office, some of which even have different versions of Word on the same machine (for backward testing of some old macros). I do not really want to loop through all the available Office products.

— JJ

 

Hey, Scripting Guy! AnswerHello, JJ. The blog post you mentioned was written in 2005 using VBScript. I wrote a blog in 2009 that is on the same theme using Windows PowerShell. You can detect the “version of Office” by querying the product version of Word / Excel / PowerPoint / Outlook, and so on Unfortunately, I cannot find a global GUID to represent the version of office that is installed. In addition, as you pointed out, it may be that one has Office 2010 installed, has Word 2003 installed as well, and maybe even Outlook 2007. So a mix and match situation could very well exist that would make extrapolating what version of Office is actually installed on the machine problematic.

In addition, problems can occur as to what version of Office is installed because of Professional version, Ultimate edition, Student edition or one of the other editions of Office that consist of different suites of applications.

Ultimately, one must describe what is meant by “what version of Office” is installed. One way to do this is to determine why the information is to be collected. For example, are you trying a software inventory, trying to detect update status, seeking information to determine upgrade costs, searching for machines that were possibly missed during an upgrade cycle, or for computers that do not have enough horsepower to stand an upgrade to the most recent edition of Office.

As you mentioned, using the WMI class, Win32_Product can be a bit slow. However, the ability to run it as a background job in Windows PowerShell reduces this really well. It is a fire and forget operation. Come back later, and retrieve the results. You can query the registry for Office keys. However, you have to allow for all different variations of the configuration. You can also query file versions but that will require you to check for every possible combination of service pack and hotfix as the file versions change at service pack levels.

From a most basic stance, you can decide that if a computer has Microsoft Excel version 12 installed, it is running Office 12. Frequently such a broad stroke is sufficient.

Microsoft Configuration Manager creates custom WMI classes that can be used to query for Office version information. The WMI classes work very well, and retrieve their information from the registry. You can take that approach if you do not have Configuration Manager installed. In addition, there is an Office inventory tool that can be downloaded. It works well, but I am not certain if it was updated to detect Office 2010. The tool seems old, having been written back in 2006, but perhaps it will work for you. If you decide to go the registry route, or the file version route, there is an excellent KB article that gives you the information that you will need.

 

Locate the Windows PowerShell Installation

Hey, Scripting Guy! QuestionHey, Scripting Guy! I want to ask about cleaning out unnecessary applications on my pc. How would I know whether I had Windows PowerShell on my computer at work? What is the normal path for this application?

— GB

 

Hey, Scripting Guy! AnswerHello, GB. On Windows 7, Windows PowerShell is installed by default. On Windows Vista and on Windows XP, it is a separate install. When Windows PowerShell is installed, it creates a folder on the Start menu under Accessories. The path to that location is seen here:

Start Menu\Programs\Accessories\Windows PowerShell

 

As for the executables, they are placed under the system32 folder. This location is seen here.

C:\WINDOWS\system32\WindowsPowerShell\v1.0

 

The following figure shows the Windows PowerShell location on my 64 bit Windows 7 Professional computer. You will notice that the folder name is still v1.0 even though my computer is running Windows PowerShell version 2.

 

Be aware, even if you have Windows PowerShell 2.0 installed, this folder name will still be v1.0. This folder name is kept for backward compatibility issues. I am repeating this, because it is a common source of confusion. I have received email messages from people who downloaded and installed Windows PowerShell 2.0, checked the folder location, restarted, uninstalled, re-installed, and so on before they emailed me. In Windows PowerShell 2.0, there is an automatic variable that you can use to determine your Windows PowerShell version. It is seen here.

PS C:\> $PSVersionTable

 

Name                           Value

—-                           —–

CLRVersion                     2.0.50727.4952

BuildVersion                   6.1.7600.16385

PSVersion                      2.0

WSManStackVersion              2.0

PSCompatibleVersions           {1.0, 2.0}

SerializationVersion           1.1.0.1

PSRemotingProtocolVersion      2.1

 

 

PS C:\>

 

If you find that you do not have Windows PowerShell 2.0 installed on your computer, this Scripting Wife blog post talks about how to install it on a Windows XP computer. The process would be similar on Windows Vista, or even Windows Server 2003.

From a Getting Started with Windows PowerShell perspective, the Scripting Wife blog posts are an excellent introduction. They chronicle the experience she had in learning Windows PowerShell. Start at the first Scripting Wife post, and work your way through them in order. Using the first link, you will see two pages of Scripting Wife blog posts. They appear in chronological order with the most recent one listed first. You want to read them in the order in which they were written. Therefore, visit page two, and start with the post on the bottom of the page. This will give you a nice chronicle of her learning experience.

 

Well, this concludes another edition of Quick Hits Friday. Join me tomorrow for the Weekend Scripter as I delve into the mysteries of iCame, iPod, iScripted – a continuation of a post that began last weekend on 11/21/2010.

I would love you to follow me on Twitter or Facebook. If you have any questions, send email to me at scripter@microsoft.com or post them on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

 

Ed Wilson, Microsoft Scripting Guy

ScriptingGuy1