# Associations to Deployments Strategy Guide Deployments are the replacement for Associations as you move forward with FileWave in future. Deployments allow you to set rules for content delivery just as associations do, but deployments also allow you to group “associations” into one place to edit and organize them commonly. When using the webadmin you will notice that you can not create associations any longer, and will use deployments in their place. But, don’t worry, deployments are easy to understand and use! # How Are Deployments Different than Associations? ## What Deployments are not exactly the same as associations, but they are very, very similar. You can think of them as über-associations, or grouped associations. ## When/Why We’ll use deployments to assign content to devices, just as we would with an association. But, deployments also give us the ability to group multiple associations together in order to create simpler, easier to both find and manage content delivery rules. ## How Reference the [View - Deployments](https://kb.filewave.com/books/filewave-anywhere-help-menus/chapter/view-deployments "View - Deployments") article to see how one creates a deployment from scratch, but in the below articles you’ll also see how to use our Associations to Deployments Conversion Tool to create deployments from multiple associations and also look at the benefits of Deployments overall. ## Digging Deeper Deployments contain the same rules for content delivery as Associations do, such as: - Timing options for installation - License management (for VPP related content) - And installation method (such as Kiosk, or direct installation)
[](https://kb.filewave.com/uploads/images/gallery/2023-07/2Pyn3vK0VBevFXqE-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/IYO7eI43VFKhQVUg-image.png) |
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
Once an Association is converted to a Deployment, the Association will currently still show in FileWave Central, but will no longer be editable as an Association; the Deployment is now managing the assignment of any Filesets included.
### How Let’s look at a case study. If we were to create associations for the following 4 apps to the Windows Computers group: [](https://kb.filewave.com/uploads/images/gallery/2023-07/8uEfcfapMo7iRsYI-image.png) 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. 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: [](https://kb.filewave.com/uploads/images/gallery/2023-07/qf8cdcSh2aeNIUfM-image.png) 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. ### Fileset Grouping Deployments do not impact Fileset Grouping. Perhaps it is nice to group Filesets by type or by Vendor:[](https://kb.filewave.com/uploads/images/gallery/2023-07/q8VXsEOqgTH82eD5-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/imMVbfANNWCB6I2H-image.png) |
It is not possible to change the timings for just one Fileset within a Deployment and so that Fileset will need to be removed from the Deployment.
Associations allow the same Fileset (but differing Revision) to be associated to the same Client Group.
### Filset Timings Deployment timing options show as: [](https://kb.filewave.com/uploads/images/gallery/2023-07/GwnGhI18t2O41l1I-image.png) **All options apply to all containing Filesets**. If there was a requirement to alter one Fileset, to perhaps make it temporarily disabled, with Deployments it would involve either: - A temporary Deployment would be created to move the Fileset into, returning the Fileset back once re-activation is approved - A permanent new Deployment is created and this one Fileset will now only live within this one new Deployment thereafter - Another Deployment will be created, but the new Deployment will be 'closer' to the target device(s) and set as inactive, until re-activation is required and this new Deployment may then be deleted Associations are handled individually, as such the current association timing may be changed without any other concerns. ### Revisions Each Fileset may have multiple Revisions, but why is this beneficial? Consider the question 'How and, more importantly, when is one Revision going to replace another?' - Associations may have differing Revisions of the same Fileset Associated to the same group of devices - Deployments can only handle a single assignment of a Fileset, regardless of Revisions #### Kiosk By supplying multiple revisions to the Kiosk, users can have the ability to choose between Revisions. With Deployments, a new Deployment would have to be created to allow for each alternate Revision, whilst with Associations, all chosen Revisions may be associated to the same Client Group. #### Timed Revision Updates It is often desirable to transition between two Revisions at a chosen time, for example, out or hours. Achieving this with Associations is much neater. The same group that already has the current Association will receive the Association to the new revision. Within each Association, the time would be altered, one set as Delete and the other set as Activate. When that point in time is reached, the magic happens and the Revision on the devices is replaced. As an example, below are 2 Associations of the macOS EyeBrowse App, both to the All macOS group, but the current version 1.0 is set for Deletion at the same time that version 2.0 is set for Activation. [](https://kb.filewave.com/uploads/images/gallery/2023-07/iUoaOmF3TuSrgbMa-image.png) Again, with Deployments, a new Deployment would need to be created, just for this one new Revision. Actually 2 new Deployments!Why 2 new Deployments? A single Deployment may only handle one Fileset (regardless of Revision). The original Deployment will have no timings set, nor should it. As such one Deployment needs to be created for the Deletion and another Deployment for the Activation.
Once the target Date and Time have been reached, the additional Deployments themselves could be removed, with the Fileset being reinstated, back into the original Deployment. If you do this with many Revisions, then the quantity of Deployments becomes unwieldy, with differing Deployments handling differing Revisions. For this same example, the Eyebrowse App is contained within the Deployment: [](https://kb.filewave.com/uploads/images/gallery/2023-07/ayDC8ttTwiNl73S6-image.png) As such, new Deployments would need to be created to handle the timed Revision changeover.Original Deployment (EyeBrowse Removed) | Deletion Deployment | Activation Deployment |
[](https://kb.filewave.com/uploads/images/gallery/2023-07/0Kh8yrdCCDb60mtq-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/KX5haDWhrCG7mLuJ-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/OEgCPOLzTwGpMoRs-image.png) |
[](https://kb.filewave.com/uploads/images/gallery/2023-07/7fFuz4qpiHZZf4H5-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/Co5iLxSmxDLASsQK-image.png) |
Pro Tip: FIltering by “Type” being Kiosk or Standard is a great way of isolating like elements for combining associations into deployments.
# Should I create one, or multiple Deployments? ## What We have established in the previous article that you can combine any payloads or destinations into the same deployment if all of the metadata would be the same. For example, I want to deploy Firefox and Chrome to the IT and HR departments starting on Friday at 6 PM. Everything matches, so I can put them in the same deployment…but, should I? ## When/Why We’ll want to very carefully think about how we intend to organize our deployments, and how we’ll want to modify them in future before we can answer the above question. ## How But the answer to the question is “it depends”. It depends on what is easiest for you, the FileWave administrator. Primarily you’ll want to organize deployments based on the payload(s), or based on the destination(s), but not both at the same time. Other key differentiators are going to be the method of delivery (i.e. push vs. pull) and the platform. An example (always) works best: Let’s consider the following table of overall payloads/destinations…**Payload (Filesets)** | **Destination (Devices)** |
Google Chrome - PC (Push) | All Windows Devices |
Google Chrome - macOS (Push) | All macOS Devices |
Firefox - PC (Kiosk) | All WIndows Devices |
Firefox - macOS (Kiosk) | All macOS Devices |
Adobe Acrobat Reader - PC (Push) | All Windows Devices |
Adobe Acrobat Reader - macOS (Push) | All macOS Devices |
TeamViewer Host - PC (Push) | All Windows Devices |
TeamViewer Host - macOS (Push) | All macOS Devices |
Remember: Conversion of association(s) REPLACES them with a deployment. Always test and convert slowly to ensure you get the behavior you expect.
# Resolving Conflicts in Associations Conversion ## What The guidance we have given in other articles is about making sure metadata matches when converting associations. But sometimes, we need to convert items that don’t match in order to “fix” them. This article covers how “conflicts” are handled within conversion. ## When/Why We’ll use the conflict resolution tool to resolve conflicts, and to preview the impact of those conflict resolutions before save to ensure we make the changes we intend. The most likely conflicts are: - changing from Kiosk to Standard deployment (or vice versa) - having more than one target (not technically a conflict, but important to understand) - differences in timing options - differing payload revisions ## How Resolving the conflicts is quite straightforward. Examples are shown below, with corresponding previews that show the changes:**Conflict Type** | |
**Conflicting Installation Type** | [](https://kb.filewave.com/uploads/images/gallery/2023-07/4ylnhQjKXctFdw3r-image.png) Note that you have to choose which installation type you want to have before you can preview |
[](https://kb.filewave.com/uploads/images/gallery/2023-07/iXHgZg4uex0VHthO-image.png) And the preview shows you which association changed, and how it changed | |
**Mixing targets and/or payloads** | Technically this is not a conflict, as mixing two targets that have differing payloads simply means all payloads will be installed on all targets, so there is nothing to “resolve”. (I.e. If we combined one association of IT/Firefox with HR/Chrome, then all devices will get both Firefox and Chrome) [](https://kb.filewave.com/uploads/images/gallery/2023-07/E14NGBcOcXWYFgZ5-image.png) Notice though that in preview, we see the “added” payloads to the corresponding groups. |
**Differences in Timing** | [](https://kb.filewave.com/uploads/images/gallery/2023-07/EEa5AUgVf7edCWPA-image.png) When timing options differ in a new deployment, we zero everything out. If adding to an existing deployment, the original deployment settings win. [](https://kb.filewave.com/uploads/images/gallery/2023-07/41pMy8n5jv6Eyvaq-image.png) Note that timing option changes will show in preview too. |
**Differing Payload (Fileset) Revisions** | [](https://kb.filewave.com/uploads/images/gallery/2023-07/2ajpsAbFE0x3L22S-image.png) A single deployment can only have one revision of a payload/fileset. In the case of a conflict between revisions, you MUST choose only one. [](https://kb.filewave.com/uploads/images/gallery/2023-07/gWFf7xQiQsUVE2yY-image.png) In preview then, you will see the changed revision. |
This conversion can theoretically have an impact though when converting associations that use clones. The link being changed to the original device/device group may change the formula of the “winning” association…so we suggest you convert this type of association slowly to gauge any potential impact in your environment.
Reference the [View - Deployments](https://kb.filewave.com/books/filewave-anywhere-help-menus/chapter/view-deployments "View - Deployments") articles to see how one creates a deployment from scratch, but in the below articles you’ll also see how to use our Associations to Deployments Conversion Tool to create deployments from multiple associations and also look at the benefits of Deployments overall. # Deployments in FileWave Central (v15+) ## What FileWave Deployments (the next generation of *Associations*) are now fully implemented in FileWave Central for creation, edit and deletion. ## When/Why We’ll use a FileWave Deployment to assign content to devices, Deployments are like associations, except the metadata (rules about assignment) are stored within the deployment. This makes it very easy to add yet another app to a deployment, and have it automatically have the same settings as others (available via Kiosk automatically as an example). ## How Deployments work almost identically in FIleWave Central to how they do in FileWave Anywhere, so you might want to check out those detailed articles linked below. Deployments have three steps. Step 1 allows you to Target and Exclude devices…Step 1 defines who gets “the stuff”: [](https://kb.filewave.com/uploads/images/gallery/2023-07/AgU1YRGXS9HYesT3-image.png) Step 2 allows you to define “the stuff” that the Targets (devices) get: [](https://kb.filewave.com/uploads/images/gallery/2023-07/9VSe7N8xMBi7Bhaq-image.png) And Step 3 allows you to set options for the Deployment. In this case, we’ll publish these filesets to the kiosk: [](https://kb.filewave.com/uploads/images/gallery/2023-07/CjxrRXHckFeRQFND-image.png) Once created, deployments are stored by name, and can be edited to add other content/devices.