Adobe Creative Cloud failing to install with ConfigMgr

[mtisd21]

Testing with a brand new built package and installing with ConfigMgr but kept getting an exit code of 6. I compared the PDapp.log of an install that works when done manually and noticed one weird difference.

Failed: Bootstrapper launch location is :: C:\windows\ccmcache\l\build\ASU2\Set-up.dat
Working: Bootstrapper launch location is :: C:\AdobeCC\Build\ASU_5.0\Set-up.dat

Under the Build folder there is ASU_4.9 & ASU_5.0. I copied "ASU_5.0" and renamed it to ASU2 under the Build folder. Testing now and it does look to be installing properly with ConfigMgr as long as it has that the ASU2 folder.

I'm not quite sure why the setup seems to be looking for a non-existent folder when running through a deployment with ConfigMgr compared to running the install manually afterwards.

Update: I realized it installs *mostly* fine with the workaround. For some reason Adobe Acrobat DC just doesn't install at all while other programs do.

[fiyahflash]

Thank you for posting this; I have been struggling for days trying to get any 2020 applications installed on a new laptop - thankfully I still had the installer for 2019 (around July) lying around, so I installed that, then installed the 2020 applications without any issues. 

Now that you have posted this, I am able to see the issue in the PDapp.log; note that I am just manually testing the installations rather than using ConfigMgr. I shall try your workaround and see if I can get it something to install.

[NParkFSTS]

I've ran into the exact same issue, but I have the issue between identical VMs running on different virtual infrastructure at two sites, and running "setup.exe --silent" manually from a local folder, so our config management tools aren't a variable. 

By some internal logic, the same install package wants ASU_5.0 on one site, and APU2 on another.  The only difference between the VMware hosts that the VM can see is the CPU - the working VMs have older CPUs, while the newer infrastructure that doesn't work are considerably newer. 

I'm also testing the approach to make a copy of the ASU_5.0 to ASU2, which has worked correctly on one test so far.

[mtisd21]

One problem I have since found with having an 'ASU2' folder is that most of the programs do install but for me Adobe Acrobat always seems to get skipped.

[fiyahflash]

I wasn't able to get any success with taking a copy of the ASU_5.0 and renaming it; then I opened a support case because installs were working if I installed via the desktop but not on a network drive. I have another thread opened for this issue as my phone/chat support was just going around in circles.

I am also surprised to find that VM installs are working for people? My abilty to take an installer from the Package Manager and then the Admin Console and install on a VM ended in 2017 (I think). Because I was installing 11 applications at once, I wanted to verify the 11GBish download had downloaded corrected and wasn't going to waste an hour of the users time. Now I have to find a "spare laptop" to test the downloads ... and with this current issue, I can't even do that.

[NParkFSTS]

Thankfully yes - We test all our packages/deployments on VMs on VMware ESXi 6/6.5/6.7 and thus far haven't had any issues on VMs that don't exist on physical machines.  That would really throw a wrench into our software deployment processes!  Something we'll watch out for though since others have had issues.

[fiyahflash]

We have since upgraded to VMware ESXi 6.5 (we were on version 5 for ages including my last test). I might setup a VM and try some local and network location testing and see what happens. That will make testing deployments way eaiser if it once again works; finding a spare laptop or desktop is a signficant challenge.