A Deployment That Reports 28 of 40

The pattern points at permissions, not version compatibility. The split is perfect: every failure is a standard-user machine, every success is an administrator machine, and failures are spread evenly across both OS builds. If the OS build were the cause, failures would cluster by build; they do not. The fact that the split aligns exactly with a permission boundary is the strongest signal in the data.

The vendor's "no admin rights required" claim is contradicted by the installer's behaviour. Writing to C:\Program Files and registering a service both require elevation on a standard Windows configuration regardless of what the documentation says. The documentation is a claim; the ACLs are the fact.

Confirm on one failing machine, not twelve:

1. Open the deployment log for that endpoint and read the actual failure line - look for access denied or a service-creation error, and note the exit code.
2. Attempt the install interactively as the user and capture the same error.
3. Attempt it once with elevation and see whether it completes.

One machine, three data points, and you know whether the fix is packaging or permissions before spending any of your Thursday on the other eleven.

Option 1 - grant the 12 users local admin. Fastest to execute, and it will work. It also permanently widens the attack surface on the machines belonging to the two departments that handle the most sensitive data, and it removes the exact control that is currently containing risk. It is the right answer only if the alternative is missing a legal or financial deadline with real consequences, and even then it should be time-boxed and reversed.

Option 2 - deploy with elevated context. Repackage the installer to run as SYSTEM through the same management console, or stage it as a required deployment that runs with system rights. This is the technically correct fix and is what the vendor should have documented. Risk: it takes configuration and testing time, and a service installed as SYSTEM needs its own security review. Recommend this one, with the single-machine confirmation from the previous step as the gate before rolling to eleven.

Option 3 - manual install by a technician on each of the 12. Works today with no policy change, does not scale, and leaves no repeatable path for the next update. Useful as a stopgap for the three or four most critical users while Option 2 is built.

Recommendation: Option 2, with Option 3 covering the finance users who must track time on Monday. That protects the deadline without granting standing admin to the highest-risk group.

Tell the CFO the truth in operational terms: the tool is live for 28 of 40 people now; the remaining 12 are blocked by a permissions requirement the product's own documentation says does not exist; you have a fix and a fallback; and you will confirm by Friday afternoon whether Monday is achievable for all 40. Give a decision point and a time, not a promise.

Do not lead with the vendor's error. Lead with impact, plan, and confidence level - the CFO needs to know whether the billing cycle will run, and a story about documentation is noise to them.

The vendor issue is handled in parallel and in writing: open a support case citing the exact error, the installer's write path (C:\Program Files), the service registration, and the statement in their documentation. Ask for the supported elevated-deployment method in writing. An email trail matters because if the deployment later breaks in a patch, "the vendor said no admin rights were needed" is a conversation you win with documentation and lose without it.

Finally, add the finding to your internal notes: anything that writes to Program Files or registers a service should be treated as privileged regardless of what a vendor states, and future packaging should assume elevation until proven otherwise on a standard-user test machine.