Deploy Office After DEP Configuration

  • July 17, 2017

In order to speed up our initial DEP process we decided to move deploy Microsoft Office on next checkin rather than part of the initial build. Doing this gave us the ability to DEP a machine in under 10 mins to get our employees up and running.

 

Todo this we have a few different moving parts.

  1. We deploy a dummy package on the machine which puts a folder in the Applications folder with the office 2016 logo and a file called “Where’s office”.
  2. We have an EA pickup on if this file exists, then does a check to see if excel exists. If it does, we remove the folder and file and assume office is installed.
  3. We have a smart group called DEP – Deploy Office
  4. Cleanup Script as part of our policy
  5. A Policy that triggers the office install called install_office
  6. We have a policy triggered on that smart group that deploys it in the background.

 

Part 1-  Dummy Package

First up we’ll use our dummy package to create a policy.
I’ve uploaded all the files I use here

This repo contains the following files:
Blackvariant-Button-Ui-Ms-Office-2016-Office.png – The Logo we’re going to use
postinstall – Where the magic actually happens
set-image.py – Creates an icon to the Where Is Office Folder
whereisoffice.pkgproj – The packages project you’ll use to create your compiled PKG to deploy using packages

By default this deploys a folder with the icon

And a file in that folder

The file’s text is the following

Welcome to your New Mac!
To speed up the preparations of your Mac, Microsoft Office 2016 will appear by the end of the day.
A popup will appear after Microsoft Office 2016 has been installed.

If you’re happy with the default you can download the compiled unsigned version here

You’ll need to upload this to your JSS, and deploy it as part of your DEP Policy’s initial deployment.

 

Part 2 – Extension Attribute to Find our txt file

I’ve posted a copy of the EA I use here

The EA checks for our file we installed above and places our machine in the smart group we define.

We’ll place this EA in our JSS  and utilize it as part of Part 4

Jamf has great documentation on how to import this into your JSS Here.

Part 3 – Smart Group

Now we create a smart group, with a value of YES for our ea looking for office. In my screenshot below you’ll notice i’ve named my EA EA_deployoffice1, this will be whatever you’ve named the ea above.

Part 4 – Deploy office and cleanup script

We then put another script in the JSS. This script checks to see if excel is installed, and then if it is notifies the user we were successful (in case the script just didn’t run). If not it’ll run the office installer.

You can grab a copy of that script here

Part 5 – Deploy office by trigger

Keeping with the idea that IBM shared where every policy calls a master policy (update it once in the jss) office install runs on a trigger called install_office2016.

It then contains any packages we need as part of our office install. This policy does not run recon.

Part 6 – Deploy & Clean

Based on this smart group. We then create a policy which has the check in triggers

When a computer’s network state changes (e.g. when the network connection changes, when the computer name changes, when the IP address changes)
At the recurring check-in frequency configured in the JSS
As we don’t want it to impede the user from doing work i’d suggest not having it a login or logout.
We define this policy to the smart group that reads our EA above.
We then add the script in part 4 to our policy, and test. You’ll note the check and notification is done when the machine checks in for a second time, this is to avoid the false positive of jamf installing the policy and then trying to run the script regardless.

No Comments

Leave a Comment