 Join me and Tom Hickling with our session about Windows Virtual Desktop. Hey everybody and welcome to today's session. We're going to be talking about Windows Virtual Desktop and joining me is Tom. Tom, welcome to the session. Thank you. Thanks for having me. Could you introduce yourself to the audience and tell them a bit about what today's session is going to be about please? Yeah, we'll do. So my name's Tom Hickling. I'm what's referred to at Microsoft as a Windows Virtual Desktop Global Black Belt. Now that's a bit of a silly name, but it's really there just to know a specialization rather than any martial arts. I cover Amir as part of a small team, but we are part of, as the name suggests, a global team that covers America and Asia pack as well. This session is really just to go into a bit more detail around WVD, in particular the roadmap. So WVD has been released over a year now. There's been a whole host of new capabilities and services, and new features that have been dropped into the platform. There is also a long list of backlog items, some of which have made it onto our roadmap, which is publicly available and I'm just going to talk about four of those particular roadmap items in this session. Awesome. Sounds good. First of all, I just want to talk about how Windows Virtual Desktop or WVD has actually been a technology that's kind of soared, I think, is maybe fair to say during the pandemic. How has it actually helped organizations with the pandemic and the working at home situation that we've all found ourselves in? Yeah, so WVD was getting traction before COVID here. And that's because end user computing is a generic type of workload that lots of organizations have inside of their environment. And it always comes up for a new at some point in there sort of lifecycle. So all of these organizations at some point, we're going to look at WVD, not necessarily adopt it, but just look at it as a service. Obviously, then COVID here, and that massively changed things almost overnight. Obviously, the reason for that is all of these, all of us, in fact, millions of people have now had to work from home and it's been forced on us. Now, what we typically see is lots of organizations who have got virtual desktop inside their own estate use it for a number of use cases. And it's predominantly the use case of having your data secured back in the data center, no data on devices that can't be lost. So you've got your consolidating all of your end user compute inside of your data center. However, from the get go, remote access has always been one of the top, three, four use cases in terms of I suppose selling the value of virtual desktop. However, what we've seen is the vast majority of organizations haven't used it in that use case. Now, they have used it in some small context. So it might be execs, it might be those people whose job genuinely is being remote and traveling and visiting customers. And the other use case is IT, so IT remote support. Besides that, there haven't been very many organizations, if any, that have adopted it firstly because of this remote access capability. Then obviously COVID hits, people are forced to work from home. Lots of customers might have a small capability in this space or they might have some sort of VPN solution. But they can't necessarily scale it up so that tomorrow even within a week's sort of time, they can have all of their users working successfully from home. And that's typically because these legacy or existing virtual desktop solutions require, if they're gonna scale out, they need to buy new hardware, that's procurement time, racking and stacking, that takes a lot of time, possibly new licenses. And the same could be said for a VPN. So a VPN is constricted by the device or the devices that an organization has. And like I said, the user demand for that is typically very sort of static. Now there's this massive demand. They might be able to accommodate a few new users, but they would probably have to scale up or purchase new appliances. Again, potentially new licenses to support that. So the key, I suppose, feature of WVD has been that it's based upon Azure. Azure's a hyperscale cloud platform. You can go and deploy in minutes rather than weeks, months. And you're not paying for anything until you've actually gone and deployed it. So there's no requirement for customers to go and buy hardware and then wait for it to be delivered. They can just go to the portal and deploy and it will deploy there and then and they only start paying once the infrastructure's there. So it's been a lifesaver for lots of organizations. We had one CIO who during the pandemic, we were on a call and then he just said, can we actually do this? Like genuinely, can we do this? The answer obviously was yes. And then we heard within two or three weeks they'd actually gone and deployed this and got 4,000 users on the platform being productive. His final words were WVD saved our bacon. So that's the kind of thing that you wanna hear in terms of your product saving people's businesses. Yeah, absolutely. That sounds really good actually. How does it work though if an organization maybe isn't fully bought into the cloud yet. They haven't moved all their workloads. They are maybe running in a hybrid infrastructure, a lot of their backend kind of applications run on-prem and then WVDs up in the cloud. Is that a scenario we're seeing customers enable? Is there any complexity to that? What's your view on that Tom? Yeah, absolutely. So the first thing is WVD is Azure only. So we only support the virtual machines, i.e. the virtual desktops that users connect to running in Azure. We don't support any on-premises virtual desktops. So users have to connect into Azure in order to get onto the desktop where they can then go and consume their apps and data. Pretty much every single organization out there has their apps and data back on-premises. So we need some kind of connectivity to get the user from their virtual desktop back to where their apps and data reside. So for enterprises, we have a product express route, a private dedicated connection back to on-premises or you could be using a site-to-site VPN. Obviously, there's some time differences and in terms of configuring that, so a VPN could say half an hour to set up. Express route might take weeks if not longer and it's obviously more expensive but it is a private and dedicated connection for that customer up into Azure and vice versa. So to enable that connectivity, there is that requirement to have that physical connectivity in the first instance. And that's millions of customers out there are using express routes. So whilst it's not a two-second job, it can be done and it can be done relatively quickly. The next problem typically comes from IT security. So what they don't like is to have network connections between two locations just open to everything. Now the problem with end user computing is you might have thousands of applications, the client side of those applications running on these virtual desktops for a large organization and those apps might all have their own port requirements that need to be opened in order to talk to a whole gamut of different back-ends. And some customers have tried to open up individual firewalls for these individual applications. It's a nightmare because they don't necessarily know them upfront because they might not have documented it because they might not have ever needed to do this before. So they would have to then start troubleshooting why things aren't working and understand the ports and then go through the firewall change request process to get these ports opened and then do it for the next app. And if there's thousands of them, it's a nightmare. So what we typically see customers having is effectively in any, any rule. And that's the last thing that IT security wants to hear because they think that that's drastically insecure. In reality, we're connecting Azure, which is secure to a customer's location, which we would hope is secure. If they've got IT security saying that this is a problem, that kind of suggests that they've got some kind of security context in place. So besides that really, there's not that many sort of particular hybrid issues, which is I suppose a good thing. Yeah, that's good to know that customers can maybe pick and choose their cloud workloads to prioritize depending on their needs and then kind of build up as they go forward. So the roadmap you mentioned, you're going to be sharing some information around that. Could we have a look at that now, Tom, please? Yeah, yeah, absolutely. So let me just bring up these slides. Hopefully that's come through. So we're going to look at four areas or four capabilities that's on our roadmap. The first is a thing called MSIX App Attach. Then we're going to talk about RDP Short Path Private, which does have a hybrid connotation. So my interesting, bringing it back to that hybrid conversation. Screen scraping protection and then start VM on Connect, which itself is actually in private preview at this point. So this is a bit of a sneak peek at that capability. So let's start off with MSIX App Attach. So this slide of the pancakes is there really just to denote this layering capability. There are lots of layers involved in virtual desktop and what this is doing is the ability to separate those layers out. And we really call it the future of application delivery because that's how a view at this point in terms of how we get these applications to the virtual machines that users are consuming in a much more dynamic and efficient manner. To take a step back to show the context here, on a physical device, a user's profile, their persona that makes them them on their machine is intrinsically linked to the OS as is all of the applications on that virtual machine, such that if a user gets a new laptop tomorrow, they can't expect everything to be there as they left their previous laptop. So that's the kind of the problem that we're trying to resolve. And we call that breaking the monolith effectively. Now, in WVD, our goal is to try to completely and utterly separate all of these layers, i.e. breaking the monolith. And we've actually done half of that with the user profile already. So we acquired a company called FSLogix and they have a capability that manages user profiles and they store the profiles on some storage and then bring that profile into any VM that the user signs into on any given day. So that kind of gets us half of the way there. The next side is the applications. What can we do around the applications? Now, this is particularly relevant when customers are doing virtual desktop in a pooled environment, i.e. you have a collection of users that need different sets of applications and they're signing into any one of any VM in this pool on any given day. Now, like I said, we can bring the profile in to make their user experience the same every single day, but what can we do around delivering the applications dynamically to a VM that they haven't been logged on to before when they need it? And that's really where MSIX Appattach comes in. And I've just listed it down there together because MSIX Appattach is the combination of two separate things, MSIX and Appattach. So MSIX on its own predates WVD and it's our new packaging format. And it will effectively replace everything that goes before it. So MSIs, Xs, things like AppV. It won't necessarily bring every single capability from all of those, but it will be the packaging format of choice going forward. And there are lots of developers out there who are already developing their applications natively in MSIX format. And we do have a conversion tool out there to help customers move from previous formats over into MSIX. And then Appattach. And Appattach is a WVD specific component. For, as the name suggests, the attaching of these MSIX apps to the WVD session hosts. So this part is only relevant in a WVD context. So just for, again, a little bit of context, this is the process of Appattach in comparison to FSLogix. So we've got lots of customers that have done FSLogix in WVD. So just to show how this operates in comparison. So a user will sign into WVD as they do today. They'll get their resource feed. They'll get some icons they can launch that represent the apps and desktop that they can connect to. Their connection is brokered by the control plane and they are connected to a particular session host at which point FSLogix kicks in and loads the user's profile into that session. Hence now the user's persona is now back onto that session host effectively where they left off the previous day. So that's good. What WVD will then also do is read the MSIX apps that the user has been assigned. And then in like manner, mount the VHDs from storage that contains the applications that they can consume. Now, the one thing that's worth pointing out here is that App Attach is not using the FSLogix technology to do this. It's just doing effectively exactly the same thing that FSLogix does for the profile, but we're now doing it for applications. And the support is built into Windows 10, 2004 and above. So no need for any agents or any management infrastructure built into the OS. All that we need is an SMB file share. Now, once we've got this, what it effectively enables organizations to do is to shift from a traditional type of management and application delivery to this sort of new modern mechanism. So on the left hand side here, this kind of describes the traditional experience that we find most of our customers have kind of fallen into in some respects. And this just very, this oversimplifies it, but it kind of demonstrates the point. In this instance, I've just got three images for three business units. Now, most organizations will have more than this and they might have them for different collections of users. It might be projects, it might be applications, it might be geography, whatever it is, they tend to have different images for these different sets of users. And then there are set of common apps across all of them and then some departmental apps. Now, if the image for sales, for example, needs to be updated, then there's a process to go and update the image and then roll that out everywhere that the sales VMs are deployed. That there's a bit of work there. What that also means is that if they started off, if all of these images started off from the same image, they've now separated from each other. And as is the case, customers are managing different images separately. So they will sort of diverge over time. Again, if a common app needs to be updated, then it needs to be updated and rolled out across all images and all VMs that it's present within. In this case, across all three. So that's everything in my case. And then if a departmental app needs to be updated, so for example, one of the HR apps, that needs to be rolled out again to all VMs that are in that HR sort of silo. The overall point here is there's lots of administration and stuff that needs to be done by IT to keep the lights on and updated in this type of deployment. What we're trying to do is move over to the right-hand side, which is where we do have one single image. We're bringing in the user profile from FSLogix and then we are bringing in every type of application. So the departmental as well as the common apps from App Attach. And we're dynamically delivering those apps to any VM that the user might log on to when the user needs it. So no longer do we have to have separate images or separate applications on for separate collections of users. We have one image used throughout the organization and the users just consume the apps when they need them. So a far simpler, more efficient, and hopefully it should be far cheaper solution than the one on the left, which is applying or requires far more management overall for IT. So let's just have a look at how this works. Now, this is just a video of the experience. Now, this to stress, this is absolutely not the user experience. This is just the mechanics behind the scenes just to demonstrate what actually happens. And again, this is all managed by the WVD control plane. So in this instance, I'm running PowerShell to initiate it. That is absolutely not a requirement. The WVD control plane will orchestrate all of that. Now, what you'll see on the left is Adremov programs. What you'll notice is Power BI is not installed on this VM. In the middle is Disk Manager. And on the right, as I like I said, is PowerShell, which I go and initiate the attaching. I'm just gonna play this video. So on this VM, I'm just gonna go and try to launch Power BI and you'll see that it's not present, so I can't launch it. I come to PowerShell and run the, basically an attachment script. What that does is it attaches that disk that you see in Disk Manager. I come to search for Power BI and now Power BI is, well, at least there's an icon for it. And what you'll now see is Power BI is launching on a VM where Power BI is not installed. And that is the App Attach capability. Now Power BI is registered with the OS. It knows it's outdated and needs an update. And the actual application behaves like you would expect Power BI to behave. So to a user, they can't determine that this is not installed locally. So the detach process is the same. I run a script to detach the VHD. That now disappears. The app is registered and destaged from the VM. Come search for Power BI, it's no longer there. So there's no presence or no remnant whatsoever Power BI having ever been installed, or in fact not even installed, but presented to this VM. So this is the capability behind the scenes and it really shows how you can dynamically deliver apps to VMs and thus to users rather than having to spend time installing applications physically onto that VM. So just to come back to the slides then, just the final slide, just around the mechanics specifically inside of WVD. Now, like I said at the beginning, this is in preview, will be GA hopefully in the next couple of months. But this just demonstrates what goes on in conjunction I suppose with the Azure portal, the WVD control plane and the session host. And for that matter, the SMB storage where these VHDs reside. So the first action is the IT needs to go and assign MSIX packages to a host pool. And they do that inside of the Azure portal or via PowerShell. When that happens, the WVD control plane will instruct a random session host in that host pool to go and read the VHD that houses the MSIX package where the applications reside. Now at this point, the session host is interrogating that VHD checking that there's a certificate that's present in the VHD, is checking the consistency, if there's any dependencies and all that kind of good stuff. If that's all good, then the next step is that the, all of the session hosts within a host pool will check in with the WVD control plane to say, are there any MSIX packages that I need to mount for users? Now it will do that within five minutes. Now this is a random five minutes, random from the point where the VM starts up. So basically within a five minute period, all of those session hosts will have checked in and then mounted the VHD. Now that can be reduced for our registry staying down to one minute for customers that want to accelerate this. So within five minutes they'll check in, they will then reach out to the storage location that has that VHD and mount that VHD onto the session host which then enables users to sign in and then go and launch the application in a process called registration and then they can go off and consume that application. So that's the process from a WVD perspective. Let me just show what that looks like inside of the Azure portal. So if I just bring up the Azure portal, this is the WVD part of the Azure portal and I'm going to an app named MSIX Appattach Host Pool. Now, what you'll see here is a new MSIX Packages section of the portal. This is the part that's enabled through the public preview. So all I need to do, in fact, there's two steps. The first is to add the application to a host pool. So if I click on add here, all that I need to do is to add the VHD location, the SMB location that contains my VHD. So this is just an Azure files location that I've got in my Azure subscription is actually connected by a private link, which means I can't or nobody can connect to it other than on the VNet that these session hosts reside. And if I tap out of here, what this will do is it'll go and interrogate that VHD and determine what applications are within it. Now, it's just worth noticing here that within this package, I've actually got two individual applications, so Chrome and Edge. I could have one, I could have multiples. This is just demonstrating that I can bring applications together inside of one package and then present them individually to my host pool. So I could click on Edge here. In fact, I've already done that. Just give it a name. So this is anything and then say it's active. If I clicked on add, you would add it as you will see here to the list of applications that this host pool has access to. So that's the process for adding the app to the host pool. The users can't at this point access the application. So to do that, I need to go to my application group, which is the connection between apps and users. So I can come to my application group, go to applications and click on add. And what you'll see here is the MSIX packages and all of the applications that this host pool has access to, I can choose to present to this particular application group. If I just clicked on save, then that would add it and then enable the users to consume it. Now it's worth just noticing another point that lots of customers ask is, they might have a large host pool with lots of applications. How can they restrict certain collections of users from only consuming certain apps? The way to do that is to create multiple remote app groups. So if I just go into here and show you, in this one, I've got Chrome and Edge. So two applications, that's assigned to a number of users. If I go to a different remote app group, so the second one here, go to applications, you'll see a different set of apps assigned to a different set of users. So what will happen is when users from those groups log into the host pool, they will only see the applications that they've been assigned to via this application group. So let's go back to my session host then. So this is a session host that I've connected to, just to save some time. What you'll see in Disk Manager is a couple of things. My FSLogix profiles for starters are here, but then also I've got, what is it, four disks that have been mounted onto this session host. If I just show you the properties of one of these, I'll just go and detach this disk three. This is actually Visual Studio, Visual Studio Code, I should say. And what you'll notice here, if you noticed earlier was this is the same Visual Files storage account, which I've placed these on. So that's the disk that's been attached. And as you would imagine, if I go and search for Visual Studio Code, you'll see it here. If I launch this, this will go and launch Visual Studio Code. So that's the real life launching of an MSI-X application in real time there. So that's App Attach. That's our first roadmap item. If I go back to the slides, we can then move on to our second feature, which is called RDP Shortpath. Now again, this is in public preview. The GA is expected within Q1 of 2021. Now, RDP Shortpath is a capability that actually started development way before COVID. And it's really designed for optimizing user connectivity into the WVD session hosts. And it does that by using any managed network that the customer has in place. A managed network is, like we said earlier, express route or a site-to-site VPN. Now, to explain what this is, we just need to go back a step to look at the normal connectivity that a user follows to get to their session host. So what we've got here is the WVD client, we've got the gateway that's part of the control, the WVD control plane, and then the session host in the Azure subscription. Now, when the session host on the right-hand side boots up, it actually reaches out to our gateway and it establishes a TLS 1.2 encrypted stream. Now, inside of there is just the brokering comms, basically advertising itself and how to connect to the session host. So that gets established when the session boots up and then basically sits there waiting for a connection. When a client connects, they effectively establish exactly the same thing. So they will establish a TLS 1.2 encrypted stream to our gateway and inside of there, again, is just the brokering comms. This is who I am and this is potentially the resources that I'm going to launch. And it does that across the public internet. Now, that traffic is encrypted using a certificate that Microsoft manages and that's installed on our gateway. So that's all established prior to a user actually trying to physically connect to the session host. So, and that's the next step, the next thing that happens. So a user will actually click on an icon, they will then establish a second TLS 1.2 encrypted stream inside of the first that goes through our gateway through to the session host. So effectively, we've got this inbound connection which is being brokered by our gateway and it establishes a connection to that outbound connection from the session host. And at this point, we've got TLS, sorry, we've got RDP traffic inside of two TLS encrypted streams. So it's encrypted twice, so it's very secure. So that's how customers connect today across the internet using our gateway. What RDP short path will introduce is this ability to direct that traffic via ExpressRoute or a VPN. So the first original outside encrypted streams are still established, so we understand who the user is and we can understand what the session host is. But once that's established and the user then connects and we detect that ExpressRoute is in place, we will direct that TLS, sorry, the RDP connection directly across ExpressRoute into the session host. The point here is, if a customer has ExpressRoute, there's obviously a cost associated with that. Let's make use of that cost. And also ExpressRoute should in theory be a lower latency connection into the session host. So let's absolutely make use of that to improve the user experience. The other thing is not only are we bypassing the gateway, we're reducing network hops and we're improving the user experience to that session host, we're also introducing the UDP protocol here. So the previous connection all uses TCP, we are now using UDP, which is a far more efficient protocol anyway to connect in. So the combination of taking that traffic off of the gateway, off of the internet and the introduction of UDP should in theory improve the user experience. And just for those people that like pictures, this is the sort of the connection architecture. What you'll notice is that blue dotted connection is the RDP traffic that today outside of RDP short path goes across the internet. With RDP short path, we are obviously going direct. Now, let's just have a look because we've got a couple of sessions running, I can show you what the performance improvement is, hopefully. So if I go back to my MSIX session and go to my connection details, what you'll see here is that we are, yes indeed, connecting with TCP. So if I just zoom in here and we are connecting and we've got a round trip time of 39 milliseconds. If I connect to, if I just close this, if I connect to my RDP session where I've got this enabled, my RDP short path session where we have this enabled, hopefully the connection will be much better. So the first thing we see is that the transport protocol here is UDP and the round trip time is slightly less. So 28 milliseconds in this case. And we have seen significant improvements. Now, I wouldn't expect a massive difference for my own environment. So I'm working from home and I've got a point to site VPN that obviously goes across the internet directly into my VNet. So both connections are actually going across the internet. I haven't got express route in place, which is where you would see the most significant improvement. But it does demonstrate that there is obviously some performance improvement. So the first one of the final two is a capability that we call anti-screen capture protection. Now, this is designed for organizations in particular that work in regulated industries where they have to, by virtue of those industries, prevent the capture of content that's running in a session. So the use case here is you might have users taking a snip of what's running in the session or they might be running a screen sharing application. There's loads of them, teams, Zoom, whatever it might be, where you might be genuinely sharing your screen with some end, some customers or some vendors that you're working with. And you might accidentally be sharing your WVD session where you might have some private information that can't be captured. Now, the end consumers of that screen sharing might go and take a screenshot themselves or there is malicious software that's out there which might be running taking that automatically behind the scenes and passing that back to the host in that instance. So what this looks like is, I suppose, two things. Here, with the snipping tool, we've got a WVD session which is turned black. Now, depending upon the version of Windows, it will either turn black or it will actually completely and utterly disappear. So if you've run up the snipping tool, your WVD session just disappears. You close the snipping tool, your session comes back again. In this instance, when this was taken, we had the black screen experience. So the net result of that snip there would be what you see exactly there which is the browser, the client and then just this black box. So no content whatsoever can be shared. The same user experience can be had with teams. So this is a teams call where someone's sharing their screen and they've got the WVD session running. So we are now hiding that WVD session. Now, the problem here is it's impossible to demo this because we, as you're aware, recording this using some screen recording software which we then pick up and prevent the session from being shown. So I could show you, I could attempt to show you my WVD session where I've got screen capture protection enabled but you won't see it because WVD is natively hiding that. So the demo is not great but at least hopefully these pictures can demonstrate what the overall capability is. Yeah, I think that shows how powerful it is, Tom because you've talked about applications that we're all familiar with nowadays, teams in Zoom being stopped but we're using something called StreamYard and then I think you're trying to record your own screen when we weren't in this session and you couldn't do it. So it obviously picks up a whole host of applications that can capture your screen. So it sounds like it's going to be a powerful feature that our customers are going to enjoy or maybe not enjoy depends on what their jobs are doing. Yeah, absolutely, absolutely. Yeah, so it was a stupid moment I had when I tried this and then I thought, why is this not working? And then it dawned on me that it's doing exactly what it's designed to do. It was me that was being stupid. Anyway, so yes, it is good. It picks up, so I've never used StreamYard and I was pleasantly surprised that actually we're picking that up. That is a screen sharing application and we're preventing that access. Okay, so the final capability is this thing called Start VM on Connect. Currently in private previews and customers can't sign up for this unless they are a part of the private preview. The public preview is expected to start in February. So this is very much a sneak peek at this capability. Now this does exactly what it says on the tin which is start the VM when the user connects. Now the use case for this is obviously besides the obvious of getting the VM powered on for the user, we have some existing automation tools firstly inside of WVD natively but also inside of Azure that can do power management of virtual machines. What that means is that IT can predict when a user or a collection of users would need their virtual machine and start the VM sometime before let's just say 30 minutes before. So for a user that starts at nine in the morning, IT might say, well let's power on at eight o'clock is ready to go. Now what happens if the user starts at 10? So there's an hour and a half of cost of a VM being powered on with no one connected to it. If the user is having a half day and starts at one in the afternoon that's even more time. If they were unwell and weren't working at all then that's a whole day of expense that could be avoided if we gave the user the power to power on. In like manner if they started early let's say they started at seven in the morning there's an hour and a half of waiting for this VM to be powered on by the automation tools which is downtime for the user. So they're being unproductive and they will probably create a support ticket into IT to get it powered on. So overall not a great user experience. So what this does is it provides the end user with the power to power on their VM at the point just in time that they need it. Now there's only a couple of things that are required. This is a host pool, a personal host pool. We just surface some radio buttons to say enable this. So that's on in this instance. And the other thing is we need a custom IAM role that's assigned to the WVD service that has just the read and start permissions. And then what we do is we, there's no sort of power on button. Basically the clients will detect whether the VM is powered off and then go and power on. Actually the first thing I wanted to show you just to show that this is not any smoke and mirrors. If I go back to the Azure portal I've got two VMs here that are personal VMs in my host pool that are configured for Starm on Connect. One of them is this one here that's published to myself. So all I need to do is click on the client and this will then go and detect that the VM is powered off. Now there's a new piece of text that gets displayed inside of client called starting remote PC. If I come back to the Azure portal and refresh this you will now see that this VM is starting. Now that will take two or three minutes to start register in with the control plane. The next thing that happens from a user's perspective is that this client that you see here saying starting will then actually connect to the session. And the next thing is I'll be effectively be connected and logged into my personal desktop in this use case. So what that's demonstrated is that that VM can be powered off for as long as possible. So as many hours in a day that that can be powered off is now possible. And only when I actually need it will we start that VM. So what's actually happened behind the scenes is the WVD service has made a REST API call off to Azure Compute with the name of my session host and then asked to power it on. That's through that custom IAM role we've been authenticated. So we know who we are in terms of asking Azure Compute to power that on. And then like we're seeing here we're connecting and eventually in a couple of minutes we will actually then go and connect to that. For customers that wanna sort of learn more we do have an all up sort of root documentation for WVD which is in you see there listed as learn more. The three of those four items that are on a public preview customers can go and deploy this and get up to speed with the capabilities. There's links to each of those of the three that we mentioned. And then that start on VM on connect will be starting preview hopefully in February. And then for more information we have a number of areas. So looking back we have a what's new page what this gets updated every month with all of the features that have landed into the WVD service every single month going back. And then for customers that wanna look forward we do also have a WVD roadmap which is listed there. And then for customers that want to change that roadmap they want to add new features and capabilities. We do have a WVD user voice where you can go and submit your ideas submit your future requests, complaints, whatever it might be and then engineering do listen to the comments that placed inside of that user voice which means that potentially those features could end up on number one on backlog and then onto the roadmap and then into the product. So that was the end of my slides. If you did want to reach out to myself then I can be reached in Twitter and LinkedIn and I do have those addresses that you see there and I also have a blogging site where I blog about new capabilities and features that are coming to WVD. So yeah, if you wanna learn more have a look at my website, if you wanna reach out then you can contact me at Twitter and LinkedIn. So that's- Thank you so much Tom. That's all right, no problem. That was really interesting. What we'll do with the links that you shared on screen they'll be in the description box. So if you wanna check out the links Tom shared please do check that description box below as what I wanna reiterate to a lot of customers was something that you talked about the user voice that is very critical to how our engineering teams actually kind of manage their roadmap features and where they go. So it is massively critical that if there's something that you want, if there's something that you don't like please do head to that user voice because as Tom said, the teams do pay attention to it and that's probably how those four roadmap features that Tom's just talked about have actually come around. Yeah, absolutely. It is worth absolutely stressing that engineering aren't existing in some ivory towers in Redmond. They absolutely do listen to feedback. The number one mechanism for getting that feedback is that WVD user voice. If you've got something that's really pressing absolutely stick it in there. It will be read. No guarantees that it will turn into a product but if you've got a fantastic use case for this then absolutely it will happen. The other thing that's worth stressing is that the work that the engineering team does is prioritized as you would imagine and it's prioritized on the amount of demand for that capability. So if you've got other users or other I suppose end user computing people that you associate with who have the same problem get them to also submit exactly the same feedback user user voice and that will get it bumped up hopefully and then hopefully that will become come into that platform. So absolutely make use of that to get your capabilities and feature requests whatever it might be into the platform. Excellent. Thank you again Tom for this session. And as I said if there's any information that we want to share the links that Tom mentioned please do check our description box below for more information.