Check if Linux Reboot is Required

Check if Linux Reboot is Required and Reboot if Needed

Check if Linux Reboot is Required

Check if Linux Reboot is Required and Reboot if Needed

The script didn't get the maintenance window end time from the Manager. 

Retry.

No subscription found for this endpoint. Check RHEL subscription and run:

yum repolist

yum updateinfo list

Timeout reached from the Connector side. 

The script ran longer than the expected time.

{ "Packages": [] }

{ "Advisories": [] }

The output has empty data.

1. Verify Endpoint Readiness

Ensure the endpoint is correctly configured and verify 100% success.

2. Check if advisories/packages are being retrieved properly

Commands:

SUSE: zypper lp

RHEL/OL/Amazon: yum updateinfo list

For SUSE, refer to this cheat sheet.

For RHEL/OL/Amazon, advisory data should look like:

RHSA-2014:1031 Important/Sec. 389-ds-base-1.3.1.6-26.el7_0.x86_64

RHBA-2015:0626 bugfix 389-ds-base-1.3.3.1-15.el7_1.x86_64

If advisory data is not visible, verify the repository XML file. If correct, run: yum clean all.

3. Further Actions

If advisories and packages are pulling properly:

Run to reset the local update file:

rm -rf /var/cache/JetPatch/scan_result.txt && /usr/local/scan_updates.sh true null null

This clears the local updates file and generates a new one in the next scan.

If advisories are not being pulled:

Ensure the local repository is configured to pull advisories.

Most often points to bad WSUS behavior. 

Follow the steps in

Recommended Maintenance Operations on WSUS

For example: a PowerShell exception or another script exception.

Windows: Verify that the PowerShell policy is enabled properly.

The output has empty data.

Linux: Likely endpoint issue - troubleshoot the endpoint.

Windows: See article

1. Check that basic package manager commands work on the machine (yum, apt-get, etc).

2. The JetPatch server may be unable to access the advisory mailing list (relevant for CentOS):

  CentOS 6/7: https://lists.centos.org/pipermail/centos-announce/

  CentOS 8: https://cefs.steve-meier.de/

  SUSE 11: https://lists.suse.com/pipermail/sle-updates/

If a proxy needs to be configured, see this article.

To test for CentOS, login to the JetPatch server and run:

curl -kv https://lists.centos.org/pipermail/centos-announce/

No patches on the NIM repository are relevant for this device.

Next Steps: Download patches to the NIM server and wait for the next collection, or run it manually.

Read more on working with the NIM repository here.

The execution didn't change any patch status on the endpoint.

Note: To manage Microsoft Defender updates with JetPatch, configure it accordingly, otherwise exit code 342 will occur: WSUS | WSUS-Less

System Level Checks — WSUS Reasons:

1. Replica WSUS Sync: Immediately trying to patch endpoints connected to a replica WSUS. Sync can take up to 90 minutes. See article.

2. Manual Install Impact with WSUS: When a user manually installs patches via Windows Update, JetPatch only detects the change once the endpoint checks in with WSUS - which may take up to 24 hours.

3. WSUS Sync Approval: JetPatch expects to deploy additional updates but WSUS Sync Approval fails. 

If not approved on WSUS, try approving it manually or duplicating the RP plan and reactivating it.

4. WSUS Cleanup: If WSUS contains outdated or superseded patches, clean up WSUS and run a full WSUS sync.

Machine Level Checks:

1. Run Windows Update manually on one affected machine.

2. Analyze the Windows Update log on the same affected machine.

The connector was unable to create the process. 

This may be due to machine resource issues.