Mojave User Template problem

I too am just starting work on Mojave builds at the moment. What we have found is that we need to completely avoid User Templates as it is clear Apple has made some security changes here. We are simply adding a few prefs for revenant apps that are installed (Firefox prefs etc), and instead the outcome is that constant prompts of the new user's Library needs repairing.

So what I am thinking is that we need to stop using User Template completely, and instead work on a process that the necessary prefs files get installed via a LaunchAgent route + script. It is taking up a lot of work for something that used to be pretty rock solid and now gone useless.

Gotta go the way Apple is going, no point trying to hack it in my view (+ past experience of Apple changes on these sort of major changes). I just wish Apple made some sort of documentation or at least a mention of these changes. I would have preferred to start this work 6 months ago rather than now.

@AVmcclint @techgeek Outset is your friend. Deploy Outset to your users, then:

1. Put files you are now putting into the User Template into a temporary folder, like /Users/Shared or even /tmp.
2. Write a post install script that: a) determines current user, b) moves the files from the temporary location into the user's template.
3. Package this up.
4. Drop package into the proper Outset folder on your machine.
5. Package that up and deploy.

For something like a one time setting, the "login-once" folder in Outset is perfect. And Outset has a makefile that will build the Outset package for you. I use this method for any first time Finder settings or user template type things and it works perfectly every time.

Have you tried downgrading by booting into Recovery mode and then run the High Sierra install via USB?

@tjhall New hardware (2018 MacBook Air and 2018 Mac Mini) means Mojave or higher only. High Sierra and below will not have the necessary "drivers" for the new hardware, so you cannot downgrade the OS.

I'm afraid the best answer is stop using it. The main reason it shouldn't be used is this; Apple own everything inside /System and it is entirely their right to lock that down with System Integrity Protection (SIP) as it provides a securer experience. Outside of that using configuration profiles for preferences is preferable and other configuration like fonts, or files in Application support can be written into the user on login using a LaunchAgent.

We used to use it, but have moved away from this after apple introduced SIP as the writing was on the wall.

Apple owns everything inside of /System, yes, but they specifically exempted the User Template folder from SIP for needed items.

Those limitations are controlled by exemptions (notated by a *) in this file: /System/Library/Sandbox/rootless.conf

In Mojave testing here, UT items are working as normal, with the exception of Safari elements. I've had to retire managing those for now, and am of course looking at items like Outset going forward.

Hello @stevewood I am beginning to learn how to use Outset and I saw your post here about using it.

Quick question, I would prefer to not use the user template for a variety of reasons. If I were to put files/folders in the /tmp directory, this would be ideal. Do you know if the OS or some other mechanism will delete these files/folders from this folder for any reason?

I would hate to place items here only to find them being removed at some point. Thoughts?

Again, thank you and Everyone who takes the time to keep the rest of us informed!!

@mconners the /tmp folder is cleared out by the OS on restart, hence the reason it is the temp folder. If you're looking to deploy stuff to end users, I would either create a folder in /Library or some other folder that is accessible (very important) by a standard user. I will typically put stuff in /Users/Shared since I know that folder will be readable by the standard users.

I only touch the user folder on login and only on the first login.

Thanks @stevewood this is helpful. I have been using the User Template for so many years, I really have to get my head around this new approach, which I really like the sound of it. I think I am going to use the /Library folder for my new placements rather than the /Users/Shared as some users might tinker with it not knowing how it could affect other users. Thanks again!!

For this one user i was able to brute force fix it. it took many hours to get it so the user's profile would work. My current problem is that there are a LOT of existing Macs where we used FUT without problem in all the previous OS versions. Once we upgrade them to Mojave, every single one of them will break severely when a new user logs in. Has anyone figured out how to completely fix the User Templates? I have gone through Jamf Admin and disabled every single FUT package so they aren't being pushed out any more. So in theory a brand new Mac out of the box running Mojave should not be impacted moving forward. I still have no idea how to quickly fix existing installations. I've looked through the User templates of existing installs, but I can't locate every single file that's going to break Mojave.

Has anyone figured out how to fix already affected Macs? I am fine with not trying to pre-populate any preferences or support files in the templates. I'll find a way to distribute them after the fact.

You could drop your already deployed packages into Suspicious Package, collect up what all has been installed to the UTs, and mass delete those files. I actually haven't been seeing too much of the original issue you described (macOS needs to repair your Library) over my wired authentications under 10.14.4, but have been seeing it quite a bit over 10.13/10.14 802.1x wireless authentications. I even see it on macs that have UTs with only Apple default files in them sooo go figure... I don't yet use Jamf though as well -- so that might produce slightly different results too.

When we build DMGs with Composer and then mark them to FUT, which template are they put into? The default language of the OS - in our case English.proj - or Non_localized.proj?

Default language of your OS it would appear -- English.lproj.
That's the only template I've ever touched, but I only deploy pkg's, and haven't used the FUT or FEU features of JAMF - so you might need to check with them.

This is an old thread about UT's but maybe it's some help:
https://www.jamf.com/jamf-nation/discussions/14978/how-and-when-to-use-fut-and-feu-or-both

OH! I just realized that I have some things in the user template as a result of this post by @rtrouton . If we can never use the Mojave User Template, how are we supposed to suppress the setup dialogs? We can use the config profile Login Window payload to suppress them. We absolutely cannot have our users go through the setup dialog boxes because they will surely login with their iCloud accounts which is verboten. Adding it to their home folder AFTER they've already logged in is like closing the barn doors after the horses have escaped.

After a lot of experimenting, I decided to run rm -Rf /System/Library/User Template/Non_localized/Library/* as a policy to purge ALL the stuff that has been pushed out over the past 4 years as FUT. I tested and it looks like new users logging in to Mojave finally works. I am lamenting the fact that I can't pre-populate some things, but I suppose I'll survive.

@AVmcclint, @techgeek, and others, I ran into this big problem three weeks ago when we started buying these new MacBook Airs with the T2 chip.

Using UT is no longer a viable option. Period.

To get around this issue, I used a combination of Config Profiles, and scripts that run in JamfPRO policies (login and check-in). I had to do a lot of scripting work with defaults write and plistbuddy commands to create plist files or insert entries into plist files.

It took a few days of experimentation to get these to work, but by using the techniques that are now supported, I've pretty much recreated all the plists that I formerly inserted into UT. There are still a few things I need to work on, like Firefox and Google browser settings deployment. But, I've found official documentation from Google and Mozilla that will help with this.

Frankly, my biggest issue now is that we can't Netboot these new machines to run our software suite installation using Jamf Imaging. However, I have an idea about using a JamfPRO policy to do this.

If you are interested, I can post my scripts and how I'm triggering them with Jamf policies here as sample starting points for you.

@itupshot I would definitely love to see how you're dealing with this new reality. Pre-populating Firefox and Chrome and Safari with homepages and company bookmarks and certs has been a pain in my side until I discovered FUT... but now we have to abandon that approach. The hardest part of all this is applying settings before users click on a single thing after logging in for the first time and then start messing things up.

@AVmcclint

Firefox and Chrome now use plist for managing both Browsers.
Firefox - https://github.com/mozilla/policy-templates/releases
Chrome - https://cloud.google.com/chrome-enterprise/browser/download/#download ( download Chrome bundle for Windows 64‑bit where you will see a plist file.)

@kroberts1 Thank for posting these. @AVmcclint They are the ones I mentioned I found for Chrome and FF. I just haven't had a chance yet to go through them.

I'd like to add these links:
Chrome Browser quick start (Mac): Set up Chrome Browser on Mac

Deployment of Firefox in an enterprise environment

I'll post a separate entry on this thread on how I've replaced using UT with other methods.

I really do not see a problem with using preconfigured UT on Mojave
SIP?
Then disable it, we did not have it previously and the world still is here, Macs still operate.
Just no not overwrite all folders, just copy few files that are needed for basic acceptable user experience. And to me it means that user logs in with AD credentials (yes, AD joined machines, some might have different opinions) and are presented with working machine, no nags, no pop-ups, standard wallpaper, standard dock
Not much to ask. Hence custom few .plist files in UT work “wonders”
Apple might say otherwise, but it works for me