Deploying Microsoft Office 2016: Building the Task Sequence in System Center Configuration Manager for Reliable Deployment

It’s time to wrap up this series on Office 2016 deployment. We’ve built several prerequisite application packages, some Global Conditions, and the Office application package itself. Because Microsoft recommends not installing multiple versions of Office together and because Office Setup cannot remove all components of previous versions, we built a Configuration Manager package with all of the OffScrub scripts from Microsoft Product Support Services to allow reliable removal of previous versions.

The application package we built last time brought everything together except the Offscrub package. That application package is useful for an operating system deployment task sequence or to device collections where you know that no member device has a version of Office already installed. To have reliable installations of Office 2016 with no previous versions, we need to add one more component: a task sequence.

Building the Configuration Manager Task Sequence

Create a custom task sequence. Do not specify a boot image. Assuming that you are installing multiple Office programs, here is a suggested name and description:

Name Office Family 2016 (32-bit) [Remove existing]
Description Removes previous versions of Office programs and then installs Office, Project, and Visio 2016 and all of their prerequisites.

You will have to give some careful thought to the content of these fields; both of them have rather short length limitations that prevent more accurate descriptions than what is shown above.

Right-click the newly-created task sequence, and click Edit. Now I will describe each step you should add to the task sequence.

Step 1: Start Software Center after restart

Type Run Command Line
Name Start Software Center after restart
Description Software Center must be running in order for progress to be displayed. The intrinsic “start” command of cmd.exe must be used; otherwise, Software Center will start on sign-in, but the desktop will not be loaded until it is closed.
Command line "%SystemRoot%\System32\reg.exe" add "HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v "!SoftwareCenterForOffice2016TS" /t REG_SZ /d "\"%SystemRoot%\System32\cmd.exe\" /C \"start \"Starting Software Center...\" \"%SystemRoot%\CCM\SCClient.exe\" softwarecenter:\"" /f /reg:64
Disable 64-bit file system redirection Checked

This step ensures that Software Center is restarted automatically the next time someone signs in. This is important to show status to the user in case the task sequence is being run. The exclamation point prefix on the RunOnce registry value defers deletion of the value until after the command has completed successfully. That means that the command will not be deleted if it fails, and it will therefore by tried again the next time the RunOnce key is evaluated.

Step 2: Restart the computer

Type Restart Computer
Name Restart Computer
Description The “/Force” switch is being passed to all of the OffScrub scripts. This kills running Office programs and will thus cause data loss of any unsaved files. Restart to prevent this from happening.
Specify what to run after restart The currently installed default operating system
Notify the user before restarting Checked
Notification message Microsoft Office 2016 will be installed, and old versions of Office will be removed. The computer must restart to continue. Please save your work and close all programs. This upgrade process requires multiple restarts. You may sign into the computer after it restarts in order to view progress, but do not attempt use any programs until this process is complete.

As the description says, the OffScrub scripts will all forcibly terminate any running Office application without prompting the user to save data. If a user runs this task sequence manually, this delayed restart step informs the user what is happening and gives him or her time to save data.

Step 3: Remove old versions of Office

Type Group
Name OffScrub
Description Remove old versions of Microsoft Office.

We’ll call all of the OffScrub scripts from inside this group.

Step 3a: Remove Office 2003

Type Install Package
Name Remove Office 2003
Description Runs OffScrub03 script from Microsoft Support.
Install a single software package Selected
Package Microsoft OffScrub
Program OffScrub03

Step 3b: Remove Office 2007

Add a step to remove Office 2007 just like the one for Office 2003, replacing property values as appropriate.

Steps 3c and 3d: Remove Office 2010

Add a step to remove Office 2010 just like the one for Office 2003, replacing property values as appropriate. Then, make a copy of it so that there are two identical steps that remove Office 2010. Make the following changes:

  • Change the description of the first one to:
    Runs OffScrub10 script from Microsoft Support and continues on errors. OffScrub10 uses non-zero exit codes for informational reporting, which are interpreted by ConfigMgr to be errors.
  • Set the first one to Continue on error (on the Options tab).
  • Change the name of the second one to:
    Remove Office 2010 (retry).
  • Change the description of the second one to:
    Runs OffScrub10 script from Microsoft Support again and fails on errors. OffScrub10 uses non-zero exit codes for informational reporting, which are interpreted by ConfigMgr to be errors.
  • Add a condition to the second one (on the Options tab):
    Task Sequence Variable _SMSTSLastActionSucceeded equals “false”

Microsoft was consistent in the return values for all of the OffScrub scripts except for the one for Office 2010. In this one, some non-error conditions are reported back via the script’s exit code, and unfortunately there is no way to specify success values for ConfigMgr package programs. The approach I chose was to run the script once ignoring errors, and then run it again, if needed, failing on errors (thus causing the task sequence to stop).

If the first run of the script is successful and returns 0 (zero), the task sequence will record “true” in the _SMSTSLastActionSucceeded variable, and the second run of the script will be skipped due to the condition.

If the first run of the script is successful and returns a non-zero informational value, the task sequence will record “false” in the _SMSTSLastActionSucceeded variable, and the second run of the script will be executed, but it will have nothing to do and so will finish quickly, returning 0 (zero) because it has no special information to report.

If the first run of the script fails and returns a non-zero failure value, the task sequence will record “false” in the _SMSTSLastActionSucceeded variable, and the second run of the script will be executed. Assuming the script runs into the same problem that it did during the previous try, it will fail again, but this time the task sequence engine will see the failure and stop the task sequence.

Step 3e: Remove Office 2013

Add a step to remove Office 2013 just like the one for Office 2003, replacing property values as appropriate.

Step 3f: Remove Office 2016

Add a step to remove Office 2016 just like the one for Office 2003, replacing property values as appropriate.

Step 3g: Remove Office Click-to-run

Add a step to remove Office Click-to-run just like the one for Office 2003, replacing property values as appropriate.

 

Back outside of the OffScrub group, we’re ready to start installing software. The instructions below install all of the Office prerequisites as separate task sequence steps. This provides better feedback to the user as to what is happening and should make it easier to follow along in the logs if something goes awry.

New Install Application steps have a Retry this step if computer unexpectedly restarts checkbox checked and the number of times to retry set to 2 on the options tab. Leave these default settings for all Install Application steps added below.

Step 4: Install .NET 3.5 SP1

Type Install Application
Name Install .NET 3.5 SP1
Description Leave blank.
Install the following applications Add the .NET Framework 3.5 SP1 application package that we created earlier as the only item in the list.

Step 5: Start Software Center after restart

Copy the Start Software Center after restart step from the top of the task sequence and paste it here.

In my testing, installing the .NET Framework 4.x required a restart for completion, so we’ll set up Software Center to start again after that installation and restart is complete. At the very end of the task sequence, we’ll delete this registry value if it is still present. This would be the case if the computer already had .NET 4.5.2 or higher installed prior to running this task sequence.

Step 6: Install .NET 4.5.2 or higher

Type Install Application
Name Install .NET 4.5.2 or higher
Description Leave blank.
Install the following applications Add the .NET Framework 4.5.2 or higher application package that we created earlier as the only item in the list.

Step 7: Install Report Viewer 2008

Type Install Application
Name Install Report Viewer 2008
Description Microsoft Report Viewer 2008 is required for Database Compare 2016, which is a companion program to Access 2016.
Install the following applications Add the Microsoft Report Viewer Redistributable 2008 (KB971119) application package that we created earlier as the only item in the list.

Step 8: Install Office Professional Plus 2016 (32-bit)

Type Install Application
Name Install .NET 3.5 SP1
Description Leave blank.
Install the following applications Add the Microsoft Office Professional Plus 2016 (32-bit) application package that we created earlier as the only item in the list.

Steps 9 and 10: Install Visio and Project

Add Install Application steps for the Visio and Project application packages that we created earlier. These will be much like the Office installation step above.

Step 11: Install Software Updates

Type Install Software Updates
Name Install Software Updates
Description Leave blank.
Install software updates assigned to the destination computer All Software Updates

Step 12: Remove RunOnce value to start Software Center

Properties tab
Type Run Command Line
Name Remove RunOnce value to start Software Center
Description If the OS was fully patched (including having .NET 4.5.2 or higher installed) prior to running this task sequence, no restarts may have been triggered since the last “Start Software Center after restart” step, so remove the registry value if it is present.
Command line "%SystemRoot%\System32\reg.exe" delete "HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v "!SoftwareCenterForOffice2016TS" /f /reg:64
Disable 64-bit file system redirection Checked
Options tab
Success codes 0 1

That’s the number zero, followed by a space, followed by the number one.

Continue on error Checked

The description field contents pretty much explains what this is doing. Note the changes to the Options tab, though. If reg.exe deletes the value successfully, it returns 0 (zero). If the value is not there, though, it returns 1. Since we just want to run the command and consider it successful no matter what, we need to set 0 and 1 as valid success codes as shown above. As insurance that some other unknown error condition won’t cause the task sequence to register as a failure, we also check the Continue on error box.

Advice

That’s it! Running this task sequence will ensure that target machines have exactly one version of Microsoft Office—Office 2016—and that all of its prerequisites are present. You will want to think carefully about how you deploy it. If your users are conditioned to sign out at the end of each work day, you may be able to deploy the task sequence as required for a specific time overnight without many problems. If users typically leave their computers turned on and signed in, with unsaved data open in various applications, you may want to just deploy the task sequence as “Available”, and then notify users via e-mail that they can run the task sequence themselves from Software Center. Running it manually will give users the warning that the computer will be restarted and give them time to save their data.

Be advised that in my testing, this task sequence took a minimum of 30 minutes to run and typically took quite a bit longer; just installing the updates takes a while. If users will run the task sequence themselves, I suggest advising them to begin the task sequence before going to lunch or before leaving for the day. If you know that your environment doesn’t have certain versions of Office, you could disable the corresponding OffScrub step(s) in order to save time. For example, I don’t think there are any Office 2003 installations remaining in my organization, so I disabled that step. Further, we no longer have a site license for Project, so I removed it. With those changes, here is what my task sequence looks like this:

Picture of Task Sequence Editor window

 

Deploying Microsoft Office 2016: Building the Application Package in System Center Configuration Manager

It’s been a long process, but it’s finally time to build the Application objects in System Center Configuration Manager for Microsoft Office and its sibling programs. There is just one bit of housekeeping to take care of first. One of my rules for a Configuration Manager Application is that it must have an uninstallation command. This provides Software Center with the ability to remove it, thus giving users an “app store” experience. That takes a little bit of work, and so we’ll do that first. Then we’ll walk through the Application-building process. Next time, we’ll use our new Applications along with our Offscrub package to build a task sequence for deployment.

Silent Uninstallation

As we did in the Customizing Setup post, we will consult the Office 2013 documentation to help us. The Setup command-line options reference for Office 2013 on TechNet has a helpful section describing uninstallation. Basically we need to use a custom config.xml file to instruct the setup program to perform a quiet uninstallation. This documentation doesn’t mention it, but because Configuration Manager Applications must not initiate a reboot, I’m going to add the SETUP_REBOOT property with a value of “Never” in order to be certain that the uninstallation process will not restart the computer unexpectedly. (You may recall that we added this property to the customization file for installation, but we don’t have a customization file for uninstallation.) To do that, we’ll use the Setting element of config.xml.

Open your favorite text editor, and save the following text as UTF-8. I named my file “Config-ProPlus2016-Silent-Uninstall-2016-02-22.xml” in the root of my deployment folder: \\fileserver\software$\Microsoft\Office Professional Plus 2016 (32-bit).

You can quickly create the needed files for other products in the Office family by changing the Product attribute of the Configuration element. Open the config.xml file located inside each product’s folder to obtain the appropriate value for that product. For example, for Visio Professional, look at the vispro.ww\config.xml file, and find that the Product attribute must be “VisPro”.

Warning: Don’t change the existing config.xml files in the installation source. Office Setup uses these files during installation, so our uninstallation settings must be saved elsewhere.

Building the Configuration Manager Application

Building the Configuration Manager Application for Office is a two-pass process. First, we’ll point ConfigMgr to the product MSI so that as many properties as possible populate automatically. Then we’ll go back and edit the Application to add our uninstallation command, prerequisite applications, and system requirements.

  1. In Configuration Manager Console, in the Software Library workspace, navigate to Overview > Application Management > Applications.
  2. In the ribbon, click Create Application. The Application Wizard will appear.
  3. On the General – Specify settings for this application page, select Automatically detect information about this application from installation files, and choose Windows Installer (*.msi file) as the Type.
  4. In the Location box, type the network path to the specific product’s MSI file under your installation source. For example, the MSI file for 32-bit Office Professional Plus is located in the proplus.ww folder. In my installation source, it is
  5. Click Next, and then click Next again to begin customization.
  6. Fill out the Specify information about this application page. This is where we supply Office Setup with our Office Customization Tool settings as well as our uninstallation settings. Although Office has a Windows Installer-based setup process, using setup.exe is required. Run setup /? to see all of the options. Keeping in mind that our example is 32-bit Office Professional Plus 2016, here are the settings.
    Name Microsoft Office Professional Plus 2016 (32-bit)
    Publisher Microsoft
    Software version 2016 (32-bit)
    Installation program setup.exe /adminfile "OCT-ProPlus2016-x86-Silent-Install-2016-02-22.MSP" /config "proplus.ww\config.xml"
    Run installation program as 32-bit process on 64-bit clients. Checked
    Install behavior Install for system

    Because we combined multiple products into one installation source, Office Setup does not automatically know which product we want to install. The /config switch and its argument provide this information to Setup so that the user is not prompted.

  7. Click Next, and verify that the settings are correct.
  8. Click Close to exit the wizard.

Double-click the newly-created Application object to open it. Now we’ll change additional settings that weren’t available in the wizard.

  1. On the General tab, check the Allow this application to be installed from the Install Application task sequence action without being deployed.
  2. On the Application Catalog tab, next to the Icon label, click Browse… Navigate to the Office installation source folder, and choose setup.exe. Select its only icon as the icon for this Application. Although this setting is on the Application Catalog tab, the icon will also appear in Software Center. This adds a level of professionalism to the Application package and makes Software Center seem more like a well-put-together app store.
  3. On the Deployment Types tab, select the deployment type and click Edit.
  4. On the Content tab, in the Content location box, remove the specific product folder from the path. In this case, that means deleting proplus.ww so that the path is \\fileserver\software$\Microsoft\Office Professional Plus 2016 (32-bit)\. (Configuration Manager used the longer path because we initially pointed it to the MSI file, but we really need the whole folder structure.)
  5. On the Programs tab, type the following into the Uninstall program text box:
  6. On the Requirements tab, add the system requirements we obtained in the Overview and Prerequisites.
    Requirement Type Operator Values
    CPU speed Greater than or equal to 1000 MHz
    Total physical memory Greater than or equal to 2000 MB
    Free Disk Space of system drive Greater than or equal to 3000 MB
    Operating system One of Windows 7 SP1 (64-bit), Windows 7 SP1 (32-bit), Windows Server 2008 R2 SP1 (64-bit), All Windows 8 (64-bit), All Windows 8 (32-bit), Windows Server 2012, All Windows 8.1 (64-bit), All Windows 8.1 (32-bit), Windows Server 2012 R2, Windows 10
    OS Installation Type Not equal to Server Core
    Internet Explorer Version Begins with 11.
    (Note that the period is included in the value: “11.”)
  7. On the Dependencies tab, add a dependency group with the name .NET Framework 3.5, and add the 32-bit deployment types from the Microsoft .NET Framework 3.5 Application package that we created earlier. That should be nine deployment types: two each (32-bit and 64-bit) for Windows 10 v1511, 10 Release, 8.1/2012 R2, and 8/Server 2012; and one for all bitnesses of Windows 7/Server 2008 R2.
  8. Add a dependency group with the name .NET Framework 4.x, and add both deployment types from the Microsoft .NET Framework 4.5.2 or higher application package that we created earlier.
  9. Add a dependency group with the name Report Viewer, and add the single deployment type for the Microsoft Report Viewer Redistributable 2008 Application that we created earlier.
  10. Click OK until you have dismissed the Application’s Properties window.

Congratulations! Now you have an Office 2016 application package suitable for deploying during operating system deployment with a task sequence. Unfortunately, all the work we have done up to this point is still not quite enough to have a reliable deployment of Office on existing computers with a previous version of Office already installed. Do not–I repeat, DO NOT–deploy this application package to your whole company. If you do, you will have a bad time. Why? See my previous post on removing old versions for the answer. For now, you can go ahead and use this application in new deployments, but you’ll have to tune in next time to get the solution for existing installations.

Other Programs in the Office Family

You can follow the same general procedure to package the other Microsoft Office-family products we included in our source folder structure. Make a separate Configuration Manager Application for Visio and Project Standard. Include all of the same system requirements and dependencies except for Report Viewer which can be omitted.

Coming Up

The next post is the last one in the series on deploying Microsoft Office 2016. In it, I will explain how to use everything we’ve built to provide a reliable delivery of Office 2016 in your organization regardless of whether an existing Office installation is present.

<update date=”2017-07-11″>Corrected HTML encoding errors in code samples.</update>

Deploying Microsoft Report Viewer Redistributable 2008 with System Center Configuration Manager

Microsoft Office 2016 has a prerequisite that is not mentioned in the system requirements. If you want to use the Database Compare 2016 program to compare Microsoft Access databases, you must have the Report Viewer Redistributable 2008 installed, or you will get a most unhelpful error message.

On you application staging file share (wherever you put application source files for Configuration Manager to find), create a folder for Microsoft Report Viewer Redistributable 2008 with Service Pack 1. Mine will be \\fileserver\software$\Microsoft\Report Viewer 2008 SP1 GDIPLUS.DLL Security Update (KB971119).

Download the executable installer from the Microsoft Download Center, and then extract its content into the folder you just created: Report Viewer Redistributable 2008 Service Pack 1 GDIPLUS.DLL Security Update. Using the folder path I stated above, run the following command at an elevated command prompt: ReportViewer.exe /x:"\\fileserver\software$\Microsoft\Report Viewer 2008 SP1 GDIPLUS.DLL Security Update (KB971119)".

Property Value
Application Properties
Name Microsoft Report Viewer Redistributable 2008 (KB971119)
Publisher Microsoft
Version 2008 (KB971119)
Deployment Type Properties
Name Microsoft Report Viewer Redistributable 2008 (KB971119) – Windows Installer (*.msi file)
Technology Windows Installer (*.msi file)
Content location \\fileserver\software$\Microsoft\Report Viewer 2008 SP1 GDIPLUS.DLL Security Update (KB971119)
Installation program install.exe /q /l “%TEMP%\reportviewer2008KB971119installationlog.txt”
Uninstall program msiexec /x {CED243AB-C7BA-3D42-9609-14EF5A6FC601} /q
Detection method MSI Product Code: {CED243AB-C7BA-3D42-9609-14EF5A6FC601}
Installation behavior Installation behavior: Install for system
Logon requirement: Whether or not a user is logged on
Installation program visibility: Hidden
Configuration Manager behavior: Determine behavior based on return codes
Requirements None
Dependencies .NET 2.0 SP2 (See below for details.)

Note that although the extracted files are still installed with an executable, deep down, the installer is actually an MSI. I was able to find the MSI’s product code and create an MSI deployment type using that information. For now, I’ll leave it as an exercise for the reader to figure out how to do this, but I may revisit the topic in the future. In any case, I provided the product code above, so you don’t need to go searching for it.

Report Viewer requires .NET 2.0. Since .NET 2.0 is basically a sub-component of .NET 3.5, and since .NET 3.5 SP1 is the minimum supported .NET version on all of our supported platforms except for Windows 7, the most economical way to proceed is to just reuse the .NET Framework 3.5 application package that we already built as a dependency (prerequisite) for this application package. On the Dependencies tab, click Add…, and give the new dependency the name .NET 2.0 SP2. Then (still in the Add Dependency dialog window) click Add… and select all nine of the deployment types from the .NET Framework 3.5 application package.

Coming Up

Now we have all of the prerequisite application packages built and our custom installation settings defined. Next time, we’ll put everything together to build a set of Configuration Manager Applications for 32-bit and 64-bit versions of Office, Project, and Visio!

Building a Global Condition in System Center Configuration Manager to Test the Internet Explorer Version

In the first post of this series, I listed the system requirements for Microsoft Office 2016. Those requirements included “The current or immediately previous version of Internet Explorer; the current version of Microsoft Edge, Safari, Chrome, or Firefox” as the browser requirements. Let’s simplify this to a minimum requirement. Since our Office 2016 application package will target Windows operating systems, we can guarantee that some version of Internet Explorer will be present. Our prerequisite logic for our Office 2016 application package can therefore focus on IE and ignore the other available options.

At the end of the overview post for this series, I wrote the following:

Windows 10, 8.1, and Server 2012 R2 have Internet Explorer 11 built in; Windows 8 and Server 2012 have Internet Explorer 10 built in. Both of these IE versions satisfy the requirements. For Windows 7 and Server 2008 R2, we’ll either have to build an IE11 application package or set a condition that checks for IE10 or IE11. My initial thought is to just set a condition because if any Windows installation is on an old version of IE at this point (January 2016), then the user or administrator has specifically blocked it from being installed in Windows Update as well as in the settings of IE itself, and so we should respect that decision and just fail the Office installation. (If I change my mind about this, you’ll find out in a future post.)

Well, I haven’t changed my mind! The day after I published that post, Microsoft ended support for Internet Explorer 10, leaving IE11 as the only supported version.

Microsoft aggressively pushes out Internet Explorer updates, and as I mentioned in the quoted passage above, any machine with IE10 or earlier is purposely configured that way, and our deployment package should not try to overcome that situation. (Alternatively, the computer may be misconfigured, or Windows Update functionality may be broken in some way; in either of these cases, it is better to fail our Office deployment and let the problem get addressed rather than try to resolve the issue in an automated way.) Based on this reasoning, rather than building another prerequisite application package for IE11, we will merely test that it is installed with a new Global Condition.

Microsoft documents several ways to determine a Windows installation’s Internet Explorer version in KB969393: Information about Internet Explorer versions. Fortunately, there is a registry value that will work nicely, and fortunately, even though this value is a string, we can test it with a “Begins with” verb when using it as an Application requirement.

As with our Server Core test, this Global Condition will be a simple query of a registry value. In Configuration Manager, in the Software Library workspace, navigate to Application Management>Global Conditions. I named my Global Condition “Internet Explorer Version”, and here are its properties:

Property Value
Name Internet Explorer Version
Description Returns the version of Internet Explorer 10 or 11 from the registry. The queried registry value (svcVersion) is not present when IE9 or earlier is installed. Use this to test the major version with the “Begins with” verb and a value of either “10.” or “11.”.
Device type Windows
Condition type Setting
Setting type Registry value
Data type String
Hive name HKEY_LOCAL_MACHINE
Key name SOFTWARE\Microsoft\Internet Explorer
Value name svcVersion
This registry value is associated with a 64-bit application Unchecked

Coming Up

In a later post in this series, we’ll use this Global Condition with the verb “Begins with” and value “11” in the requirements of our Office application package to ensure that IE11 is installed. Next time, we’ll study a pitfall of Microsoft’s Office setup program.

Building a Global Condition in System Center Configuration Manager to Test for Server Core

When specifying requirements for an application package, Configuration Manager doesn’t provide a way to differentiate between full installations and Server Core installations of Windows Server 2012 and higher, but we may sometimes need to know this in order to choose between deployment types or to prevent installation of an application altogether. This is a job for: a new Global Condition!

Microsoft was good enough to provide documentation: Determining Whether Server Core Is Running. We’ll use the registry option described on that page.

In Configuration Manager, in the Software Library workspace, navigate to Application Management>Global Conditions. I named my Global Condition “OS InstallationType”, and here are its properties:

Property Value
Name OS InstallationType
Description Returns the OS installation type from the registry. Possible values: Client, Server, Server Core.
Device type Windows
Condition type Setting
Setting type Registry value
Data type String
Hive name HKEY_LOCAL_MACHINE
Key name SOFTWARE\Microsoft\Windows NT\CurrentVersion
Value name InstallationType
This registry value is associated with a 64-bit application Unchecked

Coming Up

Next time, we’ll use this new Global Condition to specify an installation requirement for a Configuration Manager Application deployment type.

Building a Global Condition in System Center Configuration Manager to Test the Windows Build Number

Configuration Manager doesn’t provide a way to differentiate between releases of Windows 10 when specifying requirements for an application package, but the Microsoft .NET Framework 3.5 feature source file differs between the two builds available at the time of this writing. (This may be true of all of Windows 10’s Features on Demand, but I haven’t checked any others.) We will also need a way to tell different releases of Windows 10 apart when installing .NET Framework 4.6.1. Therefore, we must make a custom Global Condition to provide the needed functionality for our application packages.

We need to find some attribute of the operating system that is unique between Windows 10 releases to test in our Global Condition . It turns out that Windows Management Instrumentation (WMI) has a property that we can use: the BuildNumber property of the Win32_OperatingSystem class. This returns—you guessed it—the Windows build number. Even though the build number is, well, a number, WMI defines this property as a string, so keep this in mind if you want to do value comparisons. For example, 10 > 9 (numeric comparison) but “10” < “9” (string comparison).

Global Conditions in Configuration Manager are located in the Software Library workspace under Application Management. I named my Global Condition “OS BuildNumber”, and here are its properties:

Property Value
Name OS BuildNumber
Description Returns the Windows build number from WMI.
Device type Windows
Condition type Setting
Setting type WQL Query
Data type String
Namespace root\cimv2
Class Win32_OperatingSystem
Property BuildNumber
WQL query WHERE clause None (leave blank)

Coming Up

Next time, we’ll use this new Global Condition to specify an installation requirement for a Configuration Manager Application deployment type.