Managing Apple Devices in Jamf: Configuration & Deployment
By M. Crawley
A Jamf Guide for building a foundation with handling real, on-the-job tasks.
If you've read the Jamf Device Enrollment Guide, then you're ready to move on to how to actually manage Apple devices. This guide will walk you through the core management features you'll use daily, from creating configuration profiles to deploying applications.
Whether you're managing a handful of devices or hundreds, understanding these foundational concepts will help you become effective at day-to-day device management tasks in Jamf.
Jamf Management Features Overview
Once devices are enrolled in Jamf, you gain access to powerful management capabilities:
- Configuration Management: Profiles, Blueprints, and Device Groups
- Application Deployment: Remote app installation and management
In this article, we'll cover configuration and deployment. Part 2 will dive into security features like restrictions, content filtering, and remote actions.
Configuration Management
Configuration management features such as Blueprints, Profiles, and Device Groups in Jamf send instructions to Apple devices and communicate configurations that control what they can and can't do while being managed.
Profiles
A Profile is an individual setting configured to perform a specific task. For example, you can create a WiFi Profile that allows connection to a specific WiFi network when on company premises. You may also have a Restrictions profile that will be used to set restrictions on what the device is allowed to do, such as disabling app installations, camera usage, or screen recording capabilities, just to name a few.
Blueprints
A Blueprint consists of a group of profiles that can be applied to one or many devices within the company. Let's say you work at a school and there are student and teacher Apple devices that need to be managed. Since student and teacher devices require different levels of restrictions, then we would need to configure different blueprints. Not only that, but there may be students at different grade levels where restrictions may need to be more granular.
Example: School Device Management
Let's discuss how we can create configurations to properly manage school devices.
We could create a WiFi Profile for teachers-only access to a specific WiFi network, and another WiFi Profile for students-only, and we may call these two profiles Student WiFi and Teacher WiFi.
Next, we can create the following Restrictions Profiles with the configurations below and apply a few restrictions based on best practice:
Teacher Restrictions:
- Disable Installing Apps
- Disable Deleting Apps, including System Apps
- Disable In-App Purchases
Student Restrictions:
- Disable Installing Apps
- Disable Deleting Apps, including System Apps
- Disable In-App Purchases
- Disable Messages
- Disable Apple Music, Apple Music Radio, iTunes Store
- Disable Camera and FaceTime
Your options for restrictions are vast, and you should familiarize yourself with them to fully understand how much you can do with Jamf as your MDM for Apple devices.
Now that you have profiles created for the students and teachers, you have a good foundation to start building a Blueprint.
Say you're employed by a school that has distributed several iPads to teachers to facilitate their teaching activities. Given that there are profiles with configurations that fit their needs, you can simply create a Blueprint with those profiles, since Jamf profiles are modular. For example, you can create a Blueprint called Teacher iPads and assign the profiles Teacher WiFi and Teacher Restrictions. These profiles would allow all iPads inheriting this Blueprint to connect to the Teacher WiFi network and adhere to the restrictions in the Teacher Restrictions profile.
Device Groups
Device Groups can be used to group a common set of devices within Jamf. They differ from Blueprints because they offer flexibility in their configuration, whereas Blueprints are better for guiding device setup during enrollment.
Let's refer to the scenario I gave earlier, but think of a Device Group called 5th Grader iPads. If you add a new iPad to the inventory, you can apply the Blueprint called Student iPads. This Blueprint includes the Student WiFi Profile and Student Restrictions Profile. You would assign this profile to the iPad during enrollment so that it has the proper configurations. Now imagine that you receive a request to add the Canva app to all iPads being used by 5th Graders. This is where Device Groups come in handy.
Now you may be wondering, what's wrong with using a Blueprint? Well, the problem is they're not designed for dynamic changes. They're intended to be used as a setup template, so if you add a new app to the Blueprint and need to deploy to a device, you'll need to reapply that Blueprint manually, which can be disruptive. With a Device Group, you can update settings and push apps to devices at any time, whereas Blueprints are primarily intended for initial setup and aren't as flexible for ongoing changes.
Types of Device Groups
Device Groups are intended to be flexible. There are two types of Device Groups: Static Device Groups and Smart Device Groups. They both depend on how you want devices added to groups.
In Static Device Groups, you can add and remove devices from groups as you see fit. This is especially useful for testing scenarios or for creating temporary groups, such as in projects.
With Smart Device Groups, you can add devices to a group based on a specific criterion. For example, you may have a device group called "iPads running iOS 15 or earlier" and set guidelines so that devices automatically enroll in that group when they meet this criterion. It is also useful when you need to catalog devices for inventory-checking purposes. TLDR: This is a rule-based device group.
Now, let's complete the scenario above. You now have all student iPads enrolled in the Blueprint called Student iPads, but you are asked to add the Canva application to all iPads used by 5th-grade students. In this instance, you can create a Static Device Group called 5th Grade iPads and assign all the iPads being used by 5th Grade students. Once you do this, you can add the Canva app to that Device Group, which will automatically deploy the app.
Application Deployment
Another key feature of Jamf is application deployment, which lets you remotely install applications on user devices. This comes in handy if you want granular control over which applications users install on iPads and to ensure the security of those apps. It also allows apps to be attached to different Blueprints and Profiles for easy deployment.
How App Deployment Works
You've enrolled a new Apple iPad and assigned it to a Blueprint that has the apps Google Docs, Canva, Slack, and Google Meet set to install automatically. Once the Blueprint is successfully added to the device via enrollment, the apps can be automatically downloaded with no user intervention.
Let's think bigger: What if you enrolled 15 new iPads in your company's Jamf portal? Imagine how tedious it would be to download these four apps on each iPad. Not very convenient, right? In the field, you may also see simple requests asking for a specific app to be added to a group of devices. You can remotely deploy the application by adding it to the Blueprint or Device group. This makes for a convenient solution for everyone involved. And just as you can add apps remotely, you can also delete them with a few clicks, and APN (Apple Push Notification) will send the uninstall instruction to the device.
Apple School Manager (ASM) and Apple Business Manager (ABM)
Let's discuss how Apple School Manager (ASM) or Apple Business Manager (ABM) can make application deployment a breeze for users. Simply put, ASM and ABM are web portals used by Apple to help users manage their device inventory and licenses for products like iBooks and apps.
You can deploy apps by searching in the Jamf portal and selecting a device or Device Group for installation. Once the instruction has been sent, the app may be installed silently only if a license was purchased (free or paid) through ASM or ABM.
If a license is not purchased before deploying that application, the installation will prompt for user assistance since Apple will treat it as a user-initiated installation. As a result, the application will not be managed, and restrictions such as preventing app removal and other granular management functions will not apply to it.
So, word of advice: if you're asked to deploy an application that needs to be managed, ensure you purchase the free or paid license through Apple School Manager or Apple Business Manager before assigning it to a Device Group in Jamf.
Real-World App Deployment Example
Let's say Bailey from the Marketing team asks to have the SharePoint app deployed to her iPad. Be sure to start by purchasing the application license in ASM or ABM, then sync it in Jamf. Once you do this, assign the app to Bailey's iPad within Jamf. Taking this path will allow the application to install silently, without user intervention, and be managed as needed by the company.
Here's a story of my personal experience for you. A user submitted a request to install Duolingo on a group of iPads in a Device Group, let's say the group's name is Sales iPads. Since I did not have a ton of experience with Jamf, I figured, why not search the app list for Duolingo, find it, and deploy it to the Sales iPads group? And this is exactly what I did. I'll give you a second to think of two reasons why this wasn’t the best route.
To start, when you deploy apps from Jamf without first purchasing a license in ASM or ABM, those apps will not respond to management instructions or configurations. The other reason is that it will be treated as a user-initiated installation, prompting the device to perform the installation. The user who requested this was very busy and unfamiliar with this type of installation process. This resulted in the app installation bouncing between a 'Pending' and 'Installing (prompting user)' status for a number of days. In the workplace, that is not an ideal outcome. You want to have requests completed and solutions implemented ASAP without being a bother to the user.
Can you think of a better approach to handling this request?
I should've started by purchasing the Duolingo licenses through ASM or ABM, syncing them in Jamf, then deploying the Duolingo app to the Sales iPads group. This would've resulted in a silent installation without prompting the user on each device within that group. The Duolingo app would've also been treated as a Managed App, causing it to respond to management instructions such as screen time and other restrictions.
Installing apps in Jamf without first purchasing a license is not a good solution in an enterprise environment that requires application supervision. However, it is a good option if you're operating within your home lab since you probably won't be able to fully set up your ASM or ABM server.
Next Steps
Now that you understand how to configure devices and deploy applications, you're ready to learn about securing those devices. In the next article, we'll cover Jamf's security features, including passcode policies, restrictions, content filtering, and remote actions like lock and wipe.
