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
www.microsoft.com/mechanics