WaitForRunningProcess failed - Error 0x87d00213

Question

_{Wednesday, June 5, 2019 2:56 PM}

One of our administrators recently left the organization and I've taken over one of his old tickets to deploy ArcGIS Pro.  He had create a deployment for the software, but that deployment is failing.

I am pretty green when it comes to troubleshooting deployments, so I'm going to need a little help with this.  I found the following in the AppEnforce log:

Exceeded timeout of 119 minutes while waiting for process 2548 to finish.        AppEnforce        5/29/2019 10:52:24 AM        11996 (0x2EDC)

WaitForRunningProcess failed.  Error 0x87d00213.        AppEnforce        5/29/2019 10:52:24 AM        11996 (0x2EDC)

CScriptHandler::CompleteEnforcement failed with 0x87d00213        AppEnforce        5/29/2019 10:52:24 AM        11996 (0x2EDC)

CAppProvider::CompleteEnforcement failed with error 0x87d00213        AppEnforce        5/29/2019 10:52:24 AM        11996 (0x2EDC)

++++++ Failed to enforce app. Error 0x87d00213. ++++++        AppEnforce        5/29/2019 10:52:24 AM        11996 (0x2EDC)

I was unable to find any other references to process 2548, so I have no idea what that is.  I searched on the error code and found a post on Reddit suggesting that this error is often caused by a dialog box being displayed that expects input, but the user is unable to see the dialog box.  Based on that, I decided to launch the installation from the command line without the /q switch so that I could see what is happening, and it does prompt for a destination folder.

So I guess that I have two questions.  First, am I on the right track?  Second, assuming that I am on the right track, is there a way to modify the deployment so that it automatically accepts the default value for the destination folder, or can I somehow specify the destination folder for the deployment to use?

Thanks in advance for any help that you can offer!

--Tom

All replies (4)

_{Wednesday, June 5, 2019 3:43 PM ✅Answered}

0x87d00213 = "Timeout occurred"

This is typical for a command-line that launches a process that displays UI however in ConfigMgr (unless you have the option selected to allow users to interact with UI displayed by the process launch by the command-line) the UI is displayed on the session 0 desktop which is hidden and not accessible by the interactive user and so can't be responded to. Thus, the process launched just sits waiting for input that no one can give to it and eventually ConfigMgr just gives up on it.

I would think/hope that the /q suppresses that completely but that's specific to the command-line that you are running and not ConfigMgr. You may need to add logging to the command-line itself to track what it is doing as this is also not subject to the control or visibility of ConfigMgr. Also, deployments don't use destination folders and (same statement) that's purely up to the command-line that you (or is) specified and thus outside the explicit scope of control of ConfigMgr.

Note that the process number (2548 in this case) is simply a unique id given to each process by the local OS and not indicative of anything specific.

Jason | https://home.configmgrftw.com | @jasonsandys

_{Wednesday, June 5, 2019 7:37 PM}

Okay, that's pretty much what I found in my research, albeit explained a little more fully.  I did try the option to allow users to interact with the UI, but that did not change the behavior, although I did still have the /q switch applied, so maybe I should try that option without the /q switch.  Ultimately, I don't want uses interacting with the UI, but as a test, it might shed light on what is going on.

Not sure how to add logging to the command line, but I will see if I can look that up.

Thanks for the help!

--Tom

_{Thursday, June 6, 2019 1:44 PM}

I think that I am on the right track.  I realized that when my former co-worker created the deployment, he had it running a self-extracting .EXE, so it was prompting for a destination folder for the extracted files.  I extracted the files, and there is an MSI file that runs the actual installation.  Now, I just need to modify the deployment to run that file.

--Tom

_{Thursday, June 6, 2019 2:41 PM}

After extracting the files and modifying the deployment to use the MSI file, it is now working.  The uninstall is working as well.  Thanks for the help!

--Tom