Casper Admin gives confusing error on .app files

@mm2270 Trial and error learning. It was just odd that it says it supports .app files in the error saying that it cannot upload .app files. I didn't see anything clarifying that in documentation, so I figured I'd ask here.

@mm2270 Is there any recommended way to run .app installers since just pushing them in the .dmg file just sets them in the root directory? I'm trying to figure out the least effort way to maintain the packages we can't use autopkg for. Composer works, but it is a lot more steps to set up a clean environment to capture from.

[Edit] Ah, that "OSX Installer.app" clarification makes a huge difference. It's current wording definitely makes it sound like it is just meaning ".app files made for OS X" and not specifically "OS X Installer.app files"

@McAwesome Recommended way to use .app installers? Yeah, don't use 'em! I'm only partially kidding. In all seriousness, if you can, I would reach out to the developer of whatever app installer it is you're struggling with, and tell them that you're struggling with it, because you can't deploy it as-is to your Macs through any management system on the planet. Developers really need to get the message through their heads that .app installers are nonsense, can't be used in large scale deployments, and that, if possible, you will find another similar product that provides a "real" installer and switch to that. (I'd tell them that even if it wasn't true)

Sadly, my only actual recommendation to you , except for the above, is to do a Composer Before and After snapshot of the installation. Those are frankly kind of crappy and I don't recommend them, but there are times when its necessary, and this may qualify as one of those times.
But, before you go through that, I would definitely contact the company. You never know, they may have an actual .pkg installer lying around somewhere they can send you.

Edit: So, I just finally got around to looking at the link you provided to this BoxEdit app, and I'm just floored that they have the audacity to state on their page that this is ready for use in Casper deployments! It is indeed an .app installer, not a .pkg. I'm just baffled at how they are calling this deployment ready. Seriously, I would call them out on this, tell them they are doing false advertising or something. Either someone there is seriously misinformed or its a typo of some kind.

@mm2270 I tried to open a ticket with them, but it was instantly closed due to bureaucracy. I'm one cog of a bigger IT system, and we have a contract with them for our users. So all of our support tickets have to go through our campus rep rather than the main Box support team. I'm trying to get a compatible installer, but I don't see much movement.

Bureaucracy sucks.

I'm guessing what happened was that they used to have a Casper compatible installer, but after one update or another it got swapped with the consumer focused installer and no one noticed.

Here is the script I used yesterday for the lousy box edit installer, it gets installed during the thin image has a launchdaemon to run it each boot and once the firstboot user is done logging in it will present it to the real user.

#!/usr/bin/perl -w

use strict;
use File::Copy;
use Sys::Syslog;

(my $progname = $0) =~ s#.*/##;
$ENV{PATH} = '/bin:/usr/bin:/usr/sbin:/sbin';
umask 0022;

my $console = "/dev/console";
my $consoleuser = getpwuid((stat $console)[4]);
my $basedir     = $ARGV[2] || '/';
my $fbuser              = "someuser";
my $installdir  = $basedir . "/.installfiles/Box/";
my $inst_cmd    = $installdir . "/Install Box Edit.app/Contents/MacOS/Box Edit Installer";
my $checkApp    = "/Users/" . $consoleuser . "/Library/Application Support/Box/Box Edit/Box Edit.app";

main:
openlog $progname, undef, 'user';
# install the software
if ($consoleuser ne $fbuser) {
        system("su $consoleuser -c '"$inst_cmd"'");
        if (-d $checkApp) {
                syslog('notice', "%s installed Successfully", $inst_cmd);
                # disable future attempts to install
                disableLaunchDaemon("com.hp.BoxEditInstall", $basedir); #you'll have to write this function or do a defaults write, or run this another way
                syslog('notice', "Installation Complete");
        }
        else {
                my $title = "Install Failure";
                my $message = "The Box Edit install Failed.";
                displayMessageBox($title, $message); #you will have to write your own display Message Box function if so desired, the app tells them it failed anyway so might just delete this else clause. 
        }
}
else {
                syslog('notice', "Not running %s firstboot user is logged in", $inst_cmd);
}
closelog;

@McAwesome Well, that sucks about the bureaucracy. Sorry to hear that.

I'm guessing what happened was that they used to have a Casper compatible installer, but after one update or another it got swapped with the consumer focused installer and no one noticed.

That's certainly a possibility. A somewhat less probable reason is that they think DMG is a Casper Suite compatible format. After all, JAMF promotes DMGs as the way to build packages for Casper Suite, which I have never really agreed with for a variety of reasons. The problem of course is that the DMGs need to be built out of Composer or they aren't going to be compatible.

I guess give @nessts's script a try. its ludicrous that we need to go to such lengths to work around silly .app installers that developers insist on putting out there. There's only two reasons they exist that I can think of - laziness and advertising, neither of which I have much tolerance for.

@nessts @mm2270 I ended up using a script I found on this site to set it up in Self Service. I should be good for now.

I have been running into this issue recently. We it even happens when I create my own pkgs and dmg's with Composer, it will some times give that error and it will duplicate the file that I dropped in Admin. Any suggestions would be helpful