Office 2016 - You are opening the application "Microsoft AU Daemon" for the first time...

[tnielsen]

When opening any Office 2016 app, this is popping up for every different user of the system.

It's easy enough to hit open but I'd like to know if anyone else saw this and was able to work around it?

[emily]

Check out this thread: https://jamfnation.jamfsoftware.com/discussion.html?id=15475

[kstrick]

Do check out the link @emilykausalik quoted--
I ended up using a solution like that that one, and then for good measure added the following to remove that app from quarantine.

/usr/bin/xattr -r -d com.apple.quarantine /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app

[tnielsen]

Maybe I'm dense but I see no solution in that thread for the problem I'm encountering above.

Edit: Nevermind, I found it. Thanks guys.

Edit 2: Well, to be honest my intention is not to disable the microsoft au daemon feature. I just don't want users to be prompted to open the file or not. Still searching.

[kstrick]

The "Microsoft AU Daemon" is part of the "Microsoft AutoUpdate.app", so if you remove the quarantine from the app (using the xattr -r -d), that should stop the message.

[bpavlov]

@kstrick Makes one wonder why MS doesn't have that as part of their script if it's just an attribute issue. Certainly wasn't present in 2011. And my understanding is that MS AutoUpdate hasn't actually changed in 2016.

[kstrick]

Microsoft always makes me wonder...

[tnielsen]

@kstrick

So, I've been going through all the posts and I have a few questions:

1) The above xattr command doesn't seem to be doing anything on 10.10.5. What does work is the following code being run while the user is logged in:

#!/bin/sh
#Find Current User
CurrentUser=`/usr/bin/who | awk '/console/{ print $1 }'`
echo $CurrentUser

#Set Command Variable for trusted application
register_trusted_cmd="/usr/bin/sudo -u final /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted"

#Set Variable for application being run against
application="/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app"

#This runs the combination of variables above that will block the running
#of the autoupdate.app until the user actually clicks on it, or goes
#into the help check for updates menu.  Additionally this needs to be
#run for each user on a machine.
$register_trusted_cmd "$application"

However, this raises a concern. What are people doing to avoid this problem for new users?

[kstrick]

Not sure why xattr not working on 10.10.5, have to play with that on a 10.10.5 machine....

If you can only get it to work per-user with the lsregister command, you would need to have a script run each time a user first logs in either via a launch agent or a 'once per user' login policy in casper...

[tnielsen]

Which is totally why I'm about to say, this isn't worth the time and inform users to hit OK.

Is there a way to "whitelist" an app for the entire system?

[kstrick]

yeah, this has me pretty annoyed now... i was playing with this and it seems like the reason xattr isn't working, is that apparently the quarantine flag isn't set set for that app?!?! (at least not showing with ls -l@ or xattr -l )

@tnielsen the xattr is supposed to whitelist for the whole system, which is why this is so annoying, and yeah seems like a lot of work for something so 'stupid'... i have an idea or two to still try, if it works i'll post....

[tnielsen]

I thought it could be a permissions issue, my thought was maybe wheel needs to have write permissions. That's not it. xattr isn't working, but the code here is if run for that specific user.

#!/bin/sh
CurrentUser=`/usr/bin/who | awk '/console/{ print $1 }'`
register_trusted_cmd="/usr/bin/sudo -u $CurrentUser /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted"
application="/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app"
$register_trusted_cmd "$application"

The shitty thing about this, is that new users would need this to be run as part of a login script in order to work around that prompt.

If you could lsregister an app for all users... that's what we need.

[tnielsen]

Hey, since I've had some time to sleep and not be drowned in work. I believe we just need to run this as part of a default login script (without the sudo command), or do this during installation to loop through all system users (for each user, run the above commands). I'm testing it now. I just want this to be over =(

[nessts]

every update/reboot on 10.11 this re-appears for me interestingly.

[franton]

How are you all deploying this? It's a critical question. The VL installer has some weird post install scripting in it that's causing these issues. In the case of the MAU, it's the following:

if ! [[ $COMMAND_LINE_INSTALL && $COMMAND_LINE_INSTALL != 0 ]]
then
    register_trusted_cmd="/usr/bin/sudo -u $USER /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted"
    application="/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app"

...

So if you've just uploaded the VL pkg into Casper and deployed it, that section of code will not run and thus the app is not trusted.

You have two ways out of this:
1) if you are using logon scripts then you can append that lsregister command into it and that should fix it.
2) Consider re-packaging the VL installer. I've a guide on how to do so on my own blog here

Be warned: my method does not install the update daemon at all, which means you will have to package and push all updates yourself.

[tnielsen]

Franton, deployment is being done through self service and ARD pushes. I'm only in the testing phase so there's no mass deployment yet.

The application apparently needs to be trusted by each user for some reason and that's what the current problem is.

The following code AT LOGIN does fix the problem. I just wish there was a way to trust this app system wide on 10.10.5.

#!/bin/sh
CurrentUser=`/usr/bin/who | awk '/console/{ print $1 }'`
register_trusted_cmd="/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted"
application="/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app"
$register_trusted_cmd "$application"

[CapU]

I just removed the app for now. I can either install it later or push the updates myself

[ryan_s]

I have also running into the MAU Daemon pop-ups with our deployment - I have followed most everything above and linked pages as well. I cannot get this to set as 'manual' after a user installed Office 2016 from Self Service (they are presented with the pop-up).

I am thinking that the "ApplyChoiceChanges.xml" solution might be what I need to visit next, with simply not install MAU as (as @CapU seems to have as well -- CapU or @millersc did you use an alternate solution to remove MAU? My issue now is that Casper returns logging that says my XML is malformed :( Are there example ChoiceChanges.xml files I can reference you guys might have in-place? I am not sure what mine is missing...

<!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>childItems</key>
                <array/>
                <key>choiceDescription</key>
                <string>Microsoft AutoUpdate</string>
                <key>choiceIdentifier</key>
                <string>com.microsoft.autoupdate</string>
                <key>choiceIsEnabled</key>
                <true/>
                <key>choiceIsSelected</key>
                <integer>0</integer>
                <key>choiceIsVisible</key>
                <false/>
                <key>choiceSizeInKilobytes</key>
                <integer>4997</integer>
                <key>choiceTitle</key>
                <string>Microsoft AutoUpdate</string>
                <key>pathsOfActivePackagesInChoice</key>
                <array>
                    <string>file://localhost/Users/test/Desktop/Microsoft_Office_2016_Volume_Installer.pkg#Office15_all_autoupdate.pkg</string>
                </array>

Ownership on the file:

-rw-r--rw-  1 rseys  TESLAMOTORSDomain Users        8983 Sep 25 15:29 tslaconfig.plist

[millersc]

I followed the instructions above also, but had same problem with MAU. Ultimately used the ChoiceChanges to rip out the MAU since we want control of updates.

[millersc]

Dropped the choice file in the tmp directory, used Composer to make it pkg and pushing with the rest of my Office 2016 policy. I followed @donmontalvo policy flow linky here and made the pkg part of it. Naming order is important, that being said, this doesn't seem logical, but it works consistently and I'm not going to question it anymore. In this order:
Microsoft_Office_2016_Volume_Installer.pkg
Microsoft_Office_2016_Volume_Installer_Choices.pkg.zip
Microsoft_Office_2016_Volume_Installer_licensingV2.plist.pkg
Microsoft_Office_Excel_15.14.0_Updater.pkg
Microsoft_Office_OneNote_15.14.0_Updater.pkg
Microsoft_Office_PowerPoint_15.14.0_Updater.pkg
Microsoft_Office_Word_15.14.0_Updater.pkg

Note we are not pushing Outlook and MAU, so that update is missing here.

This is my choice file:

<?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>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.word</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.excel</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.powerpoint</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.onenote.mac</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>0</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.outlook</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>0</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.autoupdate</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.licensing</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.licensing.volume</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.office.fonts</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.office.frameworks</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.office.proofing</string>
    </dict>
</array>
</plist>

[tnielsen]

Nice, thanks for the update.

[bpavlov]

@millersc Since the other items are by default seleted, you really only need this:

<?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.outlook</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <integer>0</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>com.microsoft.autoupdate</string>
    </dict>
</array>
</plist>

[millersc]

Tried that, it didn't like me then. This works consistently over and over.

[charles_hitch]

Shameless plug to get folks to up-vote my feature request to have Casper support choices.xml files natively. https://jamfnation.jamfsoftware.com/featureRequest.html?id=3516

[tomr]

Took a more forceful approach as trying the register the app for individual users would just become too much of an issue and I was tired of trying to figure out a more technical solution. As part of our post install script for Office I renamed Microsoft AutoUpdate to MircosoftAutoUpdate.

This prevented the dialog box from popping up for users on first run and also has the added benefit of removing the "Check for updates" functionality from the individual application help menus in case users get curious. Though since the app is still there techs can run it if they need to pull updates for a particular machine that didn't get the patches we push out. Not elegant but its simple and it works.

Of course if AutoUpdate ever gets reinstalled its name would have to be changed again.

[AdamH]

Originally I hade tried renaming or moving the Microsoft Autoupdate app as I still wanted our Self Supporting users to be able to use it. However what happened when I moved it is that if you actually update the app, it just installs it back into its original location and will keep going into a loop because its not updated.

What I did find that works is disabling (unloading and removing) the MAU LaunchDaemon: com.microsoft.autoupdate.helpertool.plist

Now its available in the menubar for people who have rights to do so, but it won't launch itself when you launch each app for the first time.

[dpratl]

Hi all,

I'm pretty new to JAMF, so please excuse if i'm asking something which is too basic.

I like the idea NOT installing MAU, but how can I handle this?
Is it enough to just applying a script to the Office Installer or do i have to generate a complete new package with composer?

Thank you
Daniel

[philcebutv]

Sorry to revive this post. Was wondering if there's an easy way to get rid of this message at first ran?

[tomr]

I've used the following with pretty good results. It registers the autoupdate app with Launch Services and suppresses those messages. The key is to do it to both the app and the binary.

if [ -e "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app" ] then /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app"
fi

if [ -e "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app" ] then /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R -f -trusted "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app"
fi

[AdamH]

I use a much more down-n-dirty approach.
I strategically break the MAU by removing the daemon that automatically launches it.

rm /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app/Contents/MacOS/Microsoft AU Daemon

It doesn't prevent it from working in the event you have admin users that want to leverage it, but it will not announce itself at first run.

[K0ss]

Hi all,

I have prepared new image with AutoDMG,
I'm already fixed issue with "You are opening the application ..."
But have another issue,
Update checking only if you manually put Help/Check_For_Updates in any MS app, (checked this install older version MS Office),
Have you any idea?

Update)
Already find solution,
Need add key "StartDaemonOnAppLaunch" to User/your_username/Library/Preferences/com.microsoft.autoupdate2.plist

</dict> <key>HowToCheck</key> <string>Automatic</string> <key>SendAllTelemetryEnabled</key> <true/> <key>StartDaemonOnAppLaunch</key> <true/>

Searching best way to populate it to all users (and new)

Thanks in advance,

[Br1con]

sorry, completely brand new here. First post... Please help me out, it's just me and my mac on our network, and i have partitioned my drive to use one with parallels, and one with office for mac. The office for mac side keeps giving me this prompt randomly 3/4 times i open a microsoft app. I've stopped using the parallels partition, and need to remove, or absorb it, but I was just assuming that was the cause for these prompts. Like it was trying to open the app from the other partition at times...

Long story a bit shorter, I lived with it until stumbling upon jamf and this thread. So I tried AdamH 's solution above from last March. I can post the terminal feed but after running his "rm" order I was asked ? and put y, then the "rm" command was "permission denied"

If anybody is listening, let me know. Thanks!

NewbIam

[parthgarg]

check here the detail article
https://applenerds.com/2017/11/20/office-2016-mac-suddenly-opening-microsoft-au-daemon-app-fix/

[cyepiz]

@tomRGA How did you deploy that script? I tried writing a simple bash script with what you wrote, but I keep getting errors in jamf "unexpected exit" etc..

[tomr]

I have a script run via a policy at login and check in set for once per user per computer.

You must capture the current logged in user though and run the commands as them otherwise it will try to execute them as root which won't help the current user.

Where exactly are you getting the errors?