Technical Anshu
Tutorials Blog
🧩 Failure Classes

Software Deployment Failed on Some PCs How to Read the Failure and Fix Each Class

Mostly green, a few red — this is what real rollouts look like. The skill is not avoiding failures, it is reading the remark next to each failed PC and knowing which of the handful of causes you are looking at.

✍️ Technical Anshu🪟 Windows endpoints⏱️ 8 minute read
🎥 Watch failed targets being diagnosed from the execution status in the video

A rollout that reports 48 successful, 4 failed is not a broken deployment — it is a normal one with four stories to read. Endpoint Central writes the reason into the Remarks column of the execution status, and those remarks fall into a small set of classes. Fix the class, retry only the failed targets, and never re-deploy the whole office because four laptops were switched off.

console — execution status, remarks column
WS-014The system cannot find the file specified
WS-027Access is Denied
LAP-009The Wait Option has been timed out
WS-033Fatal Error during installation
44 othersExecuted successfully
Four failed PCs, four different causes. The remark is the diagnosis — read it before touching anything.
1

Class One — the File Is Not There

Remarks like The system cannot find the file specified or The Network path not found mean the PC never got the installer. Usual causes:

  1. You referenced the installer from a network path and that share was down, renamed, or the PC could not reach it — prefer uploading the file into the package (HTTP upload) so the server hosts it
  2. The share exists but the agent cannot read it; network-path packages need read permission for Authenticated Users on the share
  3. The package file was moved or replaced on the server after the configuration was created — re-check the package itself
2

Class Two — Access Is Denied

The file arrived but Windows refused to run or write it. Work through the short list:

  1. The installer needs admin rights and the configuration was set to run as the logged-in user instead of the system account
  2. Antivirus or endpoint protection blocked the installer mid-run — check the AV console for the exact timestamp before blaming the package
  3. A previous broken install of the same software left locked files or registry keys; repair or remove the old install on that PC first
  4. The target folder or a file inside it is in use — the application was open during deployment; redeploy after hours or with the app closed
3

Class Three — Timed Out or Still in Progress

The Wait Option has been timed out and endless In Progress states are usually not errors at all:

  1. The PC was switched off or asleep mid-deployment — it finishes when it returns, especially with retry enabled
  2. The installer is waiting for input because the silent switch is wrong — this is the hang from the silent-switch guide; fix the command, do not extend the timeout
  3. A large package over a slow link is simply still downloading; Endpoint Central resumes interrupted downloads instead of restarting them
  4. One stuck PC can be nudged by running "C:\Program Files\UEMS_Agent\bin\cfgupdate" computer on it to apply configurations immediately
4

Class Four — the Installer Ran and Failed with a Code

Fatal Error during installation or Failed with unknown error code means the installer itself gave up. For MSI packages the classic codes tell the story:

  1. 1603 — generic fatal error; reinstall locally with logging msiexec /i "app.msi" /qn /l*v "C:\app.log" and read the log's first real error
  2. 1619 — the installation package could not be opened; the file is corrupt or unreachable, re-upload it
  3. 1605 — you tried to uninstall a product that is not installed; your uninstall target list is wrong
  4. 3010 or 1641 — actually a success that needs a reboot; do not chase these as failures, let the reboot policy handle them
  5. The same code on many PCs means the package is wrong; the same code on one PC means that PC is different — compare it with a working one
5

Retry Only the Failures, Then Close the Loop

Endpoint Central lets you retry the configuration on failed targets — use that, not a fresh office-wide deployment. Fix the cause per class, retry the handful of machines, and confirm each one flips to success. Whatever remains after one honest retry round gets a desk visit or a remote session; three stubborn PCs should never hold the other forty-seven hostage, and they should never be silently forgotten either — they go on tomorrow's list with their remark attached.

🔴 Golden rule of failed targets: same remark on many PCs = one shared cause, fix the package or the server. Different remarks = different small causes, fix the PCs. Re-deploying everything without reading a single remark fixes neither.

🎥 Watch the Full Deployment in the Video

Watch the execution status and remarks being worked through in the full video.

▶️ Watch Full Video
❓ Frequently Asked Questions

Why did the same deployment succeed on one PC and fail on another?

Because the PCs differ — an older version already installed, an antivirus block, a full disk, a user who had the app open. Group the failures by remark and treat each group separately; there is rarely one single cause.

Should I increase retries to fix timeouts?

Retries help when PCs were off or busy, and Endpoint Central's retry-on-failed-targets setting is worth enabling. But if the remark shows a wrong silent switch or access denied, more retries just repeat the same failure. Read first, retry second.

A PC shows Ready to Execute for two days. Is it stuck?

Usually it simply has not checked in — switched off, on leave, or the agent service is stopped. When the PC comes online the configuration applies. If the PC is on and the agent is healthy, run the cfgupdate command on it to apply computer configurations immediately.

This guide is based on the Technical Anshu video on remote software deployment with ManageEngine Endpoint Central • Stuck on a step? Ask in the video comments and you will get a reply 🙏