The Patch Management Solution for Windows Compliance Reports are showing clients needing a reboot, when they have been rebooted, or they display inaccurate data concerning the client's compliance.
Patch Management 7.1 SP1, SP2, MP1.x, 7.5 and 7.6.
Software Update Cycle is captured as an 'Event' for Patch Management. If the event is missed due to client tasks being backed up / stale; the 'Event' is lost. If the Event is lost; the Patch Reports are not able to provide accurate 'IsInstalled=TRUE' or 'Reboot Required' data.
- Note: This is an environmental issue and not a bug of the product. The status will be remediated the next time a Software Update Cycle has executed, capturing the Event, and provided the environment is in order; process to the database resolving this temporary problem.
- Advisory: This Event cannot be duplicated with a reboot. The process for Software Update Cycle, reboot required and reboot executed, is the only way to generate the event.
Found that utilizing scripting to execute the Software Update Cycle does not trigger the event, so the process does not gather the Event data. This is not supported, for it is utilizing other solutions (Software Delivery or Task Jobs) to execute the Patch functions. Ensure that the process is completely owned by Patch Management.
Additionally, this can be caused by a myriad of things;
- SMP unable to process NSE files due to queue full or other errors
- 503 errors on SMP or other IIS issues
- Database is unable to process with deadlocks or other maintenance issues
- Client GPO blocks return of NSE files
Review the following to see if the issue is present:
1. Check the Client's Registry to see if a reboot is required
- This process it outlined on KM: TECH127365
- Value of 1 indicates that a reboot is needed
- Reboot the client and allow for time to gather the event files
- Review KM: HOWTO77167 if this process needs to be manually executed to refresh the Reboot Event
2. Check the Client's InstallLog.csv
- This location is outlined on KM: TECH147912
3. Check the Client's Resource Manager
- Console > Manage > Computers > All Computers pane
- Right-click Client > Resource Manager
- Resource Manager > View > Inventories > Data Classes > Software Management > Patch Management > Installed Windows Software Update
- Current tab in the right pane
- Match the installed list with the compliance report to see what is conflicting.
Once deemed this is the issue in the environment: Wait for the Software Update Cycle to execute on the client(s) once more to resolve this temporary problem. However, if unable to wait for another Software Update Cycle / Reboot Event; review the following work around:
Work Around: run the attached sql files to update the views in the Symantec_CMDB database; vPMCore_SWDEventExecutionSuccessByComputer and vPMCore_SWDEventExecutionSuccessByComputer2
- This work around will remove the Reboot Event requirement from the Compliance Report. The report will render compliance based on the IsInstalled Rule returned value.
- Advisory: Before running the SQL rename the existing view for backup purposes.
- Note: The change made slows down the view slightly when rendering the report. In most environments it will not be noticeable; however, larger databases may see a greater impact.
Workaround Addition 1: Import the attached custom report: Listed Missing Reboot Events
Workaround Addition 2: View the attached 'Custom RebootRequired Inventory_Dataclass_Report.zip' file; walks through the process to create a custom Inventory Job (gather reboot data without event), custom DataClass (store inventory in database) and custom Report (view data in Console).
Additional Info: Uninstalling / Reinstalling the Altiris Agent will not resolve this issue, for the Patch Inventory is held in the Symantec_CMDB database and will not be affected.
- However, if the Client Resource is deleted through the Console > Manage > Filters > Computers; the client will return Patch Inventories and the database will process the inventory as 'Installed by User' which will bypass the Reboot Event check.
- Caution: Perform this process at your own risk, for database info will be lost for the client's full inventory, and this data is not recoverable through product.
Advisory: To help prevent the missing Event in an environment: Review the steps detailed on KM: TECH183347 to ensure the EventQueue settings are in order to allow more data through. The data is processed from the client via the EventQueue and if the SMP is unable to process that data; it could result in losing the Event Data from the clients.
Note: Step 6 of the linked KM article: the 'FastQueueThreshold' value should not exceed 50,000, but go as big as possible.
Additionally, stagger the Windows System Assessment Scan to run off schedule of any other inventory pulling processes (e.g. Send Basic Inventory or Replication).
If this issue is seen in older versions of Patch (PM 7.0-7.1 MR4); review KM: TECH140529.
Advisory: This has been resolved in Patch Management 8.x by running the following setting to enable the 'Send additional status events for Software Update policies (Aex SWD Status)' on the Windows Patch Remediation Settings.
Note: This process is not real-time and is dependent upon scheduled tasks to execute. The results should be present within a day at the most, but as early as 4 hours following, for the setting will request the missing event from the Clients following 'Update Configuration' to get this policy's change, the run of the Windows System Assessment Scan, and return inventory to the SMP Server to be processed to the database.
Imported Document Id
Attached SQL Files to update the views in the Symantec_CMDB database: vPMCore_SWDEventExecutionSuccessByComputer and vPMCore_SWDEventExecutionSuccessByComputer2
Updated Views - Workaround.zip (2.0 KB)
PowerShell Custom Inventory for RebootRequired registry key.
PowerShell PM Reboot Required.zip (455.6 KB)
Report used to view Computer Name, Missed Event and Last Executed date. Note that the Software Updates affected by this are irrelevant as the event needs to take place once more before the issue is resolved and the workaround is no longer needed. However, the Last Execution date helps to know what time frame the updates were deployed.