@GaToRAiD @tvsutton
Great "write up". I do have a question and a comment.
First, its great that all the plists finally use the same key to disable the welcome screen. That just floored me in 2011 when the keys were different for every application.
Now, the question: Can you please explain the part with the trusted command? The comments mention this is to stop autoupdate from running unless the user intentionally opens it. Is there no way to change the autoupdate plist to manual checks in Office 2016? I'm not familiar with lsregister so just wanting some more information about that whole process.
Thanks
@jrippy The auto update config profile/preference still does apply however, with office 2016 regardless if you have the preference in place it will ignore it on first boot. What I'm doing here is telling GateKeeper to not trust the application AutoUpdater.app thus when the application tries to open it, it will fail to open.
Also for OneNote:
/usr/bin/defaults write /Library/Preferences/com.microsoft.onenote.mac kSubUIAppCompletedFirstRunSetup1507 -bool TRUE
@timsutton Thank you for the help troubleshooting this, also pretty sure his blog will have more detail than I provided.
@GaToRAiD Ok. Interesting idea about blocking it with Gatekeeper. How does lsregister differ from spctl for controlling gatekeeper?
Thanks to you and @timsutton, the rest of us will be ready for 2016 when we adopt it!
@GaToRAiD Just for the record, this script would be run once on login per user right? Also, is there a significant advantage to blocking Microsoft's update through this script rather than the Restricted Software section in the JSS?
@McAwesome We are deploying via a self service policy so it is ran at that time, but during testing we did run at at login if it is being pushed separate of the installer. We didn't want to fully break the AutoUpdater, which is why we didn't block via Restricted Software, we just didn't want it popping up for the first run of each software.
@GaToRAiD Interesting. Does this get around that annoying "You are opening the application "Microsoft AU Daemon" for the first time" prompt? I just started looking around for a way to get rid of it on our lab machines before we push it out.
[EDIT] Nevermind, I see it in the script there. I should read more thoroughly before asking questions.
We really need an ether-beer button here on JAMF Nation and on blogs like http://macops.ca/. :)
There is some other thing which should be mentioned ... After installing I stumbled through the plists and found this:
defaults read com.microsoft.autoupdate.fba
{
SendAllTelemetryEnabled = 0;
}
I guess you all want that deactivated, here is a little untested script. (If I find more, I'll post that.)
#!/bin/bash
# Disable Ugly Microsoft Features...
# Within USER_TEMPLATEs
for USER_TEMPLATE in "/System/Library/User Template"/*
do
#Turn off Telemetry
defaults write "${USER_TEMPLATE}/Library/Preferences/com.microsoft.autoupdate.fba.plist" SendAllTelemetryEnabled -bool false
done
# Within USERs
for USER in "/Users"/*
do
#Turn off Telemetry
defaults write "${USER}/Library/Preferences/com.microsoft.autoupdate.fba.plist" SendAllTelemetryEnabled -bool false
done
@bofh How does ownership of com.microsoft.autoupdate.fba.plist look when you run it on your Mac?
@donmontalvo
In my User Folder:
-rw------- 1 root wheel 73 Aug 10 11:00 com.microsoft.autoupdate.fba.plist
In one of the User Templates:
-rw------- 1 root wheel 73 Aug 10 11:00 com.microsoft.autoupdate.fba.plist
I'm not sure if that happened with the script above or if the filerights where like that before
OK so I'm not losing my mind. Mine looks like that too. I ran it locally, might be why root shows as owner.
I'll test through Self Service when I get to the office (since it runs as user with root rights). Guessing as well the User Template plist may need to be chown'd (additional line) if Self Service sets owner of all the files it is touching to current user.
I'm just thinking out loud here, but could one not specify a choices installer with the following content so that AutoUpdate is never installed to begin with?
<?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">
<array>
<dict>
<key>attributeSetting</key>
<integer>0</integer>
<key>choiceAttribute</key>
<string>selected</string>
<key>choiceIdentifier</key>
<string>com.microsoft.autoupdate</string>
</dict>
</array>
</plist>
I mean if the goal is to manage the updates yourself then this would surely stop it from coming up on first launch. I know I'm probably overlooking something, so someone please tell me why this approach isn't the way to go.
@bpavlov Funny you say that, the issue is, if you have office 2011 on there, which would include the MAU as well, it will actually run that if the other is not found.
Right, there's the issue of computers that already have Office 2011. But what about machines that don't have it? Not sure about others, but are others going to keep both 2011 and 2016 running side by side? I know it's possible, but I imagine usually companies leave the old version behind and uninstall it (emphasis on usually).
So a bit more investigating on what kicks off Word launching after install:
postinstall in the Word installer
#!/bin/sh
if ! [[ $COMMAND_LINE_INSTALL && $COMMAND_LINE_INSTALL != 0 ]]
then
domain="com.microsoft.autoupdate2"
defaults_cmd="/usr/bin/sudo -u $USER /usr/bin/defaults"
application="/Applications/Microsoft Word.app"
application_info_plist="$application/Contents/Info.plist"
lcid="1033"
if /bin/test -f "$application_info_plist"
then
application_bundle_signature=`$defaults_cmd read "$application_info_plist" CFBundleSignature`
application_bundle_version=`$defaults_cmd read "$application_info_plist" CFBundleVersion`
application_id=`printf "%s%02s" $application_bundle_signature ${application_bundle_version%%.*}`
$defaults_cmd write $domain Applications -dict-add "$application" "{ 'Application ID' = $application_id; LCID = $lcid ; }"
fi
parent_dir=`/usr/bin/dirname "$0"`
chain_clu="$parent_dir/chain_app"
perpetual_license="/Library/Preferences/com.microsoft.office.licensingv2.plist"
office365_license="$HOME/Library/Group Containers/UBF8T346G9.Office/com.microsoft.Office365.plist"
# Find the PID of the installer process
installer_pid=$(/bin/ps -o pid,command -ax | /usr/bin/grep "Installer.app/Contents/MacOS/Installer" | /usr/bin/awk '{print $1}')
if /bin/test -d "$application"
then
if /bin/test -e "$perpetual_license" || /bin/test -e "$office365_license"
then
logger "Office product already licensed."
else
# Launch $application once the installer process goes away
/usr/bin/sudo -u $USER "$chain_clu" -p "$installer_pid" -a "$application" --args -silent 1 &
fi
fi
fi
exit 0
and the postinstall script calls the chain_app script also located in the same scripts folder for the Word installer:
#!/bin/sh
# Chain launch a file system object.
#
# This script will wait for a process to complete and then open a file system
# object.
# Exit 1 if no args.
if [ $# -eq 0 ]
then
exit 1
fi
# Parse args.
while getopts ":a:d:p:" option
do
case $option in
# Application to execute.
a ) APPLICATION=$OPTARG ;;
# Delay in seconds to wait until $PID quits.
d ) DELAY=$OPTARG ;;
# PID to wait on before executing $APPLICATION.
p ) PID=$OPTARG ;;
* ) break ;;
esac
done
shift $((OPTIND - 1))
# Default $DELAY to 1 if not passed.
DELAY=${DELAY:-1}
# Set extra args to rest of arguments.
EXTRA_ARGS=$*
# Sleep until $PID quits.
while [ $(/bin/ps -o pid -p"$PID" | /usr/bin/grep "$PID" | /usr/bin/awk '{print $1}') ]
do
/bin/sleep "$DELAY"
done
# Execute application with extra args (if any).
/usr/bin/open "$APPLICATION" $EXTRA_ARGS
exit $?
Perhaps modifying the chain_app script so that it exits gracefully will do the trick so that Word isn't launched post-install.
#!/bin/sh
exit 0
Not sure why Microsoft suddenly feels the need to open up an Office app after its been installed. Anyways, I'm just sharing what I'm finding. I haven't tested or put anything together, but will post more if any other little bits like this may prove useful to someone else.
Just to follow up. It appears that modifying chain_app script does indeed work. Word is not auto-launched after install. And if I manually launch Word and have a profile set to make the first run preferences set to true, I get a nice clean experience. No autoupdate.
chain_app
#!/bin/sh
exit 0
Will still need to test deploying via Casper just to see how it behaves, but I'm liking the results so far.
Hi,
Rename the MAU2.0 folder in /Library/Application Support/Microsoft/ suppress the AutoUpdate. This removes the "Check For Updates" option in the Help Menu as well.
Thanks & Regards,
Karthikeyan
Rename the MAU2.0 folder in /Library/Application Support/Microsoft/ suppress the AutoUpdate. This removes the "Check For Updates" option in the Help Menu as well.
Good find! A quick question though. Would there be any reason why you might not simply create a policy to delete "Microsoft AutoUpdate.app" in this folder? It would have the same effect.
Yes, We can even delete it.
Yes, if the MAU app isn't present then the auto update issues go away.
I inadvertently discovered this when I was attempting to package up the VL Office installer. See my blog
Is there a way to disable the "Gallery" screens that continue to pop up, even after disabling the firstrun screens? I would just like the window to open to a new blank document or spreadsheet.
Hi @zbennis
Microsoft Stores the New Template dialog settings in
"MicrosoftRegistrationDB.reg" file in ~/Library/Group Containers/UBF8T346G9.Office. We have to include this package in file. I was not able to create the script to create the file so copying it to All Users and User Template.
Thanks & Regards,
Karthikeyan M
