Skip to main content
Solved

Execute (Dockutil) Script When User Logs In Post Imaging


Forum|alt.badge.img+22
  • Honored Contributor
  • 289 replies

Scraping from some scripts here on Jamf Nation I have a small script attached to a policy that executes at login and sets the dock using dockutil. I want it to execute at login so it adds the user's Documents folder to the dock:

echo "Adding Documents..."; /usr/local/bin/dockutil --add '~/Documents' --no-restart --position 11 "$LoggedInUserHome"

This works perfectly in testing with the policy but I'd love to have this run at login only after a computer is newly imaged. I can't add it to my first boot script because it won't set the Documents folder, not knowing what $LoggedInUserHome is.

Wonder if anyone has any thought on how to accomplish? I'm almost ready to just have our Team run this from Self Service, post login and post imaging, but reaching out to Jamf Nation first!

Best answer by dpertschi

@TomDay If you drop bread crumb on the machine during imaging (dummy receipt or file) you can create a smart group for that condition. Then create a dock policy that executes at login once per user per computer scoped to that group.

With this approach though, you might need to delay the dock script a little bit to allow the default preference to get written first. I add a sleep 30 at the beginning of mine. YMMV

View original
Did this topic help you find an answer to your question?

14 replies

Forum|alt.badge.img+26
  • Honored Contributor
  • 457 replies
  • May 10, 2017

Someone once shared a LaunchAgent and script that set the dock for each user as they logged in. It had logic that it would not run the dockutil if they logged in again by referencing text file. It was cool... and of course, now I can't find it but I sure could use it too.


Forum|alt.badge.img+13
  • Honored Contributor
  • 550 replies
  • May 10, 2017

@TomDay

i do exactly this with the full dock after the computer is imaged with dockutil and outset. script for dock is installed at at reboot.


Forum|alt.badge.img+12
  • Contributor
  • 181 replies
  • May 10, 2017

can't you use it in a jamf policy, trigger on login and run once per user per computer?


apizz
Forum|alt.badge.img+15
  • Honored Contributor
  • 395 replies
  • May 10, 2017

@TomDay we use outset to run a number of scripts when a user signs in for the first time.

Basically you would copy your script into the desired outset folder, in your case /usr/local/outset/login-once (which will run the script as the user), and when a user logs in outset runs any and all scripts in the login-once folder for the user.

I've had some weirdness with some policies not kicking off for user when they login, so I use outset to take jamf out of the equation. At least on a few configuration things that I only want to have happen once.


Forum|alt.badge.img+22
  • Author
  • Honored Contributor
  • 289 replies
  • May 11, 2017

@marklamont I am using in a jamf policy, triggered at login, in my testing with one device and it works fine. The problem is I don't want this to roll out to all my current devices and blow out the current dock that my suers have customized. I just want this to run on a freshly imaged machine for incoming students and employees.

@aporlebeke @LSinNY Thx for tip the tip on outset, I'll check it out.


dpertschi
Forum|alt.badge.img+19
  • Contributor
  • 459 replies
  • Answer
  • May 11, 2017

@TomDay If you drop bread crumb on the machine during imaging (dummy receipt or file) you can create a smart group for that condition. Then create a dock policy that executes at login once per user per computer scoped to that group.

With this approach though, you might need to delay the dock script a little bit to allow the default preference to get written first. I add a sleep 30 at the beginning of mine. YMMV


Forum|alt.badge.img+12
  • Contributor
  • 181 replies
  • May 11, 2017

@dpertschi I would have said that as well, or else use a smart group scoped to enrolled in last day which would also do the job if you don't want to go for an EA


Forum|alt.badge.img+14
  • Valued Contributor
  • 296 replies
  • May 11, 2017

@TomDay As others have said, there are a few ways to do this. I use a LaunchAgent which is only set to run once (first time they log in) and then never again. I also put a delay on the dockutil script as @dpertschi mentioned. Here is the LaunchAgent I use:

<?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.company.dock</string>
    <key>LaunchOnlyOnce</key>
    <true/>
    <key>ProgramArguments</key>
    <array>
        <string>sh</string>
        <string>/path/to/script/dockutil.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Hopefully this helps.


Forum|alt.badge.img+13
  • Honored Contributor
  • 550 replies
  • May 11, 2017

@perrycj outset creates the LauchAgent on install that points to the folder where you load your scripts, One and done. After install put your script in the folder with the corresponding frequency: login-once,every,once-with-priviledges,every-with-priviledges, etc. No need to create an Agent for every script


Forum|alt.badge.img+14
  • Valued Contributor
  • 296 replies
  • May 11, 2017

Sure, lots of different ways to do different things. As I stated in my post, just offering another solution and what works for me.


bentoms
Forum|alt.badge.img+35
  • Legendary Contributor
  • 4331 replies
  • May 12, 2017

Why not add a script for dockutil to the imaging process that amends all the docks via -allHomes ?

Then it's a oneshot for imaged machines.


Forum|alt.badge.img+22
  • Author
  • Honored Contributor
  • 289 replies
  • May 12, 2017

Dropping a dummy file or a smart group based on enrollment are great ideas thank you @dpertschi @marklamont , putting those ideas on hold for a few minutes! @bentoms I think using it in the imaging process might be easiest and I just won't worry about the Documents folder. Quick test, dockutil gets installed properly during imaging but the script doesn't work, not sure if the timing it correct on it? Currently set for "at reboot". After the reboot and I login, not seeing the new dock, I run a test command adding 1 item to the dock and it works correctly, so I know dockutil is installed.

#!/bin/sh

configureDefaultDock() {

if [ -e /usr/local/bin/dockutil ];
then
   dockutilVersion=`/usr/local/bin/dockutil --version --version`; echo "dockutil version: $dockutilVersion"

echo "Clearing Dock..."; /usr/local/bin/dockutil --remove all --allhomes

echo "Adding Launchpad..."; /usr/local/bin/dockutil --add '/Applications/Launchpad.app' --position 1 --allhomes
echo "Adding Self Service..."; /usr/local/bin/dockutil --add '/Applications/Self Service.app' --position 2 --allhomes
echo "Adding Google Chrome..."; /usr/local/bin/dockutil --add '/Applications/Google Chrome.app' --position 3 --allhomes
echo "Adding Safari..."; /usr/local/bin/dockutil --add '/Applications/Safari.app' --position 4 --allhomes

else
   echo "dockutil not installed, skipping initial dock setup..."
fi

}

exit 0

Forum|alt.badge.img+26
  • Honored Contributor
  • 457 replies
  • May 12, 2017

Verify the order things are taking place during imaging. Verify the account is getting created prior to running the Dockutil script.


Forum|alt.badge.img+22
  • Author
  • Honored Contributor
  • 289 replies
  • May 12, 2017

Got this completed, many thanks to Everyone that jumped in to help.

  1. Placed a line in my First Boot script that created a file /Users/Shared/NewlyImaged
  2. Create EA (see below)
  3. Create smart group based on having the EA set to "yes"
  4. Create a policy with the login trigger, runs once per computer that runs the dockutil script and then deletes the NewlyImaged file. .
#!/bin/sh
if [ -f /Users/Shared/NewlyImaged ]
then 
  echo "<result>Yes</result>"
else
  echo "<result>No</result>"
fi

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings