Hey friends.
Azure Virtual Desktop enables a secure, remote desktop experience
from virtually anywhere. But
did you know that Azure Virtual Desktop has built-in diagnostic capabilities?
Virtual Desktop Insights is a dashboard you can use to understand your Azure
Virtual Desktop environments.
And Ben Murphy is here to show me how it works, today
on Azure Friday.
Hey, friends, I'm Scott Hanselman and it's Azure Friday.
I'm here with Ben Murphy. How are you, sir?
Doing well. How you doing, Scott?
Very well.
You know, Azure Virtual Desktops taking over.
Everybody's moving into the cloud and I assume that they have to
observe all of those resources, especially if you have hundreds
or thousands of these running your whole company.
Yeah, absolutely.
Observability is really critical for Azure Virtual Desktop
and really any virtualization solution.
Yeah.
So those insights that you're going to get, you can't just think about this
on a one by one basis.
You might want to debug one person's particular item,
but you also want to think about
like the health of the entire company and how they're doing.
So can I do macro and and micro analysis?
I'm excited to see how this works.
Yeah, that's a great question.
And yes, absolutely.
So that thought process is exactly what we put into Azure Virtual Desktop
Insights, where you've got the ability to look across all of your resources
and then you have the ability to dig down into specific cases
for either individual users or individual session hosts.
And we can take a look at that functionality today.
So we'll start off with kind of a top level view.
Alright, Let's do it.
Alright.
So I'll go ahead and get us kicked off.
Effectively, Azure Virtual Desktop Insights
is a native monitoring tool for Azure Virtual Desktop.
Now you can access it directly in the AVD menu area.
There's an Insights area that's overall, which is what we're going to start with,
which is an overview of all of your resources.
You can select multiple subscriptions, multiple resource
groups, multiple host pools and see them all in one place.
Then I'll introduce you to the lower level of information,
which is data that's specific to individual host pools,
which are collections of session hosts,
and give you the ability to look at performance characteristics
for groups of those session hosts or individual session hosts.
So we'll get into that in a minute.
But the starting point here is an overview of my
AVD estate.
So I've started off
with this set of 23 host pools that I've got in my personal environment.
I've got 45 session hosts distributed across those different host pools,
five of which are personal, 18 of which are pooled.
Now, this overview is just to give you an idea of what's active right now.
So effectively, how many hosts do I have?
How many users do I have active currently?
What kind of capacity do I have over time?
Things that help me understand utilization,
which we'll take a look at in more detail in a second, especially when it comes
to cost optimization and insights about activity.
Other items that you can identify here, though, include things
like the number of users that are having challenges connecting to the environment,
which we'll take a look at in the connection diagnostic tab,
the amount of time it takes for sessions to actually start, for users
to be productive, to look at that in the connection performance area
and then an overall summary of utilization.
So exactly how many active users do you have on a daily basis?
How many connections do you see on a daily basis?
And we can get into some more specific details about that.
But to get into the core functionality,
I'll introduce this Connection Diagnostics tab.
So one of the big questions that a lot of customers have about AVD
Insights is are my users able to connect to my resources
successfully and can they stay connected?
So the Connection Diagnostics tab is designed to give you a view
across your environment of all of the different users
that are accessing AVD and the success or failure of those connections.
So here we have the ability to show you a trend
and you can really quickly see if there are points in time
where there's a failure, the ability to dig in and diagnose
who was it that was impacted by that failure, what kinds of failure
events do they have and the errors that apply to them?
I can also graph that over time.
So effectively giving you an overview of are there time periods where my success
rate drops below what I consider to be sufficient for my environment?
So we're not going to go exhaustively through this.
But the other stuff in there includes stuff like error analysis and basically
mapping users that we anticipate probably are having issues and articulating
what errors are kind of unique to them for troubleshooting purposes.
The next area we'll take a look at is connection performance.
So this is really important if you're trying to maintain
a good quality of connection experience for someone.
Sessions are really influenced by latency, as you would probably expect
in that roundtrip time,
latency is measured and presented here effectively.
You want to have below 150 milliseconds of latency, give or take,
and here we can very quickly identify when people
are out of keeping with that and what region they're coming from.
So in our case, we have a tendency to have higher latency
in Japan East and Northern Europe.
And this highlights not only where that's happening,
but we can actually see which users are impacted by it
and what session hosts they're attempting to connect to work
with this higher latency.
So this whole tab is dedicated to that purpose.
Now, one thing I'm going to dig into in a little bit
more detail is overall utilization, because this is a really critical use case
for a lot of people using Azure Virtual Desktop, which is essentially this
how do I optimize the cost of my environment
and make sure that when I need session hosts, they're around and available
for connections When I do not, they are either off or
basically saving me money through the use something called the scaling plan.
So I'm not going to exhaustively go through what auto scaling is.
We do have a separate series on that, I think available somewhere,
but instead I'll highlight this is how I make the decision
of does auto scale make sense to me?
So the utilization chart in here is very useful,
especially when you look in the aggregate to try and find specific host pools
where I can optimize things for either my own cost or for user performance.
So this overview gives me some really important stuff.
Basically, how many sessions do I get in each resource group?
What kind of
activity do I see and really critically
are idle sessions causing me to have session hosts be used
but not actually driving real what I would call consumption or user productivity?
So this chart is really important.
It outlines how many active concurrent sessions overall I have.
The other really important part, though, is idle sessions.
So effectively an idle session in this case
is what we call a disconnected session, which means that somebody
has just left their workload running on a session hosted somewhere.
They may or may not actually be doing that on purpose.
So this highlights an important thing, which is the ability for customers
to turn on the ability to automatically sign people out
after a fixed amount of time, which in this environment we're not doing.
So that can be a good first pass. Yeah.
Quick question, though, When I'm thinking about different kinds of workloads,
there's the I'm in office, I'm in the middle of Outlook and I walk away.
That's true idleness for two reasons.
A the CPU's doing nothing and they're not moving their mouse.
But then there's the I'm a developer and I'm running a build
or I'm a, you know, I'm a light developer
and the build is running, so the CPU is active.
But I walked away. How would I think about something like that?
Yeah, it's a great question.
And in practice you probably need to evaluate
what it is that the users are actually intending to do.
This is mostly just high level observations that for the most part
when someone leaves workload and what we call a disconnected state,
it's non-interactive.
So you're right, there are plenty of cases where a developer might start
a build, let's say, and this is totally expected
in those cases, there's really not a lot to do,
but in a lot of cases, customers will, as an example, not be really good
about logging off and instead will disconnect from the session.
And in those cases, that's what we're trying to highlight is basically
here are resources that we anticipate are not really being used
for a business purpose.
But you're right, there might be some cases
that are exceptions. That make sense.
But what I'm hearing, though, is
I've got the metrics that I need to ask the right questions.
So there may not necessarily be an answer
for all of them because it depends on the workload
and the company in the size and the scaling.
And you also pointed out that you're going to be optimizing
and that word is generic,
but you're really talking about optimizing experience, optimizing cost,
optimizing latency, optimizing max users per core.
These are all different
things that every customer is going to optimize differently. Correct.
Yeah, Every customer is going to be a little unique.
They're going to have kind of different portfolios of applications that they have.
They're going to have different user expectations.
But you're exactly right.
Our intent is to try and provide telemetry and metrics
that are useful for administrators to make the right decision about what to do.
So to the point of efficiency of usage.
Another chart that we have in here that's really important is max users per core.
Effectively, this is a representation of how efficient your workload is.
So in a very efficient case, you'll have a lot of users
that fit per core, especially in a multi-session environment,
which can be a good cost saver in some cases where users have a lot
more resource intensive activity that users per core can drop off,
which effectively means
they're more expensive users or they have more advanced workloads.
But this is a way that you can basically see
how many people can I fit on one given size of a session host.
The next bit that's really important
and I'll focus on this a little bit in terms of what I referred to earlier,
Scaling plan is this, which is an overview of how many overall
session hosts do you have turned on at a particular point in time?
So in this particular sample environment, you'll notice
that we've got a lot of what we refer to as idle posts.
So basically to think of it, this top
is how many session hosts do I have overall?
So at this particular point in time, let's say I've got 21 session hosts
that are active, However, 14 of them are idle.
So in this context, idle means nothing is happening on them at all.
There's no disconnected session, there's no activity.
They're just sitting there driving Azure compute resource costs.
So the big question is do I want those devices to be on and available, yes or no?
Now in the case that you would like to try and optimize your costs a little bit,
this is where we can start to dig into this idea of developing
a scaling plan and effectively when I don't need all this excess capacity
and let's say that I can very easily understand when people are active,
I can set up a schedule that will basically
let me have a minimal number of hosts active at a time
to still have capacity for people who sign in
and then manage the case that I get maybe unexpected activity
or I've got expected activity throughout the day that I can ramp up and ramp down.
So this can be a real cost savings opportunity. Right?
So I'm hearing that you're in control because everyone's experience
is different.
It might be something where at your company, for reasons
people are leaving for 30 minutes and they need to come back
and have instant, instant on.
But you might be in a different company where after 5 minutes or 10 minutes
you log folks out and you suspend those sessions.
It really just depends.
But I'm hearing with these metrics and with Virtual Desktop itself,
you have full control.
Absolutely.
And that's exactly the intent here, is to try and provide as much information
as we can to make sure that administrators
are enabled to make the best decisions that they can.
So from a cost savings perspective, this can really help out
quite a bit because as you can imagine, if we could turn off,
you know, 12 of these idle session hosts, let's say, at any particular point,
obviously that's going to have a pretty large knock-on impact
on the amount of Azure costs that I'm incurring.
So the final thing that I'll take a look at, at this kind of top level view, again,
just as a reminder, we're looking across all of your AVD estate right now.
We're going to take a detour to a specific post for a second.
But the last thing we'll look at in the aggregate is this: clients.
So another really common customer question is, are my users
attempting to connect to the service in a way that I don't expect?
So maybe using the web client versus using the MSRTC or remote desktop client?
Or are they using outdated versions of the client
which can really adversely impact your ability to interact with the session?
Because we introduce new features,
we make performance improvements all the time, optimize the experience.
So this clients tab is really useful to give you
an overview of one, how are people actually connecting to the service?
So in our case, we've got a pretty robust set of different types of clients in use.
So we've got a lot of Windows users, we've got some Mac OS users,
some iPhone users, we've got people on Android.
But the real magic to me is this,
which is the ability to highlight as an example
the MSRTC client and identify in particular
what version is it that we think should be used.
So in our case, we've identified the latest version
and we've seen that we have 225 connections
that actually have outdated versions of that client active.
So I can expand.
Get to the details of what specific users are having that problem.
I can even identify client names, let's say
if I would like to propagate out an update to update the client.
So it's very within my control to be able to manage the version that I've got.
But this gives me the visibility that I need to have to know,
are users not keeping up to date with their client resources?
And of course, because this is in a workload -
in a workbooks format using Insights, I've got full control of the report.
I can go and export it, push it to my team that manages updates or MDM.
Again, the ability to do whatever I want or just email them and say, "Go and update."
It's really up to me,
correct?
Yeah. You do have the ability to manage this on your own.
I will note that if you do choose to customize this
when we make updates, I would highly encourage you
to check back in and update your customized version of the workbook
because we're adding new tabs all the time,
basically updating functionality.
We're also introducing new diagnostics in the future.
As an example, we have connection graphics data in preview
as part of our diagnostic pipeline for AVD that will end up getting surfaced
in insights in the future.
So just keep an eye out for that.
So to be clear, I if I'm using Azure Virtual Desktop, I have this now,
I don't need to sign up for this. I just need to start using it.
Absolutely.
And that's a great question.
Prerequisites, you just get this out of the box so it does not require
any additional configuration or deployment of your own workbook.
To be very clear, what it does require is diagnostic settings for the host pools.
Those need to be enabled.
You also have to have some form of data
collection on the session host in the form of an agent.
So we are in public preview with the Azure Monitor Agent currently.
Or you can use the email or Microsoft Monitoring Agent, which is part of the Log
Analytics offering.
We configure that for you though.
So all the stuff that I've shown you thus far can be configured
directly and automatically via our Configuration workbook.
This lets you configure what workspace you would like to send stuff to.
So as an example, I can just pick an arbitrary Log Analytics workspace.
It effectively lets me manage all of that configuration stuff
without having to go through
kind of the manual process of checking the boxes, deploying the agent.
This stuff is all done for you,
so this helps
you kind of streamline the process of configuring
performance objects in this case, I've got everything preconfigured.
That all comes naturally with AVD.
So no additional setup.
The only cost that's associated with this is the ingestion
cost for the diagnostics data.
Very cool.
Alright.
Well, folks that are watching and myself who are using Azure Virtual Desktop,
I need to get on board.
All you do is check out your Azure Virtual desktop insights.
You've got that full self-hosted data environment available
for all the different data that your insights could produce.
I can look at everything.
I can look down into the little details
and see disk access, or I can look at just something like idle sessions.
Love it. Fantastic.
Thanks so much for sharing this with me today, Ben.
Perfect. Thanks, Scott.
I appreciate it and thanks for the time.
All right.
I am learning all about how to monitor my Azure virtual desktop deployment
with Azure Virtual Desktop Insights today on Azure Friday.
Hey, thanks for watching this episode of Azure Friday.
Now I need you to like it.
Comment on it. Tell your friends. Retweet it.
Watch more Azure Friday.