Articles in this section

Endpoint Readiness Settings

Settings can be accessed via the button in the upper right corner of the Endpoints -> Readiness page.

Enable Endpoints Readiness

The Endpoint Readiness feature can be disabled/enabled.

If the Readiness is disabled, all exemptions will not appear and JetPatch won't inform the user about endpoint issues related to patching readiness.

Required Repository Configuration

 

JetPatch needs to know which repositories the environment is configurable for in order to make sure it is all set up as expected to ensure high security.

A new configurable repository must have:

  1. Name
  2. Endpoint specifications - 
    1. Operating System - the OS that can work with the configured repository.
    2. CIDR list - Specify the endpoint needed to be configured to the configured repository using CIDR entry
  3. Repository specifications - List of enabled repository IDs. To fetch the repository ID from an endpoint:
    1. For Windows OS- The IP/Hostname of the WSUS appears in the endpoint configuration as specified in "Specify intranet Microsoft update service location". More information on EP configuration can be found in WSUS Configuration ("Endpoint server configuration" section)
    2. For Linux OS - 
      1. YUM based systems -"yum repolist -v"  or "yum repolist all -v " (to see disabled repositories also). The value for the settings should be the same as the "Repo-id".
      2. ZYPPER based systems - "zypper repost". The value for the settings is under the "Alias" column.
      3. Note: You can also run the built-in endpoint readiness task to gather this information for Linux OS
Configured Repositories Exemption Handling - if the "Exempt endpoint not matching any OS and CIDR combination from the list above" flag is marked JetPatch will exempt all endpoints without any matching OS and CIDR entry in the Required Repository Configuration (EPs with "Unknown" status on the "Repository Configured" criterion)
 

For "Required Repository Configuration" examples check the Required Repository Configuration Examples.

 

Add Repositories - Manual

  1. By selecting an option for manual addition, the system will behave as it is now without any changes

  2. The Add button will be disabled until an operating system is selected and all Repository fields are filled

  3. When User Press ‘Add’ - The Repositories will be added to the List with Relevant Details (Same Behavior)

Add Repositories - Autocomplete

  • By selecting an option for Autocomplete Addition :
    • A New Search Field will be displayed
    • Watermark - Enter endpoint name / IP
  • The search will bring all matches Applicable Endpoints (Search - ‘Include’) & display them on a Table with the relevant information:
    • Name
    • IP
    • Operating System
    • Repositories

  • When the User Select Lines' The Repositories will be Auto-added to the Repositories list with

    • ALL Relevant Details (Same Behavior)

 

Endpoint Repositories - Search Behaviors :

  • Able to search by name - Search type is ‘Include’

  • The table will be updated according to typed characters - Minimum 2 Characters

  • No Matches - Information Message will be displayed “No Endpoints found'

  • Delete Search Value - The endpoint repositories table will not be displayed

 

Linux Subscription

If "Check Linux subscription as readiness criterion" is enabled - JetPatch will consider endpoint subscription as a readiness criterion.
Otherwise, JetPatch will not check for endpoint subscription (to support local repositories environments).
 
Note - In any case, there is an exception list to provide endpoints that should be treated differently.
 
Example #1
Check Linux subscription as readiness criterion = On
Endpoint Execpltion list = EP1
Result - JetPatch won't check subscription readiness for EP1
 
Example #2
Check Linux subscription as readiness criterion = Off
Endpoint Execpltion list = EP2
Result - JetPatch will check subscription readiness for EP2
 

Readiness Checks Interval and Timeout

mceclip0.png
Defining readiness checks intervals and timeouts:
  • Not-ready endpoints will check readiness criteria every (minute) - What is the frequency of readiness checks in not-ready endpoints
  • Ready endpoints will check readiness criteria every (minute) - What is the frequency of readiness checks ready endpoints
  • Timeout for readiness check operation is - Timeout for the readiness check operation. 

Endpoint Communication with WSUS

mceclip0.png

Defining the "WUA communication" readiness limit (default 1440)
  • The last status reported for Windows Update Agent to WSUS should be less than (minutes) - If a Windows endpoint didn't communicate in the configured time, JetPatch will raise an exemption.

Note - The configured value for Endpoint Communication with WSUS should be higher than the Discovery Source WSUS scripts run frequency:

  • discovery-source.WSUS.success.sleep-time.min (default 20)
  • discovery-source.WSUS.error.sleep-time.min (default 20)

Required Repository Configuration Examples

Windows - Single WSUS

Environment details: A single (Main) WSUS in the environment

Required Repository Configuration Settings: A single entry that will apply to all environments, without CIDR limitation.

This can be achieved by filling the CIDR as 0.0.0.0/0. With this configuration, JetPatch will match any endpoint in the environment with the configured Repository in the entry

Windows - Multi-WSUS (Main-Replica architecture)

Environment details: A Main-Replica WSUS architecture in the environment. Usually, the Replica is configured for a remote site that has a special CIDR range.

Required Repository Configuration Settings:

  • One entry pointing to the main WSUS without CIDR limitation - 0.0.0.0/0
  • Another entry configured for the endpoint that communicates with the Replica with the required CIDR list

Notes:

  • If an endpoint should communicate with the Replica WSUS but is configured for the Main WSUS - JetPatch won't detect it, it will be in a "ready" state.
  • If an endpoint should communicate with the Main WSUS but is configured for the Replica WSUS (and it's not in the IP range of the CIDR) - JetPatch will detect it and will have the "unready" status.

Linux - Multi-OS & Several Environments

Environment details: Several Linux flavors in different sites.

For example - RHEL 8 & 7 in two sites (A & B):

  • RHEL 8 in site A - should communicate with repositories A and B
  • RHEL 7 in site A - should communicate with repository C
  • RHEL 8 in site B - should communicate with repository D
  • RHEL 7 in site B - should communicate with repository E

Required Repository Configuration Settings: Entry should exist to each Linux flavor in each site:

  • OS - RHEL8, CIDR - site A, repositories A and B
  • OS - RHEL7, CIDR - site A, repository C
  • OS - RHEL8, CIDR - site B, repository D
  • OS - RHEL7, CIDR - site B, repository E

Notes - 

  • If you add repoids with optional or extra, it will fail the Advisory ready check, because no advisories exist in either optional or extra repos (RHEL example). This is a known issue and will be fixed in a future version. For now, just remove those repos from endpoint readiness.
  • If you don't have the exact CIDR block for any site you can put 0.0.0.0/0 but JetPatch will not detect situations when endpoints are communicating like they are located in a different site. For example - JetPatch will have a ready state for an RHEL8 EP from site B that is configured to work with repositories A and B (although it should communicate to repository D)
  • JetPatch assumes that the repositories (A, B, C, D, and E) should be enabled. JetPatch ignores disabled repositories.

Related Articles

 

Related articles

Comments

0 comments

Please sign in to leave a comment.