Running Command as logged in user

[bruth85]

Hi All,

I have been combing through the forum and got this far but need some help to see what I am missing. I am trying to set Microsoft Automatic Update to Autotamically Download and Install updates for all users. If I run the script from the system through BBedit it works I have even confirmed its pulling the proper username. However when I run it through Jamf Remote it acts like it runs but no change is made. Here is the code please let me know what I might be missing:

!/bin/sh

currentuser=stat -f "%Su" /dev/console

defaults write /Users/$currentuser/Library/Preferences/com.microsoft.autoupdate2 HowToCheck AutomaticDownload

[mschroder]

I see several potential issues:

• I hope the '#' only got lost in this posting, not in your scriptlet

• you say 'for all users', but your scriptlet only selects the currently logged in user. What about the others? What if nobody is logged in when you run this?

• what permissions does Jamf Remote have

• are you certain that /Users/$currentuser/Library/Preferences/com.microsoft.autoupdate2 exists?

People always write scripts as if we were living in an ideal world, were everything is as it is supposed (assumed?) to be, but in reality things are not always as they should be. So it might make sense to check whether $currentuser has a value. It might make sense to check whether /Users/$currentuser/Library/Preferences/com.microsoft.autoupdate2 exists before trying to modify it.

One of the best comments I ever saw was "this should never happen, but we all know better" before a check for an exotic condition.

I don't know about Jamf Remote as I never use it. I would probably invest a bit more work and

• write an extension attribute that checks the setting you mention
• create a smart group that contains all nodes that don't have the correct setting
• write a script that applies the correct setting, with checks for missing prerequisites and checks on the return code
• write a policy that targets the smart group and executes the script
• have a look at the log of the policy to find out where things go wrong

[mm2270]

One of the pitfalls of running a command such as a defaults write against a user's plist file from within a Jamf policy is that since the policy is usually running the command as root, especially in the case of a natural check-in trigger, it sometimes changes the permissions on the user's plist file to be owned by and only writable by, root, making it inaccessible to the user. When that happens, the OS, or maybe the application that uses that plist, typically creates a new default plist, assuming the original one is corrupt. So you end up back to square one, with a default property list with none of the changes you intended to make.
To avoid this, you usually need to run the command as the user, not just against their files as root. You are doing the latter in your script above, not the former.

All that being said, rather than writing this value into a user's, or all users' plist files, why not make it into a Config Profile, which enforces the setting and can apply to all users? I would go that route with in regards to specific setting you're looking to change.

[bruth85]

@mschroder Yes the # is there in the text I copied but evidently the forum removes it. Sorry when I meant all users I meant all systems, our systems are not shared but single user systems. Jamf remote is just being used as the module to push the policy to the system for test so its simply manually running the Jamf Policy that is on the JSS server. And finally yes I am sure the file exists as when I run the same script/command from bbedit or terminal it makes the appropriate change to MAU.

[bruth85]

@mm2270 sorry new to scripting and was trying to make the change as the user but obviously not. :) I did see a post on here about making it a config profile and I suppose if I set it that way I don't have to worry about users going in and changing the setting. I will try and go back to that post and see what I can do with the config profile, just thought a quick policy with that defaults write command would be faster.