# 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)
[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/2Pyn3vK0VBevFXqE-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/2Pyn3vK0VBevFXqE-image.png) [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/IYO7eI43VFKhQVUg-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/IYO7eI43VFKhQVUg-image.png)
But deployments, unlike associations, also allow you to assign those same rules to many different filesets/payloads at the same time. And, when changes are required, a singular change makes the change for all payloads. # What makes Deployments better than Associations? ## What Deployments are new, and will replace Associations entirely eventually. But, does this make them better? Why yes, indeed it does! However there are exceptions where Associations still may be required. ## Deployments First consider deployments. ### When/Why Why Deployments rather than Associations? There are three primary improvements with deployments over associations: 1. The ability to specify Exclusions in a deployment 2. New targets/payloads can be added to existing deployments and will inherit the options 3. Neater Fileset grouping

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: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/8uEfcfapMo7iRsYI-image.png)](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: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/qf8cdcSh2aeNIUfM-image.png)](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:
[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/q8VXsEOqgTH82eD5-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/q8VXsEOqgTH82eD5-image.png)[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/imMVbfANNWCB6I2H-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/imMVbfANNWCB6I2H-image.png)
Deployments make it easy to keep Fileset structure, with the assignment of the Fileset contained within the Deployment. Without Deployments, it would be typical to have something like: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/3NapHdx82u7eG5aq-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/3NapHdx82u7eG5aq-image.png) The Default Apps Group, although desirable, has fragmented the Filesets. The latest versions of Adobe Reader DC and Google Chrome are no longer in their respective Fileset Groups. With the addition of multiple default and Kiosk Apps, this fragmentation issue is compounded and makes it harder to keep a neat Fileset structure and to find Filesets. ### Digging Deeper 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. ## Associations How about Associations? Associations stand out due to a key feature when working with Fileset timings. Imagine one of the Filesets is chosen to be set for Deletion or to be made Inactive for a period of time, but to be made Activate again later.

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: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/GwnGhI18t2O41l1I-image.png)](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. [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/iUoaOmF3TuSrgbMa-image.png)](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: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/ayDC8ttTwiNl73S6-image.png)](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 DeploymentActivation Deployment
[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/0Kh8yrdCCDb60mtq-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/0Kh8yrdCCDb60mtq-image.png) [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/KX5haDWhrCG7mLuJ-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/KX5haDWhrCG7mLuJ-image.png) [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/OEgCPOLzTwGpMoRs-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/OEgCPOLzTwGpMoRs-image.png)
[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/7fFuz4qpiHZZf4H5-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/7fFuz4qpiHZZf4H5-image.png) [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/Co5iLxSmxDLASsQK-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/Co5iLxSmxDLASsQK-image.png)
### Neatness This is a fundamental consideration of the choice between Associations and Deployments. On the one hand, Deployments are neater. Filesets can be grouped, sensibly by either vendor supplied, Fileset contents type, etc. however seen fit. The Deployment then handles the link between the Filesets and the Clients. Associations causes Fileset grouping to be dictated by the Association instead, fragmenting the Fileset structure. On the other hand, Associations keep things neat, where Fileset Timings are concerned. One single Client Group can handle all Revisions for any single Fileset or a single Fileset Association's timings can be altered, preventing the need to build out lots of Deployments. ## Conclusion Yes Deployments are better, but currently only in some instances. Each assignment of Filesets to Clients should be considered, with merits given and choices made appropriately, be that Association or Deployment. Like to see examples in action? Check out the Foundry Onboarding section on [Associations and Deployments](https://foundry.filewave.com/course/view.php?id=23), which contains a comparison video. # How to decide what is included in a single deployment? ## What So deployments allow us to put together multiple payloads for deployment in an easy way and then edit these deployment rules in bulk. Great! But, which things should I put in the same deployment? ## When/Why The question above applies whether you are creating brand new deployments, or converting existing associations to deployments. In either case, we need to answer the question, “what content belongs together?” ## How And how we evaluate this is to look at two primary things: 1. What is the least amount of work for us, the FileWave Administrator, and 2. The metadata of a deployment: 1. Licensing options 2. Timing Options 3. Delivery Options 4. Fileset/Payload Revisions 5. Destination platform Both of the above questions are broken down in the following articles referenced below. # Combining payloads into a singular deployment based on metadata ## What Every deployment has related metadata about the content being deployed. That is, HOW it should be deployed, WHEN it should be deployed, and what LICENSING options to use. ## When/Why Deployments are only effective for multiple payloads/destinations if ALL of those metadata elements match. See below for examples. ## How So, how do we make a decision here? Generally it is very easy. If **ALL** of the below are true: - If all payloads are meant to be installed by Kiosk, or conversely by Direct Installation - And If the timing options are all the same - And if the licensing options (i.e. Device Assigned) are all the same - And if the destination(s) for and the revisions of the payload(s) are all the same Then, we can combine all of these elements into the same deployment. For instance, if we want to deploy Firefox by Kiosk to all devices in Accounting and HR, then we can combine those into a singular deployment. But, if we wanted to install Firefox via Kiosk to Accounting, and via direct installation to HR, then we could **NOT** combine this payload in the same deployment. ## Digging Deeper Conversion of associations to deployments will follow the same rules…generally, you’ll combine associations into one deployment if the metadata matches, as shown below: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/JojAUCeHOxtlDDvJ-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/JojAUCeHOxtlDDvJ-image.png) These associations all make good candidates for being combined into one deployment because: - They are all direct installation (Type: Standard) - They have common timing (none actually) - They all have the same destination group/platform - VPP Apps all have the same license type (Assign to Device) - And there are no payload revision conflicts

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
So, how would we best create as few deployments as possible? - We’d likely combine Adobe Acrobat Reader, Chrome, and TeamViewer Host into TWO common deployments, split by platform, and we might call them something like this: - Standard Apps PC (Push) - Standard Apps Mac (Push) - And for Firefox, we would also create two deployments (again because we don’t want to mix platforms), and we’d probably name them something like this: - Optional Apps PC (Kiosk) - Optional Apps Mac (Kiosk) And we arranged them in that way because now we have some excellent base building blocks for adding other apps if the destinations are the same (i.e. the All groups). For instance, if we added a new installer, say MSFT Teams, then we can easily simply add it to the proper deployments, and it would be available to all of the same devices with the same options. # The FileWave Associations-to-Deployment Conversion Tool ## What We’ve covered in other articles what types of content we might put together in a singular deployment, and we’ve discussed best practices for deployments in general. But some of you may be asking: “I have 1000 associations currently, is there a way for me to convert those into deployments instead?”. And the answer, thankfully, is “Yes!”. ## When/Why You'll use the web admin Associations conversion tool whenever you want to convert previously built associations into deployments: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/5MKTXYYAClX8LFBK-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/5MKTXYYAClX8LFBK-image.png) ## How Conversion of associations is quite simple…if metadata matches, then you can simply add the associations to an existing (or new) deployment, choose to preview and save. A simple example is shown below: If metadata does not match, for instance if the timing options, or installation type are different, you’ll need to resolve conflicts to save the deployment. That topic is included in the below linked document.

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**[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/4ylnhQjKXctFdw3r-image.png)](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
[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/iXHgZg4uex0VHthO-image.png)](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) [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/E14NGBcOcXWYFgZ5-image.png)](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**[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/EEa5AUgVf7edCWPA-image.png)](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. [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/41pMy8n5jv6Eyvaq-image.png)](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**[![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/2ajpsAbFE0x3L22S-image.png)](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. [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/gWFf7xQiQsUVE2yY-image.png)](https://kb.filewave.com/uploads/images/gallery/2023-07/gWFf7xQiQsUVE2yY-image.png) In preview then, you will see the changed revision.
## **Digging Deeper** Important note: If there are timing options in the past with regard to file deletion, those “associations” will automatically become exclusions in the new deployment. You’ll see exclusions identified as an icon with a slash through it. Some additional notes regarding the preview view: - You can have a lot of records in this view depending on the scope of changes, you can scroll through to review - **NO** changes are made until **PUBLISH** is chosen from the preview page - You can cancel a conversion at any point before choosing “Publish” and no changes will be made whatsoever - There can be 4 types of changes: - No change at all - Modification of one element (i.e. timing) - Addition of an element (i.e. a payload is going to something it wasn’t going to before) - Deletion of an element (i.e. a payload is no longer going to something that it did prior) # Explanation of Clones with Deployments ## What Clones are a theoretical concept in FileWave. A clone represents a symbolic link to an actual device/device group. This article covers how clones are treated differently in deployments compared to how they are handled in associations. ## When/Why Sometimes clones are either purposefully chosen for an association, or just chosen for convenience sake by an admin. Regardless of the “why” behind this, the result is the same…the payload(s) end up assigned to the device or the device group in the real world. ## How But there is a difference in the way Deployments handle clones compared to Associations. Basically, Associations use the actual clone (i.e. they reference directly the id of the clone itself), but Deployments convert the “clone” into the id of the original object…be it a device or a device group. This conversion in deployments simplifies the content assignment, and makes more logical sense.

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”: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/AgU1YRGXS9HYesT3-image.png)](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: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/9VSe7N8xMBi7Bhaq-image.png)](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: [![image.png](https://kb.filewave.com/uploads/images/gallery/2023-07/scaled-1680-/CjxrRXHckFeRQFND-image.png)](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.