> For the complete documentation index, see [llms.txt](https://docs.adaptiva.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adaptiva.com/patch/patching-fundamentals/patch-lifecycle.md). # Patch lifecycle Describes the patch lifecycle on a device This topic describes how a device communicates with the OneSite Patch server in order to determine how and when to apply patches. ## Initial device status reporting When a device first installs the Adaptiva Client, it reports basic system details to the OneSite server, such as the installed OS, the device name, IP address, etc. The OneSite Patch server subscribes to patch metadata feeds from the Adaptiva CDN and downloads patch metadata specific to each OS (sometimes referred to as a discovery feed). The server then sends this OS specific metadata to the device. This metadata contains rules on how to detect installed and applicable versions of the software products installed on a device. The client then runs a scan based on this metadata to build a list of the software installed on the device and the version of that software, and sends that list to the server through the peer-to-peer network. This list also contains the [patch status](#patch-status) of each available patch for the products installed on the device. This enables the server to maintain a complete inventory of the software and software versions installed on every device. ## Autonomous patch cycle The OneSite Patch server uses a sophisticated object model that contains the logic required to autonomously set the [desired state](#desired-state) for each device. This logic determines if and when patches should be deployed to devices, and also includes processes like generating approval requests, sending notifications, and staged roll outs of patches across groups of devices. When a device scan reports a new patch as applicable, the server routes that patch to all **Strategies** that manage the software that patch applies to. Each Strategy contains logic that takes in the patch, checks if it passes a filter, and generates the new desired state. The new desired state is then routed through the rest of the configured logic and eventually the server sends the new desired state to the appropriate devices. ## Device processing of desired state When a device receives a change to a desired state, it will attempt to meet that desired state based on various settings. If no [maintenance window](#maintenance-and-reboot-windows) is defined for the urgency of a patch, the device will attempt to immediately apply the patch change in order to meet the new desired state. Otherwise the device will wait until the maintenance window to attempt to apply the change. After each patch, the device will perform a partial scan to update the status of the product and version and report that status to the server through the peer-to-peer network. ### Acquiring content If [content prestaging](/patch/advanced-settings/content-prestaging.md) is enabled, a device will download the content before the maintenance window. This helps ensure that patches are ready to be applied when the window opens, and reduces the chance of patches taking too long and missing the end of the maintenance window. If content prestaging is not enabled, then the device will download the content when it attempts to apply the patch change. Devices use smart logic to try to optimize bandwidth and reduce network strain when acquiring content. For more information, see [Content flow](https://docs.adaptiva.com/platform/user-guide/platform-management/network-topology#content-flow). ## Core concepts ### Patch status When a device performs a scan, for each installed product it will evaluate the status of each patch in the metadata for that product. The device will assign each patch one of the following statuses: * **Applicable** - The patch is newer than the currently installed version, and there is no newer version of the patch available. * **Installed** - The patch matches the latest installed version. * **Installation in Progress** - The device is currently installing the patch. * **Outdated** - the patch is newer than the currently installed version, but there is a newer version of the patch available. * **Not Applicable** - indicates that there is already a newer version of the product installed. Once a day, devices will run a full scan to refresh their state. In addition, a device will run a scan * When new metadata is received from the server * When the desired state changes * When a patch deployment makes progress * When a patch deployment succeeds or fails After a scan, the device sends the updated patch statuses to the server. The scan results are logged on the client device in the **Patching.log** file. ### Desired state The server contains the rules and strategies that define what the "desired state" is for each device. Desired state is defined for each patch that applies to a product on the device. When a strategy running on the server deploys a patch, it notifies devices of changes to the desired state, and the devices are responsible for reaching that desired state. Each device will maintain a list of the desired state for each applicable patch. There are five possible desired states: * **Mandatory Install** - The device will install the patch at the next opportunity. * **DoNotInstall** - The device will not install the patch. * **Uninstall** - The device will uninstall the product (uninstalling a patch results in uninstalling the whole product). * **Rollback** - The device will roll the product back to the specified patch version. * **NoChange** - The device will take no action with the patch. Changes to the desired state are logged on the client device in the **PatchingPolicyClient.log** file. ### Compliance Compliance is a measure of how patched your devices and products are. A product is considered compliant when there are no newer versions available to upgrade to. If you have specifically defined an exclusion for a patch, but the product is up to date not counting the excluded patch, the product is considered "compliant by exclusions". ### Consistency Consistency is a measure of how well a device has fulfilled the desired state send by the server. Consistency is evaluated on a per patch basis, and compares the desired state of a patch on a device against the patch status reported by the latest device scan. For example, if a patch has a desired state of **Mandatory Install** and the scanning reports the patch as **Applicable**, then the patch is considered inconsistent. If the scanning reported the patch as **Installed**, then the patch would be considered consistent. ### Maintenance and reboot windows A device may have specific time slots configured that determine when they are allowed to make changes, such as apply a patch or rebooting the device, so as not to interrupt users. A reboot window defines when a device is allowed to shut down and restart, if required as a result of applying or uninstalling a patch. A maintenance window defines when a device is allowed to apply patches, uninstall products, rollback patches, etc. If the action requires a reboot, the device won't reboot until the reboot window. These windows are configured on the server, which then communicates the windows to the device. You can use the same window for all urgencies or you can define different windows for different patch urgencies (low, normal, high, critical). This enables you to have devices apply critical urgency patches as soon as possible, while delaying low urgency patches to once a month, for example.