IUpdate.Approve Method (UpdateApprovalAction, IComputerTargetGroup)
Assembly: Microsoft.UpdateServices.Administration (in Microsoft.UpdateServices.Administration.dll)
IUpdateApproval Approve ( UpdateApprovalAction action, IComputerTargetGroup targetGroup )
function Approve ( action : UpdateApprovalAction, targetGroup : IComputerTargetGroup ) : IUpdateApproval
Action that clients should perform when applying the associated update. For example, installing or removing the update. For details, see UpdateApprovalAction.
Target group to which you want to deploy the update.
Return ValueAn IUpdateApproval that represents the approval.
The value for action is not valid. Only Install, Uninstall, and NotApproved are valid values.
targetGroup cannot be null.
You can receive this exception because of either of the following reasons:
The update or target group was not found in the database.
This operation requires WSUS Administrator privileges.
This method is equivalent to Approve with DateTime.MaxValue. This method does not update the value of the IsApproved property or any other properties of this update. Use Refresh to update the properties of this update if necessary. You can approve an update for only a single action per target group. Approving the update for another action overrides the current approval.
To impose a deadline by when the action must occur, call Approve
A bundled update represents multiple child updates. The children updates may be explicitly or implicitly deployable. Approving a bundled update also approves its children.
Before approving an update for removal (setting action to Uninstall, you should call UninstallationBehavior to verify that the update is removable. The update is removable if IUpdate.UninstallationBehavior.IsSupported is true.
There are no restrictions on approving superseded updates. When you approve superseded updates, the client determines the correct update to install. This is often the safest course of action.
You can also approve different revisions of the same update for deployment to different groups; however, if one of the groups is the All Computers group, the approval actions cannot conflict (for example, you cannot approve one revision for installation and another revision for removal). You cannot approve different revisions of an update for deployment to the same group.
Approving different revisions of an update is typically done when you want to test the latest revision. In this case, you will deploy the latest revision to a test group for testing. Once testing is complete, you will remove the deployment to the test group and call RefreshUpdateApprovals to move the deployment from the older revision to the latest revision.
If a client computer belongs to multiple groups and, as a result, there is an updating conflict, the server applies a set of rules to determine what action the client should take. For example, if ClientA is in both Group1 and Group2 and an update is approved for Install to Group1 and Uninstall to Group2, the server must determine the resultant action on ClientA.
To determine which groups' actions take precedence, the server compares the priority of the groups. The actions associated with the group of the highest priority override the actions associated with other groups. If the priority of the groups is the same, then consideration is given to whether it is an install or uninstall action, as well as the type and deadline of the actions.
The server applies the following rules to resolve conflicts and determine the resultant action on clients:
The actions associated with the group of the highest priority override the actions of other groups. The deeper a group appears within the hierarchy of groups, the higher its priority. Priority is assigned only based on depth; all branches have equal priority. For example, a group two levels beneath the Desktops branch has a higher priority than a group one level beneath the Server branch.
Install actions override uninstall actions and uninstall actions override scan/detect only actions. Required installs override optional installs.
Actions that have a deadline override those with no deadline and actions with earlier deadlines override those with later deadlines.