with certain login triggers I've found that sometimes, when a computer takes a minute to load past the login window, policies are triggered yet cannot run because they are not at the desktop yet. a workaround i've found is adding a delay or sleep command in the script, another workaround is putting the script on the machine locally and running it that way.

try putting the script on the machine & utilizing a launchagent to run the script

@Hugonaut His script is already waiting for the Dock to be running, right at the top, so I don't think it's because it's firing too soon. Adding a sleep might help, but I wouldn't count on it.

That being said, I don't have a good answer. Dockutil also works kind of inconsistent for me in my testing. Sometimes only a few icons show up (until a log out/restart), sometimes no icons appear other than Finder and Trash, sometimes it works perfectly. Wish I could say dockutil was 100% reliable, but it just isn't. However, I consider it more Apple's fault than the developer. The Dock is notoriously difficult to manage and manipulate and Apple hasn't made it any better over the years.

What has worked for me more reliably than others is to do as you said, to generate a local script with all the items in it, and run that script as the logged in user. That seems to be the most consistent way to make it work. Even that's not 100% perfect in my tests, but it's a fair bit better than trying to run it entirely in a Jamf policy script payload.

I do something similar with my elementary mobile cart. No need to script this as JAMF has all the tools.

First, under Settings -> Computer Management -> Dock Items

Make an entry for every item that's on the dock currently (my list is just the default apps) AND an entry for every item you want to add to the Dock (firefox, chrome, et al)

Second - Make a policy - Mine is called Carts - Dock - Add Programs

Step 2.5 - In that policy use Dock Items and add or remove the items you setup in Step 1

I also have it available under self service so a tech (or teacher) can just hit the button to re-run the policy if someone deleted or moved a dock item.

One caveat to this setup is Webhooks, which you can't add as part of this setup (you can run them as separate policies), however, sometime they just refuse to load. You can just drag them out of Library -> Application Support -> Configuration profiles.

@mm2270 I will try having the script stored on the local machines and then having a policy with a command to execute the script and report back. I'm not sure it's Apple because the script works every time when I use UNIX via ARD.

@larry_barrett Sadly, what you described is exactly how I first attempted to manage the dock items for users in that lab. It never worked reliably, removing and adding all the items. Thanks for posting screenshots because it confirms that all my settings were correct. Speaking to Jamf support, they didn't have a solution for how to resolve the issues of not working/applying consistently.

Lastly, I'm also going to experiment with outset and see if that gives a different result.

If anyone has additional ideas or experiences, please share! :)

@psherotov

I missed this piece yesterday. It's how you force the dock to co-operate.

Our mobile cart is set to auto-login to the shared login credentials. The killall command is the magic.

Sorry for not including this important part yesterday and don't forget to put the first policy in self service to make sure your tech's can fix it with one button. I would guess that I have to reset the dock manually via policy on 1-2 out of 60 computers every 2 weeks or so.

@larry_barrett I had almost the exact setup, except my command under files and processes was: sudo killall -hup cfprefsd; sudo killall -hup Dock

I will give your command a try to see if it works any better and report back.

I had some success making the script into a package deploying it through Jamf (so that it's stored on each Mac) and then creating a policy scoped to a test computer and limited to one of the user accounts with this command under files and processes:
/Library/Scripts/DockP_3.sh

Trouble is it takes a while to work, a couple minutes after dock loads.

@psherotov are you sure you can run sudo commands there?

@larry_barrett You're right it's not needed, I wonder if that was an issue. It worked on one test machine, but the problem is that I don't know if it will work consistently. I can do some more testing. I also didn't have Startup selected, so I can try adding that.

So far, after some fiddling around I got the script to work by having it on the machines locally and using policy to run it at login, but it's a bit slow.

At least in a few instances deleting the user profile allowed the script to run from Jamf, BUT it always works when run from ARD. It's odd.

I'm having some trouble getting Outset working but that's prob. me doing something wrong :)

I wonder if creating a Launch Agent to run the script would be the most efficient way to get it to load quickly and correctly?

We used to use dockutil a few years ago. I did not set it up. But I recall that the staff member who set it up did experience issues with reliability. Sometimes the dock would not be modified, other times the dock would be partially modified. I believe that this person felt like it was a timing issue. I believe the solution we used was to run the dockutil commands more than once. It seemed that after the second run the dock would be set properly. So maybe just put a loop in the dockutil section of your script.

I know that the person who set this up for us tried to put in sleep commands to slow things down but they found ultimately just running the command block twice was more reliable and faster.

However, I would agree with larry_barret that there has to be a way of making this work using JAMF native dock tools. I have created a custom event on our cart computers that I call studentLogin that I then use to trigger policies in JAMF. I would imagine that you could create custom events for PorKLogin, OneLogin, TwoLogin, ThreeLogin and then use those custom events to trigger the policy that modified the dock.

You would add these to a login script (see below I have modified your script to use custom triggers) so that when a user logs in the custom trigger fires.

Then you add a policy that is waiting for that custom trigger (see screenshot). In my screenshot I am waiting for the custom trigger of "studentLogin" to trigger the policy. You would create 4 separate policies waiting for the 4 custom triggers where each policy modifies the dock as larry_barret suggests.

#!/bin/bash

Get the current logged in user that we'll be modifying

if [ ! -z "$3" ]; then user=$3 else user=$(python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + " ");') fi case $user in p|k) echo "p or k found" sudo jamf policy -trigger PorKLogin ;; 1) echo "1 found" sudo jamf policy -trigger OneLogin ;; 2) echo "2 found" sudo jamf policy -trigger TwoLogin ;; 3) echo "3 found" sudo jamf policy -trigger ThreeLogin ;; esac exit 0

@larry_barrett @mm2270 Larry,
Question, are you using 10.14? Does the Jamf Dock command fill the user templates? I've found I only need to run a dock policy of this kind once per computer and it affects all the users, even ones not logging in yet. So is this behavior not going to work in the future due to SIP and 10.14 not liking user template fills? As others have said, I don't like the idea of Dockutil since its inconsistent, however my old method of capturing a dock plist and filling the user template is something that it looks like Apple won't be supporting going forward.

Gabe Shackey
Princeton Public Schools

@gshackney We're on 10.13. Since this is a POLICY it should not be a problem. I run mine at startup and login so no matter who logs in it runs it. I also have a command in Self Service called "Fix Dock" which is manually running the POLICY again.

User templates are basically almost dead, I've never really even messed with them. This method doesn't use User Templates at all and should be future proof. Again, I'm not on 10.14 yet, but I can't imagine it's going to affect this method.

edit: change configuration profile to policy where bolded.

Got it, wasn't sure if it was a profile or a policy command due to the screens shots showing policy dock commands.
Gabe Shackney
Princeton Public Schools

@gshackney The Dock Items part of it is setup in Settings - Computer Management. Without populating that application data, it won't be chooseable as an option when you setup the actual Policy -> Dock Items

I said Profile above by mistake, its a Policy, not a profile. I'll edit my previous post.

I'm working on a custom dock in Mojave now and dockutil is inconsistent for me as well, so I've tried this. This is not working for me either though. I created an entry in Settings > Computer Management > Dock Items for all of Apple's apps and the ones I want to add. Then I created a policy that runs on login to remove each one of Apple's apps and add the 5 I need. When I log in, Apple's dock appears and then the dock is re-launched. Sometimes it's Apple's standard dock. Other times it's Apple's dock with 1 or 2 of the extra apps added. There doesn't seem to be any consistent way to set a dock and it's a little frustrating. Our users will be logging in with AD accounts. Is that the issue?

Make sure you are doing: sleep 5; killall Dock

I run it in a separate policy at startup and login, Ongoing. My Add to Dock policy runs at login and ongoing. Once in a while it just won't work, my add to dock policy is in Self Service too so you can just run it to fix it.

Summary:
Computers -> Policy -> Restart Dock (runs at login, startup and ongoing)
Computers -> Policy -> [Carts] Dock - Add Programs (runs at login, keep in self service also)

One problem might be the order you are running your policies. They run alphabetically (correct me if that's not true)

As of todays date, it works 60/60 on my cart machines. I logged in with an AD account, a hidden admin account and a standard user, all had the dock arranged the same way.

Have you considered outset? I have worked with JAMF/Airwatch/Munki environments and have never had an issue with outset and dockutil with custom docks

L

For what it's worth I have a script in Jamf that creates another script locally called configureDock. configureDock gets copied to /usr/local/bin/ and it uses dockutil to configure the dock the first time a user's account is logged in. I also have a Self Service option that will call it to reset the dock when the user needs it to be. This works by using a launchagent that calls a different script on login which looks for a file in the user's Library. If it exists, it thinks the dock does not need to be configured. If it's not there, it then launches the configureDock script I mentioned above.

I won't claim it to be the perfect solution but it's perfect for us. Once in awhile(rarely) it doesn't seem to run so the user is trained to use the Reset Dock option in Self Service. What I like best about this is it's incredibly easy to make changes on the fly by editing the script that is used to create the configureDock script. When Adobe decides to change the names and paths every freaking year, I just edit the text and tell the policy that distributes it to run once again. Done!

Just a few days I was talking with my part timer telling him that I'm thinking about getting a license for Filemaker to make it even easier. Use the database to save all of the software and paths and then do queries for each of our labs at the community college we work. For each query it would generate the needed script with dockutil commands so I wouldn't even need to edit the script but just copy/paste it in. I'm not sure my director will bite on that one since we're really a Microsoft shop but once the semester prep for fall is over, I plan to ask.

@larry_barrett I was using the killall command but the dock was still inconsistent. This is for "lab image" that goes on our Library's computers so the Self Service fix wasn't really going to work for them. I got dockutil to work with a script that wasn't as complicated as the one I was using before that I found in another thread. You've been a big help these past couple days. Thanks.

@dnelson2813 We are using a profile for our dock settings, that isn't anything fancy, just merge apple's dock with the user's additions. It worked on sierra rather consistently (over 90% of the time) if it failed for some reason, a reboot resolved the issue. On Mojave however, it just fails about 90% of the time, and a reboot doesn't fix it.. We also are AD bound, so I don't know if this is one of the complications we are experiencing as well.

@tdilossi I've had good luck with Dockbuilder that @ryan.ball created:

https://www.jamf.com/jamf-nation/discussions/32017/i-built-dockbuilder-for-you

It's been working flawlessly with Mojave bound to AD in our labs.

Timing the dock is probably the issue, so I don't think relying on policies/triggers is the best way. What I've had the most success with is using a launch agent which runs a local script that uses dockutil to configure the dock on initial user login. A hidden marker file in the root of users home checks if it's been run already. Dockutil works MOST of the time this way, however I've seen it fail randomly, it's not a perfect app; if this happens we just delete the hidden marker file, have the user log in again, and that usually takes care of it.

LaunchAgent is the way to go. Along with DockBuilder, I also created launchd Package Creator that you can use if you want to stick with your own script. Some logging in your script might help to track down what is occurring, but login policies are not the most reliable.