We have some users who have long since received a new Mac but for what ever reason they won't return the old Mac. I see in Jamf Pro that they are still using these old Macs and the new ones. We could send a remote lock command to the old Macs but I think that would complicate matters with our remote users. Instead, I want to use Swift Dialog to launch a full screen alert to the users that they need to return the old Mac. The only option that will be provided will be to shut the Mac down. I will include a 60 second timer. When it runs out, the Mac will shut down. I want to use a launch daemon to launch a script that I will install locally on these old Macs. I'm having trouble getting the script to launch using the launch daemon. The script does launch immediately after the launch daemon gets installed and loaded, but it does not launch when the computer is restarted/shut down and then started up again. I see in the error log an entry that says "id: : no such user". It appears that the script is being launched as a user that doesn't exist. I added the user key in the launch daemon to run as root. This has had no effect. I have used launch daemons to do a lot of things at start up in the past but launching a script eludes me. How do I make this happen? The launch daemon does launch the script right after my Jamf policy installs it. It's just not launching the script at the time I need it to. I could have the launch daemon run a Jamf policy that would show the Swift Dialog alert, but I want this to work even if the Mac is offline.
Launch a script at startup/login using a launch daemon?
+23
+26As @jamf-42 said, this is not a problem for you to solve. If your field service team (Assuming you have one) is unable to collect the devices for whatever reason, and the users are refusing to return the devices you escalate.
Escalation path:
- Users direct manager
- Deputy director of the users business unit
- HR/Security
- If someone with the risk ownership ability says forget about collecting the device, than delete it from Jamf and move on.
I recommend sending the remote lock command, it does not wipe the device and will force the user to engage with you. Ultimately the devices should not be in the field anymore, so even wiping them to remove organizational data is fair game once certain deadlines are past.
+11While i agree with the statements that have already been posted; not really an admin problem and more of a HR issue; in an effort to solve the underlying issue. for science. I have used the below launch agent creator, to run many scripts at login without issue. The script must be installed somewhere locally, etc, but it seems to work well for me. Hope it helps, check the vars for different use cases
#!/bin/bash
# launchDaemon and Agent creator
# feed it with;
# launcher type = Daemon or Agent
# launchItem = path to the app being launched, the full path to the executable
# launcherPlistName = unique bit of the plist name. it will be com.mycorp.{unique bit}.plist
# isScriptIn = is this a script yes or no. defines which plist will be used
#1) $4 launcher type = Daemon or Agent
#2) $5 launchItem = path to the app being launched, the full path to the executable or script
#3) $6 launcherPlistName = unique bit of the plist name. it will be com.mycorp.{unique bit}.plist
#4) $7 isScriptIn = is this a script yes or no. defines which plist type will be used
launcherTypeIn="Agent"
launchItem=""
launcherPlistName=""
isScriptIn="yes"
# set input strings to lower to avoid case failure
launcherType=$(echo $launcherTypeIn | tr '[:upper:]' '[:lower:]')
isScript=$(echo $isScriptIn | tr '[:upper:]' '[:lower:]')
#echo "$launchItem"
#
case "$launcherType" in
"daemon" )
#echo "**** Daemon ****"
launchFolder="LaunchDaemons"
;;
"agent" )
#echo "**** Agent ****"
launchFolder="LaunchAgents"
;;
*)
echo "**** no launcher type selected. Exiting *****"
exit 1
;;
esac
case "$isScript" in
"no" )
cat << EOF > /Library/${launchFolder}/com.mycorp.${launcherPlistName}.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.mycorp.${launcherPlistName}</string>
<key>ProgramArguments</key>
<array>
<string>${launchItem}</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
EOF
;;
"yes" )
cat << EOF > /Library/${launchFolder}/com.mycorp.${launcherPlistName}.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.mycorp.${launcherPlistName}</string>
<key>ProgramArguments</key>
<array>
<string>/bin/bash</string>
<string>-c</string>
<string>${launchItem}</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
EOF
;;
*)
echo "**** no type selected. Exiting *****"
exit 1
;;
esac
/usr/sbin/chown root:wheel /Library/${launchFolder}/com.mycorp.${launcherPlistName}.plist
/bin/chmod 644 /Library/${launchFolder}/com.mycorp.${launcherPlistName}.plist
+36You want to add the launchd item to /Library/LaunchAgents instead of /Library/LaunchDaemons.
Launch agents run as the currently logged in user.
+23I appreciate the help! I totally agree that this is an HR problem. I have been asked to do this. I first explored the possibility of automating sending a remote lock command to those Macs, but I realized that would make the situation harder to deal with. I can build an escape hatch in the Swift Dialog window to allow support techs to disable the shut down. We just want to make using these Macs impossible. That said, I really do want to know how to use a launch daemon to launch a script. There are other uses for that.
+11I appreciate the help! I totally agree that this is an HR problem. I have been asked to do this. I first explored the possibility of automating sending a remote lock command to those Macs, but I realized that would make the situation harder to deal with. I can build an escape hatch in the Swift Dialog window to allow support techs to disable the shut down. We just want to make using these Macs impossible. That said, I really do want to know how to use a launch daemon to launch a script. There are other uses for that.
if that is the case, i would just lock them, if you lock them, they will come back; i've had to do that in the past; maybe a swift dialog window saying, please migrate data before <date> and lock it after that with a polite request to return to the home office.
+23if that is the case, i would just lock them, if you lock them, they will come back; i've had to do that in the past; maybe a swift dialog window saying, please migrate data before <date> and lock it after that with a polite request to return to the home office.
I think I will do that. I could make it pop up at every check-in and make the window full screen.
+12I have a script that runs from a Launch Daemon.
They are very particular about permissions settings.
Launch Daemon Scripts have to be set to 700
And The LaunchDeamon plist has to be 644
All I then use is this...
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.unique.name.for.Daemon</string>
<key>ProgramArguments</key>
<array>
<string>/Path/to/script/somescript.sh</string>
<string>-argument</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
This will run once after every boot of the Mac. it runs as root, because it is a LaunchDaemon.
But if your laptop users are anything like mine, they never shut them down, only close the lid.
Launch Daemons do not like to interact with the GUI, which might be where you are running into issues.
If all you want is for the script to run, at a time you want. I would simply load it up as a script in JAMF, and make a policy to run the script. assign it to your group of devices. I would make the policy available off line, it will download your script to the Mac and run it from there. Jamf will run the script as root.
+17@howie_isaacks You can also try outset.
Outset is a utility application which automatically processes scripts and packages during the boot sequence, user logins, or on demand.
Thanks
+23I decided to abandon doing this. What I will do instead is have a policy run at every check-in to make these Macs an annoyance to use. After a certain amount of time, I will lock them. I agree this is an HR problem but if I can't get these Macs returned I will make them unusable.
+9I decided to abandon doing this. What I will do instead is have a policy run at every check-in to make these Macs an annoyance to use. After a certain amount of time, I will lock them. I agree this is an HR problem but if I can't get these Macs returned I will make them unusable.
We're having a similar problem so let me invite you on how to be as annoying as possible. If you are using a VPN, disable their VPN. This can be from an exclusion group that revokes a config profile or you can go more nuclear.
If you make a static group to put these devices into, you can automate the removal of all apps. Push uninstaller, after uninstaller to remove programs. Add the same group to a device restriction for Apple Mail, Safari, System Settings, etc. Empty the dock. Set the wallpaper to "This computer has been marked for decommission, please return to "your info" ASAP. Change permissions to their home directory.
You can be intense or use a light touch. For example, you can have the decom static group. That does one of the above and runs a script that updates an EA with the time it was added to the group. Day 2, the EA dumps the computer into a smart group to trigger the next round of restrictions. Continue on and on each day until the computer is a pretty paper weight
Mix and match or use all. Hope it helps.
+23We're having a similar problem so let me invite you on how to be as annoying as possible. If you are using a VPN, disable their VPN. This can be from an exclusion group that revokes a config profile or you can go more nuclear.
If you make a static group to put these devices into, you can automate the removal of all apps. Push uninstaller, after uninstaller to remove programs. Add the same group to a device restriction for Apple Mail, Safari, System Settings, etc. Empty the dock. Set the wallpaper to "This computer has been marked for decommission, please return to "your info" ASAP. Change permissions to their home directory.
You can be intense or use a light touch. For example, you can have the decom static group. That does one of the above and runs a script that updates an EA with the time it was added to the group. Day 2, the EA dumps the computer into a smart group to trigger the next round of restrictions. Continue on and on each day until the computer is a pretty paper weight
Mix and match or use all. Hope it helps.
I love this. I have always been a strong advocate for users, especially creatives. Since it's my job to manage all these systems and ensure that everyone has the best hardware possible, I need to be able to decommission older Macs or put them into use as spare or test computers, or just get rid of them. When these users hold onto the old Mac and refuse to give them up they make my job harder, especially the ones who don't even use the old Mac. They just have it stashed away somewhere. The last time I checked, I have just over 100 Macs that have not checked in for over 30 days, the same with inventories. I don't like having that statistic always in my face because it makes it appear that we're not successful getting new software out to everyone and there's always this big group that doesn't get macOS updates. I can't just delete these systems from Jamf Pro without knowing where they are first. This didn't used to be so hard but this is a big company where a lot of people just do their own thing without following best practices. When I worked for smaller companies we had a better handle over this.
Reply
Most helpful members this week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.