If these are replica servers, that will definitely be a problem. If the groups were created before the servers were configured as replicas (replica servers should always be built from scratch), or if the downstream servers were taken out of replica mode to create the groups (ooops), that might explain this.There are four computer groups which are causing probably this problem. These groups have different ID's on upstream and downstream servers.
Exactly, the GroupID from the upstream server does not exist on the downstream server, and that causes an exception to be thrown.Hier one of that groups GIG_Clients.
GIG_Cients by upstream:
ID: 42F13AF7-A2BB-438F-8F3B-E935D094514AGIG_Cients by dowstream:
ID: A1180ED0-8A2A-4A69-8467-6A9548C14415So when I remove the approvals for that group GIG_Cients (with ID: 42F13AF7-A2BB-438F-8F3B-E935D094514A) on the upstream server and at end delete that group from upstream server, what would happen? The downstream server tries further to delete it's GIG_Clients group with ID: A1180ED0-8A2A-4A69-8467-6A9548C14415 which is not known by the upstream server.
You will need to take each of the downstream servers out of replica mode, remove the approvals for those computer groups, delete the computer groups, put the server back in replica mode, and synchronize to get the correct GroupID and Approvals.So how do you think to solve this problem?
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.