Best practices for automating Office 2016 updates?
I am just wondering how everyone is managing automating Office 2016 updates with Jamf? I know that MAU 4.0 is supposed to have system level settings available but as of right now it is still user level. I have a very large number of dispersed lab computers that do not normally have admins login so I am wondering what would be the best way to go about forcing automatic download and installation of updates. I am sorry if this question has been asked and answered in the past. Thank you in advance for the advice.
3 Likes
60 Comments
Order by:
subscribed. My environment also has many people without admin rights. I've been manually pushing out updates (5 packages for each office app).
You're in luck as you can do that now with MAU 3.8.
https://macadmins.software/docs/MAU_38.pdf
Brad_G, thank you for posting that but if I am not mistaken the "Automatically Download and Install" option is not defaulted for each user and is a user level setting. So while I may set it for the admin account any user that logs into the system would be defaulted to "Automatically check". It is great that it gets past the admin credentials requirement but would you happen to know how to force the settings change for all users? Additionally, I have found that, and I may be wrong, MAU is only checking for updates to Office 2016 applications that the current user has opened so if they have only opened word then that is all that will update. Again thank you for your quick response and I apologize if I am entirely incorrect in my assumptions.
MAU 4.0 will have command line support. This should allow you to build a policy to check for updates and install them. Coming soon.
@ABigRock at the bottom of Rich's article you will find a .mobileconfig link that you can upload into Casper and use as a Configuration Profile. Set it to Install Automatically and at Computer Level.
Enabling Automatic Download
@stevewood Thanks, that is exactly what I was looking for.
@ABigRock I did a talk on MAU the other week - as well as getting MAU and a config profile out to your Macs, there are a couple of things you need to do when you consider that those running it may not have been the ones who installed in/Office. Full details in the video!
https://youtu.be/lxizq5EZHWM?t=39m58s
You need to make sure the apps are registered (can be added to the profile - either run all the Office apps on a machine and copy out the keys from ~/Library/Preferences/com.microsoft.autoupdate2.plist to your profile or check out the postinstall scripts in the Office installer pkg - you can use those to create the keys on a Mac you don't have Office on).
Also make sure MAU is registered with Launch Services for the current logged in user so it doesn't prompt them the first time it runs for them.
Login script to register MAU with Launch Services (I run this once per user per computer):
This script will create a LaunchAgent and registers MAU and All Office apps for the autoupdate, otherwise you will have to open each office app once to get it registered with MAU when you install Office via Casper.
You only need to run this script once per computer.
@stevewood Hi, i would like to ask about Rich's article where i need to copy this code?and where in casper i need to put it? do i need to upload it under custom setting under configuration profile?
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> <key>PayloadContent</key> <array> <dict> <key>PayloadContent</key> <dict> <key>com.microsoft.autoupdate2</key> <dict> <key>Forced</key> <array> <dict> <key>mcx_preference_settings</key> <dict> <key>HowToCheck</key> <string>AutomaticDownload</string> </dict> </dict> </array> </dict> </dict> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>MCXToProfile.67ad2621-b510-4060-b971-7f7cf51506c9.alacarte.customsettings.c00e472d-4cb4-4231-8fd4-c7fa866efc00</string> <key>PayloadType</key> <string>com.apple.ManagedClient.preferences</string> <key>PayloadUUID</key> <string>c00e472d-4cb4-4231-8fd4-c7fa866efc00</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </array> <key>PayloadDescription</key> <string>Enable Automatic Download and Installation of Microsoft Office 2016 Updates</string> <key>PayloadDisplayName</key> <string>Enable Automatic Download and Installation of Microsoft Office 2016 Updates</string> <key>PayloadIdentifier</key> <string>com.company.profile.EnableAutomaticDownloadAndInstall</string> <key>PayloadOrganization</key> <string></string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadScope</key> <string>System</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>67ad2621-b510-4060-b971-7f7cf51506c9</string> <key>PayloadVersion</key> <integer>1</integer>
</dict>
</plist>
Carrying on from Brad's response above, we followed this from derFlounder Blog:
https://derflounder.wordpress.com/2016/10/12/enabling-automatic-download-and-installation-of-microsoft-office-2016-updates/
was very good at improving this, but still reqquires the user to press to search for updates, so we cant automate this well just yet, but has certainly improved the rate in which users update office.
@jamfmdm yes, under Configuration Profiles you click the Upload icon and upload the .mobileconfig file to your JSS.
macOS Configuration Profiles
@stevewood i tried that but i have an error message telling me that "
The file could not be parsed"
is there any other script for autoupdate?
@jamfmdm how are you creating that .mobileconfig file? The error that you have there leads me to believe the formatting of the file is wrong. How did you download/create the file?
Here's what I just did to test:
I did not receive the parsing error that you received. Can you confirm that those are the steps you are taking? I would make sure you are not using TextEdit to copy and paste. That often times causes parsing errors like this. If you have to, download Text Wrangler and use it for saving the file.
@stevewood it's working now.
thanks
@Kumarasinghe Hey, that's a great script, and I think it comes in handy if you haven't run MAU in a computer.
But, since I've run MAU on a machine already, can I just use my existing com.microsoft.autoupdate2.plist, add the key for AutomaticDownload, point it to our in-house MAU Caching Server, convert it to a Configuration Profile, and call it a day?
I guess I could still use the launchservice script by @neil.martin83 just to trigger the thing, right?
@itupshot the script will trust MAU and also registers each Office applications on MAU to get auto updates working otherwise MAU only update the apps which were previously registered (by opening the app).
e.g. If you have never opened Outlook after install Office 2016, MAU will not auto update Outlook.
(This only applies if you install Office 2016 via command line or via Casper. Manual install has a postinstall script built-in with Office pkg which does the same thing.)
@neil.martin83 Your script didn't work for me as is. I get an error logged from Casper Remote when I tested it. Using only the two middle lines also resulted in an error. So I launched MAU manually to test Config Profile.
Good news is that the Config Profile I derived from my com.microsoft.autoupdate2.plist file seems to be working. My test machines are downloading the updates very fast from my local MAU Caching Server. However, it doesn't seem to be logging anything to the /Library/Logs/Microsoft/autoupdate.log file. In fact, it just stays blank, and says it's zero bytes in size.
One thing I noticed is that the MAU still allows the checkbox for "Join the Office Insider program..." to be selected. Shouldn't it gray it out?
@itupshot I think if you run scripts with Casper Remote, the logged in user is detected as root. The script needs to be run by a policy triggered at login - it detects the name of the user logging in and runs those commands to register MAU with Launch Services as that user. :-)
@neil.martin83 OK, I'll try it on my second test machine as a policy run at Login. You said the frequency should be "once per user per computer," correct?
@itupshot Yep that's how I do it.
@itupshot
You need to add the following key to your mobileconfig to disable the "Join the Office Insider program..." check box
or run the following defaults command as part of your login policy/script ( once per user)
I have used both with no issues
@LSinNY Thanks for the tip! I'll add that to my "master" com.microsoft.autoupdate2.plist file, and convert it again to a Config Profile for the next round of tests.
@neil.martin83 I'm getting this output when the script runs with a lot of these "error -10811" lines.
Is that normal?
It looks like it worked, though. When I launch one (or two) of the Office apps, the ones not running are being updated, and I get the notification that there are updates for the ones running.
Any ideas how we can deploy this for users who don't have MAU installed? Currently, we install Office with a choices.xml file that excludes MAU. If I deploy MAU now separately to all those users, they'll get the app asking if it's OK to run. My users pretty much never log out, so it's not easy to sneak this one in for the app to register with Launch Services in the background.
@itupshot Take the "-v" out of your lsregister line(s). This verbose flag is causing you to see these errors.
@itupshot yep those errors are normal - lsregister literally tries to register every file in the app bundles but only succeeds on the root of the bundles themselves. It's harmless and doesn't mean failure. Keeping the -v flag means you will see that the command has run properly - e.g. if the target app bundle isn't present or has been moved, you'll know. Running it without -v won't give any feedback either way which might hamper troubleshooting later on.
@itupshot you can also include that script in the policy that installs MAU, to run after the pkg is installed - if a user is logged in, those commands will run in their context and MAU will get registered and won't prompt. If no user is logged in then the commands will fail because su won't have a user to switch to (the policy won't fail though because the script always exits with code 0). Again, harmless. I did this myself when deploying MAU just in case.
I'm trying to set this up, but struggling with setting up a MAU cache server. Per the documentation here, I should be able to run this: MAUCacheAdmin --CachePath:/Volumes/web/MAU/cache --CheckInterval:60, but it appears to be ignoring the parameters - I'm just getting the ShowUsage function, which is the default if no params are passed. I suspect it's something I don't know about running BASH scripts in El Cap, but I'm not finding any tricks involved with that. Any help appreciated!
@dmillertds
Is your server cache path /Volumes/web/MAU/cache ? if not that is the problem. What you posted from the help file is an example. My cache path is /Volumes/MAU/MO2016, so the full command would be MAUCacheAdmin --CachePath:/Volumes/MAU/MO2016 --CheckInterval:60, which works and has the last line that reads:
Sleeping for 60 minutes
No, forgot to mention that - modified the cache path to match my environment. But it's like it isn't even trying to read the parameters, that's what I'm not getting. I've tried prefixing with "sh " and "sudo sh ", but nothing is working. Actually, I should say that prefixing with "sh " is the only way I can get it to do anything, but then it only returns the ShowUsage verbiage. The actual command I'm running is:
sh MAUCacheAdmin --CachePath:/Volumes/Server SSD/Library/Server/Web/Data/Sites/Default/MSOffice2016Updates/ --Checkinterval:60
Any chance the space in the volume name would be causing a problem?
This will get you going.
I have a mixed environment of Office 2011 and 2016. I'm noticing not all machines have MAU 3.8. Can I push a MAU 3.8 installer to all machines, enable Automatic Download (defaults write com.microsoft.autoupdate2 HowToCheck AutomaticDownload) and expect this to work?
What is the interval in which a machine will check for updates with automatic download?
@dmillertds have you tried using the absolute path? I have the MAUCacheAdmin binary in /usr/local/. so the full command is
@bbot Yes, however you will may need to update com.microsoft.autoupdate2 via defaults write, modify the profile above or run @Kumarasinghe's script to reflect the addition of the Office 2011 apps
@Kumarasinghe and @LSinNY - thank you both! I combined your suggestions and it finally worked. I had already CD'ed to /usr/local, so I don't know why I had to put in the path, but it did work. And I should have tried the single-quotes around the cache location. I had tried double, but that didn't work.
Glad you got it working. just so you know, if you do cd into /usr/local/, you can run the command by adding "./"
to run the MAUCacheAdmin binary directly
How can I force the enable insider build using a configuration profile?
I'm creating 2 mobileconfigs, one to disable for most of the company, and another to enable Officer Insider for our internal technology department for testing purposes.
I've updated the MAU clients to v. 3.9, and now we can't download updates from the MAU Caching Server. We keep getting this error:
EDIT: Never mind. I didn't give the server enough time to download the updates. They're all in now, and we can download.
@neil.martin83 How often does the MAU 3.9 app check for updates by default? I ran the script that registers the Office apps with MAU and installed a profile to auto download and install and lock out the MAU prefs. I had to put the clock forward on the Mac a couple of weeks to get all of the Office 2016 apps to auto update silently. We are not using a MAU caching server. For instance Word, Outlook and Powerpoint updated right away but then Excel and OneNote did not until I set the clock forward a few weeks.
@rtrav I know the documentation states every 12 hours
but I left a test machine on and intentionally did not run updates but it did not install anything over night and it's been more than 12 hours.
Does anyone know a way to manipulate the time it takes to check in?
neil.martin83 can you share - the profile that you used to auto download and install and lock out the MAU prefs?
I've created a Configuration profile to push out that enables auto downloads in MAU and also registers each application as @neil.martin83 pointed out but it's not automatically updating the closed applications, only the open ones.
Should the configuration profile be user level ? at the moment i have it set to computer level.
(i did test at user level but it still didn't update the applications)
if i look at /Library/Managed Preferences/com.microsoft.autoupdate2.plist i can see the key entries,
when i look in ~/Library/Preferences/com.microsoft.autoupdate2.plist i do not (it's set to Auto Check and has no applications registered)
any pointers ?
here's the custom plist i'm sending in the configuration profile
Also, can someone point me to which folder the downloaded updates are stored in before they're installed ? maybe i can monitor that to see if it's working or not.
thanks!
i've tested the configuration at user and computer level and looking at the /Library/Logs/Microsoft/autoupdate.log nothing updates when set to Download and Instal Automatically, i created a LaunchAgent and script to register the MAU app and Daemon once per user, is there anyway to confirm that it is registering them correctly ?
Apologies for the late reply, life took over a bit...
@rtrav It checks at least every 12 hours and is invoked when you launch one of the apps. I need to double check the docs but I believe it'll run again after 12 hours if there's a registered app running (e.g. user leaves Word open for that long). It will only check for updates against apps that are registered with it (those <Applications> keys in its preference domain). If you're not managing those keys in a profile or by defaults writing them, registering the apps happens when each app is launched on a per app basis at the user level. If you have a user who never launches OneNote, for example, it won't ever update, unless you manage its <Application> keys.
@cbruce My profile is here, for reference: https://gist.github.com/neilmartin83/cb7ebe5f9afb3aa40e6d97d5bc917ded
Note that I am also managing preferences for our own caching server which holds both the collateral and packages. I also disable the Insider checkbox. I install this profile at system level and the closed apps also update just fine across my fleet.
As a side note, I have another profile which is the same as above, but points to a different set of URLs (subdirectories on my caching server) where I host the current set of updates - this lets me roll those out to a pilot group of machines for testing.
@May Here's the script I use to register MAU with LaunchServices so you don't get the nag dialog. I run it at every login via the JSS - it's not resource intensive and this method means it catches everyone. I noticed that after a MAU update, it needed re-registering, so that's why I did this, otherwise I'd have done it once per user. This method also means the JSS collects the output and logs it. You can get verbose output by adding the -v flag to the lsregister commands: https://gist.github.com/neilmartin83/4e704a0c627453ca216d413c2ae43182
This script runs as root (as it's being run by the jamf binary) so essentially works out who the logged in user is, then runs the commands to register MAU as them, plus deleting the <LastUpdate> preference key so that when they launch one of the Office apps, it'll check for updates right away. I'm lazy and didn't bother with the awesome amount of sanity checking you've put in yours because Office is deployed to our entire fleet. :)
Check /Library/Logs/Microsoft/autoupdate.log to see if it's doing what it should, it's pretty good at telling you that it's checking, downloading, then installing the packages. You can also enable even more verbose logging by managing the <ExtendedLogging> key (true/false).
All the reference material is here: https://macadmins.software/docs/MAU_38.pdf
Thanks @neil.martin83, you've been very helpful in laying out the hidden pieces of this puzzle!
Good to know that MAU needs re-registering each update, i'll test out your login policy/script approach so i can set it and forget it rather than messing with LaunchAgents each update.
@neil.martin83
Are there any particular tricks to getting login policies to run ?
I just created a policy with the Trigger = login, Frequency = ongoing, Make available offline is checked.
Double checked that Management Settings > Check - In > Login/Logout Hooks has Create login/logout hooks checked.
I've logged the user out and in a few times and also ran recon incase that's needed to pull down the script initially but if i check the policy logs it's still shown as pending.
Should i see something from the Policy within /Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh ?
(i can see that com.apple.loginwindow has this set as the LoginHook),
and will login hooks only run if the Mac is on the network ? (i was assuming that the Make available offline option would mean network wasn't required)
JSS 9.96
OS X 10.11.6
I'm glad to say i couldn't get a login policy to run as it sent me down a different route, ideally i didn't want to wait for a user to login for MAU to get registered, i was looking at using /bin/launchctl asuser but couldn't get it to work then stumbled across this post which has a wonderfully simple approach to running commands under the user context, thank you @mm2270 !!
Now i can run this to register MAU once per user and each time there's an MAU update, hoorah.
```
!/bin/bash
LoggedInUser=$(stat -f%Su /dev/console)
LoggedInUID=$(id -u "$LoggedInUser")
if [[ "$LoggedInUser" != "root" ]] || [[ "$LoggedInUID" -ne 0 ]]; then
cat << EOF > /private/tmp/MAU_register_script.sh
!/bin/bash
LoggedInUser=$(stat -f%Su /dev/console)
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted -v "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app"
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted -v "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app"
mkdir /Users/$LoggedInUser/Documents/.MAU_check/
echo "Autoupdate.app registered for $LoggedInUser" > /Users/$LoggedInUser/Documents/.MAU_check/MAU_register.txt
EOF
else echo "No user logged in. Can't run as user, so exiting" exit 0
fi
if [ -e /private/tmp/MAU_register_script.sh ]; then /bin/chmod +x /private/tmp/MAU_register_script.sh /bin/launchctl asuser "$LoggedInUID" sudo -iu "$LoggedInUser" "/private/tmp/MAU_register_script.sh" sleep 2 echo "Cleaning up..." /bin/rm -f "/private/tmp/MAU_register_script.sh"
else echo "Oops! Couldn't find the script to run. Something went wrong!" exit 1
fi```
All we'd like to do is just shoot a simple bash script using a policy in the JSS to our logged in users with the following:
defaults write com.microsoft.autoupdate2 HowToCheck AutomaticDownload
but for some reason, it's not working. If i copy and paste this into Terminal directly under the logged in user, it works.
Any ideas why?
@monaronyc You have to write to the logged in user's prefs:
@StoneMagnet SWEET MARY JESUS! That worked! THANK YOU! THANK YOU! As you can see i'm still a bit of a novice with this stuff, but getting better thanks to folks like you and the JAMF community! One thing though, we're still not seeing that global prefs file in /Library/Preferences yet. Are we supposed to place that manually some way?
@monaronyc As near as I can tell any com.microsoft.autoupdate2 prefs file in /Library/Preferences is ignored, and only the one in ~/Library/Preferences matters
MAU 4.0 was released.
https://www.jamf.com/jamf-nation/third-party-products/384/microsoft-autoupdate?view=info
Has anyone disabled the automatic functions and set it to manual? If so, care to share?
@rkovelman Check out (https://github.com/pbowden-msft/msupdatehelper) for @pbowden's Jamf Pro helper script for controlling Office and Skype updates. There's a link on that page for a video tutorial on msupdate which shows how to disable the automatic updates by deploying a configuration profile.
Juser wondering - are all admins always downloaded the latest office version ?. For years we have always been running 1-2 versions behind and updating 3-4 times a year, but never to the newest, as there always is a risk that the newest tuff is buggy and not fully tested ?` - but maybe this is not the way to think?
I update mine about once a month and I use the auto update script from mac.admins site.
@kericson Thanks for input. So you are using the msupdate script to update ? -
Yes the one from Mac.admins site.
@jameson , biggest issue with not updating monthly is that for the Mac version of Office, Microsoft doesn't have a separate channel for security/critical updates. So each month's updates on the Office 365/2019 are feature, security, and critical patches all in the same update. For Office 2016, they are now security only.
I wish Microsoft would bring their Mac development cycle in sync with Windows, where there are semi-annual channels that are supported for 18 months with security updates, in addition to the monthly update channel. In fact, on Windows the default channel for Office 365 Pro Plus is semi-annual.
Personally, I run about 1 month behind what is current. Usually a show-stopping bug will get publicized during that time-frame.
@taugust04 Thanks for the input. We are on office365 and did not know that that that microsoft did handle Mac this way. For windows I knew the way as been in contact with our Microsoft guys in Company, so actually did think more of a manual way of upgrading semi annual way. But if security updates also are part of it, it should be quite often. So think the way you do it with once a month and not right away push new out could be a way to go.