I am trying to delete the target group on downstream server manually following the way told in the link below.
When this works I would have to do that on all 18 downstream servers too.
http://social.technet.microsoft.com/Forums/en/winserverwsus/thread/4e57e3ad-a8f8-4da4-8bec-410b0180bc4c
No, you don't need to do anything on the downstream servers.
In the cited thread, the issue was that the group could not be deleted from the upstream server because there were still existing approvals for that group. The UI fails to identify this problem. The fix was to create a custom view so that those approved updates could be identified and the approvals removed for that group, thus allowing the group to be deleted from the upstream server.
In the instant case it looks like you're getting timeout errors because, before you can delete the target group, the approvals must be removed. The WSUS server is attempting to remove those approvals, but it's hitting a timeout error -- probably because of the number of approvals. If you removed the group from the upstream server with approvals assigned, then the replica server must first remove those approvals before it can remove the group. The timeout is actually occuring because of the number of update approvals that need to be removed.
2013-01-17 08:58:06.166 UTC Error WsusService.29 CatalogSyncAgentCore.ProcessTargetGroups
DeploymentSync: could not delete target group a1180ed0-8a2a-4a69-8467-6a9548c14415:Timeout expired.
The timeout period elapsed prior to completion of the operation or the server is not responding.
Change:Deleted deployment(Install) of Windows XP Update Package, October 25, 2001 by NT AUTHORITY\NETWORK SERVICE UpdateID:1847AE6D-8360-4E5A-9D15-DA82B24DEFFD Revision Number:100 TargetGroup:GIG_Clients
Change:Deleted deployment(Install) of Critical Update, November 19, 2001 by NT AUTHORITY\NETWORK SERVICE UpdateID:57A02FF3-31B4-4BE8-BCEE-33D74EBA9A18 Revision Number:100 TargetGroup:GIG_Clients
Change:Deleted deployment(Install) of Remote Assistance Connection by NT AUTHORITY\NETWORK SERVICE UpdateID:4B62AA32-52F6-4C15-B739-1C8E696EB33E Revision Number:100 TargetGroup:GIG_Clients
In this case, the better approach is:
- Remove the approvals for the GIG_Clients group from the UPSTREAM server, using the procedure described in the cited thread. Note: Depending on the number of updates actually approved for that group, it may take more than one cycle. If you try to remove the approval for too many updates at once, you'll get a timeout error when the database fails to report the task as completed before the console gets tired of waiting. I would suggest unapproving no more than a hundred updates at a time.
- After each cycle of update approval removals, synchronize ALL downstream servers so they get the update approval removals.
- Once all of the update approvals have been removed for the GIG_Clients group, and those approval change events synchronized to the replica servers, THEN you can remove the group from the UPSTREAM server, and that Delete Group event will be replicated to the downstream servers.
You cannot add/remove groups from a replica server! You can only change computer group memberships on a replica server (when using server-side targeting)
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.