Casper Admin "migrate" fails

[jonscott]

I've read a few discussions of the pros/cons of migrating packages and scripts in Casper Admin after a v8 to v9 upgrade, but I've seen nothing yet where migration itself failed. Has anyone had to deal with this? JAMF support remains a bit stumped at the moment (as do I). In fact, I've just learned that a defect has been opened for this specific behavior based on my case. I've been considering throwing this out to the Nation for awhile, and figured why not!

The upgrade itself went from 8.73 to 9.62, and with no major issues during testing or upgrade (though I did NOT test a distribution point Casper Admin migration). Client apps are all current, and the migration fails from multiple machines. Also, I'm using a local admin account (non-LDAP) with full permissions. I've also tried running this from a newly created full admin account, but that fails in the same way.

The migration fails with an error: There were errors during script migration. For more information, see the log file <...>. Script "whicheverScript.sh" failed to upload.

My first attempt failed on the first script encountered. A python script -- which I removed, thinking there could be a problem with my one and only python script. But subsequent attempts now fail on the very next script in line. All that's left now are shell scripts which have never presented any problems. I removed that next script in line and tried again, with the same result.

In debug mode, this is all I get from Casper Admin:

ERROR: The script  whicheverScript.sh failed to upload. The operation couldn’t be completed. ( error 401.)
Output: <?xml version="1.0" encoding="UTF-8" standalone="yes"?><uploadResponse><id>-1</id><md5></md5><message></message><receivedSize>0</receivedSize><successful>true</successful></uploadResponse>

The <id>-1</id> portion of the log makes me look at the JSS IDs of my scripts -- all I noticed is that there is no script with ID 1, but not sure that means anything. It doesn't seem a likely culprit. A 401 error is normally an authentication issue, I think, but I'm not sure what that might mean in the JSS since I'm using a full admin account already.

Full disclosure: I started typing this up last week, and there has been additional movement on it with support. It appears that a specific mysql table relating to migration is not being created correctly nor sticking around when it has been created manually. That may turn out to be the culprit in the end.

Post upgrade, I also have issues with package edits sticking in Casper Admin. I'm wondering whether the two are related. After uploading a new package, editing multiple fields (info, OS, notes, category, etc), saving, and quitting -- the edits seem to stick when I immediately (within a couple minutes) re-open Casper Admin. But 5 or 10, or maybe 30 minutes later those edits have disappeared. Since all that information is written to mysql, and I already seem to have another table issue in mysql, I am of course wondering whether this is a MySQL problem altogether.

FYI I am running on RHEL 6.6, MySQL 5.5.41, tomcat 7, java 7. I upgraded MySQL from 5.1 to 5.5 about a month before the JSS upgrade and did not see any issues with JSS 8.73 on MySQL 5.5, so it seems to me to be related to the upgrade.

[m_entholzner]

have you tried to upgrade your MySQL to 5.6? We had very, very strange effects with MySQL 5.5 on some of our customers servers.
My favourite: a table with 5.6GB in size which was only 200MB after MySQL upgrade
Another ones: non-working enrollments, installs and so on...

[jonscott]

@entholzner I'll give that a try today in my test environment. It wouldn't surprise me if MySQL was the problem, since most of my post-upgrade issues seem related to writing information to the database.