Removing old FUT settings

[cberry]

We are on our first year with JAMF.

Early in the year we created a suite of configuration profiles and policies, and some PKG/DMGs using Composer.

In a couple cases we set FUT to ON.

This has created some issues. Now when new users are created, a bunch of unwanted settings are created. We have turned off FUT of the offending PKGs and DMGs, but the settings are persistent. Even if we un-enroll and re-enroll, the settings show up with every new user created on the computers.

Where does all this stuff that's added to the new user template come from? What is happening behind the scenes when we create a new user? Our new user template in /System/Library/User Template/English.lproj is clean. But the new user has all kinds of stuff already there on sign in.

I'd like to purge this cruft so we don't have to clean up users after creation.

[sdagley]

You mention your /System/Library/User Template/English.lproj is clean, but have you re-imaged the computers that previously had packages with FUT enabled installed? If not, all of those settings exist in the user template on those machines, and will be inherited by any new user.

[cberry]

But the items I'm talking about don't live in the template folder.

For example, my machine, the User Template is clean - just the basics. But if I create a new user right now, that user's folder is full of stuff that is not in the user template folder.

The JAMF client has to be adding its own folders and files.

Where does this stuff that is added to the new user on creation come from? Where is it stored? Once I know that, I can clean it out in any of several ways.

[sdagley]

The jamf client isn't automatically re-installing things unless you have policies that are still being trigged. The FUT option simply writes any settings that would be user specific to the System's user template. Unless you erased and re-imaged those machines, all those files will come back for the next new user login. In theory you could identify every user file that was modified in your install packages (anything in /Users/whateverusercomposerranas/Library/) and then go open every one of those files and edit by hand to remove the changes you deployed, but a wipe is probably much faster.

[cberry]

Thanks for your answers!

So, where is it adding the extra files from? We have no policies or PKGs or DMGs now that have FUT ON.

Does it pull the files it stuffs in the new user off the JSS, or is there a location on the local machine?

If it pulls off the JSS server, why is it pulling old data? Nothing has FUT set to ON now. This has to be legacy info, put in place some time ago, and replicated every time a user is created.

Since I suspect it is something cached on the local machine, where are these files stored?

We can't re-image hundreds of machines in the middle of the school year. Isn't JAMF/Casper/Pro supposed to dispense with the need to image all the time?

[cberry]

I think I just found what I was looking for.

In System/Library/User Template there is a folder called Non_localized. The legacy FUT stuff is in this folder.

So the process on new user creation is clearly merge the contents of /System/Library/User Template/English.lproj and /System/Library/User Template/Non_localized into the new users Home Folder.

I have tested, and without Non_localized available, users are created without the FUT cruft.

I will either delete this folder from all machines, or, more likely, redistribute an edited version per your earlier response.

Thanks, sdagley! You put me on the right track!

[sdagley]

@cberry Glad you got it figured out, and good find on the /System/Library/User Template/Non_localized directory. Back in my pre-Casper days of directly manipulating the User Template I just tweaked /System/Library/User Template/English.lproj directly since I was only concerned with the English version.

[cberry]

Yes, my experience has always been with modifying English.lproj. I never gave Non_localized a second look. I'm super happy to put this mystery to rest!