Migrate Casper Admin scripts to Database any caveats

Contributor III

My current client has had Casper for roughly 2.5 years. They went from version 8.x -> 9.x but have never hit the migrate button in Casper Admin. They DP's are Windows with SMB and HTTPS.

Can anyone foresee any issues with this?


Valued Contributor

I've never had issues migrating scripts and highly recommend it.


No issues here either... nice to be able to modify them on the fly via the web interface as needed too.

Legendary Contributor III

Agreed. If anything, I would encourage your client to do it as soon as possible. There are distinct benefits to them being located in the db. On the fly editing and creation of scripts, as mentioned, is one of them. Plus, if there's an issue with the DPs, either not mounting, or not being accessible over HTTP/S, scripts in policies can still run in most cases, so it can be useful if you needed to run a script on a client having trouble connecting to your sharepoints since its not reliant on them when the scripts reside in the database.

Release Candidate Programs Tester

Heh.. I should probably do this.

Contributor III

@bentoms @mm2270 and others... believe it or not... I have never hit the migrate button in Casper Admin as of today.
Our JSS still on premises, DP's are SMB and no cloud DP for the time being. What happens to pre-existing policies and their (existing) pkgs they're bound to?
Are all existing pkgs compressed to pkg.zip, is that right? Or does this will only involve uploaded pkgs after the migration?
If the name of the pkg changes to pkg.zip, would then existing policies still maintain the link to the (zipped) pkg without needing to updated them (the policies)
I mean: let's say an existing Policy "Install Application_Z" has a payload with "Application_Z.pkg" to install "ApplicationZ"
What happens after I hit and complete the migration?
If that pkg is being zipped after the migration starts, will l have to update Policy "A" to use "application_Z.pkg.zip" or this is done automatically and then policy will then show "application_Z.pkg.zip" in its payload?
I think I have missed something (late friday night) but could not find any explanation to better understand...
Many thanks to all!

Release Candidate Programs Tester

@carlo.anselmi how old is your jamf instance? Do the scripts live on the DP or within Jamf?

It's likely you won't need to do this as it's done already.

Contributor III

@bentoms hello and many thanks for you reply. Sorry forgot to say it's a very old JSS (originally 8.x I think), happily upgraded through the years up to 10.26.1 and all pkgs and scripts are still on its main DP (and replicas), so the option to migrate it's still available in JAMF Admin app. I would like the idea of having scripts in policies can still run even if clients fails to reach the DPs.
Many thanks again! Have a great weekend

Release Candidate Programs Tester

@carlo.anselmi wow.. yea.. so the scripts being in the DB is great!

For the .pkg's.. only non-flat are appended .zip, which now would be only pkg's like the Adobe one's.

IIRC, the JSS just handled this. But backup all the things, reach out to support and hit the button :)

New Contributor

ideal to have the option to change them on the fly through the web interface depending on the situation as well.

GarageBand for Windows