Shared Device Management: May Sprint Update
May 2025
Welcome to the latest update on the Shared Device Management (SDM) project.
Summary of May sprints
In May, the project team focused on:
-
completing the Role-Based Access Control (RBAC) model
-
beginning enrolment work in the visiontype (a high-fidelity prototype used to communicate and align on future experiences)
-
continuing the ‘As Is’ mapping of MPLS and MDDS
-
iterating on Version 1 of the ‘As Is’ service blueprint
-
documenting our file and print management approach when using Microsoft Intune for device management.
We’ve made solid progress. The RBAC model is now configured within the visiontype, though we encountered challenges in aligning administrative roles and permissions within Microsoft Intune.
To address this, we’ll hold a workshop with a Microsoft consultant to review our solutions and explore alternatives.
Next sprint, we’ll configure the visiontype to reflect the needs of different user groups. This will support demos and feedback sessions with IT teams.
Additionally, our research into current device management practices across the university - especially in MPLS - has informed updates to the ‘As Is’ service blueprint.
Enrolment
Watch the below video where Matt explains how we’ve set up automatic enrolment for Windows devices using Microsoft Intune.
13455 - Set up Automatic Enrolment for Windows Devices.mov
While our initial Intune rollout focuses on Windows, we’re also evaluating support for MacOS.
"This sprint, I explored Intune’s capabilities for Mac enrolment, particularly through Apple School Manager. Successfully enabling automated device enrolment is a key first step toward a streamlined experience for Mac users." - James Robson
Research with the Maths, Physics and Life Sciences (MPLS) Division
As with other divisions, we mapped a sample of MPLS departments to understand current service models. The table below highlights commonalities and differences across departments.
| Specific to Department A | Specific to Department B | Common to both | |
|---|---|---|---|
|
Large number of student laptops – and most have admin rights: difficulties with moving to centralised model of devices management. |
Pressure from external security audits: device management tooling and practices need to be improved. | Lack of clear information, timelines and technical engagement on central projects: also mentioned late discovery centrally provided tools or services. | |
| High volume and complexity of course-specific software: more than 40 courses, each needing multiple software packages and dependencies tailored to specific teaching modules. Packaging these requires significant effort and subject matter expertise. | High-security project requirements: projects with commercial partners necessitate very high security standards for device management–hard to meet with current tooling. | Lack of clarity and practical access to central Microsoft platforms like EntraID: unsure what these tools can do and lack the access or information needed to experiment or plan their adoption. | |
| Annual device wipe and re-imaging cycle: due to frequently changing software requirements for teaching labs, there’s an annual task to completely wipe and rebuild hundreds of machines. | Current deployment tool and enrollment into on-prem AD domain needs urgent replacement. | Need to retain a degree of local control and administrative capability within any central device management solution: concerns exist about who else might have administrative access to their managed devices if control isn't sufficiently devolved. | |
| Dependence on Altiris for disk imaging and pushing software: The potential need to move away from Altiris requires reconstructing their package library. | Limited software stack management resources: relies heavily on a single individual | Remotely managing devices once they leave the local wired network or are used remotely is challenging: gaining visibility and pushing updates or software becomes significantly harder–particularly relevant for laptops and BYOD devices. | |
| Incompatibility with central AD/cross-realm trust: departmental Active Directory setup is not connected with central AD via a cross-realm trust, partly due to concerns about potential SSO disabling for users with frequently renewed contracts. They are unsure if EntraID would allow the flexibility needed for their user types. | Currently allow many end-users admin rights to install some custom software–poor security stance: centralised deployment solution & other tools could mitigate risk. | Need an effective, potentially centralised, method for pushing out software packages to devices: Dept B wants a self-service catalogue for users to install approved software. Dept A wants a cloud-y solution to store and deploy their numerous bespoke packages. | |
| Lack of awareness of central IT offerings: unaware of existing central IT services like Google Workspace, highlighting a gap in communication about available tools. | Multiple monitoring tools: overlapping but also distinct functionalities; issues with usability, performance overhead, and cost. Would prefer fewer tools. | Better tools needed for visibility (monitoring) and reporting on the security stance of their machines. | |
| Wants a tailored service catalogue: specific need identified for a service catalogue of tools and services tailored to the needs of IT staff within units. |
Meeting Cyber Essentials certification standards is a key strategic requirement: impacts device management, including the need to account for personal devices accessing university data. A comprehensive central solution would be ideal for achieving this. |
Need remote wipe capabilities: especially for laptops that may be lost or stolen or contain confidential data. | |
| Policy management shift: understanding that Microsoft considers traditional Group Policy obsolete and are aware they will need new systems (EntraID) for policy management. | Concerned about cost: particularly about future high costs for central services after initial funding periods end. | ||
| Need improved asset tracking: in current asset catalogue (in Help Desk tool), tracking device ownership changes after initial deployment is not possible. |
We also developed empathy maps (see below) to capture the perspectives of those managing device services within teams. An empathy map is a visual tool based on research data and is used to understand a user's thoughts, feelings, behaviours and needs. It has four quadrants for what a user Says, Thinks, Feels, and Does. It is used to help teams gain a deeper insight into user perspectives and motivations when designing and building a product.
Divisional Department - As Is - Empathy Map Department A
Divisional Department - As Is - Empathy Map Department B
This analysis will feed into a broader discovery report to be shared once completed. In the meantime, contact James Cox or Lawrence Richards if you'd like more details.
Service Blueprint
One key output this month is a simplified service blueprint illustrating the end-to-end device management lifecycle.
Service Design Blueprint Diagram
This artifact highlights shared steps taken by IT teams university-wide - even where local processes vary. It will help inform proposed changes and assist with onboarding and documentation.
What have we learnt in May?
-
Our user research surfaced several recurring themes, which we’re consolidating into a single summary document (discovery report) for wider sharing by the end of June,
-
Managing a team with part-time availability for the project presents challenges. We’re exploring ways to better support staff balancing project and non-project responsibilities.
What’s coming up in June?
We’ve outlined what a Minimal Viable Product (MVP) might look like. An MVP delivers core functionality with enough value to gather user feedback and iterate quickly - central to Agile and lean approaches.
In the next two months, we’ll focus on delivering the above MVP.
Other priorities include:
-
Further refining the ‘As Is’ blueprint with MPLS findings and inputs from other divisions
-
Finalising the file and print solution requirements and presenting them to the project’s new technical governance board
-
Completing the first draft of our discovery report, which will guide decisions for both product and service design
We hope this update provides a clear view of our May progress. We’ll return next month with updates from the June sprints.
Questions or interested in joining our next sprint review?
The next sprint review is taking place on Wednesday 18 June, 14:30–15:30, email us to join.
Email: shared.infrastructure@admin.ox.ac.uk
If you’d like to receive these updates directly into your inbox, you can sign up below.
