User Templates for Mojave Upgrades

In the past I used this method
1. Create a local user account and configure as needed
2. enable root account and the use the UNIX command ditto command to copy the /Users/user folder to /System/Library/User Template/Englih.lproj
3. Repair permissions
4. package that with Composer

With Mojave, this isn't working. any time I create a new account (mobile AD user) it has tons of "need to repair permissions" prompts. Looks like it never updates the owner/permissions for the /Users/xxx folders for the new user.

I'm still looking for a way to make this work. But as a work around, I created a temp user, configured everything and then did a Capture (modified files) with Composer. Created a DMG and deployed with a log in policy for "once per user per computer" and set the FEU option.
This works pretty well, but it's not the same and also requires a reboot in order to make all the setting kick in.

I'd be interested if anyone has found a better way to modify the User Template.

@jleomcdo I haven't yet looked at this yet but why wouldn't you simply create a snapshot with Composer of what you configured in any account and then deploy that dmg once with FUT configured?

@alexjdale Does the above not work in Mojave with FEU set?

Not that Jamf is always going to get things right but I'd feel more comfortable with Jamf knowing how to copy something correctly into that template than me taking the time to make sure I have the right flags and such to get the permissions, ownership, etc. all correct. If that doesn't work, then ignore this(and I'll need to definitely look into this) but that would be my first try for modifying it rather than copying an entire account and repairing permissions.

I was seeing issue with this until I reset this path to Apple defaults (i.e. the Apple default is that the Safari directory doesn't exist):

/System/Library/User Template/English.lproj/Library/Safari

The other location I alter (with only a couple of plist files) is not seeing any issue with 10.14.2 with newly created AD home folders as of today:

/System/Library/User Template/English.lproj/Library/Preferences

Hi @SGill , I also spotted that the original Mojave English template user had fewer folders in the library and tried limited to the ones Apple had by default. But I'm still getting errors - the resulting folders created for a user are owned by root. If I manually move the originals back they work fine. There's some happy ground inbetween apparently but not just defined by only having the folders in the Library that Apple wants. Ideas?

See if you can reproduce the problem on a clean install of Mojave..

I think apple's attitude with this stuff is somewhat like how PPPC works... It's ok if someone does it in the GUI, but via command-line/script you either just can't do it, or you can only do it if you are verified,codesigned, etc...

To future-proof processes (and cure current headaches around this), I recommend abandoning User Template modifications. This was always a bit of a “hack”, and as others have mentioned seems to go against Apple’s paradigm around privacy controls and the ‘sovereignty of user land’ (my wording).

Most items that need to be managed should be configurable via MDM. Most of those that aren’t can be scripted (I would recommend giving Apple feedback/feature requests to incorporate any items you need to script into the MDM specification for further future-proofing). If there are any items that cannot be solved via MDM, scripting, or package delivery, I would raise those more urgently with both Apple and Jamf and also re-examine whether the organization truly needs to manage those particular items.

I can't recommend @jleomcdo method, a packaged "Default User" is not working like in previous macOS versions. This will not work without many issues in Mojave.

We use a script to customize the default user template at first login of a new user. Nearly all settings can be scripted using a login script, other settings are configurable via MDM and Configuration Profiles (specially PPPC settings). The combination of Configuration Profiles and login script is working fine and we don't see any issues so far.

Isn't anyone else extremely concerned, and annoyed, that it's becoming so difficult to configure macOS for business and education use? Since 2005, I was able to customize the default user template, create a netinstall image, and I was done. That was it. Now, you need a combination of JAMF, MDM, config profiles, scripting, and packages to accomplish the same thing? What's next? I'm assuming since ARD hasn't been touched by Apple in years that it's next on the chopping block.

Granted Apple has a gazillion technical people, I did talk to one of their support engineers about the use of the user template folder. He said third party applications using the user template folder should continue to work for the foreseeable future. Because of the way SIP is working, any of the Apple apps such as Safari will cause issues in Mojave. Since this conversation, I have still used the User Template "hack" to get predetermined settings into new user folders.

These settings can be serial numbers, registration, auto updates disabled and many more. For some apps, yes the .plist can be converted over to a configuration profile and they will usually work fine. However, even a configuration profile has limitations such as being able to select run once rather than every time a user logs in.

In our employee group, we like to setup an application as configured once on login, which is what the user template gives us, and then allow the user to modify the settings as they see fit. A configuration profile will not allow this, at least from what I understand.

@nkuhl30 I'm concerned mostly when there isn't enough communication on these things. After that it becomes how much time and resources my organization or institution gives me to do my job.

Technology changes...that's the nature of the beast. If you're going to manage computers, you're pretty much stuck with what you're given and guess what? It's the same in the Windows world. Some things you can do in Group Policy and some you can do in Group Policy Preferences and then you have scripts and various ways to deploy packages containing software and settings. Windows admins do have default user profiles but they've become increasingly more difficult over the years to configure as security becomes more of an issue. Back in my Windows days I used mandatory profiles extensively for labs but I've heard from people now handling Windows support that with Windows 10 mandatory profiles aren't reliable.

This isn't to say that we shouldn't raise our concerns to Apple, Jamf, and other mdm vendors but it's important to understand that just because something has always been done a certain way, doesn't mean it's always going to be the best way going forward. At the moment it would seem Apple has decided that it's not the best way.

Hi jhuls, working in IT for the past 15 years, I'm used to change. It's not change that I have a problem with in this matter. It's that they're over complicating device management and replacing tried-and-true methods with sub-par tools.

If Apple came out and said, imaging is dead but here's a better way of doing things, then I'd be on board. But their new(er) system relies on an organization to purchase JAMF, or something comparable, and still need to use scripts, packages, etc. to accomplish something that used to be extremely easy.

So, anyone got a one stop shop for creating a custom user template via; scripts, profiles, MDM, packages, etc?

It seems like everyone is just doing their own thing for their own business, but there's no standardized way to get this done. Like a boiler plate or something?

Also, login hooks are pretty much broken with macOS and JAMF right? So its more like a LaunchD that calls a script. I just don't like how messy and inelegant this is getting.

So, one stop shop custom user template, Anyone?

Login hooks are used by Jamf, but that means you can have login policies that do what you need.

We don't interact with the user template at all these days, we just apply config profiles and/or login scripts triggered by Jamf policies as necessary.

@nwagner Basically I run along the lines of...

OS settings -- Configuration Profiles
Dock settings -- Dockutil in 3 packages
- Dockutil is deployed to all systems on campus
- Launchagent is deployed only on systems needing preconfigured docks
- script with dockutil configuration is deployed to launchagent systems for easy changes to swap in and out as needed
Microsoft software settings -- Configuration Profiles
Adobe and other software settings -- Individual Composer packages w/FUT and sometimes FEU

There might be more software settings I can do with Configuration Profiles but I haven't had time to explore yet. I do feel like Configuration Profiles are a bit limited and not enough information about them is out there but they're getting the job done for what I need at the moment.

For what it's worth as far as the dockutil configuration I could see where some wouldn't break that up like I did but I have different labs with different configurations so the above made more sense at the time. It could be argued to package it with less than 3 but why change what's working? lol

Thanks for this jhuls. I feel like your post proves my point. We have a mixed environment of mostly Macs but some Windows PCs as well. And, to be honest, Mac management is not far off from the Windows management experience at this point.

@nkuhl30 In terms of touching this and that, yes, it's getting close.

Honestly though I don't consider this to be that big of a deal at this point unless being able to install packages with FUT and FEU gets cut and even then, for us anyways, the instructors would simply need to instruct the students once how to setup the current settings through Self Service.

Sure, there are multiple places for admins to go to configure something but how often do you need to reconfigure all of them? I certainly don't need to change my OS settings all that often so I don't necessarily have to worry about them or redo them over and over again.

The Dock config took awhile for me(not a script expert) to figure out but now it's mostly painless. I'm actually tossing around the idea of using a Jamf policy script to create the Dockutil script on the machine. This way I don't even have to create a package when I need to change the dock configuration. I just change it inside of Jamf, re-deploy, and done. I've done this with another application I support and seems to work well. The more steps that can be eliminated the better but I honestly can't complain at the moment. Admittedly what I stepped into when I took over was a little nightmarish so the bar was low.

Moving from imaging to DEP and this configuration style actually made things easier for me. Some of that is probably because I was already use to using group policy in Windows. I also like the idea of knowing more about the OS. If I simply captured a user template, I wouldn't necessarily learn the specific files that contain settings for the different System Preferences and such. The settings would just be there. I consider that a plus.

I'm new to this new provisioning paradigm. I I'm learning about what I can and cannot configure with JAMF. I run the mac lab at a university library. I want a consistent and usable user environment for my patrons. As these are lab computers, user profiles are not saved. I've been able to set up a script using dockutil to set my dock. What else are you all using scripting to do?

Thanks,
RR3

I'm not sure if anyone is still dealing with User Template issues; I expect most business users don't need to touch it but as mentioned above those of us who manage labs need to make changes to the profile since every user that sits down is always a new user when logging in.

I'm seeing something that appears to break things in the User Template--Composer captures where the application uses a Container. Generally the folders in ~Library/Containers--once you navigate down through them--have links to "regular" folders in ~/Library.

It looks like these Container links are breaking something during the account creation process. We're dropping in links with FUT before they are ever created in the user creation process. Since the folders in question don't exist in the User Template, we end up with zero-byte files instead of folders when creating new users.