Trigger a policy or script at the first user login only?

@dhanes "Once per user, per computer" trigger?

You should be able to accomplish this with a LaunchAgent that is set to run once, at login.

If you put the dockutil script locally on the mac (maybe as part of your imaging/configuration process), you can set the LaunchAgent to run that script.

@bentoms Yeah, I thought of that. But if I create a policy scoped to all machines, with Once Per User & Once Per Computer, wouldn't that mean the next time anyone logs into their machine (new or not) it would run the policy?

@dhanes While I've used "once per user per computer" in the past, if the policy fails it falls to me to manually flush the failure in order for it to run again for that user on that machine.

Because of this, I've shifted in favor of setting my first-login policies to run at an ongoing frequency, but as part of whatever needs to happen with the policy (for me this is usually setting some settings/preferences via script) I have in my script a command to write a dummy receipt on successful completion. At the beginning of the script it checks if a dummy receipt exists for the user and if found the script just exists. As added insurance I set these few policies to be available offline in the event computers can't talk to the JSS.

The thing I've just run into in my testing however is if more than one user is logged in this can cause whatever I've told the script to do for the logged in user to fail, so I'm in the process of remedying that now.

You can also kind of achieve the same thing with a script that runs every login but checks for a flag of some type before doing anything.
I do dockutil like this so that if someone wants to rerun the dock they delete the flag file and log out and back in.
We also have a particular plist file on our machines that we use to write various flagging and logging information to for later reference, that works quite well as defaults is a nice way to access this info.

@perrycj But how does the LaunchAgent know to run it ONLY if this is a fresh account?

@dhanes

I think LaunchAgent is what most admin use.. I just have my 1st run script that was triggered by the LaunchAgent delete itself and the LaunchAgent.

C

@dhanes It will run one time only, if you tell it too. I assume you'll just add it to your first run workflow.

For existing macs, you can package up the script and LaunchAgent as a dmg and deploy it with FUT and FUE to ensure it goes on all users in the future on a specific mac. If you don't want it to run on an existing mac/user account but do for future accounts on the same mac, you can take advantage of the "execute command" field in a policy to delete the LaunchAgent and/or script after it's deployed. It will run that command last in the policy and if the LaunchAgent isn't present within that user, it can't run the dockutil script. It will stay in the User Template though, so future users will get it.

Also, what @gachowski said, to just have the script and/or LaunchAgent delete itself once it runs on login.

https://github.com/chilcote/outset !

Outset saves my bacon on the reg.

-Lee

I may look into LaunchAgents. I like the idea of filling the template, then calling a script that removes the LaunchAgent... Now...Does anyone have a good resource for creating LaunchAgents? haha. This would be my first one.

@dhanes There are lots of ways to make a LaunchAgent but I would look into Lingon X. I've used it in the past and it's pretty easy to use. You can find it here

@dhanes LaunchControl is free and the interface is easier on the eyes, check that out for easier creation of Launch Agents/Daemons, it also has an excellent help section if you're just getting started. You'll need to know about launchd so also check out this site.

But in answer to your question, the simplest and fastest solution to your issue right now is probably Outset. @chilcote made this excellent tool which circumvents issues I've found with Casper running scripts and actions at user login, strangely Casper isn't that reliable I've found.
Outset on GitHub <-- Dig it

Hi,

isn't the contents of /System/Library/User Template/ exactly for that purpose: define how a freshly created account should look like. You dump your settings there and the user takes these settings, but has the freedom to change them.

So for reasonable starting values for package ID you create /System/Library/User Template/English.lproj/Library/Preferences/ID.plist, and every account that is created will get these settings.