Submit a ticketCall us

AnnouncementsAre You “Flying Blind?”

When it comes to your complex IT infrastructure, you want to ensure you have a good grasp of what’s going on to avoid any fire drills that result from guesswork. Read our white paper to learn how proactively monitoring your IT environment can help your organization while giving you peace of mind.

Get your free white paper.

Home > Success Center > Patch Manager > Patch Manager - Knowledgebase Articles > API Mismatch error in Patch Manager

API Mismatch error in Patch Manager


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


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


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


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