Thanks for your feedback Timothy! Yes, right now, MAS managed distribution of apps (Office and non-Office) has some challenges with updates if the apps are continuously left in a launched state (e.g. OneDrive, Outlook). So, right now, I'd recommend deploying Office through our standard PKG download mechanisms. See macadmins.software/mas for more details. Also, look out for a video in a couple of weeks where I discuss the pro's and con's of each approach. I hope this helps!
Any input on how the best way it to auto update the office applications. I use a config profile forcing auto updates, but users don´t ever restart the application to get this updated. Is there any workarround on this?
Hi Peder. Typically, it's best to use Microsoft AutoUpdate in the 'AutomaticDownload' mode. Through this, each machine will detect, download, and apply updates as soon as they become available on our CDN. Users will see a notification if the app is open, but if they continually hit 'Update Later' it becomes a challenge to force the update. Three pieces of advice here - 1) make sure that all users are running MAU 4.11 - there were some issues with updating later in earlier versions 2) we're working on a 'deadline' feature for MAU where in the future, IT can force the user to restart 3) If you absolutely must force the user to update, you can use the installer as an updater, and simply force a reinstall with the latest Suite PKG. Users will be given a 2-min warning to quit apps, but if they still don't close them, we'll force close the apps as cleanly as possible, and begin the update.
@@paulbowden3724 Thanks. Is there any way a "trigger" that can be found (like specific file exisit etc) if there is fx pending outlook updates on a client that awaits restart?. So I could make a smart group based on that, and then create script to force restart of the application that has the update pending
@@pederjensen7288 It's a little bit hacky, but essentially, you'd need to find the process ID (aka PID) of the MAU Daemon (e.g. prgrep), then look in $TMPDIR/MSau_ and look for .pkg files. If there's a PKG file present, then an update for that app is pending (the app name is part of the filename for the pkg). You'd need to run all the above in the security context of the user. The alternative approach is to add the app version Extended Attribute to Jamf (see my github), and use that to determine if a machine didn't get updated. Hope this helps!
The dead packages segment broke me LOL well done.
Haha! Me and my daughter (Jessie) had fun putting this scene together. Thanks for your feedback Nick!
This is so much easier now Office is in the App Store! Great video, regardless!
I don't know wtf is going on at microsoft-mac, but I love it.
How many kegs of beer do we owe you so far?! :)
Haha! Thanks so much for your kind feedback Don!
Great video. Question: If I am using DEP, VPP and deploying MacApp Store apps, is there an advantage to going this direction instead?
Thanks for your feedback Timothy! Yes, right now, MAS managed distribution of apps (Office and non-Office) has some challenges with updates if the apps are continuously left in a launched state (e.g. OneDrive, Outlook). So, right now, I'd recommend deploying Office through our standard PKG download mechanisms. See macadmins.software/mas for more details. Also, look out for a video in a couple of weeks where I discuss the pro's and con's of each approach. I hope this helps!
If I push office 365 business pro and have licenses for business premium and some office 365 E3 will that matter?
Any input on how the best way it to auto update the office applications. I use a config profile forcing auto updates, but users don´t ever restart the application to get this updated. Is there any workarround on this?
Hi Peder. Typically, it's best to use Microsoft AutoUpdate in the 'AutomaticDownload' mode. Through this, each machine will detect, download, and apply updates as soon as they become available on our CDN. Users will see a notification if the app is open, but if they continually hit 'Update Later' it becomes a challenge to force the update. Three pieces of advice here - 1) make sure that all users are running MAU 4.11 - there were some issues with updating later in earlier versions 2) we're working on a 'deadline' feature for MAU where in the future, IT can force the user to restart 3) If you absolutely must force the user to update, you can use the installer as an updater, and simply force a reinstall with the latest Suite PKG. Users will be given a 2-min warning to quit apps, but if they still don't close them, we'll force close the apps as cleanly as possible, and begin the update.
@@paulbowden3724 Thanks. Is there any way a "trigger" that can be found (like specific file exisit etc) if there is fx pending outlook updates on a client that awaits restart?. So I could make a smart group based on that, and then create script to force restart of the application that has the update pending
@@pederjensen7288 It's a little bit hacky, but essentially, you'd need to find the process ID (aka PID) of the MAU Daemon (e.g. prgrep), then look in $TMPDIR/MSau_ and look for .pkg files. If there's a PKG file present, then an update for that app is pending (the app name is part of the filename for the pkg). You'd need to run all the above in the security context of the user. The alternative approach is to add the app version Extended Attribute to Jamf (see my github), and use that to determine if a machine didn't get updated. Hope this helps!
@@paulbowden3724 Thanks I will try. Is there any specific folder where updates are downloaded to before they are installed
@@pederjensen7288 Yes, the updates are downloaded to $TMPDIR/MSau_ before they are installed (where PID is the process ID of the Microsoft AU Daemon).
Ah! Sweet nod to The Sixth Sense.