Error 304 when installing Named License package from Enterprise Admin Console

[TonyPaco]

Greetings.

Vitals: I'm running macOS Catalina v10.15.2; using federated licenses at a university

I'm getting consistent error 4 when trying to install a previously good and working Self-Service Creative Cloud Desktop App package from the Admin Console using munki. Using admin privs to repair the installation does not solve the issue. I did get one install to finish, and got to authenticate, but upon trying to install Acrobat Pro, I was presented with an error 304, telling me to download and install the Creative Cloud Desktop App again. Actually doing that, outside of our munki environment, also did not provide satisfaction. It led to more error 4s.

Additionally, when I checked the Admin Console, the previously good self-service package was listed as "up to date," but it had expired. I decided, for the sake of troubleshooting, to download a new self service package. THAT package gives a never-ending error 81 upon installation attempt.

I understand maintenance was done on Creative Services today, but https://status.adobe.com stated the maintenenace had concluded by the time my testing and re-packaging was done.

Any advice would be appreciated because, well, sending a tech out to each of our 500 or so Mac users who might be trying to install this software on the first Monday back after break isn't really an option.

Please and thank you.

[___Dom___]

Hello,

error 81 is caused by the installer detecting another instance of an installation running on the system; please could you reboot one of these machines and confirm if the same error occurrs by starting the installation without having opened any applications? If you still get the same error, please try running the installation in safe mode. I appreciate that this is not a viable solution for all 500 machines, but it should help rule-out an issue with another application or installer, or identify whether there is a different problem here.

Further details here: https://helpx.adobe.com/enterprise/package/help/troubleshoot-install-uninstall-errors-ccp.html 

[TonyPaco]

Rebooting the machine just causes munki to install in a loop forever, throwing the error 81 into its logs.

Rebooting into Safe Mode, and using the Named License Self-Service package I downloaded yesterday, also results in error 81. Additionally, deleting the LaunchDaemon and PriviledgedHelperTool installed by the installer, along with all references to Adobe folders in /Applications/Utilities and /Library/Application Support also causes error 81. (Logs: https://pastebin.com/K9z1Kjea and https://pastebin.com/SGV4ENrC)

However, the previously known-to-be-good installer, circa Nov 25, 2019, (to which the installer downloaded yesterday claimed to be identical) does indeed install and seems to be working fine having been installed while in Safe Mode. I've since restarted, authenticated with my federated ID, and am testing installations now.

This, obviously, isn't the best solution to try to explain to 500 users, many of whom don't have admin rights, hence why we use something like munki to install software. However, I can add the addtional file and folder deletions to my munki pre-install code and see if that provides satisfaction.

[TonyPaco]

I see there is yet another different Named License self-service package when I download it today.

A whole 50 MB more of goodness from last night's download.

Gonna try that because I'm convinced that the issue is your Desktop App is just having a difficult time updating itself when it gets inititally installed as an older version.

Not like that's EVER happened before or anything...

[TonyPaco]

Today's package will not install outside of Safe Mode. It does install under Safe Mode, but then wants Admin Privs (back in non-Safe Mode) when trying to install applications which is literally the opposite of "Self Service" that I requested be part of the package when building it in the Admin Console.

[TonyPaco]

Update: It will ask for Admin Privs twice, then provide Self-Service installations...until I restart the machine. Then it will ask again.

[TonyPaco]

Jan 8, 2020, Update:

Using the installer I downloaded from our Admin Console yesterday at 12:49 pm CST, packaged into munki, I still get Error 81 errors when munki is attempting to install the package at the login window after a fresh restart.

I haven't logged in.

I haven't started a single application.

Munki simply did it's usual hourly check-in and tried to install.

Installing manually while in Safe Mode does seem to work. But, to reiterate, that isn't a solution for 500 users who will want this software, a fraction of whom have admin priviledges. Munki doesn't function correctly in Safe Mode, as Safe Mode isn't the idea location to really install software.

Additionally, I've had reports from users claiming they've had success installing the package using the product version I have in munki that was packaged on November 25, 2019.

Any further help would be appreciated.

[___Dom___]

I think it would be best to have someone take a look directly on the system and analyse the log files if necessary. Please raise a support case via your Admin Console.

There is currently a known issue installing via ssh or Munki on Catalina where the installation is done entirely via the command-line, but the error messages are different, so I don't think that's what's happening here. Also, that issue can be worked-around by running the package installation twice.

I assume you're performing the installation with a command such as:

sudo installer -pkg PackageName.pkg -target /

I appreciate you need to get this package onto a large number of machines, and that it would be best to automated it, so I suggest having our support team take a look at the logs, and you can make them aware of any other tests you've performed - perhaps link them to this thread so they have all this information already.

[TonyPaco]

Thanks.

In the interest of full disclosure, I've been testing on a macOS Mojave machine since Tuesday morning. I neglected to mention I reverted back.

It's being installed however Munki installs it, which I'm fairly sure is the command you cited. I can add a post-install script to try to install it twice, or even make a totally different method of installation to stash the package in tmp and run your explict command.

I will try a few more things and then raise a question via the Admin Console.

Regardless though, the fact that the installer worked in mid-December and stopped working in early January and I changed nothing is quite frustrating. 

[TonyPaco]

This problems seems to have gone away, without much change in the package or deployment methods from munki.

I'm on to a new problem regarding configuration of the Desktop App under certain conditions.