What to delete from Composer as best practice?

[ddasilva]

Hey Everyone, we did our JAMF jumpstart some 9 months ago and just getting back into the swing of actually using it now. I have some notes that I took during the jumpstart related to what some of the recommended best practices were but between my illegible handwriting and the length of time since we did it I know i'm missing something.

Below is some of what I recall or have noted down but I could have sworn there were other things to remove prior to building the packages. For example, logs or items in the user folder? do you keep them or remove them.

Here are some of what I recall:
1. Always try to build on a clean system (clean image)
2. Package using Admin account
3. Check sources
4. Delete saved application states ( I have this noted but haven't run into it so not sure what it is)

[roiegat]

@ddasilva When I use composer to capture a snapshot I take a look closely at what gets put on. It also depends on if your doing a normal snap shot or also capturing modified files.

A lot of stuff happens on a computer when you install stuff. So filtering through it is a skill in itself. What I do is as follows:

1) Get rid of anything that is not application related. For instance our security suite usually produces a file or two, other applications might do so as well. So you want to eliminate anything not relating to the application/settings your installing. Most of the time this is simple since these apps put their things in their own folders.
2) Most of the times I get rid of the installer logs. I find that if I installed it on my machine, it usually contains information about my computer and I would just be putting a log file with wrong info on a machine. So in theory if support in the future was to log at the log on another machine they'd be perlexed why it has all the information of another machine. 3) Saved Application States are fancy method of being able to put your application back the way you left it. If you had a window open, or a file open - it'll put you back where you left. Since it's personalized for you, get rid of it.

Once you have something remember to test it on all the different hardware types and network types in your enviornment. I always test on laptops (old and new), desktops (old and older), and even servers (ancient). I also try to test on ethernet, wifi, and VPN to ensure it works if deployed through any method. As usual, adjust as needed and re-test.

[mpermann]

@ddasilva most people would recommend if the software comes from the vendor as a .pkg file then you should test the package as it before using Composer to capture. Many .pkg files will work without doing anything to them. If you are deploying a vendor .pkg at imaging time, you may need to check the "Install on boot drive after imaging" option in Casper Admin to get those to install correctly. If you have an .app (i.e. Firefox) that comes on a .dmg you can use Composer to repackage those up or there are some other methods for doing that. Many people will mention getting AutoPkgr setup to help with packaging which is a good idea if you want to automate some of the packaging.

[kerouak]

I normally delete anything that's not 'application Specific" Also, Of you have time,like myself, Test it on a Clean OS on a VM..

Then take the steps..

Remove the obvious. (saved application state) etc.

Package and test.

Remove some other 'dubious files.. Then test..

Then test until you have you have a 'failure' , then re add the last deleted , bobs your uncle..
The beauty of the VM is that you can revert back to snapshot, so you are testing in the base state.

Bit long winded, however, in the end, it does make sense..

[apizz]

• Anything ByHost should be deleted.
• Saved Application state, as mentioned by others.
• Verify all captured Library changes are for the application you're trying to package only. Especially if the installation requires you to restart. Even if you're using Composer's new file snapshot it's going to collect other things you won't want to package with your application.
• Log directories and files. Even if they're for the application you're trying to package, they'll get recreated when the application is run after being installed.

[opus-nbo]

sorry, new to this whole thing. made the before and after snapshots and noticed some files unrelated to the software i want to package. how do i remove the stuff mentioned above? there are logs, changes in plist files etc. ... some files written by the installer... how to handle this? just leave it in the package? if not, how to remove it from the package?

[sdagley]

@opusmarketing Select any item you want to delete from your installer in the Composer window then right-click and the item at the bottom of the popup menu displayed should be Delete the item(s) selected.