+5Am I able to stage a .sh file on my user's computers?
This script contains a sudo command but I want to be able to run from the user's account. This will be a break glass script to fix the stupid Sonoma Time/Date bug.
What file permissions would I need to assign as well?
Best answer by jamf-42
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,
+19You 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/
+17What’s the sonoma time / date bug?
can you post the script
+5You 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/
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.
+5What’s the sonoma time / date bug?
can you post the script
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.
+17The 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..
+5As 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.
+17Jamf 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,
+25The 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.
The time bug should have been fixed in the past few versions of macOS Sonoma (14.3.1 as I write this).
+5The 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.
+5Good point! Cache the policy (set to ongoing and offline ) and set it to run at startup or login,
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.
+5Good point! Cache the policy (set to ongoing and offline ) and set it to run at startup or login,
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.
+17Just 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..
+25Yes 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.
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.
+5Any 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?
+17We 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
+5create 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.
+17To 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.
+5what 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
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
