FUT & FEU...is it really needed ?

We use it all the time in our environment. When creating a snapshot in composer, you may need a file that gets put into your user folder rather then the system folder. Well, your home directory is not going to be on every computer and unless you check the FUT & FEU, the package will fail because it can't find the directory. FUT & FEU allows you to put the files into the currently logged in user directory without having an issue.

My understanding (not used it) of indexing is that it's for having the option to "uninstall" later. I've read mixed reviews on that.
As @chet.bishop said above, the user account used to create packages will not show up if you check FUT & FEU. If those were not checked, it's possible that the installer(s) did not need anything placed into the current logged in user's (and/or future users) accounts such as a Dock icon, pref, etc.
So if you wanted to package Chrome as an example, the DMG would have the Chrome.app only, and need no user template alterations.

Hi, Not sure why that would be.. Rather I think that you may have remembered this 'the wrong way around' !

Since usually you do not want to index packaged - The only purpose as someone else has already mentioned is to 'uninstall' something, that was previously installed.. And using 'indexing' swells-up your database,
so best to use indexing only when you actually need it.. i.e. "not all the time".

Also usually you do not want to use FUT/FEU - except when 'copying' some user settings from a DMG image.
(i.e. if not doing this via a configuration profile).
The FUT/FEU method, lets you copy over miscellaneous things into the user account.
- That's what you would want to use it for.
- Otherwise you would not want to use FUT/FEU.

Yes!

I use FUT to set certain defaults that need to be set just "Once" to get a user started when they log in for the first time on a computer (like a Dock with our apps instead of Apple's). This is because Configuration Profiles doesn't allow this: it's always or nothing.

I've used FEU to drop certain files as well. The way to do it is to make the DMG from a local account that will not exist in the target machine. When the policy runs to drop off the FEU contents, you can follow it up with a script that deletes that user folder that gets created by the policy.

We use FEU/FUT for things we capture with lots of user-folder saved preferences, license files, stuff like that. And our default dock image, wallpaper settings… basically anything in the user environment. So I'd argue that it still has relevance, but not all environments will use it or need it based on how machines and applications are deployed.

I use FEU whenever I'm doing a snapshot in Composer regarding a software install that installs files inside the user's home directory. This is especially handy for incorporating a site or volume license into a piece of software, for example. Here's a more specific example:

We own Sublime Text, with a volume license key. Normally we would have to install Sublime Text and then open it, then manual enter the volume license key to register it correctly. But through the magic of Casper, Composer and FEU, I can do this instead:

Open Composer, and start a new snapshot package. After it takes its first snapshot and says to install, then install Sublime Text. Then open Sublime Text, and enter the volume license key into it. Verify it is registered correctly, and quit out of Sublime Text. Then tell Composter to take the second snapshot and complete the package.

When it's done, look at the list of everything that was installed in-between snapshots. You will see Sublime Text in the Applications folder, but you will also see some files that were installed into your home directory, usually into the Application Support and Library folders. Go through them and look for anything related to Sublime Text, and you will see where the license key file is stored, in addition to some other support files.

Build your package as a DMG, and then import it into Casper Admin. Once there, click the FEU checkbox for that package. What this does is allow Casper to automagically install all of Sublime Text's support files in their correct relative locations for the user that is currently logged into the target Mac at the time, in addition to putting Sublime Text itself in the applications folder.

So when that user runs Sublime Text for the first time, it doesn't ask for a license key because the key file is already in place inside that User's home folder, thanks to FEU. It is literally ready to use as soon as it's installed.

Think of FEU as being a wildcard for the home directory. If you don't need to install files into a user's home directory, then you don't need to use FEU. And FUT is similar, but instead of just installing files for the currently logged-in user, FUT installs files into the user template so those files will be automagically created for any new user added to that Mac.

It took me a little while to get the hang of it too, but now I am enamored with FEU/FUT. It's a ridiculously powerful option, and managing a bunch of Macs would be a lot harder without it.

@znilsson Yep, we use it for dropping license files. That was the "drop certain files" part in my post. I just didn't want to get too deep into it. But, yeah, it works very well for these types of things.

I've always been taught: a, don't touch users' home directories; b, DEFINITELY don't touch the user template. If for some reason you need to put something in either, write a launchagent instead. [1]

Still, sometimes that philosophy just doesn't make sense. My best example is setting Safari default preferences for new users. Yes, I could write a script to be triggered via launchagent or Outset that uses an extensive series of default write and plistbuddy add commands... but that just seems more cumbersome than just using FUT and moving on with my life. :)

[1] Yes, this isn't a law or anything, but it's a good philosophy.

We were using it a lot more about 3-4 years ago. Our use of FUT and FEU, along with Composer has dropped considerably. It's a nice option to have, but we prefer to use login scripts if there is something that needs to go into users home folders as we can store all the info in the JSS and manipulate it later on if required.

It's always been considered a "bad thing" to mess around with the user template, while on the other hand, it's worked for over 15 years and still continues to work for the most part.

That aside, if it's preferences your setting, I would use config profiles. Dropping files into the user template is one thing we've seen not work in the last few OS versions.

+1 for @davidacland's comment. We take advantage of it, but not as often as you would imagine. The only time I can think of a situation where we ALWAYS push it is our dock items configuration to remove "?" from the dock or apps we block by policy (ex: iTunes).

That aside, if it's preferences your setting, I would use config profiles. Dropping files into the user template is one thing we've seen not work in the last few OS versions.

For me, config profiles work great for "enforced" preferences. I haven't had them work nearly as well for preferences you only want to apply only once as an initial default (that is, the "set-once" model from MCX). I'm aware of using mcxToProfile to create these "set-once" profiles, but I have had very scattered results by doing so, enough to avoid doing so at all.

Hi Guys,

Thanks for all the responses, its made things a lot clearer for me now and interesting to see what people are doing out there.
I took a look at one of the 3 packages in our JSS that was actually indexed and also had FUT & FEU ticked. It looks like the guy who created this Canon printer package in Composer had his email, etc open when he did it as the package contains links to things like /users/username/documents/microsoft user data/blah blah and I've now got a copy of his Outlook 2011 identity on my mac amongst other things :-)

I guess the moral of the story is double check everything if you're going to use these options before pressing go :-)