There have been a few discussions about using or not using the user template folder for populating a new user's folder.
Over a number of years now, we have used the user template folder for loading in settings, license information and auto updating information depending on the application.
The question I have is whether people are having any luck with Mojave and the user template folder being populated with these types of files. I know many of you aren't touching the user template and use scripts and LaunchAgents to populate the folders at login time. We know we have a lot of work to do to prepare for changing our deployments.
In the short term though, any thoughts out there on this?
Thank you in advance...
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.
Thank you all for your reply.
Like others, I have been using the user template folder as a way to populate specific application settings that the .plist won't provide. With this all stated about SIP, I am beginning to re-explore the use of custom configuration profiles for those applications so we can avoid the pitfall of the user template folder.
I don't really have any experience with the launch agent stuff that has been recommended. Something to learn this school year.
hi here it my thoughts apple are going to stop launch agents i would go down that route i would use the users template until you cant launch agents are how the system is essentially hacked the users template only effects new users it has a lower priority with apple as far as i know launch agents are getting depreciated the users template will always be there
Configuration profiles are awesome... until the user needs to change something. Then they're either fsck'ed or you're creating a fleet of custom configuration profiles for users (lulz... not happening).
The next best thing to User Templates are launch agents, and/or the Outset tool. And I really don't see LaunchAgents going away... not until command line access does. There's just too much stuff dependent on launchd.
I'm new to using configuration profiles as a solution to the default user profile problem. I admin a lab of 20 iMacs. We do not save user's profiles. From what I'm hearing, the only way to load a custom default profile is through some saved config settings captured using Composer or some other app and launching it each time a user logs in as part of a script. This seems like a very clunky solution. What does this do to your user's log in times?
@rriojas Composer has no part to play in Configuration Profiles. On Macs (not iOS) you can have custom settings as an option when creating a new configuration profile via Jamf. This allows you to upload a plist file, for any app or Apple setting located in /Library/Preferences or ~/Library/Preferences. This preference shouldn't be uploaded as is, but cleaned down to only the config you need as it will merge with the users preference. The question is what settings do you need to set? Attached is an example of custom settings.
May be best to use the /Library/LaunchAgents to run scripts that configure the account. I agree with above posters that it's not a good practice to use the User Template folder anymore. SIP and other reasons. This can be a burden on us older scripters but in the end, /Library/LaunchAgents will be easier to manage... and cleaner.
Thanks for getting back to me. The problem is that on these lab computers, the default profile is highly customized so that my users have a consistent unencumbered experience each time they log in. I I've said before, no user profiles are saved. The profile I want loaded is highly customized: mouse settings, muted external speakers (we're in a library), customized dock and background, disabled Wi-Fi and Bluetooth, MS Office and Adobe Creative suite set so there are no annoying new user messages, no keychain demands, etc, etc, etc. A consistent, streamlined user experience is very important. I was checking out Profile Creator. It's up to beta v. 10. In my attempts to use it, I had multiple errors. Granted, I've never used this before, but it seems rather hinky. I thought JAMF Composer also created plists or .mobleconfig files to be used with login of startup scripts. Is this not the case?
Something not mentioned in here is that if you uncheck "Perform login hook actions in background" in Jamf > Settings > Computer > Check-In, you can apply settings to the user that is logging in before their user environment loads. This makes scripted changes with docktutil and other scripted user settings changes more seamless to the user. It likely adds a slight delay to the login but not significant.
@allanp81 Hope all is well could you reach out to me if you have a minute or two today. I'm having an issue with a High Sierra User Template that I'm not having anywhere else. This lab has all new systems that had High Sierra installed with APFS+. I created the template and when logging in the message just pops up cannot log in because of an error. I'm not having this issue with any of my systems that are High Sierra and HFS+.
In these labs I too am very granular these are all Music labs with lots of hardware and Pro tools, Reason, Finale and Aria Player setting that cannot be done with another method that I have been able to find.
I did Create this template on these machines actually a single machine at this time, not on another machine and not ported over from an older system.
Do you happen to have the steps to create one in High Sierra? I could, check it against my script that has worked, seems like forever. Maybe I've missed something somewhere or something needs to be changed for APFS+.
Thank you, and have a great day today!
@allanp81 Not sure that it is a user template now. Seems that after I joined this lab to our Windows AD it won't allow anyone to log in and that is before the template was pushed, which I tested last week. I've never had issues after Binding them to AD having a login issue. I've checked with our networking group they say the switches are all open and fine. Strange had to create local, student, accounts until I can fix this issue.
Thank you, Allan, I will let you know what I find.
I've had no problem customizing the guest account but it's done individually; each machine has to be set up. First make a duplicate of your English.ljproj folder in your root account! After making all the changes to the guest account that I want I fast user switch to the Root account. There I open 3 windows, one in the upper left corner with Guest highlighted, in the lower left corner I have the system, library, user template open with the English,lprog highlighted and the 3rd in the lower right with the system, library open with the keychains highlighted. I COPY the library file in the guest account then delete the library file from the English.lproj and paste the new library file. I COPY the keychains from the system, library and paste it into the English.lproj library folder. works for me. Once you have a good and complete English.lproj folder you can copy that to the rest of your machines. I am struggling with 10.15 but I'll figure that out someday..
I am rather late to the Mojave party but I too have experienced issues modifying the User Template. My scripts used to delete the contents of English.lproj and replace them with the contents of a .dmg using FUT. A post-install script would apply root-only permissions. This has worked perfectly until 10.14.
I don’t like being told ‘NO’ so I have found a work-around. After all, what’s the point of a ‘template’ folder if you can’t modify it.
After much testing I have found a way to update the contents of English.lproj instead of removing and replacing it. This way Apples original permissions are maintained. The way I have achieved this is to only modify a small sub-set of com.apple.x.plists (quite a few can’t be modified without producing login errors) and then make a permissions preserving .tar of the customised English.lproj Library folder. I then deploy the .tar file to a temporary directory, extract it while maintaining permissions - also to a temporary directory and then use cp -R commands to copy the files from the temporary directory into the System/Library/User Template/English.lproj directory. Not the whole Library folder, but the specific files and directory’s in Application Support, Containers, Group Containers and Preferences as needed. This approach allows me to modify the directory without using FUT and maintains Apples default permissions. Essentially this is all about permissions really.
Thanks Apple for making something that was once so simple so complicated!
I hope this helps anyone still struggling with this.
Thanks a lot for this great question and for everyone's replies. I was running into the exact same problem.
We run a set of applications that need to be configured extensively, so the user template has really been a vital component of our system.
I disabled SIP and put all my files into the en_UK.lproj and it worked for me.
Then re-enabled SIP and everything works fine so far for me it seems.
I know it's not the best of ideas, but I don't have any other solution yet. (Will have to study hard.)
Good luck everyone and thanks for these great threads.
I've now discovered that the user template in Catalina (and consequently Big Sur) is basically broken. Whether this is a bug or intentional is anyone's guess.
Firstly it doesn't apply permissions correctly to things in the template, so for instance I have an app in the template desktop directory with 755 permissions, but when a new user account is created it only has 700 applied to it.
Also it seems that any directories that are created from within the template have some sort of ACL applied to them stopping any new user from creating them, even though they're the owner.