Every rollout has them: forty PCs install cleanly and six refuse. The console is not being difficult — each failure has a specific cause, and the causes repeat. This ladder checks them in the order they actually occur.
An agent installation failure is information, not bad luck. ManageEngine's console reports the installation status per computer, and the same handful of causes account for almost every red row: the PC was off or unreachable, the credentials the console used were not really administrators on that machine, a firewall blocked the push, an old or broken agent is already sitting there, or the package belongs to a different office. Work this ladder one rung at a time on one failed PC; once you know which rung it was, the other five failures are usually the same rung repeated.
The most common 'failure' is not a failure at all: the target was switched off, asleep, or a laptop sitting at someone's home while you pushed from the console. A push install can only reach a machine that is on and connected. Check the obvious before touching anything technical — is the PC powered on, on the office network or VPN, and answering on the network at all? Leave those machines in a 'pending' list and catch them when they return; a rollout that reaches 95 percent today and the last few laptops this week is a finished rollout, not a broken one.
'Access denied' almost always means the account the console used to push the install is not a local administrator on that specific PC. Domain admin accounts usually pass; a helpdesk account that was never added to the local Administrators group does not. The honest test: log on to the failed PC with those exact credentials and try installing any small program — if Windows refuses or demands elevation you do not have, you have found your rung. Fix the credential (use an account that is genuinely admin on the targets, or add the deployment account to the local Administrators group through policy), then retry the push.
A push installation needs the server to reach management services on the target PC. An office firewall between VLANs, the PC's own Windows Firewall profile, or a third-party security suite can quietly block that path while normal browsing works fine — which is why the user insists 'the PC is on the network'. Test from the server side: can the server reach the PC's administrative functions at all? Endpoint Central needs specific ports between agent, server and any distribution server; rather than guessing numbers, check the port list in ManageEngine's documentation for your deployment and open exactly those between the server VLAN and the client VLAN. Do not 'fix' this by turning the PC's firewall off permanently.
A PC that carried an agent from an older server, a trial install, or a half-removed previous attempt can refuse a fresh install — the installer finds existing agent components and stops. The console reason may say the agent already exists, or the install may 'succeed' while the PC still reports to the old server. The clean fix is a clean removal first: uninstall the old agent properly (the companion uninstall guide covers the protected way, including the OTP), and for genuinely stuck machines ManageEngine provides an Agent Cleanup Tool that removes leftover agent components so a fresh package can install. Then install the current office's package and watch it check in to the right server.
Two quiet package mistakes cause stubborn failures. The first is geography: the package was downloaded for the wrong remote office, so the agent installs but phones the wrong server address — from your console's point of view the PC simply never arrives. The second is age: an agent package downloaded months ago for a pilot, reused from a shared folder. Download a fresh package for the correct office from Agent → Computers → Download Agent, install that, and confirm the PC appears under the right office in Scope of Management. If the PC previously reported to another server, remove it from that server's scope as well so it is not managed in two places.
Windows itself can be the blocker: a PC with a restart pending from earlier updates may refuse new service installations, and an interrupted first attempt can leave the installer in a half state. A plain restart of the target PC clears the first and often the second. After the restart, run the correct package manually on that one PC as an administrator and read the result directly instead of pushing blind. Manual installation on the failed handful is not defeat — every large rollout ends with a short manual list, and finishing those machines by hand is faster than a week of remote retries.
See the clean console download and client install once, so every failure on your list has a known-good process to compare against.
▶️ Watch Full VideoYes. A small failure tail is normal in every rollout — machines that were off, laptops away from the office, one PC with a leftover old agent. Work the ladder per machine; most offices finish the tail within a few days as laptops return.
Retrying fixes only the first rung — a PC that was off and is now on. Access denied, firewall blocks, old agents and wrong packages fail identically on every retry until their specific cause is fixed.
The agent probably belongs to a different office package or an older server, so it is reporting somewhere else. Remove that agent, install a fresh package downloaded for the correct remote office, and confirm the PC checks in to your server.