Commercial in Confidence

FOR INTERNAL USE

AUTHOR(S) :
DOCUMENT NUMBER :
VERSION : 1.0
STATUS : Final
SOURCE :
DOCUMENT DATE : 05 May 2020
NUMBER OF PAGES : 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

Contents
1 Introduction................................................................................................
1.1 Purpose......................................................................................................
1.2 Audience....................................................................................................
1.3 Scope.........................................................................................................
1.4 Related documents......................................................................................
2 Hardware Layer...........................................................................................
2.1 Design schematic........................................................................................
2.2 Azure Subscription.......................................................................................
3 User Layer Design.......................................................................................
3.1 User Topology.............................................................................................
3.2 User Locations.............................................................................................
3.3 Logical User Groups.....................................................................................
3.4 Endpoints and Peripherals.............................................................................
4 Access Layer Design....................................................................................
4.1 Windows Virtual Desktop Brokering................................................................
4.2 Access Methods...........................................................................................
4.3 Access Criteria............................................................................................
4.4 Access Flowchart.........................................................................................
5 Resource Layer Design...............................................................................
5.1 Personalization..........................................................................................
5.1.1 Profiles.....................................................................................................
5.2 Policies.....................................................................................................
5.2.1 Active Directory Policies..............................................................................
5.3 Printing....................................................................................................
5.4 Images.....................................................................................................
5.4.1 Azure compute..........................................................................................
6 Control Layer: Infrastructure.......................................................................
6.1 Active Directory.........................................................................................
6.2 SCCM.......................................................................................................
6.3 High Availability.........................................................................................
7 System Administration...............................................................................
7.1 Administrative Consoles..............................................................................
7.1.1 Service Account.........................................................................................
8 Security....................................................................................................
8.1 Session Timeouts.......................................................................................
8.2 Antivirus Configuration...............................................................................
Appendix A Hostnames /IPs:.................................................................................
Appendix B - User Groups Detailed Requirements....................................................

05 May 2020
2 of 15
 sys_WordMark_AT
version: 1.0

For internal use

document number:

List of changes
Version Date Description Author(s)

05 May 2020
3 of 15
 sys_WordMark_AT
version: 1.0

For internal use

document number:

1 Introduction
Windows Virtual Desktop is a desktop and application virtualization service that runs on the cloud
simplifying the desktop as a service offering by removing the need to manage all of the
infrastructure services. It does this by offering the brokering, web access, load balancing,
management and monitoring services for you managed by Azure. This only leaves the image and
user management as administrative tasks to allow users secure access to their desktops in the
cloud from any machine. As at the time of writing this document WVD support Windows 10
Enterprise desktops, Windows Server and is also the only way to provide Windows 7 desktops
with free extended security updates.

1.1 Purpose
The purpose of this document is to provide detailed design and architectural guidance required to
implement a new Windows Virtual Desktops service on Azure in accordance with the HLD. The LLD
contains implementation details and options that can be used and enabled for a specific customer.

The HLD provides a high-level technical view of the service from an “outside in” perspective and
will outline all major technical decisions made for the service. The Low-Level Design(s) will
expand on this by describing the detailed configurations and settings that are required to
successfully implement these design choices.

1.2 Audience
This document is intended for Virtual Workplace engineers, architects and designers tasked with
implementing or migrating to a new solution, as well as for other Service Matter Experts (SME)
which are incorporated in the overall Virtual Workplace stack as one of its building blocks.

1.3 Scope
The scope of this document covers the following:

1. Windows Virtual Desktops on Azure

The following areas are explicitly out of scope:

1. Windows Image Creation and management

2. Virtual network peering / VPN
3. Virtual network security groups in Azure
4. Multi-factor authentication?
5. Active Directory layer
6. Azure Design Considerations

1.4 Related documents

The following best practice documentation has been used in this blueprint:

Vendor Document Name

Microsoft Microsoft Security Baselines
https://technet.microsoft.com/en-us/library/jj898540.aspx
Table 2: Related Documents

05 May 2020
4 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

2 Hardware Layer
As all the infrastructure layer is managed by Microsoft the only real decision is what sizing of VM
to use for the Virtual machine deployment in the WVD pool(s). Virtual machines used in a WVD
deployment are subject to the subscription & quota limits here https://docs.microsoft.com/en-
us/azure/azure-subscription-service-limits.

2.1 Design schematic

The Windows Virtual Desktops Service offers virtual desktops or virtual applications to Virtual
Workplace users. These desktops and applications run in a MS Azure data center(s) and are
remotely accessible from any client device via the Internet. The Virtual Workplace Service
sessions are presented to the end-user device via a secure connection. Only keyboard-, mouse-,
video- and audio signals are transferred across this secure connection, the virtual desktop or
application itself and the data stay in the datacenter.

Figure 1:

05 May 2020
5 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

2.2 Azure Subscription

The following information relates to the WVD service in Azure:

Azure Value
Subscription ID

JusticeUK.onmicrosoft.com
Tenant ID
Windows Virtual Desktop
application ID

Vnet name
Vnet address space
Images Resource Group
WVD VMs Resource
Groups
Network Resource Group
WVD Tenant Name
WVD Pool Names
VM naming conventions
OU for WVD VMs
Domain Join Account

05 May 2020
6 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

3 User Layer Design

3.1 User Topology

Understanding user requirements, locations and concurrency will help in defining the overall
architecture of the solution.

Decision Point Design Decision Notes

Total Users Production As this is a proof of concept This is the maximum number of
Environment design these decisions have not aggregate production users that
been made yet will access the WVD environment,
regardless of concurrency.
Total Users Test Environment As this is a proof of concept This is the maximum number of
design these decisions have not aggregate test users that will
been made yet access the WVD environment,
regardless of concurrency.
Concurrent Users Production As this is a proof of concept This is the approximate maximum
Environment design these decisions have not number of users that will be
been made yet accessing the WVD environment
at any given time
Concurrent Users Test As this is a proof of concept The Test environment will be
Environment design these decisions have not deployed to provide a capability to
been made yet perform test cases that reflect the
Production environment.
External User Security Multi Factor Authentication & All external users that
Requirements only accessible from UK based IPs authenticate using 2 factor
Authentication
Operating Hours Not defined yet Users can operate 24 hours a day
and 7 days a week.
Table 1 : User Topology

3.2 User Locations

The Azure Region “UK South” has been chosen as the primary region for the solution.

3.3 Logical User Groups

The current WVD implementation does not support user group assignments onto WVD Pools.
Instead users have to be entered individually either via a web GUI management console or this
can be scripted via a PowerShell script (available in the Standard Operating Procedures guide).

3.4 Endpoints and Peripherals

WVD is designed to fit the BYOD model meaning any internet connected computer can connect to
the service and use a configured virtual machine as long as the user correctly authenticates.

05 May 2020
7 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

4 Access Layer Design

In order to help in defining the infrastructure and solutions required for managing user’s access to
the new environment, it is essential to understand how users connect to the WVD environment,
how they authenticate, where they authenticate, and the relevant authentication infrastructure
such as Active Directory, RSA and Client Certificates.

4.1 Windows Virtual Desktop Brokering

4.2 Access Methods

WVD requires users to access from either a web front end
(https://rdweb.wvd.microsoft.com/webclient) or a specific RDP Client (not to be confused with
mstsc). The client can be downloaded from here https://docs.microsoft.com/en-us/azure/virtual-
desktop/connect-windows-7-and-10#install-the-client. It should be noted that when using the
client you can only subscribe to 1 tenant at a time. It is highly recommended to use the desktop
client in order to get full use of the WVD system including web cameras etc.

4.3 Access Criteria

Although network security is outside the scope of this document this is included for completeness.
There is a requirement that access to the WVD service is only available from UK IP addresses.
This is configured via a conditional access rule for the WVD application which is found within the
Azure AD Security section of the portal.

05 May 2020
8 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

4.4 Access Flowchart

The following figure depicts the process flow alongside with the used ports based on the access
methods discussed in the previous section:

Figure 2 : Access Scenario Flowchart

05 May 2020
9 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

5 Resource Layer Design

5.1 Personalization
The WVD Pools have been setup as personalized desktop pools. This means each user is assigned
a desktop on first launch and this desktop will be persistent. The user will connect to that same
WVD desktop each time they launch WVD, with all their customizations intact. OneDrive is
configured within the image, so users have access to their documents / desktop items etc.

5.1.1 Profiles

No windows roaming profiles are implemented in this WVD solution. The WVD machines are
persistent meaning all customizations will persistent on the VM between user logons.

5.2 Policies
Policies provide a user experience tailored to the needs of the user community. This section
provides discussion on the Active Directory policies implemented for the WVD workstations in
Azure.

5.2.1 Active Directory Policies

Each virtual desktop is associated with a set of Active Directory policies. These policies provide
users with an expected operating environment similar to their physical devices. As the WVD OU
exists under the desktops OU all policies that apply to desktops on the estate also apply to the
WVD workstations. An additional WVD policy has been created to apply settings specifically
required for the WVD OU to include policy requirements such as RDP printing restrictions.

5.3 Printing
It has been decided that as a security measure printing or drive mapping to the local device from
the WVD workstations should not be permitted. This is controlled via an additional AD group
policy to restrict RDP drive and printing redirection.

5.4 Images
As at the time of this document creation there is only 1 master image for use in WVD. This was
created using a sequence from the existing SCCM build process to create a gen1 VM and uploaded
into Azure. It is envisaged that for standardization only 1 master image should be used in Azure
for WVD. It is possible to update the existing master image with updates etc and then create a
new image based on this.

5.4.1 Azure compute

The agreed standard for a WVD workstation in Azure is a D2hs_v3 which consists of 2vCPUs, 8GB
RAM with a max IOPS of 3200. This machine type is not publicly available yet and so does not
appear in the list of available machine types in the WVD Wizard. The storage has also been
changed from premium SSD to standard SSD.

05 May 2020
10 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

6 Control Layer: Infrastructure

The infrastructure for the solution provides a set of common components to allow secure access
to the virtual workstations in Azure WVD. This layer is completely managed by Microsoft and as
such is outside the scope of this document

6.1 Active Directory

The existing Active Directory will be used for the WVD workstations. A new OU has been created
to store the machine objects with WVD specific policies applied at this OU level. Existing policies
for machines are applied to this sub OU from higher up the OU hierarchy. As part of the
provisioning process the above OU should be specified to ensure the VMs apply all required
policies. This process is covered in the Standard Operating Procedures guide.

A new domain controller has been setup in Azure and a new site for the Azure subnet has been
created in AD in order to increase AD efficiency.

6.2 SCCM
SCCM will be used to manage patching on the devices and allow users to install approved
applications. In order to reduce bandwidth consumption an SCCM Server) has been provisioned
in Azure as a Management and Distribution Point. Furthermore, a new boundary group has been
created for the SCCM estate and a new boundary subnet to capture all the WVD devices. This will
mean all WVD devices will install the SCCM client from the Azure SCCM server, assign it’s
management point as the Azure SCCM server and download software updates locally in the cloud.

6.3 High Availability

As the Infrastructure layer of WVD is managed by Microsoft and is a global service it has high
availability built into it and is completely managed by Microsoft. The current solution has no high
availability configured at the WVD VM level which currently resides in the UK South Region only.

05 May 2020
11 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

7 System Administration

7.1 Administrative Consoles

Decision Point Notes

Azure Portal This portal allows the management of
https://azure.microsoft.com/en-gb/features/azure- compute resources, vnets, NSGs, VPNs and
portal/ Tenant security access
Azure WVD vmanagement GUI This website allows basic management of
https://wvdmi-app.azurewebsites.net/ WVD machines such as VM assignment,
whether a user is active and also adding
users to pools

7.1.1 Service Account

The following table details the design decisions for the service accounts for the server components
defined within the Control Layer.

Access/Purpose User Name Notes

Production Environment
Active Directory Domain join for
WVD VMs
Azure WVD Service Principal

05 May 2020
12 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

8 Security

This section provides information such as session timeouts, SSL certificates and anti-virus
software

8.1 Session Timeouts

Decision Point Design Decision Notes

Microsoft Remote Desktop Session (Resource Layer)
Set time limit for active but idle ??? This determines, in hours, how
Remote Desktop Services sessions long an uninterrupted user device
connection to a session will be
maintained if there is no input
from the user
Set time limit for disconnected ??? This determines how long, in
sessions hours, a disconnected session can
remain disconnected before the
session is logged off.
Screensaver lock screen timeout 15 mins This determines how long, in
minutes, an idle session will wait
until a lock screen appears
prompting the user to re-
authenticate
Table 2: Session Timeouts

8.2 Antivirus Configuration

If incorrectly configured, antivirus scanning can adversely affect the performance of machines.
The Anti Virus on the WVD workstations is set exactly the same as a normal workstation whose
settings are already tried and tested.

05 May 2020
13 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

Appendix A Hostnames /IPs:

In all VNET subnets the following are reserved addresses from Azure:
X:X:X.0: Network address.
X:X:X.1: Reserved by Azure for the VNET router.
X:X:X.2: Reserved by Azure for gateway use
X:X:X.3: Reserved by Azure for gateway use
X:X:X.255: Network broadcast address. Azure does not support broadcast in a VNET, therefore
this address is reserved.

Network connection properties, such as IPs, DNS server IPs, should not be edited directly within
Windows VMs but in the related Azure network interface object. This is because they might get
erased during service heal when the virtual network adaptor gets replaced.

The WVD workstations will consume an IP from the vnet pool of available addresses and this
address space is provided by a DHCP service in Azure based on the vnet settings.

05 May 2020
14 of 15
 Commercial in Confidence

sys_WordMark_AT
version: 1.0

For internal use

document number:

Appendix B - User Groups Detailed Requirements

Unfortunately, group membership support for accessing WVD isn’t supported in the current
version of the service. This will become a feature later in the year and in the meantime user
administration to grant access to the WVD Pool is achieved either through re-deploying the host
pool to add additional VMs or by using PowerShell commands to add additional users to existing
spare virtual desktops in the pool. These instructions will be covered in the Standard Operating
Procedures guide

05 May 2020
15 of 15