On April 28, the event Microsoft meets Community: Windows Virtual Desktop took place. This was originally planned as an in person event hosting 120 attendees. Due to COVID-19, it unfortunately had to be transformed into a virtual event. It did however, turn into a huge success! With 2236 registrations and approximately 1200 live attendees! 
I had the privilege to present the topic "Dealing with application landscapes on WVD, current and future, together with Micha Wets". We had a blast presenting on WVD, MSIX app attach, FSLogix and Azure DevOps CI/CD pipelines! Today, all content of the event has been published! Videos and slide decks of all sessions are available to everyone! Watch our session here! and get out slide deck here! 
For the full set of all videos and slide deck visit the this page: We want to thank everyone who attended our session. Two weeks ago, on April 30, Windows Virtual Desktop Spring Update 2020 Public Preview was released! A huge jump forward for WVD! If you missed those announcements, check out my two previously published articles: The next big innovation in Windows Virtual Desktop is here! Migrating your existing WVD Workloads to WVD Spring Update! In this article I want to highlight a different use case, using WVD to provide your (customers) administrators a secure management server accessible from anywhere using any device. If you are running any resources in Azure, there is a good chance that one of those resources is a Management Server / Jump Host or whatever you want to name it. Such a server is used as central management for administrators to access admin tools like Active Directory Users & Computers, DNS, Group Policy, other MMC Snap ins and any other 3rd party vendor management consoles. It is also often used a single point of entry to RDP "jump" into other servers. Why is this? When organisations move resources to the Public Cloud, in this example Microsoft Azure, the first thing you need in Azure is Networking & Storage. In most cases expanding a current (on premises) Active Directory Domain (ADDS) is the next step to support Domain Services for Azure resources. Or, you might be implementing Azure Active Directory Domain Services (AADDS) or Azure Active Directory only. Having either of these services available in Azure allows you to deploy Domain Joined Application Servers, File Servers, Database Services et cetera. As you move more resources to Azure, the need for a centralized management server grows. In many cases you already have such a management server on premises or at a hosting facility. A couple of questions: How are you allowing access to that management server? Using a VPN? Published by an RDS/Citrix/VMware platform? Is it secured by Conditional Access & MFA? Can administrators access it on any device? Why not leverage the Windows Virtual Desktop platform in stead? Use a centralized Management Server / Jump in Azure and publish it to your administrators, applications vendors, external contractors using Windows Virtual Desktop! This allows secure access using any device from any location! Using an RDS deployment (on premises, hosted or in the Public Cloud) you can of course achieve the same the goal. For example if you have an RDS deployment in your environment that you use to publish applications and desktops to end users, it makes perfect sense of course to re-use that platform for administrators to access a management server. But if you don't, setting up a full RDS Deployment just for remote management only is not that cost-effective and by default it does have the security needs we require today like for example Conditional Access, enforced MFA et cetera. Sure, you could also just deploy an RD Gateway Server with an NPS Server and MFA Extension. I wrote about this back in 2017 in the article Securing RD Gateway with MFA using the new NPS Extension for Azure MFA! and I have seen a lot of organizations successfully use this approach. Also remember that using RDS requires the purchase of a RDS Client Access License. With WVD, and especially with Spring 2020 release, I believe its time to move on and start leveraging the latest technologies! Even if you do not use the WVD platform right now, if you have the need for a secure management server in Azure, leveraging WVD makes total sense! And if you do already have WVD for other use cases, re-use it and eat you own dog food! So, how do we get started? Deploying a WVD Workspace including Host pool and AppGroup for the purpose of publishing a Management Server is similar to deploying WVD for any other purpose. Your deployment options are as follows 
To make sure name of the WVD Workspace meets the overall naming convention I'm using for other Azure Objects, I define the WorkspaceName as follows. 
Next, we create the Host Pool. We need a couple properties to define the friendlyname, description, hostpool type and load balancing type. 
Again, to make sure we comply to a generic naming convention we define the host pool name as shown below. For the Host Pool load balancing type we select Pooled since multiple Administrators will be sharing sharing a pool of x number of Management Servers. We define the load balancing type as BreathFirst so that sessions are distributed evenly across the VM's we publish as Management Servers as part of this host pool. 
Breadth-first distributes user sessions across all available session hosts in the host pool. Depth-first load balancing distributes user sessions to an available session host with the highest number of connections which has not reached its maximum session limit threshold. More info: https://docs.microsoft.com/en-us/azure/virtual-desktop/configure-host-pool-load-balancing Next, we define the creation of a WVD App Group. Again we define the usual properties like name, location, friendly name and description. 
For the property applicationGroupType we choose "Desktop" since we are publishing a Full Desktop session towards the management server. The other option is RemoteApp which allows us to publish individual applications. For the property hostpoolarmpath we provide the resource ID of the hostpool we had create earlier. The screenshot below shows the list of variables used to give you an idea what was specified. 
STEP 2 Creating the Management Server VM Since we now have completed the JSON code to create WVD backplane components, lets cover the creation of the Management VM itself. There are guides available online that cover the creation of a VM in Azure using JSON. Therefor, I will not duplicate that content. A good place to start is Create a Windows virtual machine from a Resource Manager template and Virtual machines in an Azure Resource Manager template. Also, if you are looking for a simple, yet fully working ARM Template check out this GitHub location Very simple deployment of a Windows VM. In my case, I have reused an existing ARM template we use to deploy a new vanilla VM to Azure inside the specified Subset and using the specified naming convention. On top of that I like to use the Domain Join Extension. This allows me to join the VM to a existing domain in the OU that I specify. More into of the extension can be found here on Github: Joins an Azure virtual machine into an AD Domain by using JsonADDomainExtension extension In most case, you will not want to deploy a vanilla Windows Server 2019 or Windows 10 Enterprise Multi-Session VM. Instead, it's convenient to create your own Template Image in Azure first. You can do that by deploying a new VM in Azure, Windows Server 2019 or Windows 10, and once that is complete install all the tools you want to have on the management server. For example you might want to install the RSAT tools and any other 3rd party management tools you want to allow administrators to leverage. If you select Windows Server as your operating system for a WVD Template Image make sure you install the RD Session Host role, otherwise the WVD deployment will fail. For Windows 10 Multi-Session, this is not needed. Also, using Windows Server requires an RDS Client Access License where Windows 10 Multi-Session does not. Once you are done customizing the VM you need to sysprep and generalize the VM and capture it to a Template Image. Note that the actions below result in the VM object that you used to create the template image, becomes unusable. Therefor you might want to take a snapshot of backup before starting the starting Sysprep and capture process. For instruction on how to sysprep and generalize, follow this guide Create a managed image of a generalized VM in Azure And finally, to create a Template Image object we capture the VM to a Template Image. To do this, select the capture option on the VM and specify a Tempate Image name and Resource Group location. 
STEP 3 Have the VM add itself to the freshly WVD host pool During step 1 we created the JSON code code create the WVD Workspace, Host Pool and AppGroup. During step 2 we talked about creating the JSON code to create a domain joined VM, optionally based on a Template Image. Its now time to bring it all together! Lets cover the most critical piece, automatically adding the freshly deployed VM to the brand new hostpool we deployed. Of course we could go ahead and use the WVD Management options on the Azure Portal to add the new VM to the new Host Pool. In stead, lets cover how to automate that part and have the VM join request a new registration key and using that key add itself to the Host pool. I selected ARM PowerShell extensions to perform this action. Main reason is that this allows me to re-use that same PowerShell script when expanding the Host Pool with additional servers using ARM and even leverage it as a way to (re)register VM's as part of troubleshooting steps in the future by manually kicking of the same script. 
To have the script support a variety of different use cases it accepts the following 10 parameters to define how the host adds itself to the existing host pools and what other optional configurations are performed Next, the script authenticates using the Service Principal account and checks for existing registration info. If registration info for the Host pool exists, it grabs the corresponding token and if not, it creates a new registration info and collects that token. 
Next, the scripts downloads both the WVD Agent and Bootloader and silently installs it on the WVD Session Host providing the token from the previous step. 
Optionally, the WVD Host can set itself in drain mode by specifying the DrainMode parameter. For the purpose of this Management Server it's most likely not needed, but this allows us to re-use this script to add additional WVD Host servers to a production WVD Host pool which we do not want to take in production right away. E.g. if you are rolling out a new Template Image version and want to switch over later during the evening or a different maintenance window. And Finally, the script (optionally) associates the AppGroup with the Workspace. This is optional and particularly handy when the script was part of a full JSON Deployment in which a new Workspace and AppGroup were also created. STEP 4 Deploying the Custom JSON Template Let's now take a deploying in an Azure Subscription. We perform a new custom deployment in our Subscription. and deploy it to a dedicated Resource Group. 
As stated before, I'm reusing an existing JSON template we also use to deploy new vanilla VM's in Azure. And we have added the creation of a Workspace, Host pool and AppGroup to is. We also added a new PowerShell extension to run the PowerShell Steps on the deployed VM as outlined in step 3. Below is a snippet from the JSON code to give you an idea how the PowerShell Extension is launched as part of the ARM deployment. 
In order to collect a couple of parameter to pass to the PowerShell extension, we collect them as part of the JSON template. And after that we kick off the deployment… 
STEP 5 Taking a look at the end result The entire JSON template only took 11 minutes to complete! This includes the creation of the domain joined VM, all the WVD backplane components ( workspace, Host pool, AppGroup) and adding the VM to the WVD host pool! 
Below is what it looks like from a Deployment overview as well as from a Resource Group overview with the created Azure objects. 
The template created a WVD Workspace and performed the association with the created AppGroup. 
And the Host Pool is created with the Management Server added and available as well. 
Ans also, the VM was joined to the domain inside the designated OU we specified as one of the parameters. 
So, we have deployed a secure and easy to access management server published via WVD and accessibly anywhere using any device in ~11 minutes! Lets see the end result! When we log on to Windows Virtual Desktop, in this case using the Windows Client, we have the Management Server available with all the admin tools we need! 
And of course we have that same management server available at our finger tips on any other OS as well using the Remote Desktop App from the various AppStores, including a Web Client based on HTML5. 
To conclude: In this article we talked about using a centralized Management Server / Jump in Azure and publishing it to administrators, applications vendors and external contractors using Windows Virtual Desktop! This allows secure access for management purposes using any device from any location! Regardless if you are already using WVD for other purposes or not, I can recommend using the service to provide easy and secure access, including conditional access, to a management server without the needing a VPN. Originally posted here: https://www.linkedin.com/pulse/using-wvd-provide-secure-easy-access-management-server-freek-berson/ So, Windows Virtual Desktop (WVD) Spring Update (Public Preview) is out as of last week! In case you missed it, on the day of the launch I published an article covering my experiences of testing WVD Spring Update in private preview! I talked about the top 10 things that stand out. Catch the article here: The next big innovation in Windows Virtual Desktop is here! As discussed in the article mentioned above, WVD Spring Update makes deploying and managing Windows Virtual Desktop a lot easier because there now is full integration in the Azure (Resource Manager) Portal! Since the first release of WVD saw the light on September 30 of last year, many organizations have already deployed it and have it running in production. I myself have helped at least a dozen of organizations with architecting and implementing and many of them are using it in production right now. So, the question arises, how can we start to manage existing WVD Workloads with the new WVD Spring Update Azure Portal Integration? First of all; Microsoft is also working on a set of PowerShell Cmdlets for the Az PowerShell module that can be used to migrate an existing Host pool including hosts from WVD Fall 2019 to WVD Spring 2020 update. I have already seen private preview information on this and it looks very promising! If the Cmdlets become available in public preview I will share it here. In the mean time, this article explains how to migrate your workloads today! Also, it is a good exercise to perform migrations using the steps explained in this article as it allows you to get familiar with the new components, PowerShell Cmdlets, ARM code and so on. This article talks about migrating your existing WVD Workloads to WVD Spring Update! Before we start it's important to realize what WVD Spring Update exactly is. It is not "just" a new Management Console for WVD. It all about making WVD a 1st Party application in Azure and as a result some changes to the WVD Service were needed. Below is a quick summary of the most important changes. Again, for a full list and more detailed information, check my previous article referenced in the first paragraph. - WVD Backplane components are now ARM Based and manageable and visible in your Azure Portal. - RBAC for WVD is now based on the Azure RABC model - PowerShell Cmdlets are now integrated in AZ PowerShell - The hierarchy of the WVD Backplane components changed To answer the most important question; Can existing WVD Deployments and resources be instantly managed using the new Spring Update Azure Portal integration? The short answer is no. Does that mean we need to start entirely from scratch? No again! It comes down to migrating your WVD Host Servers from WVD current release to WVD Update Release. This article takes you through these steps. Migrating to Spring Update (even with the upcoming migration Cmdlets) basically comes down to 4 main steps: STEP 1 — Duplicating existing WVD backplane configuration into WVD Spring Update In this step we are going to duplicate existing WVD Tenants, Host Pools and Applications Group into the WVD Spring Update. Basically, we are creating a second WVD Deployment fully separated from the existing WVD Deployment. Depending on the size of your existing WVD Deployment you can perform this manually using the WVD blades in the Azure Portal, by using JSON Templates, or by using PowerShell to export and import the configuration. In this article we will use PowerShell to automate the duplication of a Tenant with a Host pool and AppGroup. And we'll also briefly touch on JSON and VD blades in the Azure Portal. STEP 2 — Moving your existing WVD Hosts to WVD Spring Update In this step we are moving WVD Hosts from the existing WVD Host pool towards the new Host pool in WVD Spring Update. This step can be performed with a single WVD Host at first to start testing the WVD Spring Update Update, and later additional WVD Hosts can be migrated the same way. We'll also discuss the option to recreate a new set of WVD Hosts in parallel with the existing environment. STEP 3 — Assign users and groups In this third step we will assign permissions to the WVD Host pool to allow (a subset of) users to be able to test the new deployment. STEP 4 — Testing the migrated WVD Deployment We are now ready to test the migrated WVD workload using our WVD Clients and plan for next steps. 
So let's go ahead and dive into the migration deep dive, here we go! STEP 1 — Duplicating your existing WVD backplane configuration into WVD Spring Update This first step is all about exporting your WVD Configuration on the current release so that you can import that configuration in WVD Spring Update. For this example, I selected an existing WVD Host pool that publishes a Full Desktop. But obviously, the same steps apply to migrating a Host pool that publishes a set or RemoteApps. In that case however, make sure to add the additional Cmdlets to export published RemoteApps. In this example I chose to duplicate a single Host Pool in each run to get better control over the migration path, the script can of course be extended to run in a loop to export every Host Pool. First, we need to define the parameters based on our existing environment, so the Tenantname, HostpoolName and AppGroupName. And second, we define the SubcriptionID, destination ResourceGroup and Location of our new WVD Spring Edition deployment. Remember that these 3 properties are mandatory as outlined in my previous article.
An automated uninstall step of the SxS Network stack seems to temporarily drop your RDP session, so I left that out. If needed it can be uninstalled manually. select "do not close "to avoid the drop in your RDP session. I have not found the uninstall switch to force to this mode yet. Then we add the WVD host to the new WVD Spring Update Host pool. In order to do so we log in to Az PowerShell, in this case with our ServicePrincipal account.