User Template - Sierra

Can you post a screengrab of the contents of the DMG?

@monaronyc There will be a number of people on jamfnation that will tell you to not deploy anything to the User Template. However, we still do.

It sounds like what you're doing is making a DMG of the actual English.lproj folder, rather than deploying individual files to the respective folders. You only want to add or change files within the respective User Template folders, not deploy the entire English.lproj folder.

What FUT does is take everything user-specific in your Composer-built DMG and automatically copies them to the respective folder in the User Template. For example, if you had a single PLIST - /Users/localuser/Library/Preferences/yourplist.plist - enabling FUT on this DMG then would install the PLIST to the location specified and copy the PLIST to /System/Library/User Template/English.lproj/Library/Preferences.

So ideally you want your process to be the following:

1. On a local user account, configure your preference(s) and drag the file(s) to Composer to build a source with the file(s) and parent folders
2. Build a DMG.
3. Upload your DMG with Casper Admin and check the FUT box.
4. When you push this DMG to machines, the file(s) will be installed both for the local user and in the correct User Template folder

@aporlebeke Composer built DMG? Oh lordy! We'll there's one mistake on our part right there. We did it manually. file by file. I'll dig into Composer now. Thanks for reaching out!

@aporlebeke I know this post is a year old, but I wonder if you could expound on why folks will tell you not to deploy anything to the User Template? A couple of my labs have some pretty extensive customizations for not only the OS, but individual applications. The only way I have been able to be accommodating for all these customizations is to modify the User Template. How else would you do it?

@kwoodard For one, I know when we started out with our Jamf deployment there was a lot we didn't know and as a result we built a number of DMGs with FUT resulting in overly large User Templates and longer initial login times.

I know many (and we do as well) use a tool called outset to run scripts, install packages, and/or install profiles at startup or login, and do this every time or once per user (in the case of logins), with either elevated or the user's context.

The benefit with this model is that if something changes, say you update your script or package, you can replace these via Jamf in the corresponding outset folders and have them run again, if necessary, for your users the next time they login. You can also run things on demand. With the User Template option you're stuck with whatever was copied / configured when a user first created their account, so you can change things but can't do any sort of remediation for preexisting users.

While you could use Jamf policies for things you want to happen when a user logs in, in my experience I haven't always been able to get these policies to trigger. By opting for a local machine based solution we get consistent results and an overall better long-term solution.

Thank you for the response. One of the things we do in our labs is remove user directories when the computers restart. We do this because each computer could potentially see over 200 individual users in a given week. Most of these students are in some form of multimedia creation or photo manipulation. We would run out of hard drive space in a day.

So in this respect, making changes to the user template works. Every login is a fresh user folder. I have been looking for better ways to do this, but I haven’t come up with anything. Right now, the user template is about 8mb in size; one application that resides on the desktop and a ton of application specific preferences and OS configurations. The other half are three launch agents and daemons that move some files into place after the user folder is created (these are licensing files that don’t properly work if they just sit in the user template). I also use Docutil to manage the dock (which seems to be working fine with High Sierra). I have to make docutil kind of brute force the updated dock, which causes the screen to flicker as the dock is rebuilt, but it works.

If you have any suggestions on how I can do this more effectively, I’m all ears.

@kwoodard it sounds like given your environment that's a good solution for you. If everything you need to do for your users in just in the context of that user - nothing you have to do in the root /Library folder, for example - I don't think you need to change anything at the moment ...

That being said, given we can no longer really image our machines with High Sierra we've opted to update our entire workflow to DEP enrollment with Jamf enrollment policies (but in our case we do this with munki) installing all the necessary software. Because of this, we don't have the opportunity to mess with the User Template because we start with a "live" system. So for us, outset is really the only answer.

@aporlebeke That is kind of where we are heading as well. All of our Mac labs will be rotated out for new gear in the next two years...The first of which, 36 mid-high end iMac's will be arriving shortly. Since we no longer can put an older OS on the computers, we are stuck with HiC and all the fun that comes with it. Looks like I will be reading up on outset to see if it works with us. I just started messing with Composer to make DMG's that will fill the user template. I'm really not thrilled to have to do it this way either. I already miss my DeployStudio setup...

@aporlebeke I know this post is a year old, but I wonder if you could expound on why folks will tell you not to deploy anything to the User Template?

@kwoodard I know you directed your question to someone else, but one big reason is System Integrity Protection (SIP). It's a good rule of thumb that anything under /System is Apple's to control, and the fact that SIP protects that directory backs that up.

That said, SIP currently whitelists the /System/Library/User Template directory, meaning you're able to make changes to that directory without having to disable SIP... but many admins are wary about Apple suddenly deciding to remove that whitelist and prevent modification to that directory.

A couple of my labs have some pretty extensive customizations for not only the OS, but individual applications. The only way I have been able to be accommodating for all these customizations is to modify the User Template. How else would you do it?

Well, there's two ways to answer that. The first would be to use configuration profiles, where they meet your needs... and LaunchAgents to move items into the profile at first login, for those things that can't be managed with configuration profiles.

The other way would be the hands-off administrator, that works under the philosophy that the user's home directory is the user's territory, and they do as little as possible within. Provide the user documentation they need to make the changes themselves, rather than an administrator doing it for them.

Using FUT, how can it be restricted to a single language template in a multi-language OS install, or does the OS need to only have a single language available?