IUpdate.Approve Method (UpdateApprovalAction, IComputerTargetGroup, DateTime)
Applies To: Windows Server Update Services
Approves an update for deployment to clients and provides a deadline by when the client must act on the update.
Assembly: Microsoft.UpdateServices.Administration (in Microsoft.UpdateServices.Administration.dll)
IUpdateApproval Approve( UpdateApprovalAction action, IComputerTargetGroup targetGroup, DateTime deadline )
IUpdateApproval^ Approve( UpdateApprovalAction action, IComputerTargetGroup^ targetGroup, DateTime deadline )
abstract Approve : action:UpdateApprovalAction * targetGroup:IComputerTargetGroup * deadline:DateTime -> IUpdateApproval
Function Approve ( action As UpdateApprovalAction, targetGroup As IComputerTargetGroup, deadline As Date ) As 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.
Date by when the client will be forced to apply the update if it has not already done so. DateTime.MaxValue ndicates that there is no deadline. Specify the date in Coordinated Universal Time. The deadline applies only if the action is install or uninstall.
An 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:
You must accept the license agreement for this update before you can approve the update for deployment.
You cannot approve the update if the server is a replica WSUS server (if IsReplicaServer is true).
You cannot create a block approval to the All Computers target group.
The desired action cannot be used because a dependency has been approved for the opposite action.
The update or target group was not found in the database.
This operation requires WSUS Administrator privileges.
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 Deleting an Approval 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.
Return to top