Solarwinds Patch Manager on distributed network

In Scenario 2 i saw that i should install automation role servers on each WSUS downstream server in order to only use port 4092 (and not the rpc/wmi ports)

Correct, since the RPC/WMI connections originate from the Automation Role Server, this creates a two-stage communication. The communication from the primary server to the automation server occurs on port 4092, and then the Automation Role Server initiates the WSUS API or WMI connections on the appropriate ports.

How can i create a repository for 3rd patch on Central WSUS Server?

Run the Patch Manager Update Configuration Wizard from the Software Publishing node of the console.

Can i do it from the Central console?

You can do it from any console, but the console must be connected to the Primary Application Server (PAS).

Do i need to configure WSUS?

That depends. Was WSUS already installed and operational and you're just adding Patch Manager to the environment.... then No. No additional work is required on the WSUS server. If Patch Manager installed a NEW WSUS server, then there's lots of additional work that needs to be done to get your WSUS environment running before proceeding with Patch Manager. These requirements are documented in the WSUS Deployment Guide and WSUS Operations Guide. See Windows Server Update Services 3.0 SP2 for more information.

Does i need to create a repository on each downstream server?

When you publish third-party updates to the upstream WSUS server, they will automatically replicate to the downstream servers, just like Microsoft updates replicate.

Repository is the autamation role server?

No. The Automation Role Server is what manages tasks and communication in the Patch Manager environment. When you navigate the WSUS node in the PM console, it is the Automation Server that queries the WSUS API and sends that information back to the console. When you launch an Update Management task to install updates, the Automation Role Server is what talks to the client's Windows Update Agent and tells it what to do. The third party updates are stored in the database and filesystem of the Primary Application Server, except for those that are published which are also stored in WSUS.

Once the repository created and if i publish  Notepad++  application update(for example) to the central WSUS server, did i need to deploy the update on each downstream server or just wait the replication from  WSUS central server?

Just wait for it to be replicated.

Thanks a lot Lawrence for your feedback.

I will check on my side if everything is clear, install and configure.

Regards

Baptiste Rosso

Hello again,

Here is the recap of the 3rd patch Management project:

Our main WSUS is already installed and operational (same for downstream WSUS).

On the central network the PAS (installed on dedicated vm) is ready to use and connected to the main WSUS server and certificate published on it.

On the PAS console i can see the WSUS central server and all the update list (critical, etc ....) from mircosoft. I have created a new view "3rd patch update"

This view is currently empty, if i publish a package from "publishing software node" on the central WSUS server, i will see this the pakage in the "3rd patch Update" view?

Once the package is published on the main WSUS server, do i need to publish/install (or not) the certificate on both WSUS downstream before the replication ?

I saw on management group windows the option to register downstream server, do i need to register both WSUS downstream server ? How this option can be used?

Also my next task list is to install Automation role server on both WSUS downstream server (local)

Port 4092 have been opened between central site et local sites.

Do i miss something in my deployment ?

Thanks again for your feedback.

Regards

Baptiste

if i publish a package from "publishing software node" on the central WSUS server, i will see this the pakage in the "3rd patch Update" view?

Yes.

do i need to publish/install (or not) the certificate on both WSUS downstream before the replication ?

The certificate must exist *everywhere*: All WSUS server, All PM Servers, and ALL clients (that will install 3rd party updates).

do i need to register both WSUS downstream server ?

It is not necessary to register the downstream servers; however, it can be useful to be able to navigate their content/clients from the PM console, and in order to execute the Server Cleanup Wizard against those servers.

How this option can be used?

Registering a downstream server is identical to registering the upstream server.

Also my next task list is to install Automation role server on both WSUS downstream server (local) Port 4092 have been opened between central site et local sites. Do i miss something in my deployment ?

After installing the Automation Role Servers, be sure to define an Automation Server Routing Rule that routes the appropriate traffic through those Auto Servers.

Hello Lawrence,

Happy new year and thanks again for all information provided.

I have some new question.

In our distributed environment, we have the PAS server installed on a dedicated vm and same for the central WSUS server.

Each local site have their WSUS downstream server.

One of this local site is the integration environnment.

I would like to publish a package only to the Integration WSUS site  from the PAS and not all other site.

Is it possible?How can i proceed?

Best Regards

Baptiste

I would like to publish a package only to the Integration WSUS site  from the PAS and not all other site. Is it possible?How can i proceed?

Greetings Baptiste.

It is not possible. Locally published packages must be published to the upstream server and they will replicate to all downstream servers.

Of course, if the package is never approved for groups that contain clients of those downstream servers, then it's effectively as if the package was not present.

Hello,

Ok i understand the behavior.

About Certificate,

this morning, i would like to push the certificate on the WSUS integration downstream stream server, but in the certificate client management wizard (from the PAS) i can only select the WSUS upstream server.

So ok i select it then click on next and the wizard show the list of the wsus upstream server and all downstream server. Few minute after, the certificate publication is ok on upstream server but failed on all DSS with the error message "unable to contact the host on port 139.....etc".

I think the problem come from the stringent firewall rules on both site. So if i take example of the integration wsus DSS, i will install the automation role server on it , did it help to install certificate on it or no?

Should i use a gpo to deploy the certificate ?

About Agent.

Once the automation role server will be installed on the WSUS integration DSS, i think the next step is to deploy the certificate on all integration server/workstation then deploy the solarwinds wmi/agent.

So if the wmi port are open in the local integration site(to recap port are not open between site to site, only open from machine to machine on the same site), should i only deploy solarwinds wmi provider?

thanks again.

Regards

Baptiste

but failed on all DSS with the error message "unable to contact the host on port 139.....etc". I think the problem come from the stringent firewall rules on both site.

I would agree. One or more ports required to communicate with the server to distribute the certificate is blocked.

So if i take example of the integration wsus DSS, i will install the automation role server on it , did it help to install certificate on it or no?

Possibly. The process still needs to communicate via those ports; but, if as I've read later in your post the ports are only blocked site-to-site, and not system-to-system, then a LOCAL Automation Role Server (with the correctly defined IP Subnet-based Automation Server Routing Rule) should avoid the site-to-site restrictions.

Should i use a gpo to deploy the certificate ?

That is our recommended procedure. The advantage to GPO is that everybody gets it at the same time, and new systems also get the cert as soon as they join the domain.

Once the automation role server will be installed on the WSUS integration DSS, i think the next step is to deploy the certificate on all integration server/workstation then deploy the solarwinds wmi/agent.

Deploying the certificate is a required step to facilitate installation of third-party updates.

Deploying the WMI Providers is an optional step, which facilitates remote execution of configuration management tasks, such as Update Management or using the Computer Explorer.

The order of deployment of the two objects is irrelevant as there is no relationship between the two.

Please note there is a significant difference between the WMI Providers and the Agent. Clients equipped with only WMI Providers will still need to be able to accept inbound connections on port 135 and via WMI.

Clients equipped with the Agent will initiate outbound connections to the assigned Automation Role server using port 4092.

So if the wmi port are open in the local integration site(to recap port are not open between site to site, only open from machine to machine on the same site), should i only deploy solarwinds wmi provider?

Yes. If the firewall restrictions are only site to site, and WMI ports are open at the host level, then you only need the WMI Providers and a local Automation Role server with the appropriate Automation Server Routing Rule.

Hello,

I have follow your advice and automation server is now installed on the WSUS integration DSS server.

I have made some test to publish a package, we choose to publish the pm agent package to check if replication works from USS to DSS.

The package was published on the USS, then few second after i saw it into the 3rd part view of intergration DSS.

Tell me if you see something wrong below:

As you could see in the first screen, on the USS, package state is "ready for installation", on the second screen (DSS 3rd view) show us that package state is "Files not downloaded (ready for installation)"

Why package state is different between the USS and the DSS?

Regards

Baptiste

Why package state is different between the USS and the DSS?

Because the update is not approved, and files are only downloaded for approved updates.