This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Co-Locating Patch Manager Server and WSUS 6 on a Single Windows 2012 R2 Server


We are planning an implementation of Patch Manager.  Our current environment of WSUS 3.2 is running on Server 2008 R2, but we are planning to install new Server 2012 R2 systems for WSUS.

After a lengthy conversation with SolarWinds Technical Support yesterday, I have a few remaining questions.  After speaking to the rep and explaining that we only have about 300 clients in each site that each patch manager server will responsible for, he stated that it should be perfectly fine to install the patch manager roles on the same servers that WSUS will be running on.

So, my questions are these:

  1. Would it, in fact, be acceptable (performance wise) to install Patch Manager roles (all three) on the same 2012 R2 servers we are running WSUS from if there are at maximum 300 clients that will connect to each?
  2. When installing WSUS, it wants to install the database into a Windows Internal Database.  Can Patch Manager be installed to a Windows Internal Database, or should I do one of the following:
    1. Install SQL Express (2008 or 2012 - whichever is supported) and install Patch Manager's database into that and leave WSUS running on Windows Internal Database.
    2. Install SQL Express (2008 or 2012 - whichever is supported) and install both the WSUS and Patch Manager databases into that.
  • ...explaining that we only have about 300 clients in each site that each patch manager server will responsible for,

    How many sites/clients total in the enterprise?


    I'm assuming from the description that these sites already have WSUS servers. If so, then yes, it would be appropriate to install a Patch Manager Automation Role server on each replica WSUS server.

    Would it, in fact, be acceptable (performance wise) to install Patch Manager roles (all three) on the same 2012 R2 servers we are running WSUS from if there are at maximum 300 clients that will connect to each?

    In reality, unless there are significantly more sites/clients than I'm imaging, you would likely only have one server with the Application Role and Management Role. Remote sites would have only the Automation Role.

    Can Patch Manager be installed to a Windows Internal Database,

    No. The WID is licensed only for use by Microsoft-native applications.

    1. Install SQL Express (2008 or 2012 - whichever is supported) and install Patch Manager's database into that and leave WSUS running on Windows Internal Database.
    2. Install SQL Express (2008 or 2012 - whichever is supported) and install both the WSUS and Patch Manager databases into that.

    This really depends on a number of additional factors.

    1. Where do you plan to install the Patch Manager Primary Application Server?
    2. How many clients, total, in the enterprise will be managed by the WSUS environment?
    3. Will you be using WSUS Inventory/Reporting via Patch Manager
    4. Will you be using the Patch Manager WMI-based Managed Computer Inventory functionality?


  • Wow, I wish I had spoke with you instead of spending nearly 2 hours on the phone with support.

    We have about 1500-1800 clients in total spread between 6 sites.  The plan was to install the primary application server into our remote data center (which has no clients) and install full secondary application servers in each site.

    I believe we would like to leverage the use of Patch Manager reporting for patch status and possibly for system inventory.  The second would be less important since we have SCCM in our environment and it seems like much of that data would be redundant.

    Thank you so much for your attention to this and your prompt response.  It has really been difficult to try to intelligently plan out my deployment based on the complexity of my enterprise and the admin guide leaving me with tons of unanswered questions.

  • and install full secondary application servers in each site.

    Deploying the Primary server into the corporate data center, and leaving it clientless, is a good approach.

    Then the next question from this then becomes: Where will you have administrators who use the Patch Manager console? In all sites, or only in the corporate site?

    If you have a distributed patch administration environment, additional application servers can be useful; if you have a centralized patch administration environment, then likely the only question of concern is whether you connect consoles directly to the PAS in the data center, or deploy a second application server at the central site and connect consoles locally.


    Generally speaking, additional application servers are deployed to support additional console sessions, to avoid launching a console session across a WAN-based connection, or where additional security boundaries are needed.

    Additional management servers are deployed to support distributed data storage of inventory data, or where unique management scopes (e.g. AD Domains or WSUS environments exist). I suspect in a Configuration Manager-based six-site environment, additional management servers will not serve any useful purpose. As noted, if you are managing Software Updates from each side independently, there may be value in having an on-site application role server.


    You may find some benefit from these supplemental materials posted here in Thwack:

    Patch Manager Architecture – Deploying Application & Management Role Servers

    Patch Manager Architecture - Deploying Automation Role Servers

    and possibly for system inventory.  The second would be less important since we have SCCM in our environment and it seems like much of that data would be redundant.

    Correct, the software/hardware inventory available from Patch Manager is mostly redundant with what you can get from Configuration Manager.

    However, a significant difference would be that the inventory selection (i.e. what you inventory) is highly customizable with Patch Manager,

    and the reporting engine is significantly more user friendly than is the ConfigMgr reporting

    This may well be sufficient justification to utilize Patch Manager for asset inventory rather than Configuration Manager.


    However, it is the specific question of performing WMI-based Managed Computer Inventories, and/or other client-management tasks,

    that will directly drive the need, or lack thereof, to deploy Automation Role servers in the remote sites.


    The good news is that you can ADD those site-based Automation Role servers at any time.

    So, it's perfectly conceivable that you might defer that decision until such point that you've identified an express need for the capability.





  • Then the next question from this then becomes: Where will you have administrators who use the Patch Manager console? In all sites, or only in the corporate site?

    I believe it would be beneficial to have a local console session available for each site, in case additional administrative activities need to be performed from the branch offices.  I have been led to believe that no matter which application server you point the console at, you can still get all of the inventory data from all the other management servers.  Would you say that my understanding of this is correct?  Is my information also correct that any console can be directed to connect to any application server at will and it is not a 1:1 relationship with a specific application server?

    I suspect in a Configuration Manager-based six-site environment, additional management servers will not serve any useful purpose.

    I'm not sure I follow this logic, could you please explain further?  I have six geographically disparate locations that will have clients that that generate inventory data, wouldn't installing a management server in each location allow that information to be stored locally instead of being streamed across the WAN back to the data center?  Is there a down-side to this configuration?

    if you are managing Software Updates from each side independently, there may be value in having an on-site application role server.

    Does this mean that if I install an application server at each site I lose the ability to manage updates centrally, or are you simply stating that unless each site is managed independently, it is of no advantage to install the application role in each site?

    However, it is the specific question of performing WMI-based Managed Computer Inventories, and/or other client-management tasks,

    that will directly drive the need, or lack thereof, to deploy Automation Role servers in the remote sites.

    Are there any disadvantages of installing the automation role, but not utilizing it?  Does it cause a large additional (and possibly unneeded) overhead if automaton is installed, but not used?

    Back to the questions regarding the database installation:

    • Does Patch Manager support being installed on SQL Express 2012 or do I need to use 2008?
    • If WSUS and Patch Manager (all roles) are installed on the same box, would it be better to leave WSUS running on WID and Patch Manager under SQL Express, or should both databases be running under SQL Express?
  • If it's just a matter of having an "available" console session for each site, there's no real value in the investment of an Application Server for that purpose. Those console sessions, if used, can latch onto an Application Server via the WAN.

    I have been led to believe that no matter which application server you point the console at, you can still get all of the inventory data from all the other management servers.  Would you say that my understanding of this is correct?

    This is correct. the data is physically stored in the Management Server role. Multiple Application Servers can be configured to access one or more Management Servers, and security configurations allow you to further permit/restrict that access on a per-user basis.

    Is my information also correct that any console can be directed to connect to any application server at will and it is not a 1:1 relationship with a specific application server?

    Yes.

    I'm not sure I follow this logic, could you please explain further?  I have six geographically disparate locations that will have clients that that generate inventory data, wouldn't installing a management server in each location allow that information to be stored locally instead of being streamed across the WAN back to the data center?

    Not necessarily. A Management Server is scoped to a management object. Currently for inventory purposes, the only available management objects are an Active Directory domain or a WSUS server. From a WMI-based Managed Computer Inventory perspective, all inventory for members of a single domain will be stored in a single database; there is no way to distribute this data. Ergo, unless you're inventorying a multi-domain environment, a second Management Role server would have no functional purpose.

    unless each site is managed independently, it is of no advantage to install the application role in each site?

    This is what I'm saying. Unless there are permanent and regular console users (plural) at a site, there's really no advantage to the overhead of having an Application Role installed.

    Are there any disadvantages of installing the automation role, but not utilizing it? Does it cause a large additional (and possibly unneeded) overhead if automaton is installed, but not used?


    No, there are no disadvantages. In fact, the overhead of an Automation Server is non existent except when executing actual tasks, and even then the majority of effort is sitting in wait states on an open RPC/WMI connection waiting for the client to do something.

    Does Patch Manager support being installed on SQL Express 2012 or do I need to use 2008?

    Patch Manager is supported on all instances/editions of SQL Server from 2005 thru 2012.

    If WSUS and Patch Manager (all roles) are installed on the same box, would it be better to leave WSUS running on WID and Patch Manager under SQL Express, or should both databases be running under SQL Express?

    Neither, actually. From some testing I did a long time ago, the best configuration appears to be WSUS and Patch Manager installed together using a remote SQL Server running SQL Server Standard Edition. Patch Manager installs SQL Server 2008 R2 Express Edition by default, but WSUS should not be used with Express Edition. Patch Manager cannot be used with WID. The problem with co-location becomes the competition for resources between the WID engine and the Express Edition engine. In addition, it's quite likely, even that with 1500-1800 questions, you will encounter performance issues with Patch Manager running on any version of Express Edition.


    However.... there's an added variable for your environment. If you're 1800 clients are spread out over a half dozen WSUS servers, then the effective load on the local WSUS server is likely only a few hundred (or maybe even the central WSUS server has no client load at all, and all clients are using distributed WSUS servers). If this is the case, you might find the coexistence of WSUS/WID and PatchManager/SQLExpress to be tolerant.


    However, the good news is that you already have Configuration Manager, which means you should already have an instance of SQL Server Standard Edition deployed. I would suggest considering migrating the WSUS database to that SQL instance (in most ConfigMgr instances the SUP database is already in the same database as the ConfigMgr Site Server), and installing Patch Manager's database to that same instance.






  • Lawrence, I really truly appreciate your time and assistance here.  I still have so many more questions based upon the admin guide's lack of thoroughness and scant applicability to my environment, and the disparity between what you have been telling me and what was discussed with SolarWinds tech support.  I really am interested in properly planning my deployment, is there any way that we could have a direct discussion instead of post, wait, respond, or is this our only avenue?

  • I'd be happy to chat with you on the phone. My email address is available in my Thwack profile. Feel free to email me and we can set up a time.