Deployments are new, and will replace Associations entirely eventually. But, does this make them better? Why yes, indeed it does!
Why Deployments rather than Associations? There are three primary improvements with deployments over associations:
The ability to specify Exclusions in a deployment
Exclusions allow you to specify a big target group like “All Windows”, and EXCLUDE from the deployment a subset, perhaps the “Staff Windows” group as an example
Deployments are more efficient. Specifically, you can have fewer deployments to accomplish as much as many associations.
And, new targets/payloads can be added to existing deployments and will inherit the options
Note that per current release, Deployments are only available for modification in the webadmin console. So you’ll only want to create deployments for now when you are ok with editing them in this tool. Within short order, we hope to have Deployments in our traditional admin console as well.
Let’s look at a case study. If we were to create associations for the following 4 apps to the Windows Computers group:
Then that will result in 4 associations, each with their own properties. And if we want to switch them all to Kiosk, then we must find/edit them together or individually. And, if we decided to then add the BGInfo payload as well, we’d have to create another association, and edit that one too.
But, the same exact scenario with a deployment is only one entry, with multiple parts:
Therefore, we only need to edit these in one place and one time to change them all to Kiosk. This makes them more efficient, and if we want to add BGInfo to this deployment, then we can do so -- with that installation now inheriting the same rules.
For those who already efficiently use Fileset/Payload groups in associations, you may be asking “Isn’t that the same thing?”. It is, almost…even if you are already efficient with this, Deployments still bring exclusions and the ability to easily find them (by name). So, even then there is an advantage.