Casper 9 "Migrate" button

We recently did our Migration. We have about 70 scripts and 800+ packages which account for ~500GB on the share. Once we got through a few scripts (compiled AppleScript) that had to be removed and changed our migration took about 2 hours. We did this in a test environment before productions as we too weren't sure how long it may take.

We still haven't done the migration. Running Casper 9.25. We have about 300GB of packages and scripts. It take it that the main advantage of migrating is that you can run JDS instances ? Is there any other advantages ?

@rcorbin

From my understanding the ability to run JDS instances is the main benefit. One additional benefit I've seen is that after you migrate your scripts are then hosted in the MySQL database. Which means you then have the ability to edit scripts from within the JSS web console.

@rcorbin @ShaunM9483,

Those are the main benefits of/reasons to hit the Migrate button.

We also, currently, have an open defect that only happens in environments that have not been migrated.

D-006777 will cause package validation errors to happen on .pkg files (and you’ll see the MD5 hash show up as the local directory of the package), even if package validation is turned off in the JSS, on 9.3x JSSes if the distribution point has not been migrated.

That issue does not happen on 9.2x as the package validation feature is something that was added in 9.3.

D-006777 is still listed as open with a planned for release disposition, so we’ll hopefully see a fix for it soon.
At the moment, so if you are considering jumping up to 9.3 or 9.31, migration may be something you’ll need to plan for as well. Once migration is done, the problem no longer occurs. This is NOT expected behavior, as it should work regardless of whether or not packages and scripts have been migrated, so we opened it up as a defect.

Just thought it would be helpful to add that here for anyone planning an update soon that hasn’t yet hit that Migrate button in Admin.

We also have a short little KB article on Migrating Packages and Scripts.

Thanks!

Amanda Wulff
JAMF Software Support

Also, Casper Admin will zip non-flat packages automatically after migration. This helped us as we host files on a Windows VM and serve them over HTTP. We were seeing failures with non-flat packages.

@Brad_G

Great addition! Given all the wrestling I've done with HTTP distribution points in the past, you'd think I'd have remembered that little nugget. :)

Having .pkg files zipped up to .pkg.zip does tend to help with both the JDS and with standard HTTP distribution points as it keeps the HTTP distribution point from trying to read non-flat .pkg files as a directory structure (aside from weird permissions problems, that's a common reason they fail on HTTP distribution points), instead of a file.

@amanda.wulff we didn't hit migrate yet in our 9.65 environment, but it doesn't seem newly uploaded .pkg files are being zipped up (I tested creative cloud package today). Is this known issue? I thought all new stuff would be zipped?

We are on 9.62 and haven't migrated yet either, as our Adobe CC packages are all non-flat (damnit Adobe!) and we would have to re-replicate them all out to 32 DPs globally, which we are loath to do at this point.

Hi @CasperSally,

Since your environment was upgraded from the 8 series, any non-flat package uploads will not automatically zip until the package migration is complete. This is because it's an "on or off" situation, where the JSS either expects the non-flat packages to be zipped (after migration) or expects the non-flat packages to not be zipped (prior to migration).

If it were a new JSS in the 9 series, there would be no need for migration and it would automatically zip packages right away. Basically, if you see the option to Migrate in Casper Admin, there will be no zipping. If you don't see the option to Migrate, all non-flat packages will get zipped.

Hope this helps!

Grant

I migrated our DPs a few weeks ago and wish I had done it sooner. The two major benefits for us are that flat packages replicate faster (we have 40+ SMB DPs around the world) and that scripts execute directly from the JSS rather than needing a DP to mount.

That last one has been a game changer for me. I have a lot more flexibility with scripts since I can run installation policies that used to fail because the DP was already mounted for the script. It's just amazing.

That said, we had a lot of packages to migrate, and the migration time wasn't my concern as much as the replication time (replication outside the US is VERY slow for some sites). I spent a couple weeks manually converting and replicating all non-flat packages and changing our policies to use them before I actually flipped the switch, so there was no interruption in service at all.