Setting wallpaper script via JAMF policy not working

KAndrews5725
New Contributor III

I've scoured JAMF Nation and the internet, and have found a little information here and there, but a lot of it is outdated.  I'm wondering if anyone has had any luck in Big Sur using a policy to set the wallpaper of a desktop via JAMF? 

We're using the recommended settings for both the policy and profile restrictions as documented in JAMF, however, when we try and run the following script after the package containing the wallpaper is downloaded and installed, we don't immediately see the wallpaper change on the desktop.

I can get it to work without it immediately changing (like when someone logs out of their computer) but it would be nice to have it work instantly.  Any suggestions would be appreciated!

 

#!/bin/sh

/usr/local/bin/jamf recon

/usr/bin/chflags hidden /Users/Shared/Wallpaper/fms-wallpaper.jpg

osascript -e 'tell application "System Events" to tell every desktop to set picture to "/Users/Shared/Wallpaper/fms-wallpaper.jpg" '

9 REPLIES 9

Tribruin
Valued Contributor II

Take a look at desktoppr . I haven't used it, but I have heard good things. 

Thanks, I've heard of it, but I was just trying to avoid having to download some other package onto the user's laptop.  It may be that the current script just doesn't work in Big Sur and Monterey.

Keith

ewu-it
New Contributor III

The most likely reason this is not working is because you now have to have a configuration profile in place that gives permission to the jamf binary to make SystemEvent calls like you are trying to do here.

 

Using the desktoppr application performs the same function and negates the need for the configuration profile.  You can add the package for desktoppr to your existing policy that puts the desktop background picture in place, it is a 73kb package and a single 231k binary which is already universal.

You would simply replace the line in your script to something like the following:

/usr/local/bin/desktoppr all "/Users/Shared/Wallpaper/fms-wallpaper.jpg"
--
Howard Griffith--Endpoint Systems Engineer--Eastern Washington University

mav_eric_jx
New Contributor III

There also needs to be a configuration profile that allows applescript to make SystemEvent calls as well not just JAMF. 

AppleScript_PPPC.png

The Profile works as I have policies that run AppleScripts perfectly well but various attempts with the desktop picture kept failing which led to me using desktoppr.

KAndrews5725
New Contributor III

Ok, this is interesting.  I created a test policy which would download and install the Desktoppr.pkg file, as well as download and install the wallpaper.pkg file.  Both install fine.  I then have a script which hides the wallpaper.jpg file (works fine) and then tries to run the following command in the script:

 

/usr/local/bin/desktoppr "/User/Shared/Wallpaper/fms-wallpaper.jpg"

 

The script exits with no errors, but the wallpaper does not change.  The only time I have been able to see the wallpaper change is if I log out, or remove the device from the config profile, and add it back in so it runs the profile installer again.  The profile we have is currently setup to restrict the desktop wallpaper and lock it to the file above.

 

Screen Shot 2021-10-29 at 12.41.58 PM.png

ewu-it
New Contributor III

In that case you could scope the profile that puts the restriction in place to a smart group where the wallpaper and desktoppr installation packages have been installed.

This should allow for the setting of the background properly before it gets locked in, assuming your installation is what is initiating the wall paper change.

--
Howard Griffith--Endpoint Systems Engineer--Eastern Washington University

KAndrews5725
New Contributor III

Thanks for your reply! I did create a smart group which shows me which devices have received the packages so I know it's working at least from the download and installation standpoint. I'm just not able to see that wallpaper change reflected on the device until I log out or remove and add back in the config profile that has the restriction.

 

I think right now the easiest thing for me to do is to simply remove the profile and immediately add it back on which should then make the change based on the testing I've done on some spare laptops. Even when I've tried running the command in terminal on a device I am still unable to see the wallpaper change and I've tried several different wallpapers in several different locations on the device.

ewu-it
New Contributor III

One other thing to keep in mind is that the desktop wallpaper is considered in the user context in macOS.  That means if you are trying to use JAMF to make the change, your script has to issue the command in the context of the user and not root (which is the default way JAMF runs scripts). That means you may have to probably do something like this:

 

loggedInUser=$(stat -f %Su /dev/console)
su $loggedInUser -c '/usr/local/bin/desktoppr "/User/Shared/Wallpaper/fms-wallpaper.jpg"'

 

We accomplish this using a tool called OutSet which allows you to run scripts in user context either once or every time the user logs in, as well as other ways.

--
Howard Griffith--Endpoint Systems Engineer--Eastern Washington University

mav_eric_jx
New Contributor III

For such cases I create a local folder under /opt/local/<companyname>  and use it to create a (hidden) empty file that indicates that the policy has run. In my case the policy contains a script that runs desktoppr using su -l $currentuser.

An extension attribute DefaultWallpaper checks if the file exists and gives a true or false in return while a smart group contains the macs for which the result of the extension attribute is true. I scope the policy that locks the  wallpaper to this smart group.