@talkingmoose That entry for StartDaemonOnAppLaunch should be:
<key>StartDaemonOnAppLaunch</key>
<true/>
@sdagley Thanks! I just ran in to this.
The Apps are all registered, however MAU does not seem to be Updating.
Hello,
when running the msupdate as root the msupdate binary throughs out a crash log. running the same as a locally logged in user works.
May someone know what's wrong ?
after 2nd or 3rd run as root the error goes away but
msupdate -l
Checking for updates...
No result returned from Update Assistant
gives always no result.
Mike
@mbracco You're not supposed to run msupdate as root. If you use @pbowden's script for calling the tool via Jamf (https://github.com/pbowden-msft/msupdatehelper) it'll handle that for you. Note the link on that page for the video tutorial on msupdate.
@HNTIT Have you updated MAU itself?
ok for that. i tried to run a policy with msupdate -i to install all updates. maybe the wrong turn. I'll give the script a try ...
Thank you for your help
Mike
@sdagley
All my Machines are on MAU 3.18.1804.
That's the Version I deployed via JAMF.
I manually downloaded and installed 4.0.1805 on a test machine to see if THAT would update to 4.0.1806 but it didn't.
@HNTIT The current version of MAU is 4.0.18061000 and you need it for the Office 16.14.18061302 updates.
@sdagley
All my Machines are all running MAU 3.18.1804.
All my Machines have already auto-updated the office apps 16.13.1805 or 16.14.1806
I am still waiting for them to autoupdate MAU to 4.0.1805 or 4.0.1806, that's the issue I have, the Office Apps auto-update perfectly, it's just MAU that dosent
@HNTIT I have auto updates disabled, and only update by calling msupdate via @pbowden's Jamf Helper script. I wasn't able to deploy the Office 16.14.0.18061000 updates with MAU 4.0.1805 so I used Jamf Pro to deploy MAU 4.0.1806 (you'll find a link to the standalone MAU installer at macadmins.software). It may also be possible to use the config profile @talkingmoose posted earlier in this thread make sure MAU is in the list of apps that should be updated. Or you can call msupdate directly to update MAU.
@sdagley
I did the same as you a couple of months back, I Deployed MAU 3.18.1804 with JAMF under the assumption is should self update.
I have a config profile with all the Applicatons registered for updated, MAU included.
if I manually run msupdate it says MAU has no updates available
If I run msupdate -c I get this, which would sort of imply the AutoUpdate App is registered for updates but it does not know what version is installed??
AutoUpdateVersion = "3.18.18041000";
ChannelName = Production;
HowToCheck = Manual;
LastCheckForUpdates = "29 Dec 1 at 23:58:45";
ManifestServer = "";
RegisteredApplications = (
{
"Application ID" = MSRD10;
ApplicationPath = "/Applications/Microsoft Remote Desktop.app";
VersionOnDisk = 983;
},
{
"Application ID" = MSFB16;
ApplicationPath = "/Applications/Skype for Business.app";
VersionOnDisk = "16.18.51";
},
{
"Application ID" = IMCP01;
ApplicationPath = "/Applications/Company Portal.app";
VersionOnDisk = "52.1805002.000";
},
{
"Application ID" = OPIM15;
ApplicationPath = "/Applications/Microsoft Outlook.app";
VersionOnDisk = "16.14.18061302";
},
{
"Application ID" = ONMC15;
ApplicationPath = "/Applications/Microsoft OneNote.app";
VersionOnDisk = "16.14.18061302";
},
{
"Application ID" = PPT315;
ApplicationPath = "/Applications/Microsoft PowerPoint.app";
VersionOnDisk = "16.14.18061302";
},
{
"Application ID" = MSWD15;
ApplicationPath = "/Applications/Microsoft Word.app";
VersionOnDisk = "16.14.18061302";
},
{
"Application ID" = MSau04;
ApplicationPath = "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app";
},
{
"Application ID" = XCEL15;
ApplicationPath = "/Applications/Microsoft Excel.app";
VersionOnDisk = "16.14.18061302";
}
);
StartDaemonOnAppLaunch = false;
UpdateCache = "";
@HNTIT You might want to post a question for @pbowden in the MAU4 channel on the MacAdmins Slack
Don't have an account on there.
Did try addressing posts on here to him, but nothing back yet
@HNTIT You can get a free account for MacAdmins slack here: https://macadmins.herokuapp.com
Tried Posting there, no luck.
My Config Profiles were based on the Original Beta Versions, so i have now changed my registration ID for the AutoUpdate from MSau04 to MSau03.
I now see updates available is i do msupdate -l, but they never install.
If i do msupdate -c, MAU never shows a "Version On Disk" I am wondering if this is an issue?
Does anyone actually have this working reliably? It seems 'fine' in basic testing but as far as I can tell the msupdate process is a bit....flakey or obtuse?
I've got machines with Office 2016 15.x. I am installing the latest MAU 4.2 from macadmins.software. Then I'm running Pbowdens script on the login window.
I also have a configuration profile scoped to the machine providing the .plist at the computer level.
So far, I have MS Word updated on one test system, on another nothing happens at all. Both are identical. These are labs so plenty of machines to test with.
Why would MS word update and no other apps? These systems have OneNote and PPT/Excel also. I'm yet to be convinced that this is a reliable solution. Do I need to run this script again and again to get it to work?
My goal is to be able to run updates from the loginwindow with no users installed. For some reason, MS continues to encourage users to update unless you remove MAU from the system so the only way we can provide an environment to the user that doesn't offer updates is to add/remove MAU each time we want to run updates...fun...
@macsysadminjamf MAU will only update apps that are registered. look at talkingmoose he has a configuration profile that will register apps for everyone.
thannk you for the reply burdett.
I'm using that configuration profile from talkingmoose (with the correction to the last key also)
okay, so i've manually added that.plist to the computer. there may be some other JSS related issue here but at least i'm seeing updates listed for the root user when run /path/to/msupdate --list
when I run the msupdate command from the loginwindow (either with jamf or ARD) it shows the apple logo and Microsoft Autoupdate and Help menus on the top of the loginwindow above the username/pass fields. It's very weird and obviously not a desirable behavior. The QUIT button is available in the menu and fully functional.
Not sure how a GUI application is launching from the login window but thats what this command below gives me.
/path/to/msupdate --install --apps xcel15
edited to add that i'm running the latest MAU and the --list command is still showing MAU 4.2 as an available download even though that's what it's running
I think it's clear this is an issue with registration or my running the command as root, but I think the fact there's no benefit to doing it this way is what gets me. With a lab environment, where updates are most critical, managing this seems so unreliable. We just want to have a system that installs updates in the backgrounds without the users having to see prompts to upgrade. The fact the only way you can do that is to uninstall MAU is a major part of the hassle of this. This binary badly needs an override command where it just does what you tell it to. No user is going to be running the MSupdate binary from the the commandline, save perhaps via Self Service. Is all of this just to support people who install to locations other than /Applications?
Again because we need to make user students don't get prompted while they use MS apps, we have to remove MAU completely after it's installed.
So to install updates in a silent way, without having 45 kids get dialogues to update randomly during classes, the process is:
-have all users logged out
-install MAU 4.2
-install .plists to trick MAU 4.2 into thinking the applications are registered so that it can be run outside the user context
-run ./msupdate --install --apps xcel15 mswd15 pppt315 onmc15
-wait a reasonable amount of time
-uninstall MAU 4.2
I think I need to leave this on this Friday PM and start fresh next week. Thanks for the help folks!
The msupdate tool needs to be called when a user is logged in.
If someone can give me a good reason why a command line binary with no GUI must be run with a console user logged in, I'm all ears. I'd love to at least know why MS is trying to keep admins from updating properly.
I'd also love to be wrong about this. I'm sure I'm missing something, but I think part of the challenge is that I fundamentally don't understand why I'd need a commandline binary that only can be run by a console user...
The msupdate tool calls the Microsoft AutoUpdate to do the actual work of installing the updates. That’s a GUI app and you really don’t want to be running it without a user logged in.
@macsysadminjamf, Microsoft isn't trying to keep admins from updating. As @sdagley responded, it's a command line tool that calls the GUI app. You may notice when running on a Mac with a user logged in the app icon appears briefly in the dock.
Only the GUI app contains the logic to correctly download the necessary software (version, delta update, full update, Insider updates, etc.). The msupdate command line tool relies on the app for all that.
You're right. This isn't ideal, but it's more than we had a year ago. It'll also get better as we give feedback to Microsoft. If you're not already part of the MacAdmins Slack workgroup, I highly encourage you to register and pop into the #mau4 channel. You'll find Olof Hellman from Microsoft has joined us there. He's now the principal developer of MAU 4. He's listening and interacting with us.
If you'll be attending JNUC this year, we also have @pbowden (Office for Mac installers, updaters and general wizard without a long beard) and Jeff Kalvass (PM for Outlook for Mac) coming to present and meet folks. Bring thoughts. Bring ideas.
