Monday, August 10, 2020

Windows Virtual Desktop spotted in the strangest place ever!

 If you follow my blog posts and articles you’ll that a for a big part I like to write about Application and Desktop delivery using Remoting Protocols (WVD, RDS VDI et cetera). Mostly on the Microsoft platform and today almost exclusively on Azure. Most of my articles are in-depth technical articles. Occasionally I also like to change gears and discuss the technology from a crazy, funny or at least different perspective!

You might remember the recent post I did about running  fluently from within WVD. The accompanied video got 10k views LinkedIn. It instantly became my most popular LinkedIn post, which was hilarious!

Catch the video here: .

Image for post

Since  works great from within WVD, lets switch to another popular game: Minecraft! My two kids (who are 12 and 9) love the game and I have seen them design and create the most amazing worlds. From time to time we also play this together creating new worlds and also playing many of the popular games within like e.g. EggWars or Hide & seek.

Minecraft is developed by Mojang Studios, was release in 2011. It’s an extremely popular game with 200 million copies sold across all platforms and 126 million monthly active users as of 2020. In 2014, Mojang and the Minecraft intellectual property were purchased by Microsoft.

The above made me think last weekend and challenge myself.

If we can play Minecraft from within WVD, would we also be able to use WVD from within the Minecraft game?

Challenge accepted !

Step 1 So, the first step is to see if Minecraft would work from within a WVD session. After having implemented many different WVD use cases successfully including some have graphics design applications, I’m pretty confident it should work just fine.

The proof of the pudding is in the eating! Below is a screenshot of Minecraft running inside a WVD session. In this case I’m using a GPU-powered VM, the NV6 containing an NVIDIA M60 GPU and I’m connecting to the session using the WVD Windows client. The game performs really well but the perceived performance is of course very much dependant on Round Trip Latency and available bandwidth. For the NV6 machine itself in terms of resources, running the game is peanuts.

Image for post
Image for post

The result was as expected really, not too much excitement there. Now that we have proved this first step, it’s time to move on to the much more interesting step. Leveraging a WVD session from within the Minecraft game! And yes, by that I really do mean launch a WVD session and interact with it whilst inside a Minecraft world!

Step 2 For this step I have installed Minecraft on my local machine. I’m using the Java edition (not the App from the Microsoft Store) because I’m leveraging various mods (modifications build on top of the original game engine) to achieve the goal. I’ll provide the details and download locations of the mods I used at the end of this article.

Let’s jump to the end result right away. The below shows I’m leveraging a WVD session from within the Minecraft game! I’m accessing a Windows 10 Multi-Session VM, published via WVD ARM (Spring Release) leveraging a GPU. The latter is of course not needed, but just makes it extra fun. I’m interacting with the WVD session inside the Minecraft world as if I’m looking at a huge touch screen display!

Pretty cool demo right? Isn’t that the strangest place where you have seen WVD in the wild? I personally was really surprised by the overall performance. From various different angles the desktops looks great and even the performance, especially considering this is the Web Client, is pretty good! Did you also catch the second screen inside the WVD admin dungeon? That was just so much fun to build. Of course clicking the huge projected screen by moving my Minecraft character around is far from an ideal workplace, but that was not purpose of the demo. Even scrolling works, although rich-click inside the session was a challenge I did run into.

Some more details on the setup. In order project the live session and use a WVD session from within Minecraft I needed a display screen, some way to access the internet and the functionality to leverage a keyboard and mouse. I used the following mods to achieve this goal. Forge, MCEF 0.9 and WebDisplays. The last one provides you with the building blocks that allow you to create a screen, keyboard and browser. Since the WebDisplays mod essentially is an internet browser, I’m of course leveraging the  to achieve this goal as you can also tell from the demo.

Fun fact, when trying to discover what kind of browser / OS I was dealing inside the MOD it showed Windows 8 and Google Chrome version 51!

Image for post
Image for post

How this was built

After installing all of the necessary mods, building the screen is pretty simple. First you create a new screen / video wall by building it using the “Web Screen” blocks. There are some limitations in terms of sizing, I think the width can be a maximum of 16 blocks.

Image for post

Next you build a keyboard to interact with the session as as as a controller.

Image for post
Image for post

To turn the screen on you use the “Minepad” item to turn on the screen.

Image for post

And finally you need to connect the screen, remote controller and keyboard together. You can do this by using the “Linking Tool”.

Image for post

One this is completed we have a working display with a browser. Click on the Remote Controller to browse to a URL.

Image for post
Image for post

Another fun fact, seconds after grabbing previous screenshot is started pouring rain, so I just had to take another screenshot of that! :)

Image for post
Image for post

And finally, for those who are wondering if you can plan Minecraft inside a WVD Session and access that WVD session from Minecraft, yes you can!

Do you think that’s air your breathing now?

Image for post
Image for post

Another fun experiment in the books! I hope you enjoyed it :) Here is  containing more fun videos!

Monday, June 29, 2020

Getting started with REST API for WVD ARM (Spring) release, and sharing my GitHub examples!


The REST API reference for WVD ARM (Spring Update) was released publicly last week! Great news, as this allows us to interact with the WVD service by using REST API. This article covers guidance on how to get started with REST API for Windows Virtual Desktop.
The landing page for the WVD REST API reference can be found here and contains detailed information about the various REST operations to interact with the WVD service. Currently, the following REST Operation Groups are available for WVD.


What I really like about the REST API documentation on is that it allows you to test all the REST API code right from within your browser. For example, open the Hostpool page and click on Try It and log on with you Admin account that you use to manage Azure and WVD.

Now you can simply provide the Hostpool name and ResourceGroup and click Run.

This will output the detailed information about the Hostpool right from within your browser as shown below! This allows us to receive a JSON formatted output with all the parameters and values. Very helpful a quick reverse engineering step, because this allows us to get great insights in what we can specify in REST API PUT actions.

WVD REST API via PowerShell

Using REST API for WVD Spring (ARM) release, we’re able to Get, Create, Update and Delete the various WVD components similar to how we are able to manage them using PowerShell and Management GUI in the Azure Portal. REST API is great for repetitive tasks and automation!
I created and shared a PowerShell script on GitHub that contains functions and examples to interact with the WVD REST API interface. In this article I will cover how you can use the steps in the PowerShell script to get a Jump Start with REST API.
First we need an account or App Registration that has permissions to performs the actions on the WVD components in Azure. In my example, I created a dedicated App Registration for REST API as shown below. Simply create a new App Registration and once completed, create a new Secret and make sure you store both the App ID as well as the App Secret. And finally, use Azure RBAC to provide the App with permissions on the Resource Groups where your WVD resources are located (or will be created). In my example I provided the App with Contributor permissions on the WVD Resource Group I’m using.

GitHub Sample Code — retrieving an Hostpool

Once we have the App registration configured, we can dive into the REST API. In my case I’m using PowerShell. The first thing we need to do is set a couple of variables related to our Azure Environment and the App Registration we just created.

Next, we create a new API token for our App Registration using Invoke-RestMethod. We pass this API Token later on when communicating with the WVD REST API interface.

And finally, we construct a API Header containing the token type (Bearer), the token itself and the content-type which we set to “application/json”. Important note, later on in this article, we’ll will also be using another content-type.

If all goes well, the header should look something like below. We are now ready to use the REST API module for WVD, and when communicating, we’ll use the created header.

In my PowerShell script I have created 8 PowerShell functions as of right now. These 8 functions are able to get and create a WVD Hostpool, AppGroup, Workspace and Published Apps. Let’s take retrieving a Hostpool as the first example. The function contains all the info that is needed to launch the invoke-restmethod command and also constructs the URL that is needed.

This function assumes that $apiheader already contains a valid REST API header, as created based on the previous step. The function takes 3 basic parameters that it needs to retrieve the Hostpool which are the Azure Subscription ID, the ResourceGroup where the Hostpool resides and the name of the Host Pool. Here is an example of how to call the function.

The function returns the full output of the Invoke-RestMethod which, in the example above, we captured into the variable $WVDHostPool.

We can of course easily output and work with the values by accessing them like below.

The properties attribute is the most interesting as it contains all of the details of the WVD Hostpool that we also have access to via PowerShell and the Azure Portal. Below is the output in a more structured way.

GitHub Sample Code — creating a Hostpool

Let’s now take a look at creating a WVD object using REST API. The PowerShell script already contains ready to launch functions for creating Workspaces, Hostpools, AppGroups and Published Apps so again let’s take the Hostpool as an example.
Below is the function taken from the script. Similar to retrieving a Hostpool as we did in the previous example, this function also takes the Azure Subscription ID, the ResourceGroup and the name of the Host Pool as parameters.

With the creation however we also need to pass the additional settings, stored in the properties attribute. If you recall from the Get-WVDHostpool function, the properties attribute is of type JSON. This means we also need to provide the Hostpool properties in a JSON format as well. To make life easy I have already added the JSON code to the PowerShell script. Below is what this looks like

As you can see we specified mandatory properties like the e.g. location, name et cetera. On top of that we also added custom RDP properties to enable a couple of redirection settings. Similar to how we called the Get-WVDHostpool we also call the New-WVDHostpool and pass the parameter including the body with the properties as shown below.

And just like that we have created a new Hostpool in WVD Spring (ARM) release, including the properties we specified!

Up until now we have covered the scenarios to both get and create a WVD Hostpool via REST API. The get and create of Workspaces and AppGroups is very similar, check out the PowerShell Script on GitHub for more information.

GitHub Sample Code — retrieving Published Apps

Let’s change gears and cover dealing with WVD published applications (RemoteApp) via REST API! The PowerShell scripts contains the function Get-WVDApps. This function takes the Azure Subscription ID, the ResourceGroup and the name of the AppGroup as parameters.

Similar to the other functions we’ve covered we can run the function as shown below.

This function gets all published RemoteApps for the specified AppGroup and, in this example, shows the friendly name ,file path, icon path and commandline setting. The output looks like below. Of course other properties can be added to the select statement as needed.

GitHub Sample Code — Creating Published Apps

As another example scenario, let’s add Outlook as a Published App to this Appgroup. For adding a new application to an existing AppGroup I have create the function new-WVDApp. This function takes the parameters Azure Subscription ID, ResourceGroupName, AppGroup, Properties (stored inside the body) and the App Name.

IMPORTANT NOTE: The Invoke-RestMethod for Published Apps needs using a different API header! This is because it needs utf-8 to be able to parse all of the properties including escape characters. I created a second API header for this purpose in the script which sets the Content-Type to “application/json; charset=utf-8”

To publish Outlook as a new application we again need to construct a JSON containing all of the parameters as shown below.

Some of the parameters are mandatory, so make sure you specify at least those. Below is the end result, Outlook is published as a new RemoteApp inside the AppGroup we specified containing the properties we provided!

This concludes this article. To reiterate, we covered the REST API interface to communicate with Windows Virtual Desktop. We used the REST API interface to create and retrieve WVD ARM (Spring) release Objects in an automated way! Here is the a direct link to my GitHub page where I shared all the sample code :

- - happy coding 😎

Friday, June 19, 2020

New GitHub Script: Automating the transformation of MSIX packages into MSIX app attach, ready for WVD!


Last week I published an article on using MSIX app attach to deliver Google SketchUp to a GPU powered Desktop running in WVD. In that article I also touched on the steps you need to take to transform an MSIX package into an MSIX app attach (vhd) package. As explained in that article as well, the MSIX source can be a native MSIX package delivered by an ISV / application vendor or the output from the MSIX packaging tool. For both scenarios the steps of transforming an MSIX into MSIX app attach are the same. There is a great article on Microsoft Docs that described the manual steps needed. I decided to automate those steps into a single PowerShell script and share it on GitHub!
I’m sharing a PowerShell script on GitHub that automates the transformation of MSIX packages into MSIX app attach, ready to use within Windows Virtual Desktop or on any other Windows 10 Build 2004!
Important note since I get this question a lot: I’m using WVD as the destination environment for the MSIX app attach. However, WVD is not a requirement for MSIX app attach at all and neither is hosting the destination VM in Azure! MSIX app attach can be used on any Windows 10 2004 build (and up). When you are using Windows 10 Enterprise it can be hosted anywhere and can even be a physical device. When Windows 10 Enterprise Multi-Session is used, it has be hosted on Azure through WVD.

Variables you can specify

The PowerShell script takes the parameters as shown below. I used a Google Chrome MSIX package that was the end result of the MSIX packing tool as an example to provide you with some sample values.
First of all you provide the information (folder and file) where the source MSIX is located, in this case I’m using a local folder on my MSIX Transformation VM. Next you provide the maximum size of the MSIX app attach (dynamic vhd) disk. Make sure you have enough room to store the extracted MSIX package files. Then provide a label, this label will be set on the vhd disk to allow you to easily distinguish multiple attached disks later on. Next you can provide the name of the root folder on the disk. As explained in my previous article, a root folder is mandatory for MSIX to work. Then provide the location where msixmgr is installed, this tool is used to extract the MSIX into the root folder on the vhd disk we’ll be creating. Make sure you point to the location where msixmgr.exe, applyacls.dll et cetera reside. The container extension variable can be kept default.

Requirements that need to be in place

Do note that the machine that you run this script on needs to have access to the PowerShell Cmdlets that work with VHD files (Mount-VHD, Dismount-VHD et cetera) which are part of the hyper-v module. The script assumes that this module is and the msixmgr tool have been installed, it does not check for that requirement (yet).
Here is a list of the steps that the PowerShell script performs:
  • Create a new VHD file in the source location specified and configure it with the maximum disk size specified
  • Mount the created VHD
  • Initialize the created disk
  • Create a partition on the disk
  • Create the MSIX root folder on the Mounted Disk
  • Extract the specified MSIX package into the mounted disk (using msixmgr)
  • Grab and output the Volume ID and Package Name to allow for easy copying. These values are needed later for the MSIX app attach Staging & Registering steps.
  • Dismount the VHD

Transformation script in action!

Let’s see the script in action! Below is my starting point. I have several MSIX packages that have previously been transformed from msi/exe to MSIX using the MSIX packaging tool. I have the script in this folder as well and the hyper-v module as well as the msixmgr are installed.
For this example I want to transform the Google Chrome package into MSIX app attach, so I specify the following parameters.
In my case the entire transformation of Google Chrome MSIX towards MSIX app attach only took 32 seconds! Below is what the output looks like. The script also outputs the Volume ID and Package name which allows for easy copying because they are needed for the MSIX app attach Staging & Registering steps later.
Here is the end result, a Google Chrome MSIX app attach (.vhd) file ready to go!

Test drive the end result

It’s now time to test-drive the vhd file to see if we can attach it to a user session and actually use the application. As explained in my previous article, MSIX app attach consists of 4 different steps Staging, Registering, De-Registering, De-Staging and Microsoft provides sample scripts for these 4 steps. To reiterate, here is an explanation of the terminology again.
So, the next step is to place the created .VHD on a Share (File Server of Azure Files) that is accessible by the client (in my case a Windows 10 Enterprise Multi-Session via WVD Spring 2020 Update). In my case, I added it as a 3rd package in the MSIX app attach share.
Now we can test the first MSIX app attach step, Staging. My Transformation script outputs the VolumeGuid as well as the package name, paste those values in the Stage script and also enter the location of the vhd hosted on the app attach share, as well as the parent folder that was used. Running the scripts mounts the vhd and creates the junction point to have Windows “think” a MSIX was extracted in C:\Program Files\WindowsApps.
The staging step only takes a second to complete, and here is the result, a mounted disk
And a junction point towards the disk
Now that Staging is complete, we can Register the application for the end user. Again, simply update the package name variable and run the Register script.
And here is the end result! Google Chrome is not installed locally, but it is available in the start menu using MSIX app attach and is running in the user session!

Final notes and download!

We are of course running PowerShell CmdLets to Stage and Register MSIX app attach applications. Under production circumstances (when MSIX app attach comes out of public preview), you would run the staging part during the machine boot (e.g. via a Computer GPO) and the registering part during user login (e.g. via a User GPO setting). In the future it is Microsoft’s plan to further integrate MSIX app attach into the WVD Service. The diagram below shows the MSIX app attach proposed milestones.
And finally, here is a link to the full script on GitHub, and as always if you have suggestions for the script feel free to send in a pull request or reach out to me directly!
— Happy Transforming!