Is it possible, either via Casper or script to have say Dockutil run ONLY at the first time a user logs into a new machine.
I don't want to reset the users dock every time they log in, but I wasn't sure if I could piggy back off of the Setup Assistant for a new user and trigger dockutil to reset their dock.
We are not in DEP (yet) and currently have our techs bind a new machine to the network, and then deliver it to the user, and I would like to have a policy in place to run when they first login, but only if this is the first time the account is logging into the machine.
@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.
@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.
@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
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.