@dswitmer here ya go...

https://github.com/pbowden-msft/NukeOffKeychain

@dswitmer

Are we supposed to use some parameters when deplying this in JAMF? I can't seem to get this working for me.
Thanks. Do any of you have an example of the NukeOff Keychain Policy?

@aaelic24 Package the script, push it out to clients to a /tmp/ dir or so and then use an script (see below) to clear keychain as user.

#!/bin/sh
# get the current user
loggedInUser=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");')

# test if a user is logged in
if [[ $loggedInUser != "" ]]; then
    # get the uid
    uid=$(id -u "$loggedInUser")
    # do what you need to do
    launchctl asuser "$uid" /bin/sh /private/tmp/NukeOffKeychain --All --Force --Jamf
fi

echo
exit 0

@txhaflaire

Thank you for the QUICK response! I will do that. I have tried running that scrip locally on a machine without using JAMF, and for some reason it still did not work. Sorry..

@aaelic24 I just use params in Jamf and run the script directly through a policy:
The script entry:

The policy entry:

The --Jamf flag just informs the script that the script is being ran through Jamf so the first 3 positional arguments are Jamf arguments that should be ignored by the script, and skip to arguments 4 or higher. If you run the command through the command line directly, you just just be able to use one of the other flags.

@nahrens Let me try that.. thanks!

Hey guys, The script worked, thanks a lot for sharing. Anyone an idea of how it makes sense to enrol the script because if the user downloaded/ installed one of the Office Suite products - it has to be enrolled, right? (if not the user getting the notification about keychain)
I've not many experiences with jamf Pro, so I'd like to double check my idea about the following smart group.

Smart Group:

(Department YX
or Department XY
or Department YY
or Department XX)

and

(Application Title Microsoft Excel.app
or Application Title Microsoft Word.app
or Application Title Microsoft Outlook.app
or Application Title Microsoft PowerPoint.app)

Policy: Recurring Check-in - ongoing

thanks

@Flaurian

• New MAS installs do not need to have the script / NukeKeyChain to be run because there are no entries.
• For migrating users from NON-MAS to MAS apps the script have run prior the launch of the MAS apps.

Depending on your needs and migration traject you can define your scopes and if the NukeKeyChain is necessary.

in our situation;

1. User has 1 or more Office apps installed through PKG/CDN
2. Then we scope a migration policy via Self Service. Apps get removed / NukeOffKeyChain runs and new apps get triggered by RECON
3. We report the installations status through an EA.

Here an EA as example. When app is CDN we scope the migration policy to the user.

#!/bin/bash

appTitle="OneNote"

if [ -d /Applications/"Microsoft ${appTitle}".app ]
then
    if [ -d /Applications/"Microsoft ${appTitle}".app/Contents/_MASReceipt/ ]
    then
        result="Installed through App Store"
    else
        result="Installed through CDN"
    fi
else
    result="Cannot find Microsoft ${appTitle}.app..."
    fi

echo "<result>$result</result>"

I'm pretty sure that I had this kind of issue on one of our new computer (installed via DEP, clear without Office Suite)
That's the reason why I'm thinking about a solution for everyone they installed the new version. Sorry for confusing

So I am able to run the NukeOffKeychain, remove the old CDN versions of the Office apps and then install the new VPP versions. However, when I launch one of the apps the first time it is acting like it needs to be activated. I first get the "Get Started" screen and then the "Start Your Free Month" screen show below. Is there something I am missing here?

@kricotta, with today's release of Office (v16.22, I believe), the OfficeAutoSignIn key in a configuration profile set to TRUE should suppress that dialog. I haven't tested yet myself, but this information was given by the Microsoft folks over in MacAdmins Slack.

@talkingmoose thanks for your response, I'm looking in the MacAdmins Slack for this info but can't find it for some reason.

@kricotta, here's a direct link to let you confirm:

https://macadmins.slack.com/archives/C07UZ1X7B/p1548460641991700

Even better! @pbowden with Microsoft made a few updates to this page last night.

https://macadmins.software/mas/

First item confirms the change.

Isn't the MAS version only available for Office 365 users? I was under the impression that it could not be license activated.

@nahrens correct - with the MAS version, you can either activate an existing Office 365 subscription (consumer, commercial, edu) or use in-app purchase to buy a new consumer subscription

@pbowden I have everything in place and when I open a MAS app now it immediately just prompts for a sign-in. This is expected behavior or is there a way to activate in a manner that allows our students to use the MAS Office apps without a login?

@kricotta Students will still need to sign-in to O365 to activate the license, even with MAS builds. Depending on your set up, you might be able to make this a little easier for them by pre-filling their email address/UPN through the 'OfficeActivationEmailAddress' preference, but either way, they'll still need to enter their password.

@pbowden

You are the wizard of office, so maybe you can help:). Do you know both in the new VPP and old setup what triggers when updates have been installed, but an restart of the application is needed ?. I just need to figure out in which file this happens, so I can see users who have updates installed, but awaiting an restart of the application

@jameson not as old as Gandalf though (yet!). Can you elaborate a bit more on your question or give me a scenario?

@jameson I just re-read your question a couple of times. It seems like you're trying (wanting?) to install app updates without closing them. Right now, this isn't possible with MAU or MAS. If you forcibly apply the update without closing the app, it'll more than likely crash a few minutes later, as the in-memory process will try to read a resource from disk, which will have changed, which will cause the app to fault.

Suffice to say, we are actively working on an improvement to MAU where it will clone the active app, update the clone, then swap paths on next app launch. We're still a couple of months away from releasing this. The engineering work has been done, but we need to do significant testing of all scenarios before we release it.

Hope this helps!

Paul.

Just for information, I had the keychain error also for clean macOS devices with the first installation of Office via VPP. I fixed it now with policy via Self-Service and your posted script. Thanks again but I still if the issue with downloading the apps from the VPP store. Sometimes the user has to the process via Sefl-Service three times.

@pbowden It sounds good the new solution for Mau. However, right now it is not what I am looking for. When updates have been applied users get an small notification sliding in the app needs to be restartet to update, but most users just ignore this.

So If I could make an extension attribute, so I can see which clients have restart pending for application. But to make such an extension attribute, I need to know which file(s) I should look at, that shows that an app restart is pending

Hope it make sense

@Flaurian we are seeing this behavior in Self Service too, sometimes office apps will install on the first attempt via Self Service. Other times it takes three or four attempts before it will install.

@jameson ahh, thanks for the info - I understand your question now. Basically, your EA pseudo-logic would look like this:

MAUPID = (pgrep 'Microsoft AutoUpdate Assistant') // get the process id of MAU's daemon if [ $MAUPID ]; then // only do the following if MAU's daemon was running PKG = (ls $TMPDIR/MSau_$MAUPID) // get a list of the package filenames that MAU has pending fi echo "<result>$PKG</result>"

That's the basic logic you'd use when running at the console. You'll need to do some investigation to figure out the best way of running this in the context of the current user, especially as $TMPDIR is a user-based environment variable.

Hope this helps get you started!

Paul.