Remote Desktop Services: Updates and recent innovations

Remote Desktop Services: Updates and recent innovations

Coming up we take a first look at
updates to remote desktop. Now with deeper cloud integration from endpoints and authentication to back-end infrastructure. We’ll show you new service architecture options to improve security and authentication, simplified setup and management
leveraging Azure, and transformative app delivery and
end-user experiences. Microsoft Mechanics I’m joined by Scott Manchester from the RDS team, welcome Scott. Thanks for having me back, Simon. So that last time you were here you showed us some really cool graphic stuff. Performance improvements and enhancements to connection scale, and some cloud reddiness. What have you in the team been working on since then? We’ve been busy during the last year, Simon. We’ve continued the investments in the
cloud optimizations and we’ve added additional capabilities to our client
application and delivery experiences and we’ve also hardened our security posture. So anyone using RDS really cares about security? Absolutely, that’s one of the fundamental
reasons people use RDS. And we’ve made even better now with integration with Azure Active Directory And with that we get
advantages like conditional access, multi-factor authentication, and integration with other security
applications that use AAD. Also we get security signals from the
intelligent security graph. So Scott you mentioned using Azure AD. If anyone’s using Azure AD for Office 365 or any
other Microsoft cloud services, that’s exactly the same Azure AD? That’s right, so if we’ve already got this
Azure Active Directory setup for other services, they can take advantage of that with their RDS deployment So now let me tell you about some of the modern infrastructure changes that we’ve made. If we take a look at a traditional RDS infrastructure roles, each server would
be joined to the domain and these components would need to be on the same
network as the application and desktop host. Here because the RD gateway in the
RD web role are both domain joined and internet facing, they’re vulnerable to attack. Now with the modern infrastructure roles, we isolate the infrastructure components from the application and desktop hosts in the infrastructure roles like the Gateway and RD web and the rest of the infrastructure are no
longer joined to the domain. And because of this now we
can support multi tenant deployments. And notice one other change there’s no RDVH role now. We’ve brought that same capabilities for VDI managed directly into the connection broker. And we’ve also added a new role, Diagnostics. This new role collects information on the
health of the deployment and can be used to troubleshoot
end-to-end connectivity problems. And finally the application and
desktop hosts no longer require open inbound ports. They establish an outbound
connection to the infrastructure using port 443. So all these architectural
changes are going to give people a lot more flexibility for running this infrastructure outside
of their own domain. I can see this has been really
appealing to hosters since they no longer need to actually connect to the
customers domain. Absolutely, hosters will be able to stand up a single RDS modern infrastructure deployment
and service multiple tenants. And if hosters are playing into Azure,
they’re really going to love this. Because in Azure now they
can take advantage of installation of the roles as Paas services. So you no longer need to manage the VMs individually, and you get seamless
elasticity and scalability that comes with Azure. Also we support hybrid deployments. So you can have the application and desktop
hosts on Prem or in the cloud in a separate environment. And that brings all of those increased advantages with regards to seasonal workers, vendors and the like
who may be accessing from different environments or might be just accessing occasionally. You also mention improvements in delivery options,
what you’ve been doing there? We’re expanding our remote desktop client portfolio to
bring virtualization to any device. We continue to support Windows, Android,
iOS, and Mac. And now we support html5 and
the new Windows 10S edition. So Scott, this is all sounding pretty cool but can we see some of this in action? Absolutely,
let’s start off with the security demo. So I’ve already set up a deployment
here where I’ve got all my RDS infrastructure in Azure. And I’ve also set up another V net with
a bunch of VDI instances. So now I’m going to access
that deployment using our new test application that’s been enlightened with AAD. So I could have set this up so my
users use single factor authentication. But how cool is that? We’re going to use two-factor auth. So I’ve set up this user 3 here to require two-factor authentication. So let me login to the client application here. So first I’ll provide my username and password. Now it’s asking me for a
verification code. So here I have my iPhone device and
I’ve got the Authenticator app. So I’m going to provide the security code
being presented to me here. Click sign in. And voila, there you go. So now I’ve been able to get a list of all
the available resources that are part of that
deployment using two-factor authentication. So the first live demo of
two-factor auth using AAD with RDS. That’s really impressive. This is actually going to really help people to increase their security posture for the login and also you get all of those benefits of MFI and conditional access
and the Microsoft intelligent security graph all for Remote Desktop Services. Can you explain actually what’s going
on behind the scenes? Yeah so let me
show you how this works. So our deployment here is in steady state. We have a remote desktop clients, we’ve got the new RD modern infrastructure and we
have our application and desktop host. And we’ve also setup the Azure Active
Directory deployment for authentication. So in steady state, all of my application
and desktop hosts maintain an active connection to the infrastructure. and we use this connection to ascertain the resource availability in the deployment. So let’s go through a typical connection sequence. So let’s say a user on a client
device wants to access a line of business app and their IT admin has made
this available through an RDS deployment. When the user attempts to access the
RDS deployment, the user is asked to authenticate against Azure AD. Azure AD receives the authentication request and performs all the necessary checks like
conditional access policies and MFA. And assuming all the conditions are met, a token is passed from Azure AD back to the RD client. Then the RD client
presents this token to the RD web role. And gets a list of the available
resource for that user. And then does the user go and launch the app? Yeah from that point in
time the application is in the client application. So the user can click on the
application to launch it and then the token is presented to the infrastructure which then again authenticates the user and determines what’s the most
appropriate resource to connect the user to. The infrastructure then converts the
token to a certificate and logs the user on to that domain joined application host and orchestrates a connection back to the Gateway. The Gateway then completes
the connection between the Rd client and the application host and the user can
now run on a line of business app. So in this configuration my application my desktop host
are domain joined but nothing else is Absolutely. So the application desktop host stay domain joined like they do in a traditional RDS deployment. The only difference here is that now they don’t have to have an open in-bound connection. They establish an outbound connection on port 443. Wow that’s pretty cool, okay that’s security. Can we delve into some of the other things like the modern infrastructure on Azure that you mentioned? Yeah let’s take a look at a
typical deployment in Azure. So let me switch over my machine here. So this is my dashboard. And I’ve already configured an RDS modern infrastructure deployment into Azure. And I’ve got it pinned to my dashboard here. So let’s drill into it
and take a look at what we’ve got. So the first thing I want you to notice Simon
is that there are no VMs running in this at all. This is all running as PaaS. So I’ll go through the list here, we’ve got our broker running as PaaS, Diagnostics, Gateway, Rd web, and even a key vault that we’re using to store all the
certificates for the deployment. And the data base also is running as a PaaS service. So the database is maintaining all the
state of my deployment. What applications I’m hosting,
what users are supported. So with that let me drill into
one of these web apps and I can show you how we’ve configured
it to support a dynamic scale-out. So let me click on the RD web, here. I’m going to go down to look at the scale-out
plan I’ve set on this already. So I’ve set a couple policies, here. So let’s say it’s early in the morning, and we’ve got a lot of users that are all trying to
connect to the deployment at the same time. When my resource utilization on my PaaS
service goes beyond 70%, then Azure will automatically add another instance. And then there’s a little debounce
time of about five minutes for it to stabilize and redeploy across
those multiple instances. Now let’s say it’s the end of
the day and everybody’s gone home. And now the utilization of these PaaS services
has dropped below 30%. So now what will happen is it’ll actually
drop off one of those instances and then load balance the rest of the work. So as the needs increase,
the system can expand. And as the needs subside,
the system gets smaller. So now I’ve got automatic scaling
of the size of my deployment without any IT overhead. And this can significantly reduce
consumption costs in Azure. I was really impressed by the way you
actually used key vault inside of that. But this is a really good example of that elasticity that you get from moving from IaaS to PaaS roles You get to take away all the management with patching. It’s going to really take away a lot of costs from running on RDS infrastructure. I also picked up in that you mentioned
that there’s no RDVH role anymore? Yeah that’s right, by eliminating the RDVH role and having the
broker talk directly to the VDI instances, we can now support VDI
management in Azure. Also by separating the infrastructure from the application and desktop host, we can also support multi tenant and hybrid deployments. Very cool so the last piece that you
mention at the start was application delivery. What have you been working on there? Yeah let me close with a really cool
demo on that, Simon. So let me just switch tabs here in my browser. And I’ve already established a connection using our new html5 client to my deployment. And what you see here first is the list of the applications and even a desktop that’s been shared with me. So let’s launch one of these applications, here. Now under the covers,
I’ve signed into this using my AD credentials. And it’s going to log me in
using the certificate to the VM. And voila there we are we’re running this application. So let’s don’t stop there let’s run a second application. So I’m going to bring up my app bar here, run a second application here also. And see how fast that second application launched. So once I’ve established a session in this instance, now I can quickly switch between
these different applications. Let me also show you a full screen. So here in full screen I think if
you walk right up to this machine, I don’t think you even realized that this
is actually running in an HTML browser. No that’s really nice that is all
browser based. This provides a lot of new opportunities for users. Let’s say that I was traveling and
I didn’t bring my laptop with me. And I wanted to sign in to a line of business app back in my workplace. And all I need to bring with me is my
username and password. And if my IT admin was smart
and he setup multi-factor authentication, I might have to bring my phone also. But now I can quickly
get access to those resources, get that work I need to get done, and log off. This also is a very cool scenario
for kiosk type of scenarios or a shared workspace. So I can set up a single machine with just a
browser and no application deployment or anything. And then have users throughout
the day just log in via browser, do their work and log off. Very simple for IT admins to set up and very cool scenarios that are enabled by this. It’s been fascinating to take this kind
of a look at some of the capabilities that are going to be coming soon to RDS. And how you and the team are
actually really innovating in this place. What do you recommend for these folks as
the next step? We’ll have all of these out in preview soon. So stay tuned to the RDS
blog and definitely join us at Ignite. And follow me on Twitter to get more
details on what’s coming. And of course keep following us on Microsoft Mechanics for the latest in tech updates. Scott, thank you very much for joining
us on the show. And we will see you the next time. Microsoft Mechanics

10 thoughts on “Remote Desktop Services: Updates and recent innovations

  1. I need to watch the full video, but I can't help but think about MS Continuum for Phones when I see RDS – I know W10M isn't exactly talked about at Microsoft anymore and many are hoping it's slips away completely but there are great opportunities here for a single device that can do everything when you combine something like the HP Elite X3, Lapdock and Desk Dock with an RDS setup for accessing legacy apps.

  2. These new Remote Desktop modern infrastructure (RDmi) roles will be coming out early next year. We will be announcing public trial details at Ignite next week. Follow us on twitter @RDS4U to get all of the details.

  3. I would love an update on this. I've been scouring the blogs but can't find any further mention of this technology.

Leave a Reply

Your email address will not be published. Required fields are marked *