Update docks for only new users

sosnovsken
New Contributor III

Hi Everyone,

We are getting ready to roll out casper here to our new users, but aren't going to re-image existing machines. I'm scoping policies in such a way that software will get installed if it needs to and have pretty much got the hang of that. I'm also going to be using docutil to make a standardized user dock. However, I'd only like that to be pushed out to new users on a machine, leaving existing user docks (that they probably have already customized) untouched. I can think of a hackish way of doing this by pushing out a hidden marker file that goes out to all current user folders right now and then having my dock script die if it finds that file. Is there a better way to do that? It would be really awesome if there was a policy trigger for first user login that I am just missing...

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

There are a few different ways you can approach this.

1- You could simply drop a modified Dock.plist into the /System/Library/User Template/ location, so it would customize the Dock ahead of time instead of waiting until someone logs in. By pushing the change there, no current users will be affected.
Casper Suite has the FUT (Fill User template) option specifically for this type of scenario. Capture your settings for the Dock and package it up as a DMG, then set the FUT option for the package once uploaded and deploy it. As long as you don't also enable FEU (Fill Existing Users) it should only send the plist into the User Template directory, not any current home folders.

2 - Another method, if you're more interested in scripting this out instead of dropping a pre-configured plist, would be to deploy a LaunchAgent into the /System/Library/User Template/Englsh.lproj/Library/LaunchAgents/ directory (The last directory doesn't exist by default in User Template, so would need to be created) that would run your dockutil script instead of doing it from a policy later. Existing users won't get the LaunchAgent since their account already exists and is therefore not pulling any settings from the User Template. But new accounts that are created would have that LaunchAgent present and would run the script at first login
In the script you could have it run, set up the Dock with dockutil, then remove the LaunchAgent and finally remove itself. That way it won't run again on subsequent logins from that user.

And there are probably other ways, but those 2 are the ones that come to mind for me.

View solution in original post

2 REPLIES 2

mm2270
Legendary Contributor III

There are a few different ways you can approach this.

1- You could simply drop a modified Dock.plist into the /System/Library/User Template/ location, so it would customize the Dock ahead of time instead of waiting until someone logs in. By pushing the change there, no current users will be affected.
Casper Suite has the FUT (Fill User template) option specifically for this type of scenario. Capture your settings for the Dock and package it up as a DMG, then set the FUT option for the package once uploaded and deploy it. As long as you don't also enable FEU (Fill Existing Users) it should only send the plist into the User Template directory, not any current home folders.

2 - Another method, if you're more interested in scripting this out instead of dropping a pre-configured plist, would be to deploy a LaunchAgent into the /System/Library/User Template/Englsh.lproj/Library/LaunchAgents/ directory (The last directory doesn't exist by default in User Template, so would need to be created) that would run your dockutil script instead of doing it from a policy later. Existing users won't get the LaunchAgent since their account already exists and is therefore not pulling any settings from the User Template. But new accounts that are created would have that LaunchAgent present and would run the script at first login
In the script you could have it run, set up the Dock with dockutil, then remove the LaunchAgent and finally remove itself. That way it won't run again on subsequent logins from that user.

And there are probably other ways, but those 2 are the ones that come to mind for me.

jennifer
Contributor

Would a configuration profile work for you? I've used one for the Dock and when building it on the JSS, there is an option to "merge with user's dock."

Or what about setting your policy to run on machines whose JSS ID Number is greater than X. (X being whatever the most recent enrollment number was) That way any machines that are enrolled after the designated time would get the policy, but old machines wouldn't. Or something similar with the date imaged?

edit: i just re-read your post, are you enrolling everyone for the first time? if so, using the JSS ID wouldn't help any.