Deploying Office 2016 and Office Proofing Tools Kit 2016 / Office 2016 language packs with SCCM 2012 R2

I recently deployed Office 2013 SP1 (and wrote a blog post about it). Now I got the honours to do the same for Office 2016. The procedure is theoretically quite the same, but with many different bugs and gotchas. The following procedure describes how to remove any previous versions of Office and corresponding Proofing tools & language packs and replace them with Office 2016 versions. I’ll dive right into the steps:

Customizing Office 2016

• Got a copy of Office 2016 and extracted the iso. Our version is “Professional Plus” with Volume Licensing.
• Fired up a command prompt and navigated to the extracted Office directory.
• From here I ran “setup.exe /admin”  to launch the Office Customization Tool (OCT).
• Customized the OCT settings according to our needs:
  • Setup/Organization Name
  • Setup/Licensing and user interface/Use KMS client key
  • Setup/Licensing and user interface/I accept the terms in the License Agreement, Display level: None, No tick in Competition notice, Tick for Suppress modal and No cancel.
  • Setup/Remove previous installations/Remove the following earlier versions of Microsoft Office Programs/Remove all (here’s a BUG btw, more on that later on).
  • Setup/Modify Setup Properties:
    • SETUP_REBOOT, value Never
  • Features/Modify user settings:
    • used a guide from http://stealthpuppy.com/office-2013-customization/ (works very nicely with 2016 also)
  • Features/Set feature installation states:
    • Everything gets installed.
  • Additional content/Configure shortcuts
    • For some weird reason, Office 2016 by default decides to put all of the shortcuts on the start menu WITHOUT a subdirectory – splattered all over the start menu. This is fixable by editing the shortcut entries. In Fig 2. below, I’ve added the path/directory \Microsoft Office 2016. You also have to add a “[“ in Start in, otherwise you can’t close the dialog box. It’s a “feature” (bug), see: https://support.microsoft.com/en-us/kb/2797938. While editing, you can also decide which shortcuts you want to put on the Desktop. In Fig 2, I’ve chosen to put the Excel shortcut on both the Desktop ([DesktopFolder]) and in the Start menu ([ProgramMenuFolder]\Microsoft Office 2016).
  • Update: More bugs, sigh. Skype for Business shortcut launches “Skype for Business Recording Manager” instead of “Skype for Business”. I’m getting very frustrated with all the bugs. See: https://community.office365.com/en-us/f/166/t/344410. Anyways, I corrected the mistake MS has made. In Fig 3 target should definitely not be Skype for Business Recording Manger, instead it should be “Skype for Business 2016”. At least so I thought. After this “fix” (and a test-deployment), my reward was the following message:

                  

                   Fig 1. Problem with shortcut

• Only solution (as I can see it), is to force-copy a “functional shortcut icon” during deployment. With functional I mean a shortcut that has been manually created from C:\Program Files (x86)\Microsoft Office\Office16\lync.exe. (You should also remove all the Skype for Business shortcut entries in OCT).
  • This shortcut will then be deployed as a dependency. See later chapter about dependencies.

                  

                    Fig 2. Office 2016 OCT.

                  

                   Fig 3. Skype for Business – example shortcut entry.

 

 

Deploying Office 2016/Removing Office 2013/2010

The deployment part was quite straight forward after the customization part was done. Well, so I thought. Instead I got to fiddle with SCCM’s supersedence and dependencies. More on that later on. As with Office 2013, I basically followed a (very good) guide from http://www.ronnipedersen.com/2012/11/how-to-deploying-microsoft-office-2013-using-configmgr-2012/ with some changes for our environment. In this case the changes were about uninstalling Office 2013 SP1, as a fully patched Office 2013 SP1 WON’T get uninstalled even though I’ve chosen to remove previous versions in the OCT (see my (unanswered) post at https://social.technet.microsoft.com/Forums/office/en-US/a664a0c7-c6b5-40a3-9e04-f347556d39a0/office-2016-oct-bug-office-2013-doesnt-get-uninstalledremoved?forum=Office2016setupdeploy). The remove previous version-feature works with Office 2010 however, which means I don’t have to create a supersedence relation for that version (luckily).

 

Checking parameters for Office 2013 uninstallation:

In order for Office 2013 SP1 to be silently removed via SCCM before you install Office 2016, you have to be sure that the uninstall string is correct and a custom xml-file is in place. I’m already using “custom.xml” (together with OCT) for the installation part, so I’ve created a custom2.xml for the uninstallation part. (The reason for this is also a bug, see my Office 2013 deployment post). This file contains only the following information:

<Configuration Product=”ProPlus”>
<Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
</Configuration>

You’ll then use this xml file when you specify the uninstall string for Office 2013 SP1 in SCCM. See https://weikingteh.wordpress.com/2013/09/12/uninstallremove-office-2013-with-configmgr-2012/ for details. If you don’t specify a xml file, the uninstallation won’t be silent. This in turn means it won’t be successful.

 

Supersedence

With all the parameters done, you can now deploy Office 2016 using Office 2013 as Supersedence (see screenshot below):

Fig 4. Supersedence.

 

All of the fields aren’t visible in the screenshot, but the fields are:

This application supersedes the following applications:

Application: Microsoft Office 2013 SP1
Old Deployment Type: Microsoft Office Professional Plus 2013 SP1 installer
Replacement Deployment Type: Microsoft Office Professional Plus 2016 installer
Active: Yes
Uninstall: Yes (Tick in the box)

That’s it! All the other options are the same as with a regular deployment, you just add the Supersedence-information (so Office 2013 SP1 can be successfully removed while installing Office 2016). This would not be successful without having specified the correct uninstallation information/parameters for Office 2013 SP1.

A general rule of thumb when using supersedence is that you must have the correct uninstall information specified for the application that will be superseded!

 

Update! I had problems deploying Office as “available”. (“Required” was working ok though). I always got the message “Past due – will be updated”  in Software Center (see Fig 5). This on the other hand made Office upgrade itself without user interaction, which was not acceptable for a deployment that was made available (NOT required).

Fig 5. Past due – will be updated.

After some googling I found out it was related to the supersedence settings. Don’t know if you can call this a bug, but at least it was working better if I followed this advice:

“Regarding the issue where you have set the application to AVAILABLE in the deployment, however the application uninstalls and upgrades without user interaction, I have found a work around.

The cause of the problem seems to be when you are deploying an application to a collection the option “automatically upgrade any superseded versions of this application” is CHECKED and GREYED out. If you deploy the application BEFORE you have added the supersedence, this will NOT be greyed out and you will be able to leave it unchecked. Then add the supersedence rules.

Hope this helps

Kevin”

Source: https://social.technet.microsoft.com/Forums/en-US/1abcc581-1ee8-4929-8a2f-71c8843a257c/application-supersedence-not-working-as-i-want-and-expect?forum=configmanagerapps

I mentioned the word better because even now it wasn’t working 100% correct. I had to click “Install” in Software Center about 3-4 times (for all the dependent applications). This wasn’t acceptable, as the software (and all its dependencies) should install with just ONE click. Well, I found the solution to this dilemma myself – just leave one checkbox unticked. (See Fig 6).

Fig 6. Supersedence checkbox.

With all this done, the deployment was running smoothly with just one click (“Install”) in Software Center.

 

 

Customizing Office Proofing Tools Kit 2016

This is actually the exact same procedure as for Proofing Tools 2013. I’ll copy/paste the information from my previous blog post:

We are using a Proofing Tools “CD” which include all of the proofing tool languages. Proofing Tools doesn’t/can’t change the UI language btw, only check the spelling. With this CD, there’s no need to separately download each proofing tool language. After some googling I stumbled upon http://www.msfn.org/board/topic/149212-office-2010-proofing-toolkit-silent-installation/ which seemed useful. Once again I’ll share my configuration so you don’t have to scratch your own head. First off, there’s NO “setup.exe /admin” on this cd/iso. You have to manually specify the languages (proofing) you need. The file you need to edit is located on the extracted iso, in my case \Office_2016_Proofing_Tools\proofkit.ww\config.xml. My file looks like this:

<Configuration Product=”Proofkit”>

   <Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
  
   <COMPANYNAME Value=”Abo Akademi” />
      
   <OptionState Id=”ProofingTools_1053″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1030″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1035″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1036″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1031″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1032″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1040″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1044″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_2068″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1045″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1049″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1048″ State=”local” Children=”force” />
          
   <Setting Id=”SETUP_REBOOT” Value=”Never” />
  
</Configuration>

This bypasses all prompts in the setup process and installs 12 proofing languages. I’m not going to list the languages here (OptionState Id values), as there’s a table is available at: http://technet.microsoft.com/en-us/library/cc179219(v=office.15).aspx . That’s it for the configuration – now ready for deployment.

Source: http://technet.microsoft.com/en-us/library/ee942200(v=office.15).aspx plus all the forgotten ones…

 

 

Deploying Office Proofing Tools Kit 2016/Removing Proofing Tools Kit 2013/2010

Again, this information is already available in my previous blog post about deploying Office Proofing Tools 2013 SP1, so please have a look there before you continue. The difference in the 2016 version is that I will use different dependencies so that Office and the language packs will be installed before proofing tools is installed. I’ll also use Supersedence the same way I did with Office 2016 above.

 

Checking parameters for Proofing Tools Kit 2013 SP1 uninstallation:

First off, I’ll copy/paste information about the installation:

Edit “programs” tab. The installation command should now include our custom.xml instead of the MSI-command. The command I used was: setup.exe /config \\sccm2012r2\Software\Office_2013_Proofing_Tools_with_Service_Pack_1\proofkit.ww\config.xml.  ( /config .\proofkit.ww\config.xml is an easier/better syntax, btw)

Ok – now you just have to add the uninstall information with a custom UNintallation xml-file. This is also the same procedure as with the Office 2016 deployment. Anyway, I created a custom2.xml file in the same location as mentioned above. It includes basically the same information as the Office 2013 SP1 uninstallation xml-file:

<Configuration Product=”Proofkit“>
   <Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
</Configuration>

…and for the uninstall program string I’m using: setup.exe /uninstall Proofkit /config .\proofkit.ww\config2.xml

There you have it. Both the install and the uninstall information are now specified. You can now go ahead and make the same Supersedence rules as with the Office 2016 deployment:

Fig 7. Office 2016 Proofing Tools Kit – Supersedence.

Only thing that isn’t fully visible in the screenshot above is Application: Microsoft Office Proofing Tools 2013 SP1 – multilanguage.

 

You can now do the same thing with Office 2010 (proofing tools) if you want to uninstall/remove that version prior to installing proofing tools 2016. You’ll then add another supersedence rule so that BOTH Office 2010 proofing tools AND Office 2013 proofing tools will be superseded (both should then be in the list in Fig 7).

(I also specified the uninstallation information for Office 2016 (proofing tools) already, so I can (hopefully) use the same procedure with future versions of Microsoft Office).

 

 

Deploying Office 2016 language packs/Removing Office 2013/2010 language packs

Some people are also using language packs with Office so I had to figure out a way of uninstalling/replacing these with the 2016 versions. Luckily, Microsoft is using quite the same syntax as with proofing tools, so the task was actually quite simple. You start with the same procedure – checking for a valid config.xml file for installation and uninstallation. The difference here is that you don’t need any specific codes for the language(s), as one language pack only installs one specific language. Another nice thing is that you can use the SAME xml file for both the installation and the uninstallation. The custom.xml for the Swedish language looks like this for example:

<Configuration Product=”OMUI.sv-se“>
<Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
</Configuration>

That’s the only thing you need to add/edit to make it silent. The paths for the files are a bit different than with Proofing tools though. The xml file is in .\omui.sv-se (or omui.xx.xx for your own language). The MSI-file used for deployment (or actually only for getting the product code) is in the same directory. The installation and uninstallation strings are also a bit different. Let me show you some screenshots and whatnot from SCCM;

First off you create a new application and make it think it’s going to use a MSI file for installation. You do it like this only to get the detection method/MSI product code.

Fig 8. Create Application Wizard.

Use the path:

\\yoursccmserver\yoursoftwarestash\Microsoft Office 2016 Multilang Pack Swedish\OMUI.sv-se (or similar for another language) and select the file OMUI.msi

Then just next, next, next through the wizard.

 

After this, you edit the Deployment Type. First off, go to the Content location. This path will be wrong (as the msi file is located in the OMUI.sv-se -directory). Please REMOVE “OMUI.sv-se” from the content location path. That’s it for content.

Fig 9. Office 2016 Swedish language pack content location.

 

Then you move over to the “Programs” tab. Here’s where the magic happens. Remove all the text/strings from installation program and uninstallation program. Replace the text with the one from Fig 10 below.

Fig 10. Programs tab. Same xml is used for both installation and uninstallation (even though it got cut off in the screenshot).

In case you want to copy/paste, the strings are:

Installation program: setup.exe /config .\OMUI.sv-se\config.xml
Uninstall program: setup.exe /uninstall OMUI.sv-se /config .\OMUI.sv-se\config.xml

 

Sources:

http://www.itninja.com/question/how-to-install-office-language-pack-2010-unattended
https://technet.microsoft.com/en-us/library/cc179145.aspx
http://www.techygeekshome.co.uk/2012/11/office-2010-language-pack-deployment-in.html

 

You can now do the same thing with Office 2010 language packs if you want to uninstall/remove that version prior to installing the 2016 language packs. You’ll then add another supersedence rule so that BOTH Office 2010 language pack AND Office 2013 language pack will be superseded.

 

 

Dependencies/Finalization

There you have it. You’ve created separate SCCM applications for Office 2016, Office 2016 Proofing tools and Office 2016 language packs. That’s very nice and all, but you probably don’t like deploying all three applications separately, now do you? Well, this is where dependencies comes into play.

In my final deployment I ONLY deploy Office 2016 Proofing Tools. Office 2016 (main office application) is a dependency of Proofing tools, and so are the language packs. See Fig 11 for details.

NOTE! Create THREE SEPARATE dependency groups, otherwise there will be an “OR” statement instead of “AND”. I learned this the hard way when the language packs wouldn’t install. See the right and the wrong way to create the dependencies below:   

Fig 11. Office 2016 Proofing Tools dependencies, the CORRECT way.

 

Fig 12. Office 2016 Proofing Tools dependencies, the WRONG way.

 

Update! As there is a bug with the Skype for Business shortcut icon, the shortcut will also be deployed as a dependency.

• First, create a new directory for your application (script) on your sccm server. Call it “Office2016-Skype for Business-shortcut” for example.
• Copy the Skype for Business 2016-custom shortcut (created in the Customizing Office 2016 part) to this directory.
• Create two new PowerShell script files in this directory;
  • Name the scripts Office2016-Skype for business-shortcut.ps1 and Office2016-Skype for business-shortcut-uninstall.ps1 for example.
    • Contents of Office2016-Skype for business-shortcut.ps1:

copy “Skype for Business 2016.lnk” “C:\Users\Public\Desktop\Skype for Business 2016.lnk”
copy “Skype for Business 2016.lnk” “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2016\Skype for Business 2016.lnk”

• Contents of Office2016-Skype for business-shortcut-uninstall.ps1:

del “C:\Users\Public\Desktop\Skype for Business 2016.lnk”
del “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2016\Skype for Business 2016.lnk”

 

Create a new application using the following information:

• Create Application
• Manually specify the application information
• Name: whatever you like
• Deployment Types:
  • Type: Script Installer
  • Manually specify the deployment type information
  • Name: whatever you like
  • Content location: wherever you store your applications, in a subdirectory called “Office2016-Skype for Business-shortcut” for example
  • Installation program: powershell.exe -executionpolicy Bypass -file “Office2016-Skype for business-shortcut.ps1”
  • Uninstallation program: powershell.exe -executionpolicy Bypass –file “Office2016-Skype for business-shortcut-uninstall.ps1”
  • Detection method: Setting type: File System: C:\Users\Public\Desktop\Skype for Business 2016.lnk AND C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2016\Skype for Business 2016.lnk exist.
  • Install for system, whether or not a user is logged on, hidden.

With all this done, create yet another dependency group. Add this newly created application to this dependency group. You then have a total of FOUR dependencies.

Source: https://tjindarr.wordpress.com/2012/05/04/application-dependencies-in-sccm-2012/

 

 

Summarization

Let’s sum it up:

• Actual deployment “object” is Office 2016 proofing tools, which in turn use dependencies (main office application + language packs).
• Office 2016 supersedes Office 2013.
• Office 2016/2013 removes/uninstalls Office 2010 via OCT (no supersedence).
• Proofing tools packages use supersedence to update themselves to the newest versions (2010 –> 2016,  2013->2016).
• Language pack packages use supersedence to update themselves to the newest versions (2010 –> 2016,  2013->2016).
• Office 2016 is a dependency of Proofing tools 2016, and so are the language packs (and the Skype for Business shortcut).
• A shortcut for Skype for Business is created in the Start menu and on the desktop. (It is NOT created via OCT as it creates a faulty one).

 

And some screenshots:

Fig 13. Downloading all of the needed packages/applications.

The number of downloaded components depend on which Office-components SCCM detects on the client. (Is Office already installed and are only the language packs needed, for example). I’ve now changed the application catalogue name of the “main” application to something more convenient than “Microsoft Office Proofing Tools 2016 – multilanguage”. Currently I’m using “Office 2016 with proofing tools + swe & fi language packs”.

 

Fig 14. Updating components. One done, seven to go.

 

Fig 15. Before Office 2016 deployment. Office 2013 SP1 (with Proofing tools and two language packs). Same components are installed if using Office 2010.

 

Fig 16. After successful Office 2016 deployment. Same thing, new versions 🙂

 

Success! 🙂 (Finally… after many, many, many hours of testing)

 

BTW, feel free to comment if you find this post useful.