Collect data about Office installations by using Robust Office Inventory Scan


Applies to: Office 2010

Topic Last Modified: 2011-08-05

Banner stating end of support date for Office 2010 with link to more info

Robust Office Inventory Scan (ROIScan.vbs) is a Microsoft Visual Basic script that collects Office data and provides error detection and analysis options. When you run the script, a log file is created. The log file can be used to perform tasks such as the following:

  • Assess the installed Office configuration on users' computers

  • Get detailed data about the Office installation to reproduce the user's environment

  • Look for mismatched Office versions or configurations

  • Help troubleshoot Office software updates and installation issues

After the log file is created, it opens automatically. The default file name is <computer_name>_ROIScan.log and the default location is the current TEMP folder. To navigate to the Temp folder, click Start, click Run, and type %temp%. You must run this command as administrator.

In this article:

  • Download the script

  • Customize and run the script

  • Log file sections

  • FAQs

Download the script

ROIScan.vbs is available for download in the Office section of the Script Repository in the TechNet Script Center (

To download the ROIScan.vbs script:

  1. Select Copy Code.

  2. Copy the code to a text editor such as Notepad.

  3. Save the file as ROIScan.vbs.

Customize and run the script

You can customize the INI section at the top of the ROIScan.vbs script. The following excerpt shows the INI section.

'[INI] Section for script behavior customizations

'Directory for Log output.
'Example: "\\<server>\<share>\"
'Default: sPathOutputFolder = vbNullString -> %temp% directory is used
sPathOutputFolder = ""

'Quiet switch.
'Default: False -> Open inventory log when done
bQuiet = False

'The script filters for products of the Microsoft Office family.
'Set this option to 'True' to a basic list of all products at the end of the inventory log
'Default: False -> Don't list other products in the log
bListNonOfficeProducts = False

The following table lists the command options that ROIScan.vbs supports. The syntax for using the commands is as follows:

ROIScan.vbs [Options]

The options are not case-sensitive.




Lists both Office and non Office products.


Lists Office Features and FeatureStates. Lists all installed Office 2007 and Office 2010 products separately.

/Logfolder ["<Path>\<Folder>"]

Specifies a custom log folder.


Logs additional product details.


Prevents the log from opening when the script finishes.


Displays ROIScan commands Help.

For example, to run the script and list non Office products, use the following syntax at the command prompt:

ROIScan.vbs /ALL


You must run the ROIScan.vbs script as Administrator. If you do not run the script with elevated permissions, you are prompted to run as Administrator.

To run the script

  1. Choose one of the following methods to run the script.

    • Double-click ROIScan.vbs.

    • To run the script from the command prompt, open a command prompt, right-click the command-prompt, and select Run as Administrator, locate the folder to which you saved the ROIScan.vbs script, and then type the following:


      For example, if you saved the script to a folder named ROIScan on drive C, type the following commands at the command prompt:

      CD C:\ROIScan


  2. To run the script with an optional command, use the syntax described in the preceding section. For example, to use verbose logging, type the following at the command prompt:

    ROIScan.vbs /LogVerbose

Log file sections

The ROIScan script includes the following sections in addition to the INI section listed earlier:

  • Title line

  • Computer

  • Review items

  • Products inventory

Title line

Indicates the script's title and the date and time that the log was created. Always verify that the time stamp matches the expected time to ensure that you review the correct log.

Example: Microsoft Customer Support Services - Robust Office Inventory - 5/3/2011 12:10:48 PM


Lists the current user and operating system specific data. This section only displays the data that is collected. No additional analysis is performed.

The following data is collected:

  • Windows Installer Version

  • ComputerName

    • OS Details

    • OS Name

    • SP #

    • Version

    • Codepage

    • Country Code

    • Language as LCID

    • System Type

  • Current User

    • Username

    • IsAdmin

    • SID

  • Logfile Name

  • ROI Script Build

  • Script Settings

  • Total Scan Time

Windows Installer version

The ROIScan.vbs script will work with computers that have at least Windows Installer version 2.x installed. For clients that run Windows Installer version 2.x, the script uses detection logic to remove as many limitations of Windows Installer 2.x as possible. Windows Installer 3.x has richer features and data. It is important to note the Windows Installer version that the client computers are running.

The ROIScan.vbs script does not use any features that require Windows Installer 4.x or later versions. For information about the released Windows Installer versions, see Released Versions of Windows Installer (

Operating system

Lists details about the operating system. Review this section to ensure that there are no unexpected language configurations. A list of Locale ID (LCID) values is available on MSDN:

Locale IDs Assigned by Microsoft (

The System Type entry reports if the operating system is a 32- or a 64-bit version.

Operating system MUI languages

A registry query returns a list of all installed and available user interface languages for the operating system.

  • For Windows 2003 and earlier versions, the registry key is HKLM\System\CurrentControlSet\Control\Nls\MUILanguages\

  • For Windows Vista and later versions, the registry key is HKLM\SYSTEM\CurrentControlSet\Control\MUI\UILanguages\

Current user

Provides information about the user who ran the script and created the log. The IsAdmin flag is not determined by a standard lookup. It is based on registry access permission checks.

The security identifier (SID) is useful if there are applications that are installed on a per-user basis. For example, this lets you check whether the application is installed for the current user or another user.

Log file name

Provides the location of the ROIScan.vbs script. The default location of the script is the current %TEMP% folder of the user who triggered the script.

ROI script build

Lists the ROIScan.vbs build number. The script is improved and its features are extended periodically.

Script settings

Lists the ROIScan.vbs command options that were used to run the script.

Total scan time

Lists the time that the script needed to complete the inventory.

The following example shows the Computer section of a log file (testclient_ROIScan.log in this case):

Windows Installer Version    5.0.7601.17105
ComputerName                 testclient
OS Details                   Microsoft Windows 7 Enterprise , SP 1, Version: 6.1.7601, Codepage: 1252, Country Code: 1, Language: 1033, System Type: X86-based PC
OS MUI Languages             en-US (1033)
Current User                 Username: DOMAINname\username, IsAdmin: True, SID: S-1-5-21-2127521184-1604012920-1887927527-2602236
Logfile Name                 C:\Users\username\AppData\Local\Temp\testclient_ROIScan.log
ROI Script Build             1.5.2
Script Settings              /Logfolder: C:\Users\username\AppData\Local\Temp\
Total scan time              10.4 s


Review items

Whenever the script detects something that is worth pointing out, the information appears in the Review items section. There are three categories for review items: Note, Warning, and Error.

  • Note   indicates that this information should be reviewed although it might not signify an issue that requires troubleshooting.

  • Warning   suggests that something might not be functioning as expected. We recommend that you review this information to determine whether you should investigate further.

  • Error   indicates that there is an issue. You must review this information.

The main purpose of the Review Items section is to indicate that certain products may have issues that should be reviewed in the Products Inventory section. The ProductCode is provided to ensure a unique pointer to the product.

Products inventory

The Product inventory section of the log file lists the details for each application within the product filter. The filter is based on the ProductCode (GUID). This ensures that only Office-based family products will appear in the log.

The data structure in the log includes the following entries:

  • <ProductName>

  • ProductVersion: Office build number.

  • ServicePack Level: Translates the preceding build number to a friendly Service Pack (SP) level RTM, SP1, SP2.

  • ProductCode: The product GUID.

  • Msi ProductName: The product name as listed in the .MSI package, for example, Microsoft Office Professional Plus 2010.

  • Configuration SKU: Office 2007 and later SKU reference, for example, Office14.PROPLUS.

  • InstallDate: The date the product was installed.

  • UserSid: Blank for per Machine installs, or user's SID for per User installs.

  • ProductContext: User or Machine.

  • ProductState: Installed or Advertised.

  • Transforms: Transform(s) .MST files that are used for the installation.

  • Original .msi Name: Original file name of the .MSI in the InstallSource.

  • Cached .msi Package: Name and path of the .MSI in the local Installer cache, for example, C:\Windows\Installer\b4f39.msi.

  • Build/Origin: Build / Origin entry from the Property .MSI table.

  • Package Code: Package Code GUID for the product.

  • Notes: Notes and Warnings for this product.

  • Errors: Errors for this product.

  • Config ProductName: Office 2007 and later configuration product name, for example, PROPLUS.

  • Config PackageID: Office 2007 and later configuration package ID, for example, ProPlusWW.

  • Chained Packages: List of Office 2007 and later chained packages for this suite.

  • Possible Licenses: Lists the Office 2010-specific license types for this suite.

  • Active License: Office 2010 specific field that has details about the active license.

  • Patch Baseline: Build version that a patch uses to determine whether its patch baseline is valid, for example, 14.0.4763.1000.

  • Post Baseline Sequences: Current patch family version levels.

  • Patchlist by product: List of patches .MSP files that are directly applied to the client.

  • Patches in InstallSource: Patches that were "slipstreamed" into the AIP (Administrative Installation Point).

  • InstallSource Type: Type of the installation source.

  • Initially Used Source: InstallSource that was used for the initial installation of the product, for example, C:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C\.

  • Last Used Source: InstallSource that was used the last time that the source was needed.

  • LIS Resiliency Source(s): Registered sources from which the local installation source (LIS) was created. These sources are used when the LIS has to be repaired.

  • Network Source(s): Registered non-web sources for this product.

  • FeatureStates: Listing of all Features and their FeatureState.


Lists the name of the product as shown in Programs and Features in Control Panel. If this is not the default product name, it is a strong indication that the installation package was heavily customized. Review this section carefully to ensure that the customizations are supported.


This is the Office build number that Windows Installer uses. Be aware that individual file versions may vary. If you click the application's File tab, and then click Help, you may see other values for the product ID under the Product Activated suite name or About program name section.

The ProductVersion is the version that is used for patching. For more information, see KB 328294 The About Microsoft <Program name> dialog box reports a service pack version that is different from what is expected in Office XP and in Office 2003 (

ServicePack Level

The ROIScan.vbs script uses custom logic to translate the Office build version to the related service pack level. It uses common terms such as RTM, SP1, SP2, SP3. For applications that are only released as web downloads, this logic does not apply. To indicate this in these cases, the build versions are indicated as "Web Release."

For information about how to check the version of Office, see the following KB articles:


GUID of the product, which is the key identifier for the product. This is useful if you have to get or identify the ProductCode for command line operations. For example, to run Windows Installer commands such as msiexec /i <ProductCode>.

For information about the product GUID numbering scheme, see the following KB articles:

Msi ProductName

Lists the ProductName as returned by the Windows Installer API. This is used if the product name cannot be retrieved from Programs and Features in Control Panel.

Configuration SKU

The short reference name for the product as it is used in the Config.xml file, for example, Office14.PROPLUS.


Lists the installation date. The following format is used: YYYYMMDD. This is available in Windows Installer 3.x and later versions.


Office is usually installed on a per-computer basis. In such cases, the UserSid has an empty string. If a product is installed in a per-user context, the user's SID is associated with the installed instance of the product. In the per-user case, an application might be listed several times, one time for each user SID.


Installer based products can be installed either per-user or per-computer. This line lists the context of the product. Office 2007 and Office 2010 only allows the per-computer context.

Example: ProductContext Machine


Windows Installer can differentiate between the following four product installation states:

  • UNKNOWN   The product is not advertised or installed.

  • ADVERTISED    The product is advertised but not installed.

  • ABSENT   The product is installed for a different user.

  • DEFAULT   The product is installed for the current user.

Everything other than the DEFAULT state, which will be listed as "Installed" in the log, is very rare.


Microsoft Office 2000 through Office 2003 used transforms (.mst) files as default methods for customizing the Office configuration. Although it is possible to use more than one transform, we do not recommend this practice.

Original .msi Name

Lists the .MSI file name of the .MSI in the InstallSource. For some Office versions, the volume license SKUs use a different naming convention from the retail product SKUs. If you are trying to reproduce an issue, the Original .msi Name provides the first hint about which file you need. However, it is not as reliable as the ProductCode and the Build/Origin values.

Cached .msi Package

Windows Installer caches a local copy of each installed .MSI package. The file is renamed by using a random file name. Since there can be many files in the local Windows Installer cache, Cached .msi Package can be useful if you have to locate a specific file. If the locally cached file is missing for an installed application, the application is unmanageable.


The Build/Origin values are stored in the Property table of the .MSI file. The values are not consistently available in all versions of Office so the two properties (Build and Origin) have been combined in a single line in the ROIScan log file. This is an essential piece of information if you have to identify the exact media to reproduce an installation issue.

To better illustrate this issue, look at the following two expressions from the English version of Office 2003 Professional:

  • 5608_0\x86\ship\1033\pro11 / 5614.0_o11pro_CBXS_ENG

  • 5608_0\x86\ship\1033\pro11 / 5614.0_o11sel_CBXS_ENG

The first value is from media that only contains the "Professional" version of the product. The second value is from "Select" media which combines all Office suites and stand-alone products.

The Build property lists the following information: "<Build>\<Architecture>\<ship/debug>\<LCID>\<SKU>". Note that this <Build> reference is not in ProductVersion.

The Origin property lists the following information: "<Build>_<Product>_<Market>_<Language>".

The <Market> entry contains the following information:

  • [Media], which can be one of the following values: C = Compressed, D = Uncompressed, P = Patch, S = Self, or W = IExpress package

  • [Version], which can be one of the following values: B=Bypass, E= Enterprise, N = Non-Bypass, O = OEM, P= PIPC, R= Retail, S = Select, or T = Trial

  • [Patch Type] or [Platform], which can be one of the following values: R = Roll up, S = Single, or X = x86

  • [Ship/Debug], which can be one of the following values: S = Ship, or D = Debug

Package Code

The package code is a GUID that identifies a particular Windows Installer package. The package code associates an .MSI file with an application or product and is also used for the verification of sources.

If the Package Code that is registered for a product does not match the one in the InstallSource, that source cannot be accepted as a valid InstallSource.

For more information about the Package Code, see Package Codes ( in the MSDN Library.


Notes and Warnings issues that were encountered for this product are listed in this section. Items that are listed in the Notes section do not necessarily mean that something is wrong with the installation or that it is in a bad state. However, it is worth reviewing the information that is listed here.


Errors encountered for this product are listed here. An error indicates that something is wrong and should be reviewed.

Config ProductName

This is an Office-specific value that was introduced with Office 2007. Some maintenance operations require that this value be specified in the command line. Examples include the /modify and the /uninstall Setup command-line switches. For information about Setup commands, see Setup command-line options for the 2007 Office system (

Config PackageID

This is an Office-specific value. It helps identify which package in the Office 2007 multiple .MSI architecture is the actual core package for the product.

Chained Packages

The Chained Packages section lists all .MSI packages related to the Office 2007 product.

Starting with the 2007 Office system release, Microsoft introduced a multiple .MSI architecture. If you have multiple Office products installed, it might be difficult to identify which .MSI belongs to the installed applications. To help you keep track of the ProductVersion of chained packages, the individual version information is listed for each chained package.

This category also lists applications that were configured as Not Available. Every .MSI file that is part of the product will be installed. However, some application features in the .MSI may be configured as Not Available.

Possible Licenses

Starting with the Office 2010 release, Office uses the same activation technology as Windows. All license types that the product can support are listed in this section.

Active License

Lists which of the possible product license SKUs is the active one that was selected for this product. Active License provides additional details, depending on the type of the active license type.

Patch Baseline

To determine whether a patch can be applied to a product, Windows Installer checks the current ProductVersion (build). The .msp package is applied only if the detected ProductVersion matches a build version that the patch can handle. This is the same as the ProductVersion and is repeated for improved usability of the log.

Post Baseline Sequences

Starting with Windows Installer 3.x, the "Patch Sequences" were introduced to allow improved patching capabilities. This section lists the patch family numbers that are higher than the current baseline.

Patches by product

List of all patches where the .MSP file was directly applied on the client. Depending on the version of Windows Installer, the details that can be listed vary. Windows Installer version 3.x and later versions, provide a richer set of details than Windows Installer 2.x.

Each line lists the following information:

  • <KB Reference>

  • <PatchState>: State values are Applied or Superseded.

  • <PackageName>: Original patch name.

  • <PatchSequence>: Patch sequence number.

  • <Uninstallable>: Indicates if the patch can be uninstalled.

  • <InstallDate>: Date the patch was installed. Uses YYMMDD format.

  • <PatchCode>: Unique identifier for this patch.

  • <LocalPackage>: Path and name to the file in the local Windows Installer cache.

  • <PatchTransform>: Reference to the patch embedded transform used.

  • <Displayname>: Title of the patch.

  • <MoreInfoUrl>: Link to patch documentation.

Patches in InstallSource

In Office 2000 through Office 2003, the products enabled you to create an Administrative Installation Point (AIP). For those versions of Office, you can apply patches to the AIP. This is known as "Slipstreaming." There are rules that apply to AIP patching that you should know about. For more information, see Strategies for Updating Office 2003 Installations (


If you deploy Office 2000 or Office 2003 from an Administrative Installation Point and you never update the image, you can distribute client patches directly to users, as long as they have reliable access to the original, unpatched source on the network. However, after you patch an administrative image, you are committed to updating that image and re-caching and reinstalling Office on users' computers in the future. To help ensure that the update process works correctly over time, decide on one method of updating Office 2000 and Office 2003 clients.
If you are applying client updates between service packs, as an efficient alternative to re-caching and reinstalling Office with every new release of critical updates or security updates, you can distribute these interim updates directly to clients, even if they rely on an administrative image as a source. You must first have established all users on the most recent baseline of Office 2003.
Note that you cannot use the same tactic to deploy the service packs themselves. The client versions of service packs require a source at the original release level — such as an unpatched administrative image or a local installation source.

The following KB articles document how to find Office updates:

InstallSource Type

Helps to identify the type of installation source on which the product is based. The possible values are as follows:

  • Original source using long file names

  • Original source using short file names

  • Compressed source files using long file names

  • Compressed source files using short file names

  • Administrative image using long file names

  • Administrative image using short file names

For Office products, we usually have the CD (or a 1:1 flat copy of the CD to a network location) in compressed format.

The "Administrative Image" or the Administrative Installation Point (AIP) is very popular with Office 2000 and Office 2003. Most Office products default to short file names for the AIP.

Initially Used Source

When a product is first installed, the product registers ProductInfo values. Initially Used Source registers the path from which Windows Installer invoked the installation.

Last Used Source

When a patch or maintenance operation has to access the installation source, it tries to use the source that is listed as Last Used Source first. If the source is not available and another source has to be used, that source will then be registered as the last used source.

LIS Resiliency Source(s)

Lists the registered sources from which the local installation source (LIS) was created. For LIS-based installations, that may show the actual initially-used source. In cases when the LIS has to be repaired, setup.exe tries to access these locations to restore the LIS.

Network Source(s)

Network sources are basically all sources other than CD/DVD drive sources and also include local hard drives. This is an optional list of sources that can be used if the last used source is not available. By default it does not have additional (more than one) sources listed.


This option only appears in the log if the /Full switch is enabled. Features and the current FeatureState (in brackets) are shown in a sorted structure. For example:

Converter12Dependencies (Local)
      Oice_QFE (Local)
Converter12DependenciesIntl_1033 (Local)
      ExcelConverter12Files (Local)
      ExcelConverter12Intl_1033 (Local)
      PPTConverter12Files (Local)
      PPTConverter12Intl_1033 (Local)
      WordConverter12Files (Local)


Who can I contact for questions on ROIScan.vbs?

For ROIScan.vbs script support issues, send an email message to

Does the script cover Office server products?

Yes, the ROIScan.vbs script also works on Office server products.

Is the script 64-bit aware?


On Windows Vista the script always reports the Web Folders Update as "Office application without entry point in Add or Remove Programs - Microsoft Software Update for Web Folders (English) 12 - {90120000-0010-0409-0000-0000000FF1CE}"

This is a known issue that occurs when the following update is applied to computers that run Windows Vista: Description of the Software Update for Web Folders: May 18, 2007 (KB 907306 at

Does the script run with user privileges or do I have to be an administrator?

The ROIScan.vbs script requires Administrator privileges and must be run as Administrator on computers that run Windows Vista and later versions of the Windows operating systems.

On Windows Vista the script always shows errors

The ROIScan.vbs script must be run from an elevated command prompt on computers that run Windows Vista.

I get a Windows Script Host error

Error: Windows Script Host - Can't find script engine "VBScript" for script "ROIScan.vbs".

Cause: This error indicates that the VBScript.dll is not registered.

Resolution: To resolve this issue, you must register the VBScript.dll.

To register the VBScript.dll

  1. Click Start, click Run, and then type the following command:

    regsvr32 %windir%\system32\vbscript.dll

  2. Press Enter.

    A RegSvr32 message is displayed: "DllRegisterServer in C:\Windows\system32\vbscript.dll succeeded."