2 Replies Latest reply on Oct 23, 2015 11:32 PM by rbabcock

    A few picky comments on Protect 9.2

    rbabcock Apprentice

      When editing a patch group and adding patches, I can right-click on the selected patches and add by picking a patch group from a list that may be long enough to need scrolling.  But most likely I want to add to the group displayed in the lower pane.  There's no context menu option for this, nor can I drag and drop.


      Display scan results, click on a missing patch (not first column), screen scrolls right.  Other places such as machine view don't do this.


      Looking at a patch in machine view, I can get a list of affected machines in the bottom pane, but I can't export the list.  I would use such a list outside of Protect to look for machines powered off or not logged in to patch outside of our scheduled maintenance windows.


      There is no complaint when starting a scan if a machine group includes a linked file that doesn't exist.


      With the taskbar at the top of the screen and not autohidden, help comes up under the taskbar.  (Using a Remote Desktop connection in case it matters.)


      When I open the operations monitor, I sometimes see standard Windows min/max/close buttons until I move the mouse over them, then they are replaced by your custom buttons.

        • 1. Re: A few picky comments on Protect 9.2
          chrisgoettl SupportEmployee

          Thanks for the feedback rbabcock!


          We will take a look at these.  They all look pretty low impact so they would not typically hit our criteria for being included in a patch, but we will see what can be done and when. 



          • 2. Re: A few picky comments on Protect 9.2
            rbabcock Apprentice

            Somewhat higher impact - I was just trying to do a scan so I could schedule a server to patch over the weekend.  The scan hung up after saying XML was up-to-date and before resolving machines to scan.  (Even did this scanning the scan machine.)  I saw timeout errors in st.servicehost.netframework.log which were not otherwise reported.  I checked the timeout and it was set to 30; changing to 3600 didn't help.  (I think the upgrade to 9.2 reset this.)  What did seem to fix it was using your operations/database maintenance tool to rebuild sql indexes.  (sqlserver 2012 express on the same server 2008 r2 as the scanner.)  Scans are now working and no more timeout errors are being logged.  They might even be running faster.


            A complicating factor: we just imaged the scan server with windows backup and restored onto larger disks.  That shouldn't have broken anything, but the initial attempt upgrading to 9.2 ran out of disk space and choked sql server  That might have left some damage that wasn't immediately apparent.