Setting wallpaper script via JAMF policy not working

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

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:

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

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.

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.

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

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.

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.

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:

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.

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.