Upgrading to Office 2016/365 using a ConfigMgr Task Sequence

Earlier this year I did a presentation at the Central Texas Systems Management User Group (CTSMUG) in Austin on migrating our company to Office 2016 (MSI).  I have provided a link to my Sway of that presentation for some general context however this blog post will be a more technical explanation of how I went about upgrading all our systems to Office 2016.


  • Working knowledge of ConfigMgr 2012/Current Branch Task Sequences.
  • An existing Application/Package for installing Office 2016/365, Visio, Project, etc. (If you need assistance with this, there is plenty of guidance here and here)

Before we get going, we need to create a new package called “Office 2016 Upgrade Files”.  This package will consist of detection scripts, Office Scrub scripts and any other custom code used for your overall upgrade process.  (NOTE: This package should NOT contain any of the actual Office installer binaries).

New-CMPackage -Name 'Microsoft Office 2016 Upgrade Files' -Path '\\SERVER\SOURCES\Microsoft Office 2016 Upgrade Files'


Start by downloading the following scripts:

  • Get-MSOfficeProducts.ps1 – I developed this script to detect as many Microsoft Office (non-server) products that I had in my environment (NOTE: The language packs section needs improvement to cover more languages).
  • IME14-Cleanup.ps1 – This cleans up registry keys associated with the Office IME (Input Method Editor).

Next, use the “Easy Fix Download” link to obtain and extract the Office Scrub scripts for Office 2010+

Task Sequence – Detection

Start out by creating a new (empty) Custom Task Sequence.  The first stage of our Task Sequence will include detecting the software currently installed on the system.  This is broken out (generally) into two different groups.

  • Microsoft Office Suites and Applications (i.e. Visio, Project, Language Packs)
  • Office-Dependent Applications – Other software packages that have a dependency on one or more Office applications that may need special attention (reinstall) during an Office upgrade.



The next section will contain various scripts and command lines that we’ll use to remove Office-Dependent products and Office itself. First off, create a group (generally via WMI query or a file check) to detect and remove each application.  Be sure to add a custom Task Sequence variable as indicated in the screenshot above so you can use that to re-install the software later.

You “CAN” upgrade Office in-place without removing previous suites, however I always run into legacy shared components that get left behind.  When these are left behind, the system still  downloads ALL of the updates for the full suite (including service packs) so I prefer to perform a rip and replace of the Office suite.

Once you have removed the Office-Dependent applications, the next set of steps will systematically remove Microsoft Office.  I’ll list this out in order of how we did it as we had excellent success with this specific order of operations no matter what the system had installed.

  1. Remove Microsoft Office – This uses the Get-MSOfficeProducts.ps1 script from the Detection step but with the added –Uninstall parameter.  This step works well to remove Office 2003 components and some of the newer components using standard methods. NOTE: There is an Office Scrub script for Office 2003 available however I never verified that it worked. image
  2. Uninstall Office 2007 – I used the main Office 2007 Professional Plus installation media with custom Uninstall XML files to remove SharePoint Designer, Proofing Tools and the rest of the suite (in that order) since I already had the original package used to install it.  I’m not doing anything else related to Visio/Project or Language Packs during this section. NOTE: There is an Office Scrub script for Office 2007 available however I never verified that it worked. image
  3. Uninstall Office 2010/2013/2016 – Microsoft has published “scrub” scripts for each version of Office that work incredibly well.  Set these up as Run Command Line Steps in your Task Sequence with the following Command Line parameters for each:

Scrub Office 2010

cscript.exe OffScrub10.vbs ALL /log "C:\Windows\Temp" /quiet

Scrub Office 2013

cscript.exe OffScrub15.vbs ALL /log "C:\Windows\Temp" /quiet

Scrub Office Click-To-Run – Use this if you are installing Office 2016 MSI

cscript.exe OffScrubc2r.vbs ALL /log "C:\Windows\Temp" /quiet

Scrub Office 2016 – Use this if you are installing Office 365 Click-To-Run

cscript.exe OffScrub16.vbs ALL /log "C:\Windows\Temp" /quiet

NOTE: The scrub scripts run twice as sometimes the scrub fails due to a corrupted installation.  Running it twice typically takes care of things.

NOTE: You’ll want to run the Office 2016/C2R scripts to remove any potentially conflicting applications before installing Office.  C2R and MSI (2016) builds cannot co-exist.

Install Office 2016/365

Before you start installing Office 2016/365, consider rebooting the system.  This can often be required if you had to remove other Non-Office applications as part of your upgrade path.

I’m using the Application Model for all Office installers.  I have separate applications for the Office Suite separating 32-bit/64-bit.  All other Office components have both 32-bit and 64-bit within the same application.

During this section is where we will leverage the Task Sequence variables created by the Get-MSOfficeProducts.ps1 script to determine which components to reinstall.

Microsoft Office ProPlus Suite (32-bit/64-bit)

Use the MsOfficeSuiteArch TS Variable to determine which architecture of Office to install.


Microsoft Project (Standard/Professional)

Use the MsProjectStd or MsProjectPro TS Variables to determine if Project Standard or Professional needs to be reinstalled.


Microsoft Visio (Standard/Professional)

Use the MsVisioStd, MsVisioPrm or MsVisioPro TS Variables to determine if Visio Standard or Professional needs to be reinstalled.


Microsoft Proofing Tools Kit

Use the MsProofKit TS Variable to determine if the Proofing Tools Kit needs to be reinstalled.


Microsoft Office Language Packs

We use the Application Model for installing Office Language Packs.  These are separated by Language, and contain Deployment Types for each Office Version/Architecture to make things easy (for us and the end user).  Take note of the priority order.


Use the following TS Variables for Language selection:

  • MsLpChinese
  • MsLpCzech
  • MsLpDanish
  • MsLpDutch
  • MsLpFrench
  • MsLpGerman
  • MsLpHebrew
  • MsLpItalian
  • MsLpKorean
  • MsLpPolish
  • MsLpRussian
  • MsLpSpanish
  • MsLpSwedish


Re-Install Additional Applications

Here is where we begin reinstalling all of our Non-Office applications back onto the system.  This could either be a simple re-install, configuration change, or an update to an application to enable compatibility with the Office 2016 suite.

License Activation

We ran into some issues with KMS activation during our upgrades (using the MSI installer) so we added in the necessary ospp.vbs commands to activate Office in an attempt to “force” activation immediately after installation.  This reduced the number of helpdesk calls we received when activation took longer than normal.imageEnd Notification

Finally, we end the deployment by forcing a machine policy update, copying off log files and notifying the end user that the upgrade is complete (Notification HTA runs via the RunOnce registry key).

IE Enterprise Mode Edge Redirect Overwritten by ConfigMgr Client Settings

Like most companies out there, my company is getting ready to migrate to Windows 10.  As part of our migration, we are using IE Enterprise Mode to handle many legacy web applications to ensure our end users get the best experience possible, and reduce the manual effort to ensure they are using the proper browser (and browser mode).

IE Enterprise Mode includes the ability to automatically re-direct sites from Microsoft Edge to Internet Explorer on Windows 10.  This is fantastic for those who choose to use Edge as their default browser (as I do).

This post will not be covering exactly HOW to implement IE Enterprise mode as there is plenty of that documentation out there on the web.  Instead, I’ll be focusing on a recent discovery that my colleagues and I made.


You’ve spent the last several months working with business partners to come up with a customized MS Edge redirect XML file and are ready to implement the file via GPP (or Compliance Settings or any other method you choose to set the registry key).  You choose to set this on a Per-User basis because you want it to follow the user, not the machine (don’t ask why, just assume this is the reason).

The registry key that gets configured with your custom MSEdge xml file is at:



In addition to the above, you are running System Center Configuration Manager build 1602 (v1511 may also be affected – see below).


You expect this new XML file to redirect your custom LOB apps, but it doesn’t.  Upon further inspection within Edge (HINT: Use about:compat in the URL bar of Edge), you ONLY see entries for your site server (specifically the server hosting the Application Catalog site).

The Solution

I messaged David James (@djammer) on the ConfigMgr Product Team to confirm that the ConfigMgr Client Settings to add the Application Catalog URL in Trusted Sites is, indeed, using an MS Edge redirect XML file similar to that from IE Enterprise Mode.


As you can see from that last tweet, the solution (workaround really) is to set the reg key using the same path in the HKEY_LOCAL_MACHINE hive instead of HKEY_CURRENT_USER.  Doing so allows your custom IE Enterprise Mode XML file to load and not be overwritten.

This can be verified by looking at SoftwareCatalogUpdateEndpoint.log and looking for this



I hope this information can help someone else out there.  IE Enterprise Mode and ConfigMgr are awesome products and will be integral to a successful migration.

SCCM 2012 Migration: Copying Boot Image Drivers

When migrating from an older SCCM 2007 environment to SCCM 2012, one of the things that doesn’t carry over are your boot images and the drivers that go along with them. During a recent migration from SCCM 2007 to 2012 R2, I found myself in a position just like this. I created new WinPE 5.0 Boot Images however I still had the need to support Windows XP and Server 2003 for just a little longer so I needed to create WinPE 3.1 boot images to support those aging operating systems.

Since I wasn’t able to easily migrate this information over from the old environment using the built-in migration tool, I took to PowerShell to make my own.

Here the gist of the script:

  1. Connect to your old SCCM 2007 Site Server and get all the drivers associated with each boot image you want to reference.
  2. Loop thru all the drivers associated with that boot image and copy the driver source to a new source directory for your new boot images in SCCM 2012 (I use a separate file share for this so I don’t accidentally overwrite something).

NOTE: I’m automatically naming the destination driver folder based on the Driver Name (excluding special characters) and Version. I’ll let DISM sort out everything else later when adding drivers to the WIM.

Here’s the script:

	[Parameter(Mandatory=$true,HelpMessage="Root Directory for Drivers to be copied too.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

	[Parameter(Mandatory=$true,HelpMessage="Your SCCM Site Server.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

	[Parameter(Mandatory=$true,HelpMessage="Your SCCM Site Code.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

	[Parameter(Mandatory=$true,HelpMessage="Boot Image Package ID.",ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]

$BootImage = Get-WmiObject -ComputerName $SCCMServer -Namespace "Root\SMS\Site_$SCCMSiteCode" -Class "SMS_BootImagePackage" -Filter "PackageID='$PackageID'"
$BootImageDrivers = $([WMI]$BootImage.__PATH).ReferencedDrivers

foreach($Driver in $BootImageDrivers){
    $SourcePath = $Driver.SourcePath
    $DriverID = $Driver.ID

    # Get SMS_Driver Detailed Information
    $SMS_Driver = Get-WmiObject -ComputerName $SCCMServer -Namespace "Root\SMS\Site_$SCCMSiteCode" -Class "SMS_Driver" -Filter "CI_ID='$DriverID'"
    $DriverVersion = $SMS_Driver.DriverVersion
    $DriverName = [System.Text.RegularExpressions.Regex]::Replace($($SMS_Driver.LocalizedDisplayName),"[^1-9a-zA-Z_]","_")

    # Create New Driver folder
    $DriverDestinationFolder = New-Item -Path "$DriverDestinationRoot\$DriverName`_$DriverVersion" -ItemType Directory

    Copy-Item -Path $SourcePath -Destination $DriverDestinationFolder -Recurse -Force -Verbose

SCCM 2012: Deploying Dell BIOS Updates using the Application Model (Updated)

UPDATE 2016-07-20: I’ve seen the comments about the download link not working.  I’ve instead made an updated script available on GitHub at https://github.com/dhedges01/Blog.  The new script uses new command line syntax as well so I’ve updated the post below to reflect those changes.

During a recent migration from SCCM 2007 to SCCM 2012 SP1, I wanted to really start taking advantage of the new Application Model for software and driver deployments. My goal was simple, to create an Application that would deploy any Dell BIOS Update, to any applicable system, and handle daisy-chaining and even reboots. All this without (much) scripting.

The process outlined below should give you a good understanding of the steps needed to create an Application and various Deployment Types with all of the necessary Detection, Requirement and Dependency Rules needed to successfully deploy Dell BIOS updates using Configuration Manager 2012.

Note: If you are reading this then you are likely familiar with my other post about Updating Dell BIOS with PowerShell.  Much of the concept and setup here is the same, however using the Application Model we get some added benefits.

  1. We only download content for our specific version.  If you have a lot of models to deal with (like I do), this really has an impact in overall download and execution times (My BIOS Update package was well over 300MB when I implemented this method).
  2. Configuration Manager 2012 now gracefully handles reboots from the Application Model meaning we only need to reference the step once in the Task Sequence.  We also don’t need to stage any subsequent updates to the local drive because we aren’t downloading ALL of the BIOS Updates.
  3. We get applicability reporting within Configuration Manager’s AppEnforce.log file which aids troubleshooting
  4. Using this model we can now more easily handle BIOS Updates from other vendors and can even deal with those pesky “Consumer” BIOS updates as well (I’m looking at you Dell XPS…).

First things first, gather up all the latest (tested) BIOS updates for the models you support and organize them (I organize them by model). Each “model” folder will end up being the Content Source location for each Deployment Type. (You could go a step further and create a Version# folder for each version of BIOS update.  But since each model will likely only have 1 or 2 applicable BIOS Updates, it’s not really necessary.)


Next up we create our custom SCCM Application. All fields are filled out manually. Make sure you use an appropriate naming convention according to your companies standards.


The next step is one that will be repeated over and over again (with a little assistance from the Copy function). We will start by creating the first of many Deployment Types. I’m going to use the BIOS updates for the Dell Latitude E6420 as my example in this post so you can see how to use dependencies in order to install “down level” updates in order.

I like to start with the lowest version number first so we can add the dependencies as we go. We’ll start off with version A05.  Provide the general items such as Name, Content Source, Installation Program, etc.

Installation Program: powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command ".\Invoke-BIOSUpdate.ps1 -UpdateFile .\E6420A05.exe -Arguments /s,/l="C:\WINDOWS\eBay_Deployments\Dell_BIOS_Update_E6420A05.log""

For the Detection Method, I chose to leverage a custom script to detect the BIOS version. This allows me to deal with those pesky “patch” updates that sometimes come out.


Here is the detection script I use:

   1: 'Change strBIOSUpdateVersion to the version you are deploying to

   2: strBIOSUpdateVersion = "A05"


   4: 'Get BIOS Version from Win32_BIOS


   6: Set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")

   7: Set colBIOS = objWMI.ExecQuery("Select * from Win32_BIOS")

   8: For Each objBIOS In colBIOS

   9:     If objBIOS.SMBIOSBIOSVersion >= strBIOSUpdateVersion Then

  10:         WScript.Echo "Detected"

  11:     End If

  12: Next

Add Requirements.

I created a custom Global Condition to echo out the Model from WMI. I use this requirement rule to ensure the Deployment Type only applies to the appropriate system type.

Here is the configured Global Condition:


And here is how it’s referenced within the Deployment Type:


Configure the User Experience.

Depending on how you configure the install command, you can have ConfigMgr handle the restart or allow the BIOS update to restart the computer. If you choose the latter, make sure you configure the appropriate return code so ConfigMgr is aware of a potential restart.


After setting up the first Deployment Type, hit the Apply button so the Deployment Type is saved within the application. Failing to do this will make it unavailable when you try to add it as a dependency.

Copy the Deployment Type and make the necessary updates to the Name, Content Source, Install Command and Detection Method. Click on the Dependency Tab and create a new Dependency Group. Then add a Dependency selecting the first BIOS update you created.


After all of the Deployment Types are created, distribute the content and deploy your new application to a test system (or you can add it into an OSD Task Sequence for testing, ConfigMgr should automatically handle the reboots and ensuring that all “down level” updates are applied in order for each model you add.


One thing I forgot to mention in this post is the ordering of Deployment Type Priority.  When an application is evaluated, the client evaluates all of the rules for each Deployment Type in order of Priority.  Once it finds an applicable Deployment Type, it executes that one, and it no longer evaluates anymore Deployment Types within that application.  So, as an addendum to this posting, here is how I have the BIOS Updates in my Application sorted by priority.


ConfigMgr 2012 Dell BIOS Application Deployment Type Priority


As you can see from the screenshot above, I am ordering the Priority of evaluation looking at the Latest BIOS Version first.  Each “down level” BIOS Update is a dependency of the next highest version.  (i.e. A17 has a dependency of A08 and A08 has a dependency of A05).  What happens here is that if the requirements for A17 are not met (version is less than A17), then A17’s dependency (A08) will then be evaluated.  If A08’s requirements aren’t met, it will evaluate A05 and so on until all dependencies are evaluated and executed (in order).  Once the dependencies are met, then A17 can execute.

The important takeaway here is make sure your highest version of BIOS Update is evaluated first because once a Deployment Type is deemed applicable, ConfigMgr stops searching for others unless they are a dependency of the one it finds first.