Tags: Landing Zones

In my previous post I talked about Landing Zones and why they are an essential part of the Cloud Adoption Framework. Following on from that post, I wanted to elaborate on some of the considerations around Windows Virtual Desktop (WVD) in particular. WVD brings with it several unique elements that benefit from additional consideration and planning – particularly when designing for Enterprise Scale. A pragmatic way of looking at this, is that if you are considering Windows Virtual Desktop, it makes sense to spend some time getting the basic foundations in place, and hopefully this post will help.

A Landing Zone should enable scalable and modular growth, by considering and designing against common design areas. Previously I covered these from a general viewpoint – but in this post I will provide some thought around WVD for each of the design areas. Whilst Landing Zones are generic and all-encompassing in their nature, the Design Areas and Enterprise Scale considerations within are extremely useful for planning and designing Azure Services – and WVD is no exception.

Just to note – my lists/thoughts/ramblings here are not exhaustive, but just designed to provoke thought, with realistic examples of the considerations that may need to be made within each area. I’ve included links to reference documentation, community articles, and other items where possible. This article particularly takes the focus viewpoint of enterprise requirements – so for some smaller or less complex deployments, some of these will obviously not be required.

Landing Zone Design Areas – Thinking about WVD… 

Enterprise Enrolment

The key here really is making sure we have a suitable Enterprise Agreement in place to support our WVD needs, both now and in the future.

• • • Agreements – To ensure we can consume the required resources for, and to support WVD. This goes beyond just hosting a workload – for example, ensuring we can consume services to support Profile Management, Networking and Security Services, and provide for any application requirements.
    • Subscriptions – How will these be structured to support business units/billing areas/regional requirements/dev/test etc? It is worth spending time planning these out to ensure they are specifically built to support growth at scale. Ensuring our plans won’t hit any limits is also worth considering.
    • Billing – Are we setup to consume WVD in a way that works for our financial needs? What about our needs in the future if we expand or change? It important here to consider any growth potential or likely changes – does the proposed design pass the “2020 test” (aka the “what if we need to scale this up/down quickly?”). Reserved instances should be considered here too.

Identity

Anyone who has ever worked on a Virtual Desktop Environment will know that identity is (quite literally) the key to everything. WVD has requirements for both Azure Active Directory, and Windows Active Directory. For WVD, we need to consider how access will be controlled and managed – and not just end user access, but also management access. We also need to ensure that our Session Host VMs can reach our Windows Active Directory Domain Controllers, so there is some crossover into other areas here.

• • • Azure Active Directory – To support users/groups that need access to WVD, and to ensure we can take advantage of all the security and authentication features in AAD. Considerations here are likely to be around MFA requirements, group management, and managing security, as AAD is the first point of authentication for WVD.
    • Windows Active Directory – We need to have Windows Active Directory available for Authentication, Group Policy, and any application authentication requirements, so this needs to be considered in any location where we may wish to host WVD Sessions. Ideally the presence of Domain Controllers in the same Region, or at the very least, network access from the Subnets WVD will reside in.
    • Management Access – How will technical staff access Session Host VMs for everyday management, or to reboot a VM should there be a failure? It is important to think here about role assignments and access levels… delegation is key!
    • Supporting Services – Have we considered if any supporting services have authentication requirements? For example – are we using Azure NetApp Files with Active Directory authentication to store user profiles?
    • Applications – Do we have any applications that require Identity Management technologies that we need to consider alongside WVD – for example applications with specific authentication requirements.

Network topology and connectivity

Networking considerations for WVD are mainly around access, and connectivity to other services (applications and supporting services), but importantly, also need to account for inter-region connectivity and provide room for growth. Given that designing for scale is a key Landing Zone consideration – it is worth spending some time planning this out for a WVD deployment. Questions around growth and scaling for all technologies in the environment is a good starting point – for example, questioning each service in use with “what if our user base halves/doubles/triples?”.

• • • Network Topology – What impacts will WVD have on our Network Topology? Have we considered the need to access backend applications across our Azure and on-premises estates? Have we considered our needs now and our potential needs in the future – thinking here about scaling! (Basic elements should be covered here – can our subnets provide enough IPs if we increase our session host count, for example?). A mapping exercise is also great option here – mapping out network paths and traffic flows for key applications that will run on WVD and ensuring the supporting network infrastructure is in place. The WVD experience estimator is useful for Client network checks.
    • DNS – DNS is critical for performant access to WVD, as Traffic Manager is involved and provides geographical routing based on the DNS lookup source.
    • Firewalling and Security – Firewall and Security implications for WVD go far beyond simply ensuring appropriate NSGs are in place. Considerations here need to be at an organisational level – and how any WVD environment will fit into requirements, and any security baselines or frameworks. Azure Policy is useful here to ensure deployed resources meet the required standards. Key considerations are around Firewalling, NSGs, Web Filtering, Traffic Analysis, access to internal resources etc. Azure network security best practises, and Safe URL list are worth referencing.
    • User access – User access is an important consideration around WVD – and specifically needs thought and planning around how users will access WVD. Will we advise users to use the HTML5 Client, the Desktop Client, or possibly an Android or iOS Client? What about unknown device types? It is worth spending some time here working on how you will communicate with and advise users, and roll out any required clients.
    • RDP Shortpath – Whilst RDP Shortpath is still a preview service at the time of writing, it has some great benefits for latency sensitive applications and input methods, therefore it could be considered as a potential future enhancement. Planning for the Networking, Public IP addressing and NSG changes required can save time in the future.

Resource organization

Organising Resources is essential for ensuring optimal deployment and ongoing management of Azure Services. Resource Organisation has implications in many areas – from everyday management, to future growth, to billing.

• • • Locations – For location it is important to consider the Azure Region that your WVD Session Hosts will run in. Usually this is a case of providing a balance between end user location and application data/backend locations. In some cases, having multi-region deployments is appropriate. It is also worth putting some thought here into whether a secondary region is needed to provide resiliency.
    • Resource Groups – Resource Groups can be used in a variety of ways, however for WVD the considerations should ideally be around ensuring appropriate levels of resource management, control, and ensuring that this follows any existing group arrangement or strategy. Most services are grouped together, and sometimes split further down by location – this also works well for WVD.
    • Business Areas – Business Areas may also need to be split into different Host Pools, across different locations, with different settings. Mapping out the Business Area requirements prior to any deployment, with a view around current and future needs is a worthwhile exercise.
    • Tagging – Tags are a great way to optimise resource management, and any WVD environment should have a tagging approach in line with the wider organizational strategy. Consider, for example, how WVD Resources will fit into the wider Azure Resources already deployed.

Governance disciplines

Governance requirements vary hugely from business to business, and workload to workload. It is also sometimes the case that various services have different ongoing management requirements that need to be adhered to. In the case of WVD it is important to consider organisational requirements, and plan how these might be applied to and controlled in WVD environment.

• • • Management Groups – Management Groups are a key part of any architecture designed for Enterprise Scale. With WVD they are a useful option for grouping WVD Resources under a management structure.
    • Security Requirements – Security Requirements should be given consideration when planning for Governance. Azure has a range of tools (Like Policy, Locks and Tagging), to ensure these are met – and various Blueprints that can help too.
    • Azure Policy – Can help to enforce standards and evaluate compliance across your estate. Azure Policy, when built into a Landing Zone, is a great way to ensure resources are deployed in accordance with organisational governance. For example, restricting deployment to specific regions, or preventing Public IP addressing.
    • Locks – This one is fairly self-explanatory – but Resource Locks can prevent accidental deletion or modification of resources, and should be considered for any critical resources.
    • Tagging – I have already covered tagging in the section above – but they are also extremely useful for Governance, ensuring Resources are categorised and managed in appropriate ways.

Well worth a look is the Cloud Adoption Framework Governance Benchmark Tool

Operations baseline

Monitoring is essential for any technical resource, whether it is on-premises or in a Cloud platform. However, with a Virtual Desktop environment like WVD, monitoring is critical. Not only for ensuring the health of the environment, but also ensuring the performance for end users.

• • • Monitoring – Azure Monitor and Log Analytics provides almost endless possibilities for working with log metrics and data. The key for WVD is identifying the key metrics and creating ways to interact with that data that provide the level of insight required by your organisation. There are some great options detailed for this – like this dashboard. 
    • Service Health – Service Health is a great way to be notified about incidents and planned maintenance within Azure. It is essential that anyone managing a WVD environment is getting alerts from Service Health. The good news – it takes only a few minutes to setup.
    • Monitor Insights – Getting Log and Performance Data out of your WVD Session Hosts, and any supporting services is critical for ensuring performance. As we all know, managing issues and providing evidence of faults or potential resolutions relies on accurate data. Getting agents and data collection setup is important, but so is identifying key metrics and technical KPIs for your environment – and then visualising the data using a dashboard, or another toolset.
    • Ongoing optimization – Ongoing optimization is an area that needs consideration for any environment built to scale. With WVD the needs are likely (in the longer term), to be around patching, application management and scaling of the environment. Considerations here need to be around how patching will be managed, how applications will be updated, and any specific requirements in terms of scaling and ongoing tweaking.

Business continuity and disaster recovery (BCDR)

When designing for scale and growth, it is vital that resiliency and continuity are considered. As well as ensuring access to business-critical resources is maintained, considerations around backups, and the need to retain data for legal purposes should also be considered. In most cases, a WVD environment will not be storing any business critical data but will be the access method for it – so usually the considerations here are around ensuring continuity, security, and regional resiliency.

• • • Local Resiliency – WVD resources should be protected within regions using Availability Sets and Zones where applicable. Consider protecting supporting services too as these are often overlooked – for example, networking links back to on-premises resources or supporting services within Azure.
    • Regional resiliency – Thanks to the flexibility of the Azure Platform, it is simple to deploy host pools in different regions and use VNET Peering to build out topologies. Consider having a host pool ready to spin up in a DR Region should there be an issue with the Primary Region.
    • DR plan – Goes without saying really – but a plan of the actions and who will action them, for invoking DR operation for a WVD environment should be considered essential. Ensuring that any DR plan will not be impacted by limitations, for example, API limits is important (WVD Specific Limits are here). (Thanks to @crod for highlighting!)
    • Backups – Backups are an essential consideration for any WVD environment. Considerations here need to be around protecting any custom images or supporting services – so that they can be protected effectively and brought up in another region should the need arise.

Deployment options

Deployment options are another area where there will be large variation in approaches between different organisations. However, considerations around deployment have implications for the whole environment moving forward – management and flexibility are impacted greatly, for example. Spending time at the start getting these elements right, and exploring the different options available, can really save lots of time in the future.

• • • Azure Portal/CLI/PowerShell/JSON/Terraform – Have we considered all available methods for deployment/ongoing management or changes to the infrastructure? If time permits have any other options, not previously tested, been evaluated? This is more for awareness – but helps to give a balanced view of available methodologies and toolsets.
    • IaC/DevOps – Could we consider an infrastructure as code or DevOps approach for our deployment? There are numerous toolsets that could assist with this, and it largely depends on organizational readiness and other methodologies already in use. As per all the points in this article, it is worth evaluating options and making decisions with long term growth and scaling in mind.
    • Disk Images – What needs do we have around updates/changes/patching to our images? Do we have a robust test plan in place, prior to rolling out any changes? How are we managing any backups for templates/images? An important consideration here for WVD is around managing applications within Images and Session Hosts – could existing tools e.g., could SCCM be used for example?
    • 3rd Party Tools – There are a number of 3rd Party tools for WVD that enhance the deployment and management process. Nerdio and NetApp VDS are potential options.

Summary

If you have made it this far down the article – congratulations! I hope this has been a helpful and thought provoking look at various areas that can be considered for the scale and growth of a WVD Environment. As always, if you have any questions, please feel free to reach out either via my contact page or via twitter @jakewalsh90. Until next time – Thanks!