Download Windows Update Agent Server 2016

[Llanque Mazurek]

Beginningsometime last week (possibly on 12/26) our Windows-based User-ID agent stopped being able to query our DCs for user-to-IP mappings. The PA shows 1000s of request for IP mappings msgs with little to no response msgs from the agent. The agent server debug log shows a long queue of pending lookups with occasional WMI/Netbios access errors. PA support walked us thru a bunch of the standard stuff without coming up with a definite cause. We recreated the config, changed users/passwords, and changed settings multiple times without success.

Today, we were finally able to get the User-ID agent working again by giving the agent Domain Admins permissions. The docs say the agent requires Distributed COM Users and Event Log Readers group permissions and then: "the PAN-OS integrated User-ID agent... requires Server Operator privileges to monitor user sessions." "the Windows-based User-ID agent... does not require Server Operator privileges". As far as we can tell we have never had the User-ID agent account as a member of Server Operators and that group doesn't even seem to exist (Windows docs say it no longer exists in local, only in AD, but we couldn't find it there either).

Does anyone know of a recent update that may have broken the agent permission? I am aware of the Windows update the broke WMI from the PAN-OS User-ID agent, but we can not find anything that would have broken the Windows User-ID agent.

I'm not aware of anything having changed that would have broken this, and I have a few environments running with the Windows agent that have the latest security patches that I know don't have the Server Operator role applied to them. I'd be looking in AD to make sure that your other permissions are correct, but it's definitely a permissions issue if Domain Admin fixed things. It's also possible that someone did some security hardening on your AD nodes that stripped away permissions that would have been present by default.

Yeah, both our AD admins say it isn't there which has me a bit perplexed and we couldn't add the group to the user. When I do a 'net group /domain' or 'net group "server operators" /domain' it is not there, but 'net group "domain admins" /domain' is there.

I spent all day Thursday and today going back and forth and testing with the AD/server/Infosec admins, everyone claims nothing related has changed. Nothing shown on the Windows agent server or DCs as a recently applied Windows update. It seems like an AD policy or update that stripped permissions, but we can't find it.

What are you referring to when you say "Windows update the broke WMI from the PAN-OS User-ID agent" ? I've been keeping an eye on these issues, but my PAN-OS User-ID lookups over WMI still seem to be working.

The PAN-OS agent queries the DCs directly from the firewall using WMI or WinRM (v9.0 and later). The Sept update broke our PAN-OS agent WMI queries, we have been running v8.1 so WinRM wasn't available. I have upgraded 1 firewall to v9.1, but we have not gotten WinRM to connect yet (may be a different firewall issue elsewhere).

The Windows UserID agent runs on a separate server and queries the DCs/Exchange servers event logs for login/logout events, and directly probes clients using WMI and Netbios. The PA connects to the server and retrieves the discovered user-IP mappings. I looked at the June 8th patch problem (KB50036xx, multiple patches depending on WinOS), but didn't find any matches on the server or DC. We had to elevate the permissions on the agent service account to be able to query the DC's event logs again. Still looking but don't know why...

Historically we've used the Windows User Agent on two of our domain controllers, but today I switched to the on-board Integrated User-ID Agent and set it up, and other than a noticeable increase in CPU load on the domain controllers, everything is working great (so far ).

But they don't go on record as preferring either agent or agentless as the method in AD. Personally, I would use the installed agent whenever practical and agentless as the fallback. This distributes the work load on the process. But I recognize there there is not much practical difference between the two which is probably why Palo Alto does not have a recommendation either way.

The bandwidth between the agent and a DC is really going to depend on how busy the security log is on that DC. I've got the Windows User-ID agent running aganist 10 DC's and two exchange servers servicing about 1500 users across multiple sites.

It's tough to parse out exactly, but the DC with maybe 25 users authenticating aganist it is pulling around 40kb/sec over the WAN. There's one really busy DC that's doing 200kb/sec. That one is local to the agent, thank goodness.

One big difference between the Integragrated User-ID agent and the Windows Service is the integrated agent queires specifically for the login event-id log entries. The service-based agent grabs the full security log, which makes for much higher bw utilization.

If you don't want to install agents at your smaller remote sites (say, smaller than 100 active users), consider using the more efficient integrated agent for some of the WAN sites and a windows agent for exchange servers, and those DC's with ample bandwidth.

If you have over 140 remote DC's, that could be anywere from 5 to 15mb/sec in total on your WAN, depending on how big those remote sites are. And if you were doing your querying from a single windows user-id agent. That's probably not the way to go!

general recommendation is that for anything more than 1000 users in your network you should offload UserID service from the firewall to the agent installed on the server (do not use agentless for more than 1000 users). Way to offload your existing busy servers is to install separate a server that will be handling only UserID, or a few if one can't handle it gracefully.

Recommendation above is coming from Palo Alto Networks and is based on mp/dp resources, using agent rather than agentless is more graceful both on Windows and firewalls due to difference in how calls are made. It is just not written in manual because your mileage may vary depending on the firewall setup, you might be able to poll considerably more users in some corner cases. CPU will decrease with Agent on the Windows server as well, due to the nature of calls (RPC vs. WMI, as far as I can remember, but that needs to be checked to be sure, and CPU will decrease for sure).

I then went through all the items listed in that github page. Nothing seems to help. I do know that port 135 is open. The TCPDUMP idea showed me that its connecting just fine and not hitting any closed ports.

The windows-slaves-plugin is deprecated and should not be used. You will need to use something like the ssh-build-agent plugin and install SSH on the Windows system. Microsoft changed the way that DCOM works and the project did not want to take on the required changes (it would require significant work to update the DCOM library for the new changes). See the notice of deprecation here: WMI Windows Agents

It continues to happen. Multiple versions of Windows server. Everything will be fine for a while after a fresh install of the agent and then I will see unknown for services checks in the web interface.

When I investigate, the Icinga2 service is stopped and if I try to start it is fails. The only way around it that I can find so far is to remove the Icinga2 agent and reinstall it. Then it seems fine again for a while.

Your problem is an error in your deployed configuration. After installing the Agent there is no config deployment from master/satelite, so the service starts. After that the config is synced, but reload failed, because there is an error in your configuration. If you restart icinga will try to load the broken configuration and fail.

You can try to stop the service and delete everything under C:\ProgramData\icinga2\var\lib\icinga2\api\zones\*. After that start the service and the configuration should be downloaded from the master again.

Hi Team. I have a question. We recently upgraded our BigFix management servers to 10.0.5.50. In the downloads section, the installer for the Windows agent says it only supports Windows Server 2012 R2 and above. However, I was able to install it on a Windows Server 2012 R1 server. Does anyone know if the agent supports 2012 R1? I have a several 2012 R1 systems and need to know if I should upgrade these agents or not.

The agent runs on the endpoint you want to monitor and communicates with the Wazuh server, sending data in near real-time through an encrypted and authenticated channel. Monitor your Windows systems with Wazuh, from Windows XP to the latest available versions including Windows 11 and Windows Server 2022.

To install the Wazuh agent on your system, run the Windows installer and follow the steps in the installation wizard. If you are not sure how to answer some of the prompts, use the default answers. Once installed, the agent uses a GUI for configuration, opening the log file, and starting or stopping the service.

The installation process is now complete, and the Wazuh agent is successfully installed on your Windows endpoint. The next step is to register and configure the agent to communicate with the Wazuh server. To perform this action, see the Wazuh agent enrollment section.

Hi @aji.shinde7 ,

please take a look at the involved components when setting up APM. Are you trying to install the Elastic Agent with the APM Server Integration on a windows server or are you stuck on how to add an APM agent (e.g. Java) to your service?

In case you are trying to install the Elastic Agent, please follow the fleet managed Elastic Agent guidelines and the guide on how to add an APM Server integration to the Elastic Agent.

For adding an APM agent to your service you can follow the documentation on the specific apm agent.

The Windows agent monitors local services and reports any issues. The agent is also used with Patch Manager to communicate with the Windows Update server to request a lists of available updates for the device.

3a8082e126