4 Replies Latest reply on Sep 26, 2012 11:24 AM by achowsy

    Big Picture for Patch manager

    achowsy

      Hi,

       

      Does any one have the big picture of how every component/traffic patterns/communication paths/reports/inventory between Patch Manager (Application/Mgr/Automation), Patch Manager Automation Server, WSUS and Clients work?   I read through the Deployment Guide and the Administrator Guide and I am still have some doubts.

       

      we have downstream WSUS servers in multiple locations and each location is connected via IPSEC 512kbps.  We have install Automation servers at each location.  The main datacentre is holding the Patch Manager PAS (APP/MGR/AUTO) /Upstream WSUS server.  I am deploying Microsoft and 3rd party patches using WSUS.

       

      Questions like:-

      1.  Is WMI provisioning portion only used to inventorize the computers?  Is it required if I need to generate reports for Microsoft/3rd party patches installed?  Is WMI portion require to deploy 3rd party patches?

      2.  How do we generate the status of 3rd party updates/installs for each computer as the status is not found in the WSUS console?  Will a "WSUS inventory" be sufficient? 

      3.  I have generate a WSUS self-signed certificate for each WSUS (after installing 1.73 PM and kb2720211 on the WSUS/PM server).  The clients would need to have the WSUS server's self-signed certificate in their "Trusted Publisher"/Trusted Root containers.  Why do i then need to republish each package which was publish before I patch the server?

      4.  Is my setup ideal for the slow connections between the sites?  Would there be a difference if I do not install Automation servers at each location except the datacentre?

       

      Thanks.

       

      adrian

        • Re: Big Picture for Patch manager
          Lawrence Garvin

          Is WMI provisioning portion only used to inventorize the computers?

          No. WMI Providers are used to provide communications and services for any Patch Manager task that is targeted to a system. Included in this, of particular note, would be update deployment tasks using Update Management and Update Management Wizard.

           

          Is it required if I need to generate reports for Microsoft/3rd party patches installed?

          No. Update status reports are obtained from the WSUS Inventory task which retrieves information from the WSUS server via the WSUS API. WSUS Inventory does not use WMI connectivity.

           

          Is WMI portion require to deploy 3rd party patches?

          If you wish to use the Update Management or Update Management Wizard tools, then yes, WMI Providers are required. If you simply approve the updates on the WSUS server and let the Windows Update Agent do the work naturally, then WMI Providers are not required.

           

          How do we generate the status of 3rd party updates/installs for each computer as the status is not found in the WSUS console?

          You use the Patch Manager console.

           

          Will a "WSUS inventory" be sufficient?

          A WSUS Inventory is required to review update status in a report. A WSUS Inventory is not required to review status information in the console.

           

          I have generate a WSUS self-signed certificate for each WSUS (after installing 1.73 PM and kb2720211 on the WSUS/PM server).

          If all of your WSUS servers are downstream replica servers, then you only need *one* certficate, created on the Upstream Server.

           

          Why do i then need to republish each package which was publish before I patch the server?

          First, you do not need to republish every previously published package. For the moment, you do not even need to re-sign the existing packages. However, the impact of KB2661254, which will be released to WSUS in 2 weeks, will invalidate all certificates that were built with 512-bit keys. This includes any WSUS self-signed publishing certificate that was created prior to installing KB2720211 (or KB2734608). In order for clients to use updates after the installation of KB2661254, those updates packages will need to be RE-signed and RE-published with the 2048-bit key. You only need to re-sign/re-publish the packages that are still NEEDED by one or more clients. The best solution here, IMO, is to ensure that all third party content that is published has been successfully installed everywhere it needs to be before deploying KB2661254. In that case, most likely, you will not have to re-sign/re-publish any updates. Also note -- updates published with the 512-bit keys should be DECLINED (or deleted) on the WSUS Server after deploying KB2661254, as those updates will be totally worthless at that point.

           

          Is my setup ideal for the slow connections between the sites?

          Your setup is really the only option when you have slow-speed connections. A downstream WSUS replica server and a Patch Manager Automation Role server on the other side of every WAN circuit is the recommended deployment scenario. What you have to give additional consideration to is the movement of the WSUS Inventory data across the WAN and where that data is most often used -- e.g. who runs the reports that are used by the WSUS Inventory task? This will drive the question of where the Management Server(s) should reside.

           

          Would there be a difference if I do not install Automation servers at each location except the datacentre?

          Absolutely! Without Automation Role servers on your remote sites *ALL* WMI-based connections will originate from the data center and all of that RPC and WMI traffic will traverse the WAN connections.

            • Re: Big Picture for Patch manager
              achowsy

              Hi Lawrence,

               

              Great answers and I appreciate it a lot.

               

              My colleagues have phobia trying to upgrade Patch Manager and we had a situation that we have to upgrade like 130+ servers before it would be working in for the form of version 1.73.  So if possible we are trying to see whether the scenario without even the Automation server at the bottom would be viable.  As mentioned each servers in each properties (location) are connected via a slow speed IPSEC tunnel back to the datacentre (512kbps).

               

              So if we do not even have Patch manager at each properties and only the WSUS, and we create the servers as Replicas to the Datacentre Upstream and we approve updates [Microsoft and 3rd party] in the datacentre, do reporting rollup, and only inventorize the WSUS in the upstream, what would be the disadvantage you forsee I would have without having Patch manager installed in each property?  Would it make troubleshooting more difficult as we cannot utilize the powerful tools of Patch manager (in the form of WMI providers)?

               

              I currently have a WSUS server replica at a slow link site and the "unapproved counts" are very different  from the upstream WSUS server, no matter how many successful synchronizations had occurred.  Would having Patch manager in that location able to help me troubleshoot the problem or give me more insight to the root cause of the problem or allow to do something that I would not able to have done?  [Or based on other forums, you suggested a reinstallation of the WSUS].

               

              Thanks.

              1 of 1 people found this helpful
                • Re: Big Picture for Patch manager
                  Lawrence Garvin

                  If you only deploy replica WSUS servers, and the local site does not need to be involved in deployment activities, and you enable Reporting Rollup and inventory only the upstream server for enterprise-wide reporting, and do not use any other functionality available in Patch Manager except publishing content to the upstream server and WSUS administration activities, then there would be no advantage to having a Patch Manager Automation Role server at a remote site because there would be no work for that server to do.


                  But your second point is the key -- by not having those Automation Role servers deployed to faciliate the use of the WMI-based tools, you would have to ensure the ability, and suffer the impact, of operating RPC and WMI connections across the WAN circuits -- which at 512kbps may not be a desirable condition.

                   

                  To your second question -- about WSUS replica server update counts -- disparities in update counts (approved, not approved, declined) between the upstream server and the replica server are quite often a manifestation of how the Server Cleanup Wizard has been used. The Server Cleanup Wizard deletes expired updates and old revisions of updates -- but those deletions are not replicated to downstream servers. The SCW needs to be executed on every WSUS server. Also, if the replica server has ever been allowed to synchronize while not in replica mode -- that can also adversely impact the count of Approved updates (which will also adversely affect the deployment of updates to the client systems). Patch Manager cannot directly assist with these type of synchronization issues, but Patch Manager can be used to schedule the regular execution of the Server Cleanup Wizard which may mitigate some of these disparities. In this instance, you may find it desirable to have a local Automation Role server to launch that Server Cleanup Wizard task so that the WSUS API connection and monitoring is performed on the LAN connection, not the WAN connection.

                   

                  One other scenario to consider -- since it seems that the current scenario may make these site-based Automation Role servers somewhat "optional". You might consider simply unregistering these servers from the PAS (and removing any related Routing Rules) and uninstalling the legacy Patch Manager installation on the remote sites. Then you can upgrade the PAS (and a small collection of core Automation Role servers that you need to keep online) to v1.73 (or v1.8), and then, at a more leisurely pace you can RE-install the v1.73 (or v1.8) Automation Role servers on those remote sites as the need is identified. Keeping in mind, though, the operational implications of not having the Automation Role servers deployed.

                   

                  You could invest a fair amount of time in trying to match up the discrepancies between an upstream server and a replica server. The significance of the discrepancy should drive how much effort you invest. If the discrepancy seems to be problematic, the easiest solution, in most cases, is simply to uninstall and reinstall the replica server with a new database. (Keep the CONTENT, as that can be reused, and unneeded content files can be easily deleted by the SCW if they're not needed.)

                  1 of 1 people found this helpful
                    • Re: Big Picture for Patch manager
                      achowsy

                      Hi Lawrence,

                       

                      Thanks so so much for your reply.

                       

                      I think i got 4 more/last easy questions for you:-

                      1.  When you said "operating RPC and WMI connections across the WAN circuits" :- can you give an example of RPC?  Is schedulling a Server Cleanup Wizard task considered under this operation? [If I didn't read wrongly in your previous answer, having an automation server at the property will help in this task].  Are "WSUS API connection and monitoring is performed on the LAN connection" - between the automation server and the WSUS server at the property?  Sorry as I just want to confirm.

                       

                      2.  As I can configure the WSUS replica to download Microsoft updates from the internet and not from the slow speed upstream server, can I confirm that the 3rd party updates have to come from the upstream server and hence have to tranverse the slow speed link?  This is via BITS? Would tweaking the SUS db to "run in the foreground" help?

                       

                      3.  For the WSUS server, is there a log file that records why the disparity of the approvals?  Based on  your vast experience, are you recommending to save time, just reinstall since it is impossible to troubleshoot?  I have search/look at google search and forums that you wrote and almost all mentions reinstalling.

                       

                      4.  Before Eminentware were bought over by Solarwinds, there were a lot of webcast or videos that you have on the tutorials and on creating 3rd party reports and how to do SCW properly or best practices to maintain WSUS, would you be able to direct me to these resources?  Are they found in twack?  I would like to find example on how to generate 3rd party reports per property so that the local IT managers can find out the percentage of the machines that are not fully patched, what machines are missing updates, how many updates they are missing , what updates were missing from each machine and troubleshoot them accordingly.  Another concern I have is whether the report rollup to the upstream server cause issues to generate such reports?

                       

                      Really appreciated your answers as it has confirmed my understanding of the product.

                       

                      adrian