Software Installation Checklist

Record vendor, product, version, business justification, requesting manager, and target user group. Pull the request from the PSA or ITSM ticket (ConnectWise Manage, ServiceNow, Freshservice) and link it to the change record.

Confirm seat count against the vendor portal, check named-user vs device-based licensing, and review redistribution terms before pushing the package fleet-wide. Microsoft, Adobe, and Autodesk audits routinely surface installs that exceeded purchased entitlement.

Standard changes (pre-approved, low-risk packages already in the catalog) skip CAB. Normal changes (new vendor, kernel-level driver, browser plugin, anything touching financial systems under SOX) require CAB review and a documented rollback plan.

Pull the MSI, MSIX, EXE, or PKG directly from the vendor's portal — never from a search result or a mirror. Verify the SHA-256 hash against the vendor's published value before importing into the deployment tool.

Check the Authenticode (Windows) or codesign (macOS) signature, confirm it chains to a trusted CA, and verify the publisher name matches the vendor. Unsigned or self-signed installers should not be deployed without a documented exception.

Wrap the installer in Intune Win32 (.intunewin), Jamf composer, NinjaOne, or your RMM of choice. Include silent-install flags, detection rules, dependencies, and uninstall command. Test detection logic — packages that re-install every 24 hours because detection failed are a classic noisy mistake.

Target the pre-defined pilot ring (typically 5–10 IT staff plus 1–2 power users from the requesting department). Avoid pushing to executives in the first ring — a broken install on the CFO's laptop turns a routine deployment into an incident.

Email the pilot group with the install window, expected reboot behavior, how to report issues, and the rollback timeline. Pilot users who don't know they're piloting file regular tickets and clog the queue.

Track install success rate, exit codes, and EDR alerts (CrowdStrike, SentinelOne, Defender for Endpoint) for the pilot endpoints. A success rate below 90% or any EDR detections means stop and investigate before broadening.

Notify all targeted users 48 hours ahead with the install window, reboot expectations, and helpdesk channel for issues. Reference the change ticket number so support staff can correlate inbound calls.

Assign the package to the production AAD or device collection. Stagger by region or department if seat count exceeds 200 — bandwidth and helpdesk capacity both get pinched by everyone-at-once rollouts.

Stay in the deployment console for the first 4 hours. If install success drops below 85% or ticket volume spikes, pause the deployment and triage before continuing. Most RMMs (NinjaOne, Datto, Intune) support pause-then-resume mid-rollout.

Pull the install report from the RMM and compare to purchased seats. Over-deployment is the #1 finding in vendor true-up audits. Note the deployed count in the asset management system (IT Glue, Hudu, Lansweeper).

Capture the install command, detection rule, uninstall command, license server / activation method, and known issues in IT Glue, Hudu, or Confluence. The next person to touch this package — likely six months from now during a version upgrade — needs the actual commands, not a description.

Post a one-page guide to the intranet or knowledge base covering launch, first-time login, SSO behavior, and where to file a ticket. For applications with material UI changes, schedule a 30-minute live walkthrough on Teams or Zoom.