Fix SCCM Application Deployment Error 0X87D00213
Let’s see how to fix the SCCM application deployment error 0X87D00213. If your ConfigMgr application deployment is failing with error 0X87D00213, there is a sure shot solution to it.
An application deployment in SCCM can fail due to several reasons. In most cases, either the application install command is incorrect or the actual issue is on the client computer.
The error 0x87D00213 is observed when you are deploying large size applications in SCCM. This includes applications like Maya, AutoCAD, and software programs that require downloading additional files during the setup.
In some cases, the application download may be stuck at 0%, and it results in multiple errors. Read how to fix SCCM application download stuck at 0% in Software Center.
In my case, the 0X87D00213 deployment error was observed during Office 365 application deployment in a remote site. Whenever you encounter error 0X87D00213, always refer to the AppEnforce.log for more details.
A similar issue was reported in SCCM forums where the user complained about application deployment error 0X87D00213. However, the issue was with the deployment script and not the application.
Fix SCCM Application Deployment Error 0X87D00213
The SCCM application deployment error 0X87D00213 translates to “Timeout Occurred“. The error 0X87D00213 is resolved by increasing the Maximum allowed run time (minutes) for the application.
The below screenshot shows SCCM application deployment error 0X87D00213. The complete error description and the associated solution is as follows:
0x87D00213 Error Message: Additional information for error resolution: Increase the Maximum allowed run time (minutes) for the application. Ensure that the maintenance window on the client is large enough to support the runtime.
+++ Starting Install enforcement for App DT "Greenshot 1.2.10.6" ApplicationDeliveryType - Scopeld_C7867F85-B1FC-4803-BCA1-6A499AABDDA2/DeploymentType_1843df. Performing detection of app deployment type Greenshot 1.2.10.6(Scopeld_C7867F85-B1FC-4803-BCA1-6A499AABDDA2/DeploymentType_1843dffa-5ec0-4d6b-bd50-37a6. +++ Application not discovered. [AppDT Id: Scopeld_C7867F85-B1FC-4803-BCA1-6A499AABDDA2/DeploymentType_1843dffa-5ec0-4d6b-bd50-37a6f6cb2a41, Revision: 4] App enforcement environment: Context: MachineCommand line: ,,Greenshot_1.2.10.6.exe" /VERYSILENTAllow user interaction: NoUl mode: OUsertoken: nullSession Id: 4. Prepared working directory: C:\Windows\ccmcache\2o Prepared command line: "C:\Windows\ccmcache\2o\Greenshot_1.2.10.6.exe" /VERYSILENT Executing Command line: "C:\Windows\ccmcache\2o\Greenshot_1.2.10.6.exe" /VERYSILENT with system context Working directory C:\Windows\ccmcache\2o Post install behavior is BasedOnExitCode Waiting for process 11236 to finish. Timeout = 720 minutes. Exceeded timeout of 720 minutes while waiting for process 11236 to finish. WaitingforrunningProcess failed. Error 0X87D00213 CompleteEnforcement failed with 0X87D00213
Let’s understand why do you get the error 0X87D00213? Every application that you install via Software Center, requires some time to install. If the application fails to install in the given time, it results in error 0X87D00213.
When you create an application in SCCM, on the User Experience tab of application deployment type window you see two options.
- Maximum allowed run time (minutes) – Specify maximum run time for application installation.
- Estimated installation time (minutes) – The estimated installation time displays to the user when the application installs.
By default, the Maximum allowed run time (minutes) is set to 120 minutes for every application you create in SCCM. Here is the guide that explains how to change the Maximum allowed run time based on your requirement.
If an application requires more time to install than the limit you’ve specified, the application installation fails with error code 0X87D00213.
Sometimes the admins modify the Maximum allowed run time (minutes) and set a shorter installation time which results in application deployment error 0X87D00213.
In remote sites, where the bandwidth is slow, the clients may take more time to download the content even though the distribution point is in the same site or remote.
Hence, the application deployment error 0X87D00213 is commonly seen in remote sites while the same application installs fine in SCCM primary sites.
ConfigMgr provides free error lookup tools that can translate error codes to error messages. In this case, none of the tools were able to decode the 0x87D00213 error. But keep using those tools to decode other errors.
I hope this article helps to you fix the ConfigMgr application deployment error 0X87D00213. In case something else worked for you, let me know in the comments section below.
Hi there,
it happened to me too – with a software that was packaged by a company from India.
They forgot to set a switch to OVERWRITE a folder while unpacking the source from a zip-file, although they were told to do so …
So if the user runs the install on the client and then e.g. does a shutdown, the install process is interrupted and the unzipped folder is existing.
When the user starts the next time with the installation, the installation routine tries to unzip again, but since the unzipped folder is already there it can’t unzip again without the overwrite-switch … —> Timeout Loop …
For anyone coming here looking for a solution to this issue for Revit 2023…
The return value is correct but, if you look further, it *might* be because Revit 2023 is already installed. The same applies to other ODIS-driven installs.
We deploy our apps using CMDs so it was a simple job to add a line to echo the %errorlevel% returned by the installer.
I am curious what this error is triggered by, as I have just seen received it while trying to remove an app with a 30 minute maximum amount of time. Using 2207, the software installer is an MSI wrapped in a SETUP.EXE utility, configured as a silent install / uninstall. This was originally installed manually by a predecessor, so this install / uninstall Application was made by me, using MSI product code detection, and silent install/uninstall strings per the vendor. When deployed as a required UNinstall, with a maintenance window, about 70% errored with this timeout error. Investigating one of the failed uninstalls, I tested it from Software Center by clicking on the Application button and hitting the retry button (after verifying the same error). After about 5 five minutes, the uninstall failed again (silently), and I have the same error. I haven’t verified my conclusion yet, but I decided to run the uninstall from programs and features (WinServer 2012R2), and it chugged along for about 5 minutes, then threw me the dreaded “could not find source file xxxx in path name. Browse?). It is a network path, which I think likely held the original install files on a server that is long gone. So if anyone knows what actually generates this error beyond timeouts, I think it could be quite educational 🙂
Its good explanation. But need to understand why it is waiting to process ? If am not wrong the error prompt after maximum allow time i.e. 120 /60 mints till why it is stuck ? Anything need to declear in installation vbs or command line ?