Casper - Best Practices.

Not applicable

Alright, forgive me if this is a little OT..

I was looking to collate the best ideas that the `Nation has for using and winning with Casper. The Resource Kit, distilled, if you will.

What's your favorite/best bit of secret sauce to make Casper do what you didn't think it could?

I'll start with an easy (probably obvious) one: every time I add a new package, I include the date in YYYYmmdd format in the Notes: field. That way if I ever need to look at a record of when certain upgrades were being deployed, I can search Admin for that date string - or determine if something that I know has been recently updated has in fact been built and deployed.

Other things I'm thinking about: scripts to gracefully quit an app if it's running prior to an upgrade. Syntax for jamfHelper that confuses the user as little as possible. Extension Attributes that find details you didn't think could be found.

15 REPLIES 15

althea
Contributor

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.

bbass
Contributor

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.

denmoff
Contributor III

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

AndyBeaver
Contributor II

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!

dpertschi
Valued Contributor

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.

egjerde
New Contributor III

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!

cmbowe01
New Contributor

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.

rderewianko
Valued Contributor II

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

calumhunter
Valued Contributor

get on IRC webchat.freenode.net/?channels=##osx-server](webchat.freenode.net/?channels=##osx-server)
read ben to...




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.

kerouak
Valued Contributor

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

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

davidacland
Honored Contributor II
Honored Contributor II

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

seann
Contributor

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.

chzar
New Contributor III

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.

Praisethesun
New Contributor II

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

mjhersh
Contributor

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