Compatibility with the WSUS 2.0 API

  • Article

 

Applies To: Windows Server Update Services

Differences in running WSUS 2.0 code on WSUS 3.0 servers

In general, you can use the WSUS 2.0 API to connect to a WSUS 3.0 server, but there are some important differences.

  1. You can connect to a WSUS 3.0 server using the WSUS 3.0 API as a member of the WSUS Administrators account group or as a member of the WSUS Reporters account group, but as a member of the WSUS Reporters account group you will not be able to change settings. The WSUS 3.0 API Remoting feature makes your code more secure by allowing for the implementation of security roles. This feature does not exist in the WSUS 2.0 APIs. Therefore, you may connect using the WSUS 2.0 API to a WSUS 3.0 server as a member of the WSUS Administrators account group only.

  2. You can run your WSUS 2.0 code on a WSUS 3.0 server installation, but not on a WSUS 3.0 console-only installation.

  3. It is possible to run WSUS 2.0 code on 32-bit operating systems, but not on 64-bit operating systems. If you have installed WSUS 2.0 code on a 64-bit operating system, the API calls may not function correctly.

  4. WSUS 2.0 code is supported for connecting from a WSUS 2.0 or WSUS 3.0 server installation with a SQL Server 2005 or Windows Internal Database, but a SQL Server 2005 Express Edition database is not supported.

  5. If you have deleted the default install auto-approval rule from a WSUS 3.0 server installation, you will have difficulty running WSUS 2.0 code against the server. The IUpdateServer.GetInstallApprovalRule() method will throw a WsusObjectNotFoundException if the default auto-approval rule is deleted.

Differences in running WSUS 3.0 code on WSUS 2.0 servers

It is possible to for WSUS 3.0 servers to manage WSUS 2.0 downstream servers. However, it is not possible for a WSUS 2.0 server to synchronize from a WSUS 3.0 server that has locally-published packages. The certificate used by locally-published packages is not trusted by WSUS 2.0 servers.

WSUS 3.0 methods and interfaces that differ in behavior from WSUS 2.0

Some WSUS 3.0 methods and interfaces do not behave precisely like their counterparts in WSUS 2.0.

  1. The Delete method. If the target group to delete is nested under another user-defined target group, any computers in the deleted group will end up in the "Unassigned Computers" group. If the target group to delete has child target groups, the child target groups will also be deleted. In WSUS 2.0 target groups were not nested, so the situation did not arise.

  2. The GetComputerTargetGroups method. This method always returns “All Computers” as well as any user-defined computer target groups to which the computer belongs.

  3. The IUpdateServerConfiguration interface. The properties LogDestinations and LogLevel have been removed.

  4. The Delete method. For Scan approvals on the “All Computers” target group, nothing will be deleted.

  5. The AutomaticUpdateApprovalAction enumeration. The Scan action (only in 2.0) is ignored.

  6. The GetInstallApprovalRules method. This method will throw a WsusObjectNotFoundException if the default install approval rule has been deleted.