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.

Attach the rollback plan, pilot user list, communication plan, and maintenance window. Note any conflicting changes already on the calendar — overlapping changes during the same window is a common reason for stacked outages.

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.

Deploy to a clean Windows 11 or macOS Sonoma VM that mirrors the production gold image. Confirm install, launch, license activation, uninstall, and re-install cycles. Capture screenshots of any prompts that require user interaction — those need silent-install flags or a wrapper script.

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.

Document each failure with hostname, exit code, and log excerpt. Common fixes: missing VC++ redistributable, .NET version mismatch, blocked by AppLocker / WDAC policy, detection script returning false negative. Rebuild the package and re-pilot before promoting.

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.

Push the uninstall command to affected endpoints, restore the previous version from the package repository, and confirm endpoints return to a known-good state. File an incident ticket linked to the change record and schedule a blameless post-mortem.

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.

Mark the change as Implemented in the PSA / ITSM tool, attach the install report and runbook URL, and email the requesting manager with the rollout summary and seat count. Schedule a 30-day check-in with the package owner to review tickets and adoption.