A- The Patch group hasn't been activated
If the assignment was made through a device group the device group assignment status is "Not Activated".

Solution:
Select the device (group) from the assign objects of the patch group, right click on the assignment and click on "Activate Patch group".


B- Patch installations are blocked
To check if patch installations are disabled:
- check the Patch Management module configuration file:

- go the the installation folder of our agent on one device where patches do not seem to install
- edit its ../config/PatchManagementPremium.ini
- check if the setting "BlockPatchInstallation=" is set to "1" or "true" or "yes"

- check Patch Management module configuration in the console:

When this is set, patches from any patch job/group won't install on the device. This can be useful when the goal is to make sure that no patch is installed on a device while:

- it's connected through the WAN, as an example (e.g an operational rule is assigned to a dynamic group which would trigger on the ip address not being local, as an example)
- the deployment of a sensitive software is ongoing and must not be disrupted by any patch installation.

Solution:
It is advised to check with the other BCM administrators if one of might have decided to block patch installations on purpose before deciding to allow patch installations again.
- stop the service of the agent
- set "BlockPatchInstallation=" back to "0" or "false" or "no".
- restart the service of the agent

This can be updated in mass simply by using the step "Update INI File" in an operational rule. Do not forget to restart the service after.


C- The patch management module is suspended
If one of the patch job/group contains patches which require a reboot and that it is configured to not to reboot at the end of the installation of all patches contained in this patch job/group, the patch management module will be suspended and will therefore block any installation of other patches by other patch job/group assigned to this device until the device will have reboot.

This implies that the patch job/group might not install patches just because another patch job/group has set the module to block patch installation, and not because of an issue on the patch job/group that is being analyzed.

To know if that it's the issue that is being encountered,:

1- Before 20.08 not included:
- go to the install folder of an agent were the patch job is stuck to the status "Execution pending" status, or "Installation planned" for patch groups
- check the most recent logs starting by "PJ_" or "PG_" in the sub-folder ../log/Patches.
If the module is suspended there should be a line similar to this one at the end of one of these files:

2016/05/15 08:15:13 PatchManagementPremium T Module is now suspended until the next reboot

If the date at the beginning of this line is newer than the last time that that same device was reboot, then this would be proof that the patch installation has been blocked because of a patch that requires a reboot in one of the assigned patch jobs/groups.

2- After 20.08 included:
This is now visible in the console, e.g:



It is also visible in the Inventory status of all devices:



Please not that this is the status known in the database, in case of an issue it could be not up to date, so the most efficient way to check is still to check in the logs.

Solution:
Reboot the device

Note: The KB 000133182 helps identify the patch job/group name from the id in the name of the PG_ or PJ_ log files.