Colons in Configuration Name breaks Casper Admin

[NTmatter]

TL;DR - Old Imaging Configurations had Colons : in their names. Renamed them with the JSS, and Casper Admin works fine again. No more UnsupportedFormatException.

Long Version
Howdy, all!

Finally upgraded from 8.43 to 8.52 and everything seems to be running smoothly, with the exception of the Casper Admin application. Ever since the upgrade, Casper Admin has been failing to launch, dying with an unhandled UnsupportedFormatException after authenticating and mounting the primary distribution point.

Deleting the contents of the primary distribution point (in the test environment) didn't seem to help things at all. Running Casper Admin under lldb/gdb didn't produce any meaningful information, other than the fact that Casper Admin is built in RealBasic. The built-in database health and optimization checks also didn't do anything. Setting up a clean install of the Casper Suite showed that things would run properly, which rules out any issues with the local software configuration.

After digging up information about RealBasic's UnsupportedFormatException, it looks like they can be caused by failures during String manipulation. Going on the hunch that this was likely a content issue deep down with one of the strings being exposed to Casper Admin via casper.jxml, I went about trying to clear out database tables until things started working.

After a few hours of DELETE FROM table_name / relaunch Casper Admin / wait for failure / repeat, deleting the configurations table caused Casper Admin to start running again. Running with this, it was possible to do begin narrowing down the offending entries or columns in the table.

As an initial guess, some of our descriptions seem to contain exclamation marks. I tried wiping them out, but it had no effect:

mysql> UPDATE configuration SET description="";

As that didn't work, it was down to binary search to identify the offending configuration(s). Thankfully, we only have a few active configurations, so a few DELETE statements helped to narrow things down.

mysql> DELETE from configurations
            WHERE configuration_id < 30;

The Admin tool began working after this, so it is likely one of these items:

mysql> SELECT configuration_id, configuration_name FROM configurations
            WHERE configuration_id < 30
            ORDER BY configuration_id;

+------------------+----------------------------+
| configuration_id | configuration_name         |
+------------------+----------------------------+
|                2 | 100% Partition_  Common    |
|                3 | 100% Partition AV          |
|                4 | 100% Partition: Creative   |
|               19 | 30-70% Laptops Common      |
|               21 | 30-70% Laptops: Creative   |
|               22 | 30-70% Desktops_ Common    |
|               25 | 30-70% Desktops: Creative  |
|               28 | 30-70% Desktops AV         |
+------------------+----------------------------+

After some trial and error with deleting various items and reloading the table from a dump, the failure-inducing configurations were narrowed to 4, 21, 25. As these didn't have much in the way of descriptions, changing their names proved to get things working. The % _ and - characters could easily be ruled out as 22 and 28 worked.

These items were ultimately renamed via the JSS Web Application. As it happens, the JSS' Casper Admin page appears to sanitize ":" characters when they are saved to the database, which seems to protect things adequately. It seems, though, that these colons have their heritage in a very old 6.x install, and up until now the colons have not triggered any issues in Casper Admin.

[ToriAnneke]

Hello NTmatter.... nice to see you are still using my old JSS.

:)

[NTmatter]

It's still alive and kicking, even after having its brain transplanted onto a FreeBSD box in a cold and dark room :)

[evarona]

@NTmatter][/url][/url,
Thanks for this post. I can confirm that this caused me a few hours of sh*t-fits on my v9.21 JSS until I found your post. Nice catch.

Cheers!

[andyinindy]

We ran into this issue in 9.72, and the culprit was a ":" in a script name that was part of an imaging configuration. Seems like Imaging has issues with special characters across the board. I really wish that JAMF would address this. I will file a defect... maybe that will help things along.