One of the top features of SMS 2003 is the ability to distribute software throughout the enterprise.  In many cases this process involves multiple SMS site servers and distribution points, each with a copy of the software being distributed.  This process of moving software through the environment opens the possibility that the software could be altered in some way - either by corruption or intentional modification.

Safeguards are used to ensure the package content as delivered is the same as what was originally packaged.  This protection is achieved by calculating a hash value that represents  the package contents.  This value is stored in the database and is authoritative for the package.  When packages are distributed throughout the heirarchy and to clients this hash value is included and is used by the receiving site server/client to validate the package is correct.

Consider two site servers, Site A and Site B, in a parent child relationship.  SoftwareA is created on the central site, Site A, and distributed to distribution points at both site A and B.  This software is also advertised to clients of both sites.  In this case, a hash value is calculated to represent the package and distributed through the heirarchy as follows.

         Package source directory
         \
            Hash value is generated to represent package contents
            and is stored in the database at Site A

         /
Site A
|          \
|         Distribution Point A
|
|            When the package is distributed to a child site the hash
|            value is transferred to the receiving site for use in evaluation
|             of the received package and validation before it is accepted
|
Site B
         \
          Distribution Point B
            \
          SMS Client Computer
            
When the SMS client receives the package it will
            also receive a copy of the hash value to validate
            the package prior to running.

In the diagram above we see that the SMS client will also receive a copy of the package hash for use in validating the package prior to executing the software.  It should be noted that this only happens when the client is configured to 'download and execute' the package.  In that case the package is transferred from the distribution point to the local cache on the client and executed locally.  When this is done it is important to ensure the copied package files are transferred without change - just like with the site servers themselves, the hash helps us do that.  The following log snippet is from an advanced client that has completed downloading a package from it's distribution point and is comparing the hash value as calculated on the site server against the hash value that is calculated by the client against the same package.  These log entries come from the CAS log with debug and verbose logging enabled.

Comparison succeeds - package contents check out

Download completed for content CEN00002.2 under context System 
Hash verification succeeded for content CEN00002.2 downloaded under context System 
Download succeeded for download request {6D8FB479-F985-4D62-9884-0BA22D62E16F}

Comparison fails - package content does not match and is rejected. 

Download completed for content CEN00005.1 under context S-1-5-21-1974466101-3182592951-3542695070-500 
Hash does not match expected D173AAE91CB71C207541F3A5CE1EF359C86E44E2, actual 042F51855763F4E426CF12A945C99B2B3FF0E7B7 
Download failed for content CEN00005.1 under context S-1-5-21-1974466101-3182592951-3542695070-500, error 0x80091007 
Download failed for download request {4C272D5A-B1A8-4CFB-A5CD-61CD3F6924E0}
 

- Steve