Schools in the District of Kassel: Managing iPads Centrally With UCS@school

In the district of Kassel, our team of 12 is responsible for the IT support of a total of 72 schools (49 elementary schools, 14 high schools, 3 grammar schools, 2 vocational schools, and 4 special needs schools) and around 27,000 user accounts (approx. 25,000 pupils and 2,000 faculty members). We take care not only of the hardware (server, PCs, iOS devices, etc.), the network, and the telephone systems, but also of the operating systems, software, and mobile device administration.
In this blog article, I would like to describe the challenges we encountered as a district with a large surface area and a multitude of small, spread-out boroughs when it came to allowing the use of mobile devices in our schools and keeping the efforts associated with the introduction and support to a minimum at the same time.

Starting Situation

Before we decided on UCS@school, most of the schools in the district were using their own solutions. Many of the educational facilities were employing a KSaN (Kassel Schools on the Net) server. These Linux computer Linux servers functioned as a firewall and DHCP server and also integrated Windows devices thanks to Samba. The announcement of the termination of the KSaN project in spring 2018 rendered development and realization of a new concept necessary.
As far as possible, the concept ought also to resolve another problem identified with the previous setup: there was no centralized domain with user administration, group policies, and role concepts as well as modular expandability. Due to the inadequate Internet connections in many schools, the education facilities often implemented their own solutions. This often involved the use of iPads, which the schools procured and set up on their own.
There were no restrictions on the Apple devices and the apps were procured from iTunes, which quickly reached the licensing limit (limited number of devices per iTunes account). However, what was lacking most of all was a standardized system for the procurement and management of mobile devices. Initial experiences with Apple Profile Manager soon revealed that the scope of functions was insufficient for our purposes and the number of iPads in use.

Requirements

In addition to professional maintenance performed by the manufacturer, the following points in particularly were on the list of requirements for a new solution: Linux based, scope of functions equivalent to KSaN server (or better), modularly expandable, support of various platforms (iOS, Android, Windows, and Linux), ease of use (e.g., via web browser), and support of role concepts and group policies.
In addition, it was important to us that we could continue to use the schools’ existing thin clients, terminal servers, and already available server hardware, that the manufacturer offers a professional service and support, and that we can administrate the system centrally (with the minimum possible effort). All the user data should remain on the district’s servers.
Of course, we also wanted to establish an MDM (mobile device management) solution that integrates well into the system. In this respect, we wanted to manage the iPads centrally, but to adapt them to the individual requirements of the respective schools at the same time. And, not to forget, of course, compliance with data protection aspects. For this reason, it was also important to us to operate an MDM software on our own servers and that everything is available from a single source.

UCS@school as a Solution

As my colleague Matthias Woede already described in his article “Development of a Central IT Structure With Integration of Local School Servers in the Kassel District – Preparation is Everything!” we ultimately decided on UCS@school as a centralized identity management system. In particular, we like the combination of centralization (operation and administration in the data center in Hofgeismar) and decentralization (we can offer individual services such as DHCP, RADIUS and SAMBA (file server) on site at the schools). In addition, it is easy to mount additional services – including the desired MDM solution.
Our clear preference was to use an MDM solution from the Univention App Center, as this guarantees simple, deep integration in the UCS IDM. There are already several different MDM systems available in the App Center. We eventually decided on the solution Relution, as, in addition to other advantages, it also offers the possibility of running the entire solution in our own data center. After just a few minor adjustments and a short test phase, we were able to go into productive operation with it in July 2018.

UCS, Relution, and Apple: How it Works

To make it easier for you to understand what it essentially came down to, I would like to explain the technical interaction between UCS and Relution in a little more detail. We operate a virtual UCS server as a master and a further UCS server (also virtual machines); we have installed Relution on one of the virtual machines. We adjusted the firewall and the routing for the connection to Apple. Each iPad contacts to the Apple server to run updates and receive push messages. The school iPads are then routed to the central MDM system, for which we had to open various ports.
In the next step, we began managing the devices with the Device Enrollment Program (DEP) from Apple. Firstly, we revised the procurement policy. The district now owns the devices.
Relution is a multi-tenant solution – that means that we have set up an individual organizational unit (tenant) on the Relution server for each school and can specify which apps and iPads belong to which educational facility. At the same time, this offers a transparent overview of how many free licenses are still available for apps and Relution licenses for iPads.

The iPads are set up in accordance with policies defined in advance. The Relution server distributes new configurations and apps via push message. In addition, we can also impose restrictions centrally and, for example, specify that pupils are not authorized to install or delete apps. The devices’ proxy server and WLAN access are controlled via the UCS management system. For the description of the servers and PCs we use a very simple and logical naming convention following this basic pattern: “Device_School_Type”.

Saving Bandwidth – Mac Minis as Caching Servers in the Schools

In order to save bandwidth, Mac minis are used as caching servers in the schools, so that the iPads do not need to retrieve their updates individually from the Internet and, in doing so, block the Internet connection. Instead, an update is downloaded once to the Mac mini, which then distributes it across the school’s local network.

Procurement of iPads via Device Enrollment Program (DEP) and Local Authority Regional Data Center

We have an Apple School Manager account via our local authority regional data center Ecom21, which has its own Apple School Manager account with the certified Apple partner REDNET AG, from which we procure iPads and licenses and which assigns them to the district (DEP – Device Enrollment Program). The license numbers are initially assigned to the DEP account and then appear in the Apple School Manager, which then assigns them to the respective school. They appear on the Relution server after the next login. A new iPad retrieves the license number when it first connects to the network. The advantage of this process is that users cannot accidentally reset all settings. In addition, theft is also completely pointless, as the device connects to the authentication server repeatedly, reconfiguring itself and rendering use outside of school impossible.

Rollout of New iPads in the Schools – Efficient Step by Step

The process here in the district of Kassel for the rollout of new iPads is as follows: We begin by finding out each school’s requirements and clarifying the technical situation on site as well as the school’s interest in using tablets in a meeting: Are broadband and school Wi-Fi available or do devices need to be operated offline? Is there a firewall? Is a procurement application necessary?…
On the basis of this information, we then set the wheels in motion for a set workflow including the processing of a checklist tailored to the requirements among other tasks. All in all, there can be up to 26 steps until the whole process from the procurement to the commissioning is complete. Depending on what the requirements are, it can be achieved in just a few weeks. We are currently optimizing this workflow with each project and adding further participants. At present, two people in the district of Kassel are responsible for the procurement, configuration, and rollout of new and old iPads.

During the changeover, we set up the new devices first and then moved on to the existing iPads. To this end, the old devices needed to be adopted on the Relution server by Apple Profile Manager. We collected them on site and configured them. The fact that the configuration and preparation of the existing iPads could be performed via Configurator2 and the caching service on a Mac mini was a practical asset in this respect.

Outlook

At present, Relution manages around 510 devices, approx. 10 are still running with Profile Manager – the rollout is ongoing.
In the next phase, we want to introduce the Relution Shared Devices mode, which allows multiple pupils to use the iPads without any concerns. Each user only sees his or her own apps – merely the device-specific configuration is the same for everyone.
In addition, there are also plans for users to be able to log on to the iPads with their UCS login data. This would mean pupils would no longer need to create their own Apple accounts, and, if required, we could also see which pupil had used the device.
Last, but not least, we want to facilitate the use of private devices and, if applicable, pupils (BYOD – bring your own device). The plan is for them to use school licenses and for login to be effected via QR codes.