You best bet would be to upload the script to Jamf and create a Self Service policy to run the script instead of trying to install it and have the users run the script locally. 

If there are commands that need to be run as the logged in user, please see this article:

https://scriptingosx.com/2020/08/running-a-command-as-another-user/

What’s the sonoma time / date bug?  

can you post the script

Sorry, didn't expand enough on the issue.

The Apple Time bug reverts the date/time to 5-6 months ago on the computer. The browsers, all apps (including Self Service) are pretty much unusable. Sometimes I am able to remote in with Teamviewer, sometimes not. Jamf connection is no longer valid due to SSL cert issues with the date/time. 

The Apple Time bug reverts the date/time to 5-6 months ago on the computer. The browsers, all apps (including Self Service) are pretty much unusable. Sometimes I am able to remote in with Teamviewer, sometimes not. Jamf connection is no longer valid due to SSL cert issues with the date/time. 

The script file is just one command:  sudo sntp -sS time.apple.com

This command fixes the issue temporarily so I can remote in and assist. However, when I can't remote in or there is a needed Admin account missing, I am screwed. I need to be able to have the user run this script. 

As mentioned, use self servic 

add the command to files and processes without the sudo and test!

I’ve not seen that issue reported on any of our macOS 14 fleet.. oddness.. 

Jamf is unusable and disconnected while the time is so far off. Same goes for Self Service. 

Good point! Cache the policy (set to ongoing and offline ) and set it to run at startup or login, 

The time bug should have been fixed in the past few versions of macOS Sonoma (14.3.1 as I write this).

Yes it should have. I have a few users that are still on 14.1, 14.1.2 that are having the issue. Hopefully the latest OS version fixes this bug. It leaves the user dead in the water until we can resolve. 

I setup a policy with just Files and Processes, input the Execute Command for my one-liner command. I set the frequency to Ongoing (available offline) and triggers to Startup and Login. Hopefully this will work as expected.

Just to confirm, If I have the policy set to Ongoing (available offline) but the triggers are only Startup/Login, then it will only trigger during every Startup/Login event, right? It will not run the policy every check in unless I select Recurring Check In? Just worried about network/device performance with running this command too often. 

correct.. but test with startup.. test with login... see what works best.. 

Any reason you're not having those users update to 14.3.1? Unless you're running Jamf Pro on-prem and older than JSS 11.0 you can use the Declarative Device Management Scheduled Update capability added with macOS Sonoma to easily force a deadline for the upgrade.

We have been manually prompting users to update. 

How do we schedule forced upgrades?

create smart group with scope for macOS 14.x - then use the beta software update to send the update with a scheduled complete time. 

scope on a small group 1st to test and understand the workflow, then expand the scope of the smart group

To be honest, it doesn't look promising with the reviews I have been reading. I may stay off it for a while until they have better reliability. 

what reviews.. ? citation required.. I have the whole fleet on 14.x  

Apples line is, the only secure version of macOS is the most up to date.. and if your in any business that does compliance.. its a requirement. 

Reading through the MacAdmins Slack channels