The launch of Microsoft Surface Duo received a lot of attention! In case you missed the announcement videos, check out theSurface Duo landing page!
The first use case I, and many other in this space, though of was: the ideal portable WVD Client that you can take literally anywhere! Work on-the-go!
The Surface Duo is not available for purchase in every region. But having so many fellow technology geeks working at Wortell, you can always count on someone who manages to succeed! And so here we are! Thanks to Maarten Goet for arranging 2 of these devices to allow us to demo and test drive!
So the main question; does the Surface Duo make for a great WVD client? The answer is yes! There was of course a reason why the WVD client for Android needed to be shipped fast, the Surface Duo is based on Android.
So, here is the WVD Client from the Google Play store in action on the Surface Duo! On the left hand side we have all of our apps installed on the device and on the right hand side we see the Remote Apps and Desktops inside the WVD Client!
And here is a Full Desktop Session in action where you can clearly see the big advantage of the Dual Screen. While being in a full desktop session on the right, we still have direct access to other apps on the left running on the phone.
If we turn the device we can also use the WVD Desktop in landscape, which of course makes more sense for a full desktop session.
And guess what! If we connect the Surface Duo via USB-C, we are running the WVD Desktop on our large screen! Doesn’t that remind us of Continuum via Windows Phone? 😉
Here is a really quick video of the Surface Duo in action. This was of course only our first quick test drive. Can’t wait to test others scenarios in more detail soon! Stay tuned for more Surface Duo fun!
I’ve been developing Azure Resource Manager (ARM) templates for many years. I love how ARM contributes to automation and to repetitive and standardized Azure deployments across different Azure Subscriptions. Whether your favourite approach is ARM, REST Api, CLI, PowerShell or anything else, automation and infrastructure as code are key to become successful with Azure.
There is no doubt that ARM is extremely powerful, GitHub is filled with thousands and thousands of samples you can reuse and also contribute to. Despite the power of ARM, the complexity of writing JSON code from scratch can be very challenging.
Yes, JSON is based on a declarative syntax, which lets you state what you intend to deploy without having to write the sequence of programming commands to create it. But, you have to build up quite some experience to become a seasoned ARM Template developer. A big part of the complexity is introduced by all of the colons, brackets, double quotes, parenthesis et cetera you have to use. I always advise people who are new to ARM Templates to start by deploying objects in the Azure Portal, grabbing the corresponding ARM code from those deployments and reverse engineering that ARM code. And secondly, browse and search on GitHub to learn from what others created.
Earlier this week I noticed the tweet below by Mark Russinovich where he referred to Project Bicep, to simplify Azure Declarative modelling!
So what is Project Bicep in more detail? The description below is coming from the public Github location (aka.ms/bicep)
“..Bicep is a Domain Specific Language (DSL) for deploying Azure resources declaratively. It aims to drastically simplify the authoring experience with a cleaner syntax and better support for modularity and code re-use. Bicep is a transparent abstraction over ARM and ARM templates, which means anything that can be done in an ARM Template can be done in bicep. All resource types, apiVersions, and properties that are valid in an ARM template are equally valid in Bicep on day one. Bicep compiles down to standard ARM Template JSON files, which means the ARM JSON is effectively being treated as an Intermediate Language (IL)…”
The description grabbed my attention so I decided to dive in and get my hands dirty! Since a specific use case always helps understanding a new technology, I based my testing on existing ARM code to deploy Windows Virtual Desktop to see what Bicep would bring to the table.
The diagram below explains where to position Project Bicep.
Setting up your VS Code to work with Bicep is super simple, you install the required CLI and optionally install the VS Code Extension. I can really encourage to do the latter as well because it provides you authoring support, intellisense and validation. Here is a link to the setup steps.
Once you’ve followed the steps referenced above, you’re ready to start authoring your first .bicep file. Building a .json file from a .bicep file is as simple as running the command below.
I this case I used an empty .bicep source file because that gives you get a good idea of what happens. Below is the end result after the build, an empty .json template with the various ARM Template sections we’re familiar with.
Lets now dig in and create a .bicep file that builds us an ARM Template to deploy WVD backplane components (workspaces, hostpool and appgroup).
Let’s start by defining parameters and variables. Below is what this looks like in .bicep format.
As you can see the syntax is super simple! There is no need to worry about colons, brackets, double quotes, parenthesis et cetera. If we build this part of the code it already becomes very clear how powerful Bicep is! Below is the corresponding .json output that the Bicep build generates.
We just simplified our infrastructure as code from 28 lines to 8 lines of code, and from 714 characters to 307!
Not only did we trim down the number of lines of code, bicep is already much more readable! And this is only the beginning!
Lets take a look at the .bicep code to create a WVD App Group. Below is the code that is needed. Again, notice how extremely simple and readable the code is!
Now compare that to the ARM code that is generated by the Bicep build process!
Take special notice to the way we can reference a resource ID of another object. Simplicity to the max!
Within VS code we’re also treated with tab completion options as per example below which make authoring Bicep files even easier.
Bicep also comes with implicit dependencies. If you are familiar with creating multiple objects using a single ARM Template, you’ll know that you need to explicitly tell ARM which objects depend on which other objects. This ensures that ARM created the various Azure objects in the correct order. Bicep has implicit dependencies! In this case I’m referencing the resource id of the host pool objects.
The Bicep build not only takes away the complexity of such a reference, it also automatically generates the required DependsOn section!
For my first test I created a .Bicep file that generates the ARM code to create a WVD Hostpool, AppGroup and Workspace and creates the necessary connections between the objects as well. The end result?
41 lines (1223 characters) in .bicep code that generate the equivalent in .json code containing of 75 lines (2432 characters)!
Here is the end result after deploying in the Azure Portal.
And according to ARM, that only took 2 seconds to deploy! :)
To share what I have built and to you help you jumpstart your .bicep projects, I have published the full .bicep file on my GitHub:
Finally, I advise to keep watching aka.ms/Bicep because with the current preview release (I would not advise to use for product deployments yet) there are a few limitations as shown below. One of the limitations I ran into is the lack of support for arrays as of now. This is why I was not able to link the WVD App Group with the WVD Workspace yet.
I’m super excited and I think this is a great move by Microsoft! It really provides even more power to ARM! I’m looking forward to new improvements and I’m sure Bicep will also be covered during the upcoming Ignite 2020 event!
I usually design and implement Windows Virtual Desktop environments for customers to provide them with Published Applications and Desktops from the Cloud, the serious stuff. But occasionally I like to use that same WVD for some fun stuff as well!
Although the Command and Conquer Remastered game leverages the GPU as expected and ran pretty smooth it was not a super graphics intensive game. So, with the release of Microsoft Flight Simulator 2020, it was time for another fun experiment!
How well does Microsoft Flight Simulator 2020 perform on a GPU powered Windows 10 machine published by WVD?
For this experiment I went all in and deployed the NV24 Series VM inside my GPU host pool, just because I could! This series contains 24 vCPU’s and 4 dedicated Nvidia M60 GPU’s, but based on the requirements of the game, a NV6 should also be sufficient.
To start installing Flight Simulator I went to the Microsoft Store and signed in. Upon purchase and installing I ran into the error below. The VM was deployed with a default OS disk size, which is not enough for the Flight Simulator 2020 install, so I had to resize the OS disk first :)
Add caption
But, after that the install launched successfully.
After the installing, a “few” updates needed to be downloaded and installed, which took quite some resources and time!
I selected Satellite experience (recommended for the best experience).
And then it was time for my first flight! Below is a screenshot of the full screen experience with the performance metrics from the WVD session. the Round Trip Latency to Azure West Europe was 12ms and I had 118Mbps available.
Below is a more detailed screenshot of the WVDsession details
I have not yet been able to compare the experience with a local install, but the overall performance was really great! Below is a screenshot of running it full screen on my Ultra Wide curved 34'’ monitor.
And guess what, here is the same session running on an iPhone, using the RD Client from the store, also running smoothly!
