Infrastructure changes

This page describes the minimum changes required to your infrastructure to make the Schoolyear AVD integration work. This document reflects the current infrastructure requirements, which are subject to change as Azure and Schoolyear AVD evolve.

This document is based on a greenfield Azure tenant. It does not take any policies or specific configurations you made into account. Specifically, this documentation cannot cover exceptions to your policies that may be required to implement Schoolyear AVD successfully.

Entra

App Registrations

Schoolyear AVD requires two App Registrations to be created in Entra.

App Registration for granting Azure API permissions to Schoolyear:

• Requires delegated User.Read permissions: basic permission required to complete Open ID Connect flow for students
• Requires native client authentication: to log in students in the Schoolyear Safe Exam Workspace application
• Requires web client authentication: to log in students in the Schoolyear Safe Exam Workspace application
• Requires an API secret to be shared with Schoolyear: basic requirement for an Open ID Connect flow

App Registration for Function App authentication:

• Requires Device.ReadWrite.All & GroupMember.ReadWrite.All permissions.
• Requires native client authentication: to allow Schoolyear to programmatically control the Function App
• Requires web client authentication: to allow Schoolyear to use the Function App

We use a second App Registration just for the Function App to reduce the scope of the *.All permissions we grant to it. Schoolyear doesn’t have any API keys associated with the second App Registration, only the Function App has access to it.

Schoolyear can then use the Functions exposed by the Function App to be able to make changes to the necessary groups & devices.

These Functions can be easily audited by your organization.

Security Group

Schoolyear AVD requires a Security Group to be created in Entra. This group holds all the Entra-joined session hosts that are deployed by the integration. This follows recommendations from the Microsoft-provided guide on configuring Single Sign-On for Azure Virtual Desktop.

Only a single security group per Azure tenant needs to be created when deploying multiple implementations per Azure Tenant.

Note

In previous versions, a dynamic group was used for this purpose. However, dynamic groups have an unpredictable delay before newly created devices are included, which could cause issues during exam deployments. To solve this, Schoolyear AVD now creates a standard security group and manages its membership through the deployed Function App.

This group is used to configure AVD not to show a prompt whether a student wants to log in to their VM. Because this prompt is only shown once every 30 days, it is no problem in AVD deployments with daily use. However, this prompt is undesirable during examination.

Function App

Schoolyear AVD needs to add and remove devices to/from the Security Group. This operation requires broad permissions. There is no way to scope Microsoft.Graph permissions in Azure to a single Security Group, so the permissions granted in this step apply tenant-wide. To minimize Schoolyear AVD’s access to your organization, the Function App is configured to only add/remove devices with the syvm prefix and only interact with the previously deployed Security Group.

The Function App contains two functions:

• AddDeviceToGroup: Adds session hosts to the security group when a student logs in. This function is scoped to the deployed group ID and only accepts devices with names starting with syvm.
• DeleteDevicesBasedOnPrefix: Removes devices with the syvm prefix. This function is also scoped to the deployed group ID.

Custom Role Definition

Schoolyear AVD deploys a custom role definition that combines the permissions of the Virtual Machine User Login and Desktop Virtualization User built-in roles. This custom role is used to grant students access to their VM with a single role assignment on login, rather than requiring two separate assignments.

MFA exception (when applicable)

Since Multi-Factor Authentication (MFA) requires students to use their phones during exams, an exception to the MFA policy is often requested by education departments.

If you enforce MFA in student accounts and want to make this exception, the following changes are required:

• Exclude the aforementioned App Registration of Schoolyear AVD from MFA enforcement
• Exclude the public IP reserved for all outgoing traffic from the AVD host pools from MFA enforcement

Azure

Dedicated Subscription

Each Schoolyear AVD implementation must be deployed in a separate Azure Subscription. The reason for this is that Schoolyear AVD requires role-granting permissions to dynamically assign students to exams. Furthermore, Schoolyear AVD will dynamically deploy a resource group for each exam. Lastly, Schoolyear AVD uses the quota available to that Subscription, which is problematic if the Subscription is used for other purposes as well.

Service Principal permissions

The Service Principal of the aforementioned App Registration requires Owner permissions in the Azure Subscription. In addition to deploying, updating and deleting resource groups and resources, it needs to dynamically grant roles to students to assign them to host pools.

Base infrastructure

During the implementation of Schoolyear AVD, the base infrastructure is deployed to your Subscription. This includes all the resources that will permanently exist, regardless of whether exams are currently active.

The exact definitions of these resources are defined in the v2-infrastructure-installation.json file available on the release page. For a visual overview, see Base infrastructure.

Some of the noteworthy resources are:

• NAT Gateway: One of the core components of the base infrastructure is the NAT Gateway. This gateway will carry all outgoing traffic from the Schoolyear AVD deployment. All the websites that students visit during their exam will be requested from the public IP address attached to this NAT Gateway.

• Key Vault: The Key Vault contains the wildcard certificate you import during the implementation.

• Storage Account: This Storage account is for image building purposes. It contains all the artifacts used to build exam images.

• Backup Storage Account: This storage account is used to backup student files upon exam deletion.

Quota

Schoolyear AVD will deploy resources in the Subscription. The quota available in the Subscription must be increased to meet your user capacity demands. See the Azure Quota page on how to plan for this.

Network peering (when applicable)

If you are planning to use an application that requires LAN access to a license server, a network peering must be configured between the network of the license server and the vnet of the Schoolyear AVD implementation.

This peering only needs to allow connections from the Schoolyear AVD vnet to the license server.

Others

DNS delegation

Schoolyear AVD requires a public domain name to host the services deployed in your Azure Subscription. This is often a subdomain of your primary domain name (e.g., schoolyearavd.school.com), but you can also choose a different or new (sub)domain name.

Schoolyear AVD creates a public DNS zone in Azure for this (sub)domain. In the parent DNS zone (e.g., school.com), a delegation record (e.g., NS schoolyearavd) must be created.

Wildcard certificate

Schoolyear AVD requires a wildcard certificate for the chosen (sub)domain (e.g., *.schoolyearavd.school.com). A wildcard certificate is required because each exam is hosted on a subdomain of the domain you configured (e.g. xxx.schoolyearavd.school.com).

Some organizations have policies against wildcard certificates because they are commonly misused. However, in this case, the wildcard certificate is used for what these are designed to do: provide SSL encryption for dynamically changing hostnames.