Configuring Jamf Teacher with Jamf School: from zero to hero

Schools can be a complex beast when it comes to technology and IT services. Some things land squarely on the IT department’s plate, others on the teacher’s table — and maybe some don’t really belong anyway.

When it comes to device management, there's normally a clear enough divide between IT and teachers. The IT department and IT admins are responsible for deploying and managing devices, and the teachers’ focus is on using the devices to help meet learning needs.

Jamf School has been designed with this in mind, providing a simple, easy to use but powerful management console for the IT admin. And classroom apps — Jamf Teacher and Jamf Student — empower teachers to support learning in the classroom without needing to worry about the “how” of the technology.

With the growth of teaching- and learning-focused use of technology, simply having a well-managed device isn’t quite enough. It’s becoming more and more essential for classroom-focused educators to have a bit more say in “how” the technology is managed or deployed.

Table of contents

• The dance of IT tickets
• Enter the EdTech
• Wait! Am I giving access to the Jamf School console?
• Creating admin roles in Jamf School
• How to be successful when creating roles in three steps
• Getting started with EdTech roles
• Adding roles
• Stacking up permissions
• User education: train the EdTech!

The dance of IT tickets

This then brings us to the great dance of IT and teachers. Let's look at a quick example of a typical school where IT has deployed iPads based on agreed scopes apps, settings, configurations etc. and manage the devices on an ongoing basis.

1. Teachers have Jamf Teacher deployed and can further guide the students devices while in their classroom.
2. The school has a project coming up that requires some amendments to the classes in Jamf Teacher; this is about device management, so it sits with the IT department.
3. Therefore a teacher reaches out to IT via a ticket to request the changes.

If the school is lucky, they might have an onsite IT admin who might just pick up that ticket within the hour. It's not uncommon however for a school to only have an IT Admin onsite and able to work on tickets for that specific school once a week or once every two weeks! This will clearly affect the plans of the classroom educator, so maybe they add “URGENT” to the ticket or contact their IT admin directly, ask for a favor, and push the ticket through.

That’s all well and good for the odd time, but now imagine that every teacher in the school is asking this of the IT admin or is sending in change requests like this on a daily basis. IT admins often don’t only manage Apple devices in schools: there are servers, network equipment, sign-in systems and printers, just to name a few other things on an IT admin’s responsibility list. Even IF the admin wanted to address all those tickets right away, there’s a good chance that they just don’t have enough time in the day with everything else they must do as well.

It's not hard to understand how regular requests like this can quickly weigh on the IT admin and how maybe those tickets become a lower priority. Especially if the IT admin hasn’t been informed and therefore doesn’t understand the impact these changes have on the classroom and the educators trying to meet their teaching and learning goals. You could easily replace a Jamf Teacher group request with app changes or redeployment requests to see that tickets can very quickly pile up in even a moderate deployment

Enter the EdTech

What is needed in situations like the example above is somebody who:

• Isn’t an IT admin
• Can support HOW devices are set up and maintained
• Has a grasp of technology in general but still has a focus on learning
• Can support the ongoing and ever-changing needs of the teachers and educators using technology in the classroom.

Having an EdTech enables common “IT” tasks to be offloaded from the IT admin while the IT admin provides more access to IT-based tools, freeing up time for the IT admin. This goes a step beyond what Jamf can already offer with Jamf Teacher. It enables that pure focus of what the MDM offers to the classroom practitioner and means they can set it up and make changes to meet learning needs, without IT admins at a top level having to worry about it.

This doesn’t mean that every teacher in the school needs to become this “EdTech” persona, but there will be natural “digital leaders” or “tech-curious” people within your schools which will spring to mind when reading this if you don’t already have a similar persona in your school already. Often this will be somebody who pushes the boundaries with the tools that the school is already using and is an early adopter when new technology is introduced into your school. What this EdTech persona looks like will be different in each school.

Wait! Am I giving access to the Jamf School console?

As an IT admin, I can understand the panic that might be washing over you as you read this. You are reading correctly: I am suggesting giving non-IT staff access to the Jamf School console. But don’t worry, its comes with limitations.

It's good practice in general, not just in education, to abide by the least privilege concept, where instead of giving an EdTech unfiltered access to the Jamf School console, you give just enough and only the permissions needed to perform the agreed task.

In Jamf School there is a concept of roles. You can have many roles; any admin can be assigned one or many roles and each role can have different permissions. That means that depending on the role assigned to your Jamf School admin, your Jamf School experience and console will look different from an admin with a different role assigned to them.

Creating admin roles in Jamf School

In order to create new admin roles in Jamf School, you will need to have full admin access to the console, so this will typically be done by the IT admin.

1. Navigate to Administrators → Roles

By default, there will be a single role named “System administrator.” This is the role that the original admin of the console gets assigned. It's best practice to leave this role alone so as not to accidentally lock admins out of Jamf School or certain features.

2. Click “+ Create role” at the top right-hand corner. In the pop-up window, give the role a name; I highly recommend using the description box to provide an intention of or workflow of the role you are creating. For example:

“Role for an EdTech who can manage Jamf Teacher settings without giving full admin access and without needing to rely on IT admins for workflows”

3. Once the role has been created, click on the “Access Rights” tab to see all of the permissions you can assign to the role. There is a list of actions and/or console areas running from top to bottom and a list of permissions running across the list. These permissions are “Read”, “Edit/Apply”, “Add/Create” and “Delete”. For some of actions or console areas you can select all four permissions, for others it's only one or two. You will notice across the top of the page a number of presets to quickly get things moving, such as “read only” to check the Read box for every permission or “collapse all” to hide all the sub-permissions

4. Once you have set the permissions as required, it's important to scroll all the way to the bottom of the page and click “Save”.

Note: If you move away from the Access Rights tab at any point without clicking save, all work will be lost.

How to be successful when creating roles in three steps

1. Scope out the workflows

To create roles for the EdTech persona and enable these tech-focused workflows successfully, there must be collaboration between the IT admin and the EdTech. Fully scope out the workflow, understand what the EdTech is trying to achieve, and document what actions and/or areas of the console IT would normally need to navigate to in order to complete that task.

If we take the “Jamf Teacher Group” role as an example again, it’s obvious that we would need to allow access for that role to be able to read, edit and maybe delete the Classes area of the console. However, depending on the workflow’s requirements, the role may also need access to the Jamf School Teacher module in Settings. Permissions can always be edited after the fact, but planning these things ahead will make for a smoother deployment of the role.

2. Watch out for dependencies

A second thing to consider is that in lots of cases, one permission will have a dependency on another permission. This can be as simple as first needing to get to the correct screen in order to navigate to the action you need! For example, if the role requires wiping the device, you first have to navigate to the device info page. If you only select the permission “Wipe Device,” you can't actually navigate to the screen to click the button. You also need read access for devices.

Other examples are less obvious, such as needing to have read access to something when accessing that data through another area of the console (we’ll see an example of this below).

3. Start with least privilege and then experiment!

Figuring out which action or area of the console you need permission for can be difficult to figure out, so there will be plenty of experimentation needed. But always use the least privilege concept to prevent giving access to something unintended. If you are not sure if you need to edit or add permissions, select one and try the workflow, if that doesn’t work, try the other. If it still doesn’t work then add both. If you are unsure don’t just select both and hope for the best, be methodical in your approach.

Getting started with EdTech roles

Below you will find permission sets for three EdTech roles that are common in customer workflows. Of course, these are just suggested permissions and you should edit these to suit your specific needs. Where applicable I have also pointed out why certain permissions have been included, where there is a dependency or where it seems confusing that a particular permission is required.

App admin

It's often the case that apps regularly change or need reassigning or deploying to different devices. Even if you use the app request feature in Jamf Teacher, it requires an admin to access the Jamf School console to approve it. The purpose of this role is to give the EdTech the ability to assign/unassign apps to groups of devices and troubleshoot app installations.

Once a role for app admin has been created, select the following permissions:

Classroom admin

Another task that often ends up on the IT admin is around changes in class membership that reflects in Apple Classroom or Jamf Teacher. This could be as simple as adding a teacher to a different class when they cover for another teacher through to creating unique “new classes” for specialist events.

In the below example, we are also giving the EdTech permissions to tackle some Jamf Parent based options but this is optional.

Once a role for classroom admin has been created, select the following permissions:

Return to Service

Return to Service is a great new iOS feature to get devices back into action within a few clicks. The only way to do this within Jamf School is through the console. They are many other people, other than an IT admin, who could benefit from having access to this workflow.

In the below example, we will also allow access to Automated Device Enrollment (ADE) profiles and the ability to reassign ADE profiles to the device before wiping. This gives the EdTech the ability, with the correct workflows in place, to not just return the device to service in its current state but completely change its configuration for the next use.

For example, if its current use case is for math and the device contains all of the required apps for that subject, it is assigned to an ADE profile called LoanMath. There is a smart group in place which, if a device is enrolled via the LoanMath ADE profile, the device becomes a member and gets all of the required apps and settings.

There is then a second (third, fourth, and so on) ADE profile called SubstituteTeacherwith a corresponding smart group and settings.

A device comes back from being on loan for a math lesson, and the EdTech knows that tomorrow the device will be used by a substitute teacher, they simply reassign the ADE from LoanMath to SubstituteTeacher before going through the Return to service workflow. Once the device re-enrolls, it will have a different set of apps and configurations than its last usage.

Once a role for classroom admin has been created, select the following permissions:

Adding roles

Once the roles have been created, they need to be assigned the to EdTech admin users.

1. Navigate to Administrators → Accounts and then click on the button with a user icon and + next to the user you want to add the permission to.

2. From here, choose the location from the drop-down menu and then the role you want to assign to that user.

If locations are used, an IT admin can assign different roles to admins for different locations. For example, an EdTech could be an app admin at Location A and a Classroom Admin at Location B, and they would see different menu items in both locations.

Assigning a role at the top level results in that role being assigned for all locations.

There are two ways to view the permissions that an admin has. The first is to navigate to the user and select the roles menu; this will show any and all roles assigned to the specific user. The second is to navigate to the role and click on the Administrators tab; this will show any and all admins assigned to that specific role.

Stacking up permissions

In many cases, an IT Admin will have multiple EdTech roles based on workflows and the EdTech will tackle more than one of these workflows. So in those cases, what are the best practices to assign permissions?

Let's take an example where an IT admin has two roles in their Jamf School instance, app admin and classroom admin. One of the EdTechs says they need to perform both app admin and classroom admin tasks.

Do you need to create a third role that combines permissions from both app admin and classroom admin? Absolutely not!

Jamf School enables IT admins to assign multiple roles to an admin; the permission set is the result of both roles combined. In the above example, assigning both the app admin and classroom admin roles to the EdTech will give them all the options, menus and tools they need to perform both workflows.

User education: train the EdTech!

With any new tool or workflow, it's always advisable to train the people that are going to be using it. This becomes much easier if, like stated above, you involve the EdTech stakeholder when scoping out the workflow. The failure or success of a project like this could depend on the training.

Training opportunities like this also allow for the following things to be addressed…

Not all “irrelevant” menus can be removed

Although setting the correct permissions within the role can and will remove a host of menus that are not needed for a workflow (which is good for keeping things simple), certain menu items cannot be removed and/or are still shown as a dependence of another permission.

As an example, in the above app admin role, the EdTech will still see “User installed” in the Apps submenu even though they don’t have the permissions to read information in this menu.

It’s a good practice to note these kinds of things with the EdTech through training. This helps them understand why it’s there and doesn’t cause confusion around it being available. It's then also good to point out…

Not to panic if you see permission denied

If the EdTech does click on a menu item not intended for them and they don’t have permission to view it, they will get presented with a permission denied screen.

This is okay and not because they’ve done something wrong. Educate the EdTech that the simplest and quickest way to get back on track is to just click on the back arrow within the browser.