Revising and Versioning Updates

Applies To: Windows Server Update Services

This section describes how to create new revisions of updates.

Revising an update

Revising an update means publishing a changed update with the same package ID. The method used for revising an update is slightly different from the methods for publishing the initial version of the update. Instead of using PublishPackage, you would use RevisePackage.

It is usually better to revise an update instead of publishing a new one when the change does not affect the update binary. This includes changing the metadata (title, description, etc), re-signing the binaries, or changing the binary setup logic. Revising will result in a much better administrative experience than publishing a completely new update. The new revision is made available automatically, and any approvals of the old revision will automatically be moved to the new revision. On the other hand, if the update binary has changed, and installing the new binary is different from installing the old one, then you should publish a new update that supersedes the older one.

You should also mark the old update as expired if you do not want customers to continue installing it. If you are an ISV creating a catalog of updates for use by other customers, you must include the expired updates in the next version of the catalog, so that customers can import the expired revision and thus be notified of the expiration.

Re-signing an update

A code-signing certificate is installed at setup time (see the topic Setting Up the Trust Relationship). If this certificate is ever compromised, you must install a new certificate, and remove trust from all clients for the old certificate. In that case, you will need to resign existing packages with the new certificate using the method ResignPackage.

Revising a bundled update

If you revise an update which is a bundled child of another update, you must revise the bundle as well in order for it to reference the correct revision of the bundled child. The simplest way to do that is to change the CreationDate of the bundle.

Superseding an update

Update A should supersede Update B if the installation of update A means that update B would no longer be needed. Customers can use either update. If both are approved and both are applicable, the client will install only the superseding update.

Example

Publishing a revised update

If you want to revise a package by changing the metadata, you should first edit the update metadata file and call RevisePackage. If you no longer have access to the metadata file, you can call ExportPackageMetadata to recreate it. The following code shows how to do this after the metadata file has been changed.

IPublisher publisher = server.GetPublisher("C:\\test\\RevisedExePackage.sdp");  
publisher.RevisePackage();  

Expiring an update

The following example shows how to expire an update.

UpdateCollection updates = server.SearchUpdates(("Exe Package Title");  
IUpdate update = updates[0];  
Update.ExpirePackage();  

Re-signing an update

The following example shows how to re-sign an update.

IPublisher publisher = server.GetPublisher("C:\\test\\exePackage.sdp");  
publisher.ResignPackage();