Different behaviour Required vs. Available application deployments

Question

I packaged and deployed thousands of applications via Config Manager and other tools. There should be no technical difference between a required an available application deployments. But there is.

I’ve seen 2 applications which are not installing with a required deployment. Both applications are using the silent install switches provided by the manufacturer. Those 2 applications are Maple and Vectorworks. 2 total different applications with one thing in common, they both use the “bitrock installer”.

So what are the symptoms?

Both application install just fine if we have an available application deployment. We can click the package in Software Center and both applications install fine, without errors.

As soon as we deploy those applications required (without any change to the deployment type), the application installation will start, but will hang during the extracting phase of the installer. The timeout set in de deployment options kicks in, this is clear in AppEnforce.log.

It doesn’t matter how we call the installer + switches (CMD, Poweshell or the EXE directly)

So what about the vendor installer logfile?
Well.... it just hangs on the unpacking process:

Maple 2020.2:

Unpacking C:\Program Files\Maple 2020\Python.X86_64_WINDOWS\Lib\site-packages\tensorflow_core\include\third_party\eigen3\Eigen\Eigenvalues
Unpacking C:\Program Files\Mapl

Vectorworks:
https://forum.vectorworks.net/index.php?/topic/60353-vectorworks-2019-silent-install-using-sccm-as-application-deployment/

Also Vectorworks just hangs while unpacking from the SCCM source. I don’t have the logfile.

The 2 different vendors of both installations can’t solve my problem.
There is nothing I can do at the SCCM or Client side to solve this.
We have to deploy required because we are in an educational environment.

Answer 1

Update. Had limited success with "Allow users to view and interact with the program installation". In some cases required "user logon". Instead ticking this worked better, "Run installation and uninstall program as 32-bit process on 64-bit clients" on the Programs tab of the deployment type. Read somewhere that JVM which is part of this particular package I'm deploying has some memory issue during deployment, and it does not when this option is ticked.

Answer 2

I can confirm that I have had the same issue with maple 2021 failing on over 1500 clients installing via required install on SCCM.
Tried multiple fix's but Adding the tick to "Run installation and uninstall program as 32-bit process on 64-bit clients" works and resolves this issue.
Thank you

Answer 3

Hi,

Thanks for posting in Microsoft MECM Q&A forum.

1,In your application, are you setting "install as device or user"? This will affect how the application is deployed. Required installs will install as system while available installs will install as user. If your install string needs access to a share but system doesn't have access to that share it will fail. If it's a user based MSI installer it will fail. If the application runs at the end of the installation and requires an account, the app will be run a system and fail to authenticate which can cause the install to time out and report it failed to install.

2,It's recommended to review the logs for further troubleshooting, please refer to:
Troubleshoot the Install Application task sequence step in Configuration Manager

Thanks for your time.

Best regards,
Simon

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
https://learn.microsoft.com/en-us/answers/articles/67444/email-notifications.html

Answer 4

Hey @JMB Did you ever solve this? I'm having the same issue with a different application.

Cheers

Answer 5

Managed to fix this by ticking "Allow users to view and interact with the program installation" on the User Experience tab. Seems odd as its a hidden and required deployment, but worked for me nonetheless.