Patch Management Solution

 View Only
  • 1.  Patch Management 7.1 SP 2, TECH167291, Reboot Status Data Class

    Posted Oct 23, 2012 11:53 AM

     

    We are currently experiencing issues with our Patch Management Solution 7.1 SP 2.  I have a ticket with support but they don’t seem to have an answer for me.  I have applied TECH167291 per support.  Which is supposed to fix the issue. 

    History:  I called support regarding Windows Compliance by Computer and Reboot Status Reports were not accurate.  Compliance numbers were off, computers needing to be rebooted (not all of them actually needed to be rebooted), some systems if they were rebooted they didn’t update in the compliance report or the reboot status report even though the updates were installed and the system was rebooted. 

    I’ve done some research and found prior to applying TECH167291, that there are some key tables which are not functioning correctly.  The following tables will execute if I take there script and execute it in a query but if I try to view the table normally through SQL Management Studio, I am unable to view the table getting a timout execution error.  If I run the script through a query it will take 9-12 minutes to finish.  Thus the stored procedure calling it is not allowing enough time for these to update. 

    The tables include:

    PCMCore_ComputersPendingRebootbyPackage

    PMCore_ComputersPendingReboot

    Inv_AeX_SWD_Execution_Summary

    vPMCore_SWDEventExecutionSuccessbyCOmputer

     

    Another table which does not have correct information in it is the Evt_Reboot table which is the key table in reporting when a  system has been rebooted.  There are several systems (50-60) which do not have any reboot history showing NULL instead.  After researching these systems in resource manager, I found that these systems are missing the data class reboot which is required for Patch to report when a system has been rebooted. 

    I have applied the TECH167291 as recommended to fix the issue regarding compliance inaccuracy but now, since the fix bypasses reboot required and keys off of actual installs the reboot status report is blank, and the compliance by windows report shows there are no pending reboots. 

    We need to have all reports function as they should.  Any ideas on how I can get the data class applied back to the systems missing it?  Or any way to generate a reboot status report maybe some other way?  I need to get this fixed as soon as possible, and support is not SQL efficient enough to help repair the tables at the current level I’m at. 

     

    Thanks,

    Misty



  • 2.  RE: Patch Management 7.1 SP 2, TECH167291, Reboot Status Data Class

    Posted Oct 25, 2012 12:56 PM

    Update to current status, I did find the Resource Update Summary task has been failing since early last month, I fixed the issue and re-enabled the original views which were modified in TECH167291.  Reboot status is showing back up but some are still an issue.  Also observed, when a policy is created to push a patch,  On the advanced tab within the policy everything is unchecked even though the policy is enabled.  Most if not all the packages on this tab should be checked if not all.

     



  • 3.  RE: Patch Management 7.1 SP 2, TECH167291, Reboot Status Data Class

    Broadcom Employee
    Posted Oct 26, 2012 09:35 AM

    Hi Misty,


    Reboot status is showing back up but some are still an issue.

    Could you please clarify what issue you observe at the moment?

    Regarding policies with disabled updates, could you please clarify is this issue observed within already created SWU policies or in Distribution Wizard during creating new SWU policy.
    Please note that in case if checkbox 'Disable all superseded Software Updates' is enabled in Import Patch Data for Windows page, superseded updates will be automatically disabled within existing SWU policies after executing PM import task

    Thanks,
    Roman



  • 4.  RE: Patch Management 7.1 SP 2, TECH167291, Reboot Status Data Class

    Posted Nov 06, 2012 10:58 AM

    Systems within patch are showing they need a reboot even though they do not.  And systems which are showing they do not need a reboot some actually do.  Also in addition some agents within the logs are showing auxillary package pending download.