cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

App Broker / SCCM Deployments

Packages that have a UNC script on the front are hanging on reinstalls.

The First request for the Catalog Item "PMI" (that did not have it before) works fine. Installs correctly and returns a Successful status with in the acceptable 3-4 minutes.


There is not an uninstall in the package thus it is removed by the control panel<Add or remove programs.


When selecting the Reinstall (or requesting the install again) is when it hangs.
The UNC VBS script kicks off the install that is located on a company wide shared drive R:
 wshShell.Run "R:\PMI\setup.exe", 1, True
I think I noticed on the first clean system install, is it changed the status to "Succeeded" when the actual package install screen comes up from the setup.exe file like it changes the status to succeeded once the UNC script has completed.

 

(1) Solution

I can't tell you specifically what's happening in this scenario, but here are some things to check.

  1. Script "wrappers" often cause confusion with the actual result of a deployment in SCCM.  The return code that SCCM gets back is from the script that is being launched rather than any other executable that may be called from the script, so you need to make sure the script returns meaningful return codes.  Then you may need to make sure SCCM is configured to understand/interpret those script return codes correctly.  For example, you may have a script that is calling setup.exe and then returning without any specific return code (usually 0/success, by default).  No matter what happens with that setup.exe (success or fail), the script is still indicating a success unless explicitly configured to return some other code based on the result of the setup.exe command.
  2. Package/program deployments in SCCM have a "rerun behavior" property that can be configured to "Always rerun", "Never rerun", "Rerun if failed previously", or "Rerun if successful previously".  Depending on how that is configured, it may be impacting the result being returned from SCCM to App Portal.  I suggest creating your own separate deployment directly in the SCCM console to see if you can get consistent/reliable results from installing/reinstalling within SCCM.  Once you have that working, compare the deployment properties to the ones set on the App Portal deployment.  If they are different, you can modify the properties of the App Portal deployment to match the working deployment, or you can remove the deployment from within the App Portal catalog item (Deployment property tab) and re-add it with the correct properties.

 

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

View solution in original post

(1) Reply

I can't tell you specifically what's happening in this scenario, but here are some things to check.

  1. Script "wrappers" often cause confusion with the actual result of a deployment in SCCM.  The return code that SCCM gets back is from the script that is being launched rather than any other executable that may be called from the script, so you need to make sure the script returns meaningful return codes.  Then you may need to make sure SCCM is configured to understand/interpret those script return codes correctly.  For example, you may have a script that is calling setup.exe and then returning without any specific return code (usually 0/success, by default).  No matter what happens with that setup.exe (success or fail), the script is still indicating a success unless explicitly configured to return some other code based on the result of the setup.exe command.
  2. Package/program deployments in SCCM have a "rerun behavior" property that can be configured to "Always rerun", "Never rerun", "Rerun if failed previously", or "Rerun if successful previously".  Depending on how that is configured, it may be impacting the result being returned from SCCM to App Portal.  I suggest creating your own separate deployment directly in the SCCM console to see if you can get consistent/reliable results from installing/reinstalling within SCCM.  Once you have that working, compare the deployment properties to the ones set on the App Portal deployment.  If they are different, you can modify the properties of the App Portal deployment to match the working deployment, or you can remove the deployment from within the App Portal catalog item (Deployment property tab) and re-add it with the correct properties.

 

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".