Submit a ticketCall us

ebook60.pngHow to be a Cisco® ASA ace

Our eBook, Thou Shalt Not Pass…I Think?! can help you overcome the challenges of monitoring and managing Cisco ASA firewalls. This eBook is a great read if you’ve been frustrated with monitoring firewalls, managing ACL configs, and troubleshooting VPN connections.

Get your free eBook.

Home > Success Center > Patch Manager > API Mismatch error in Patch Manager

API Mismatch error in Patch Manager

Overview

When you publish updates to the managed computers, an API Mismatch error displays in the SolarWinds Admin Console. 

Environment

  • SolarWinds Patch Manager is installed on a different Windows Operating System than the added WSUS

Cause 

The WSUS server and the server hosting the Primary Application Server (PAS) are running different Windows Server operating system versions. 

Resolution

In order to resolve this specific issue with the API Mismatch, an Automation Server must be installed on WSUS servers that are not on the same Windows operating system as the Primary Application Server (PAS). During the install process of the Automation Server on the WSUS, the server will be automatically provisioned with the Automation Server role.

 

Post Automation Server Installation Steps

  1. To check that the correct provisioning has occurred open regedit.exe on the WSUS server and go to: HKEY_LOCAL_MACHINE\SOFTWARE\EminentWare\Data Grid Service\Roles\Automation  
  2. Check to see if the Enabled DWORD_REG is set to 0x00000001 (1)
  3. Go to the Patch Manager Console and confirm this:
    Patch Manager(Console)>Patch Manager System Configuration>Patch Manager Servers>Management Servers>Automation Server Monitoring(tab)
  4. If at this point you do not see that the server provisioning is set correctly to be an Automation Server uninstall Patch Manager installation on the WSUS and go back through the installation steps for setting up an Automation Server 

 

Decide whether or not Automation Routing Rules are necessary

Automation Routing Rules are used to control which server is committing the action. If routing rules are not in place, the default round-robin will control where the actions are being executed from. In the further reading section below, there are more details on how these alternate roles work and how they can be controlled using the routing rules.

 

Further Reading

Automation servers can be set up for more than this purpose, further reading on additional Automation Server Roles can be found here:
Additional Automation Server Scenarios
Deploying Automation Role Servers (Thwack)

 

 

Last modified

Tags

Classifications

Public