Casper - Best Practices.

A tip we picked up from someone else here in JAMFNation -- add every Self Service policy to an "All" category (in addition to whatever other categories are appropriate), so that when a user launches SS, they have a master list of available policies just one-click away.

With regard to gracefully shutting down applications via the command line, the 'osascript' command is your friend.

For example:
/usr/bin/osascript -e 'tell application "Mail" to quit'

This allows you to leverage applescript from the command line. It's quite handy in cases like these.

why did this thread die? I'd love to see more "Best Practices" tips.

Something I learned early on from this community is to have a naming convention for your packages and dmg's.
ex someapp_v158_10312013.pkg so the name of the app, version and when it was created. This has helped me over time for sure. Great thread!

Package Info field.
I make heavy use of this to alert the field support staff the status of the package or script. Some of our techs only do Mac stuff once in a while, so this notation is of great use to them. This text shows up in Casper Imaging and Remote when you select an item.

Some of my info notes include: Confirmed, Unconfirmed, testing, do not use, use at imaging only, at your own risk, license required, no license required, freeware, 10.6 only, 10.7 +, and so on.

These are helpful little tidbits but I wish there was an entire book of these... jumping into mac administration and just "using" Casper is less than easy!

This should be one of the most active and healthiest threads. We all could benefit from updated best practices. In our environment we're planning to rebuild our Casper infrastructure. Currently we have one OSX MacPro acting as Netboot server and JSS server. I'd prefer separating and virtualizing the servers and would like to assume that would bring us some great benefits. I was hoping to find at least a Pros/Cons or feature matrix for the OSX, Linux, Windows server choices. Some actual performance comparisons would be nice too. Likewise, best practices for any or all of those environment choices. I can follow the system administration guides but there are a lot of gaps in the information in terms of what those design choices are either going to give you or how they may limit you. Anyone out there know of a reference with that sort of information? My searches have turned up fairly empty so far.

Here's a few on my list.

• TEST
• Don't test in prod
• Learn Thin Imaging Work flows (using auto dmg for base) (create user for the base accounts)
• Follow the self service model if you're doing it more than twice, automate

get on IRC webchat.freenode.net/?channels=##osx-server](webchat.freenode.net/?channels=##osx-server)
read ben toms' blog [macmule.com](macmule.com)
read rich trouton's blog [derflounder.wordpress.com](derflounder.wordpress.com)
read greg neagle's blog [managingosx.wordpress.com](managingosx.wordpress.com)
watch the macsysadmin videos [macsysadmin.se](macsysadmin.se)
watch the PSU macadmins videos [http://macadmins.psu.edu/conference/resources/
watch the JNUC videos https://www.youtube.com/channel/UCUGhY1mOxdEA4hyEnnB1NSw

once you have the knowledge, ideas, concepts etc then you can apply the best practice for your environment.

There really isn't a cookie cutter best practice because everyones environment is so different.

I'd like to see this resurrected.... MAY WE??

While I'm at it..
Best practices for packaging using composer...

Good idea!

On packaging, I would say:

• See if the vendor package works as-is (no need to re-package something that doesn't need it)
• Use AutoPKG if you can, it saves you a load of time
• Given the direction of SIP and 10.11, I'd avoid FUT and FEU as much as possible (use login scripts as an alternative)
• Use snapshot packages as an investigative tool to find out what an app is putting where, but avoid them as your main method for packaging
• Use config profiles rather than packing up plists in your composer packages. It works a lot smoother

Try to build Smart Groups so they can be re-used. For example, we like to make a smart group for each of our licensed apps, and name it Application Installed: xyz, which just uses the criteria "application title is xyz". (This can also be extended to something like "Application Allowed: xyz" where you can set the criteria for selectively publishing apps in Self Service.)

You can then easily re-use this smart group for a number of things. For example, if a license file is used and has to be updated, it's very easy to scope a policy to "Application Installed: xyz" and push a package/script. Or if I wanted to do something that excluded machines with this app, I would just add Application Installed: xyz to the Exclusions list. It also lets you quickly get a number on your install base by simply finding this smart group.

Use one payload per profile. If your wireless payload and restrictions payload are in the same profile and you make a change to your restrictions, you will see all of your users at your doorstep momentarily.

Hi chzar, do you recommend one payload per profile for both mobile and computers?

Yes, it's a good idea for both. It makes it easier and less disruptive to make changes and troubleshoot problems.