Patch approval definitions
You can approve and decline patches by type through rules associated to devices. Approvals ensure that the patches a device is looking for or wants to download is legitimate and will not cause any issues or conflicts with the device or within the network environment. If there is no approval applied to a patch, N-able N-central will not deploy it to a device.
When conflicting patch approval statuses are applied to a device from either a Rule or a device level approval, precedence is given according to strict approval hierarchies.
The table below describes each approval type. For more information see Approving and declining patches manually.
Not Approved and No Approval are not the same thing. No Approval is the default state associated to all Rules. It means no decision has been made. This is the state that you want to leave every Rule that you do not intend to make a decision for. See Not Approved vs No Approval section below the table.
| Approval Type | Description |
|---|---|
| Not Approved | N-able N-central does not install the patch on a device, and flags it as missing. It will be visible to the device for patch updates. You may want to save it for a future time. This means that the update remains in the default list of available updates and will report client compliance, but will not be installed on any devices. |
|
Approved for Install |
The patch will be installed. The patch will appear as missing until it is installed. |
| Approved for Removal |
The patch will be removed if the removal option is available. To determine if the patch is removable, on the Patch Management Home page, click By Patch and click on the patch name and locate the line called Removable. This status implies a best effort for N-able N-central to remove the patch. Removing a third party patch will result in the entire removal of the third party application. If you remove the patch, it will be flagged as missing. |
| Declined |
N-able N-central does not install the patch, and does not flag it as missing. The patch is still available for installation through N-able N-central, but will not be visible to the device when checking for updates. |
| No Approval (inherited) |
This value makes no change to the intended action with the patch. If a value has been set by another rule, then that value is retained and this one ignored; otherwise N-able N-central takes no action with the patch and does not install it on a device. Because there is no approval, it appears as a new available patch. |
| No Approval (Set) | This value sets the intended action of the patch and, if the precedence of the rule requires it, it will overwrite values set by other rules. As a result, N-able N-central takes no action with the patch and does not install it on a device. Because there is no approval, it appears as a new available patch. |
| Revert | After selecting an approval category and you do not want the selection. Select to return to the previous state. |
|
Revert Children |
After selecting an approval category for a child of the customer node, and you do not want the selection. Select to return the child elements to the previous state while leaving the parent state intact. |
| Revert Current Node and Children | After selecting an approval category and you do not want the selection. Select to return the parent and child elements to the previous state. |
| Clear and RE-evaluate Device Level Approvals | Remove any approvals set at the device level. N-able N-central uses the approvals set at the higher levels, customer or so level approvals. |
| Preserve Device Level Approvals |
Reverts the selection of Clear and Re-evaluate (described above). |
| Apply to Children | Available at the parent level, select when child elements have different approval settings to change them to match the parent. |
| Same as Parent | Available at the child level, select for a child element to use the same approval setting as the parent level. |
Not Approved vs No Approval
Not Approved is a specific patch approval state where a patch will show as Not-Approved in the Patch Status service, but we take no action on the patch. The No Approval state is a default state, and is the result of there being no specific approval for the patch/device combination. If a higher level approval were made, a No Approval would always be overwritten, whereas a Not Approved needs to be explicitly overwritten.
Setting auto-approval targets had slightly different behaviour from this. In part this is historical, and in part it is because there are slightly different requirements between standard approvals and the "meta" nature of auto-approvals.
In auto-approvals "No approval" might be set as a value (rather then merely be the default) in order to allow explicit exclusions of devices whose status has not yet been decided, and hence to provide filters on this. This is provided by setting this value explicitly and displaying it as "No Approval (set)". Whereas "No Approval (inherit)" is the default value when there is no setting and behaves as described in the preceding paragraph. In versions prior to 2022.4 these values were indistinguishable on the N-central interface, leading to confusion and numerous NCIs (A technical description of the historical description is here When is "No Approval" not "No Approval"?). Following that version it is possible to differentiate due to the annotation in brackets.
In order to explicitly set "No Approval (set)" the value "No Approval" is selected from the dropdown. In order to revert to "No Approval (inherit)" the options "Same as parent", "Apply to Children" and "Clear" are used.