Troubleshooting

The SSM Agent is not running, the EC2 instance profile is missing the required policy, or the instance hasn't checked in yet.

1. In the AWS Console, go to Systems Manager → Fleet Manager.
2. If the instance is missing entirely, RDP into it and run: Restart-Service AmazonSSMAgent
3. If the instance appears but shows Ping Status: Connection Lost, verify the EC2 instance profile has the AmazonSSMManagedInstanceCore managed policy attached.
4. Wait 60 seconds after any change and refresh Fleet Manager.

PatchPilot sent an SSM Run Command but the command did not reach the instance. This is almost always an SSM Agent or instance profile issue.

1. Confirm the instance shows Online in Fleet Manager (not Connection Lost or Missing).
2. Confirm the EC2 instance profile includes AmazonSSMManagedInstanceCore.
3. Re-run discovery after correcting the SSM issue.

The SSM Agent service has stopped, or the instance lacks outbound internet access to the SSM endpoint.

1. RDP into the instance and restart the agent: Restart-Service AmazonSSMAgent
2. If the instance is in a private subnet with no internet gateway, configure a VPC Endpoint for SSM (com.amazonaws.region.ssm, com.amazonaws.region.ec2messages, com.amazonaws.region.ssmmessages).

The SSM command reached the EC2 node but found no SQL Server installations. This usually means SQL Server is installed under a non-standard path, or the SQL Server Browser service is stopped.

1. Confirm SQL Server is installed on that EC2 instance (check Programs and Features or the registry at HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server).
2. Ensure the SQL Server service (MSSQLSERVER for default instances, or MSSQL$INSTANCENAME for named instances) is in Running state.
3. Wait 1–2 minutes and refresh the Instances tab — discovery results are written asynchronously.
4. Re-run discovery. If the issue persists, contact support@zerodba.com with your Instance ID.

Discovery ran but could not read the current build version from the registry. This can happen if the SQL Server instance is starting up, recovering, or if registry permissions are restricted.

1. Verify the SQL Server service is Running (not Starting or Stopping).
2. Re-run discovery on that specific instance using the refresh button on the Instances row.
3. If UNKNOWN persists after two attempts, contact support with your EC2 Instance ID.

Discovery data is more than 48 hours old. PatchPilot marks instances Stale to flag that the compliance picture may be out of date.

1. Click Discover / Add Node and re-enter the EC2 Instance ID to run a fresh discovery.
2. Alternatively click the refresh icon on the instance row.

The CU installer package requires approximately 3 GB of free space on the system drive (C:\) for download, extraction, and installation. The pre-flight check found less than this threshold.

1. RDP into the EC2 instance.
2. Open Disk Cleanup on the C:\ drive and clear temporary files, Windows Update cache, and the Recycle Bin.
3. Alternatively, delete old SQL Server backup files or log files from non-system drives if space allows.
4. Free at least 4 GB to provide a comfortable margin.
5. Re-run the patch job from the Jobs tab once space is cleared.

PatchPilot requires the SQL Server service to be in a Running state before patching. If the service is Stopped, Starting, or in an error state, the pre-flight check fails to prevent patching an already-unhealthy instance.

1. RDP into the EC2 instance.
2. Open Services (services.msc) and locate SQL Server (MSSQLSERVER) or your named instance.
3. Start the service and wait for it to reach Running state.
4. Check the SQL Server error log (default: C:\Program Files\Microsoft SQL Server\MSSQLXX.MSSQLSERVER\MSSQL\Log\ERRORLOG) for startup errors if the service won't start.
5. Re-run the patch job once the service is confirmed Running.

Windows has flagged that a reboot is required before new software can be safely installed. This is detected via registry keys left by previous Windows Updates or software installs. Installing a SQL Server CU on a machine with a pending reboot can result in a failed or incomplete installation.

1. Schedule a maintenance window to reboot the EC2 instance.
2. After the instance comes back online and SSM shows it Online in Fleet Manager, re-run discovery to confirm connectivity.
3. Re-run the patch job.
4. Alternatively, if your job plan was generated with Allow pre-patch reboot enabled, PatchPilot will handle the reboot automatically before proceeding.

PatchPilot downloads the CU package directly from Microsoft's download servers at the time of patching. This error means the EC2 instance could not reach the Microsoft CDN. This is usually a network or security group issue.

1. Confirm the EC2 instance has outbound internet access on port 443.
2. If the instance is in a private subnet, verify a NAT Gateway or VPC endpoint is configured that allows outbound HTTPS.
3. Confirm no Security Group or Network ACL is blocking outbound connections to *.microsoft.com or *.download.windowsupdate.com.
4. Test from the instance: Test-NetConnection -ComputerName download.microsoft.com -Port 443
5. Re-run the patch job once connectivity is confirmed.

The SQL Server CU installer ran but reported a failure. Common causes: another process is using SQL Server files, the installer was interrupted, or Windows Installer is in a locked state.

1. Open the job audit trail and note the exit code in the failure event.
2. RDP into the instance and check the SQL Server Setup Bootstrap log at C:\Program Files\Microsoft SQL Server\[version]\Setup Bootstrap\Log\.
3. If the error is 'Another installation is in progress,' wait 10 minutes and re-run the job.
4. If the SQL Server service is stopped after a failed install, start it manually and verify the instance is healthy before re-running.
5. Contact support@zerodba.com if the installer log shows an error you cannot resolve — include the exit code and the last 20 lines of the bootstrap log.

The patch job started executing but did not report back within the expected window. This can happen if the instance rebooted unexpectedly, lost SSM connectivity mid-job, or if the installer is taking longer than usual.

1. Check the instance in Fleet Manager — if it shows Connection Lost, the instance may have rebooted. Wait for it to come back online.
2. Check the SQL Server service state once the instance is online. If SQL Server is running and on the new build, the patch succeeded even though the job timed out. Re-run discovery to refresh compliance state.
3. If the instance is online and SQL Server is still on the old build, re-run the job.
4. If the instance is unreachable, investigate the EC2 console for system logs or scheduled maintenance events.

The SSM command is running but has not completed. Large CU packages (some are 1+ GB) can take 20–40 minutes to download, extract, and install, depending on instance type and network speed.

1. Wait at least 45 minutes before treating a job as stuck. Patching a SQL Server CU takes longer than most software installs.
2. If the job has been Executing for more than 90 minutes, check Fleet Manager to confirm the instance is still Online.
3. Use the Force Fail button in the Jobs tab to manually fail a confirmed-stuck job, then re-run it.

The job completed successfully but the compliance state hasn't refreshed yet, or the post-patch discovery didn't run.

1. Wait 5 minutes after job completion — compliance state updates asynchronously.
2. Click Refresh in the dashboard to force a data reload.
3. If the instance still shows BEHIND, re-run discovery on that node. The post-patch discovery occasionally misses if the instance rebooted slowly.

In rare cases a CU install can leave SQL Server in a state where it won't restart. This is typically caused by a corrupted temp directory, a missing Visual C++ redistributable, or a licensing change in the CU.

1. Check the SQL Server error log immediately: C:\Program Files\Microsoft SQL Server\MSSQLXX.MSSQLSERVER\MSSQL\Log\ERRORLOG
2. The error log will show the specific startup failure. Common fixes: repair the Visual C++ redistributable, clear the SQL Server temp directory, or run a SQL Server repair from Add/Remove Programs.
3. Email urgent@zerodba.com immediately — this is a production-impacting issue (P1) and will receive a response within 2 hours.

The patch applied successfully but the job's post-patch validation step timed out or couldn't connect to read the new build number. The instance is actually patched.

1. Re-run discovery on the instance. If it now shows COMPLIANT, the patch succeeded.
2. Use Force Fail to clean up the stuck job record if it hasn't already auto-expired.