Plan One or Multiple Deployments

What

WeA haveDeployment establishedgroups one or more payload assignments under shared delivery rules. Put assignments together when their timing, installation method, Kiosk behavior, and licensing rules should be managed as one unit.

Decide before you group assignments

Split assignments into separate Deployments when any of these settings need to differ:

Setting	Use separate Deployments when
Assignment type	Some content installs automatically, appears in theKiosk, previousor articleexists thatonly youfor canlicense combineassignment
Activation anyand deactivation	Payloads need different start or end dates
Installation timing	Payloads need different installation windows
Kiosk rules	Items need different self-service visibility or presentation
Deployment on request	Only some payloads or destinationstarget intogroups should use self-pickup behavior
Payload requirements	Platform, Booster, or runtime requirements do not match

Fewer Deployments are easier to maintain only when the assignments genuinely share the same deploymentrules.

if

Example

all

Suppose of the metadata would be the same. For example, I want toyou 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 HostFull intoClient TWOto commonboth deployments, split by platform,Windows and wemacOS. mightTeamViewer callHost theminstalls somethingautomatically likeat this:night,

while StandardFull AppsClient PCis (Push)offered Standardthrough AppsKiosk Macat (Push)noon.

Create

one AndDeployment for Firefox,the weWindows wouldand alsomacOS createHost Filesets, then another for the two deploymentsFull (againClient becauseFilesets. weThe don’tshared wantbehavior stays together, and you maintain two Deployments instead of one per payload.

Related Content

• How Are Deployments Different than Associations?
• Convert Associations to mix platforms), and we’d probably name them something like this:
• Optional Apps PC (Kiosk)Deployments

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.