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 Registration

Schoolyear AVD requires an App Registration to be created in Entra.

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

Dynamic Group

Schoolyear AVD requires a Dynamic 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 dynamic group per Azure tenant needs to be created when deploying multiple implementations per Azure Tenant.

This group will include any device with a name starting with syvm. Every VM created by Schoolyear AVD will have this prefix. 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.

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 Principle permissions

The Service Principle 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.

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:: The Storage account is for image building purposes It contains all the artifacts used to build exam images.

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.