Provisioning and Deployment: What They Are, How They Differ

Provisioning and deployment: A lot of the time, people who work in or around IT use the two terms interchangeably. But they don’t mean the same thing.

At a high level, provisioning is the act of getting a device ready for a user. Deployment is the whole process of getting a device to a user.

Broadly speaking, provisioning entails defining the settings and software you want on the device, then implementing them (typically with an MDM solution). It is part of the deployment process; in most cases, you can’t do one without the other.

“So what?” you might ask. Why worry about fine differences in meaning when you’ve got work to do? We’d say that such distinctions are actually vital to getting that work done.

When you’re trying to explain something to an IT admin, manager, or executive—especially something as potentially complex as the deployment of Apple devices—you need to be sure that everyone involved in the project understands what you mean when you say “provisioning” versus “deployment.” Understanding that difference will help everyone communicate and think through the process.

Such clarity can also help you navigate change. Maybe you’ve previously been in charge of the provisioning process, but now you’re being asked to manage an entire deployment. Or maybe your team has grown, you no longer handle both, and you have to explain which parts of the process you want someone else to handle. Such changes require a common understanding of the terms you’re using.

So, yes, we think the difference in meaning between “provisioning” and “deployment” matters. Here’s how that difference can play out in the real world.

What Is Provisioning?

Modern provisioning starts with defining the desired settings and software necessary to meet the organization’s goals. Those calculations may require consulting with other teams outside of IT: the people team, the security team, procurement, networking, and—importantly—the teams that will actually use the devices you’re deploying.

There are three main approaches to provisioning:

Fully pre-provisioned. Devices are fully configured by IT; everything the user will need is preinstalled before they receive the device. After a device is delivered, MDM is mainly used for maintenance.
Thin provisioning (a.k.a. middle-ground or hybrid). IT pre-provisions only those settings and apps that are absolutely necessary from the moment the user receives the device. Users are responsible for things like creating user accounts; additional content may be provided via self-service.
Zero-touch. Devices are ordered and shipped directly from the vendor to the user, without any pre-provisioning. MDM is used to deliver apps and settings after the user opens the box, and that user plays a role in facilitating device configuration.

Fully provisioning devices requires the greatest time commitment from IT. The configuration steps must be determined and then repeated on every device. The other two models still require you to determine the provisioning steps, but reduce or remove the requirement for IT to configure each device directly.

Your choice among those three will be guided largely by the configuration needs you identified in that first consultative step and by what you want the experience to be like for users. (For more detail on this, see our post on managing large-scale deployments.)

Once you’ve decided on the kind of provisioning process you want to pursue, you can then set up your MDM solution to implement it. That solution should be able to deliver the settings and apps you want. In Kandji, for example, we use profiles to configure settings such as FileVault, software update behavior, network settings, pre-approving apps for full disk access using Privacy Preferences Policy Control, and pre-approving system extensions. We can use Auto Apps and other tools to deliver content. (In some cases, you’ll need to gather the necessary software installers and licenses before you proceed.)

There are some details of the provisioning process that an MDM solution can’t help with but must be figured out ahead of time.

You need to think about network infrastructure and whether it’s robust enough to handle the provisioning process. This is true for all three provisioning models, even out-of-the-box, but where that infrastructure needs to be most robust may vary.

Devices should be delivered to end users with enough charge to use them for the whole day. If you’re fully or partially provisioning devices before deploying them to users, you need enough power outlets in whatever workspace you’re using to keep devices powered on and appropriately charged. This is more complicated than providing a bunch of power strips, which may cause you to trip the circuit breakers. If you’re opening the box to provision them, you need somewhere to re-package them for shipment or storage.

Oh, and don’t forget to wipe off the fingerprints. The details are important.

Repeatability is key. Documented work instructions that tell someone—a tech or a user—how to perform the necessary steps ensure your devices are configured consistently with the added benefit of allowing you to scale up more easily.

The guiding principle in thinking through all these scenarios: You want to help the user be successful—and then get out of their way.

How Provisioning Fits Into an Apple Deployment

Deployment includes provisioning, but also everything else that happens to devices before and after that.

That starts with acquiring the devices. This is when you’re thinking through fulfillment and delivery times—from the vendor to your organization, then from your organization to the users. Your chosen approach to provisioning is the primary determining factor here. If you’re planning to deploy devices that have been fully pre-provisioned, your team may need more storage and workbench space than if you were doing a zero-touch deployment. Regardless of model, devices need to be received on a timeline that accommodates the time to provision the devices and accounts for unexpected delays.

Someone needs to work with the shipping provider to make sure all the transportation logistics—both initial reception and then re-shipment—are in place. It’s hard to provision devices that were delivered to the wrong location.

Even small-scale deployments have many moving parts, of which provisioning may be just one piece. Project management is an important factor for success, and bringing in a project manager early on will help everything stay on track.

The point is that having a holistic view of the whole deployment process can help you to break that process down into smaller, more manageable pieces that all work together. And in many ways, provisioning is the centerpiece of the bigger process.

A broad perspective will help you understand the roles that other teams could play: the technologists who think about the software to deploy, the security engineers who think about limiting attack vectors, and the logistics managers who think about moving and storing devices. All of those teams may be involved, and all need to have a common understanding of what the ultimate goal is: to help the user be successful, with minimal disruptions. Build a provisioning process around that, and you’ll be well on your way to successful deployments.

For more on the subject, be sure to bookmark Apple’s definitive guide to deployments. And check out our other posts on the topic:

About Kandji

Whatever part of a deployment you're managing, Kandji can help. The Kandji team is constantly working on solutions to streamline your workflow and secure all of your Apple devices. With powerful and time-saving features such as zero-touch deployment, one-click compliance templates, and plenty more, Kandji has everything you need to bring your Apple fleet into the modern workplace.