welcome back to the az140 study guide
for your wvd
specialty certification and in this
episode we're going to get into all the
things around your fs
logix profiles let's get into it
[Applause]
i'm dean sefola and this is the azure
academy in our last episode we planned
for our fs logic
storage and now that you understand all
of that we can plan
for the profiles that will go on that
storage
so we need to understand what a profile
is the options of our profiles
and how they can all be configured along
with the best practices
so let's start by talking about what
fslogix profiles
do they are designed so that you can
roam your windows
profiles from one virtual machine to
another
and perhaps you've used a user profile
disk or
roaming user profile in the past fslogix
is very similar but superior in my
opinion in areas of performance onedrive
integration
additional folders folder exclusions
just to name a few
and your profile will be stored as a
virtual hard drive
and that will be located on a smb file
share in
azure and with that comes a lot of
native functionality
things like native backup disaster
recovery scale
performance and we covered all that
stuff in our last episode
now when your user logs on the profile
that's stored in that smb file share as
a virtual hard drive will be dynamically
attached to the session host virtual
machine
once the profile is attached to the vm
it appears and functions
exactly like a native user profile so
what does all that mean for you
it basically no longer matters which
virtual machine your user lands on
in your host pool because all of their
files and settings will come with them
and those files and settings think that
they're all part of a normal standard
local windows profile and everybody's
happy and this also means that when you
need to upgrade
your vms and replace them with newer
models or you've lost a vm for some
reason
no worries because your user data is
safely stored
somewhere else and the next vm that they
go to log on to
their profile will be mounted and
they're good to go now there are
lots of different features in fs logics
and if you use it in another kind of vdi
environment you might be thinking that
you should implement it the same way
in wvd but i want you to think
differently
so let's talk about the specific things
you need to consider
when planning your profiles and first
off
there are two different profile
containers in fslogix
user profiles and office profiles now if
you've seen the other
two deep dive videos i did on fslogix
you'll know that in windows virtual
desktop you really don't need this
office profile
now there could still be a few reasons
why you ultimately want it in your
environment but you really
don't need it because all that office
data
is inside your user profile so what kind
of data are we talking about
well it's the persistent data that makes
your user profile
unique it's the files that are on your
desktop your documents pictures
music videos but it also contains
configuration information
like desktop settings persistent network
connections application settings
and don't forget about all of that
office profile data
from things like onedrive onenote
outlook sharepoint
skype and teams basically it's
everything that gives your users the
look and feel
of their windows experience and all
their personal data
so now that we know all of that you
should also know that this is the
default
implementation of fslogix to only use a
user profile
however as i said you can separate that
office stuff into its own profile
so what's inside there the office
profile is made up
of cached data and one of the best ways
to illustrate that
is with email your email lives on the
exchange email server but to make
performance of the outlook
client a better experience for the user
outlook can
cache that email locally and that
outlook cache would live
inside the office profile and it's the
same basic principle for teams or any of
the other office apps that i mentioned
and since these two profiles are
different kinds of data
persistent and cached data you might
want to
separate them to be more efficient
because separating them means you could
put them on
different file shares which could be
made up of different sizes and
performance characteristics this would
also allow you to protect
that data differently for example your
user profile should be backed up
it should be replicated in case of
disaster recovery
the office stuff does not it is cash
data
and if something happens and you lost
your office profile
nobody is going to care because the data
is just going to re-download from the
server and cache again
this also frees you from having to
manage the office profiles
now both the user and office profiles
will grow over time that's just what
they do
but when a user profile gets too large
you need to do
maintenance on it to shrink it and
there's a link right here to a tool that
jim moyle developed and that'll help you
to automate the process of cleaning up
your user profile so
big thanks to jim for that one but your
office profiles you don't really need to
do that at all so that all sounds like
pretty good stuff so why would you
not want to use the office profile you
know why is the delete function of
fslogix to only have
a user profile well like i said for one
all this data
really lives here already by default so
adding the office profile into the mix
means you have now more steps
more configurations more management and
more troubleshooting
and there is also a way to have the best
of both worlds by not having this cash
but also not keeping that data in your
user profile
and in my deep dive videos that i
mentioned i show you how to do
exclusions which is where you can take
things like the team's cache
data and just not have it included or
protected
inside your user profile at all which is
great because teams in particular is
about five gigs worth of storage
and who wouldn't want to save five gigs
for every user that they have
so now that you understand the two
different kinds of profiles
let's talk about attaching them to your
wvd systems now this happens in two
different ways
the first one is called vhd locations
and what that basically means is that
when you read or write any data to your
profile
you are communicating directly with the
file share
now this is very different from how
cloud cache works
cloud cache will actually create a
little hidden space
on the c drive and perform all of the
rights
locally once those writes have been
written then they will
replicate out to the file share and both
of these will give you the option to
write to
multiple shares so that you have some
measure of redundancy
cloud cache however gets an upper hand
here
since it's writing all the data on the
session host itself and then replicating
to storage
you could look at it more as a disaster
recovery tool because in vhd locations
if you lost the file share
all of your users would lose their
profiles now when they go to log back in
fslogix would see that they can't access
the file share anymore and it would go
to the secondary
share that you have in vhd locations and
they could get back to work
in the cloud cache scenario it would be
like nothing happened
yes you would lose connection to the
file share because it's gone
but all of the rights still happen
locally
so it would see that the primary share
no longer exists and it would just
make the secondary the new primary until
the original primary came back online
and then it would take care of making
sure that they're all in sync so cloud
cache does
quite a lot and because of that that's
the one
downside of cloud cache is that it does
take
longer for each user to log on to their
session by a couple seconds
now the one thing to consider here is
that if the outage happens for too long
and you don't have any secondary shares
couldn't you fill up the c
drive well in theory yes you could but
like i said already the easy fix is to
have
more than one file share and if you're
doing disaster recovery in your scenario
you should have that set up already
so no problem but another thing to
consider in cloud cache
is local c drive performance in azure
all drives have a specific size and that
size
gives them certain performance
characteristics so all things being
equal
10 users with cloud cache writing their
profile data to the c
drive will have half as much impact as
20 users would
i mean that's just simple math so if
you're thinking with going with cloud
cache and are planning on some high
density numbers
consider the size of your c drive you
may need to bump it up so that you get
the performance locally that you need
and if you might be thinking at this
point well why don't i just get another
drive and put that on the system
and have cloud cache right there i mean
that'd solve the problem of not taking
down the c
drive right and yes you would be correct
however i don't generally recommend this
because having another disk in the mix
means more management
cost and it's just one more thing that
may go wrong and why would you do that
to solve the problem when you could in
your provisioning templates that i'm
sure you're using in automating
you could just change a single number
and increase the size of your c
drive to whatever levels of performance
you want and then you don't have to
think about it
so let's switch gears here a little bit
because there are three different kinds
of host pools
which means there could be three
different types of users
and i've said it before and i'll say it
again the best practice here is to have
one host pool to one file share so
speaking of host pools we of course have
our pooled
desktop host pools remote application
host pools
and personal host pools now generally
speaking
personal desktop users don't need
fslogix
because remember the purpose of fslogix
is to allow your users
to go from vm to vm and have their
profile
follow them and for personal users this
is just not the case
because that user has been assigned to a
single dedicated vm
just for them and they're going to log
on to that same machine
all the time so their profile doesn't
have to go anywhere so they really don't
need that
and i did go deep on a section of
fslogix that's called concurrent
connections in
my other videos so that's not a feature
that i'm really going to spend any time
on here
and i'll just say that even though it is
fully supported
concurrent connections are highly
discouraged in wvd
because i said the best practice is to
have a unique file share
for each host pool but let's move on and
talk about remote app host pools
should you use fslogix here that's
really going to depend on the
applications that you're hosting
see there's two different kinds of
applications basically speaking
those that are presented as is and those
that can be personalized and configured
take a web browser for example you don't
need to customize a web browser for it
to work
all of the configurations and extensions
could even be set up by it
centrally for everybody however you can
have a more
personalized experience logging into
that web browser that gives you your own
look and feel and your favorite
bookmarks and all that stuff and if you
want that second experience
the only way to preserve that is to have
a profile that maintains that data
so always remember to consider your
applications when thinking about remote
apps and your profiles
then we have our pooled desktop users
and this is generally
the fslogix hero solution but i'll also
say that it depends on what the users
are doing for example if your wvd
environment is set up for nothing more
to be
a jump host into your existing
environments
then no profile needed in fact if you're
creating a jump host environment you
should protect
that jump host and lock it down with
something like app locker
so that the users can only start the
applications that they need
to function as a jump host like putty or
rdp
but that's another episode so let's
shift gears
again and talk about antivirus whenever
you mount any kind of drive whether
that's a usb
drive or a virtual hard drive over an
smb share
the local system is going to want to
scan that with your anti-virus tool that
just helps keep the system
safe however in the case of fslogix
if you're doing that then you are
actually causing the entire user logon
process
to be slower as well as impacting
every user who's already on the machine
because the cpu
is going to look at the antivirus as a
high intensive process
and it's going to dedicate all the
resources it can to antivirus scanning
now of course you could tweak that but
there's a better way to deal with this
and that is through setting up antivirus
exclusions
for fs logics now hear me out these are
the list of things that you'd want to
exclude no matter what the antivirus
tool is that you're using
but don't misunderstand you should
absolutely be
scanning your profiles we just don't
want it to happen when the user is
logging on to wvd
those scans should be done at the file
share level
separately and the host itself should be
excluding
fs logics as well as virtual hard drives
so that way the performance of wvd stays
up and your environment stays secure
now the list of all of this don't worry
about copying it is down
in the resource section below along with
the other links for today's episode
and if you're using a antivirus tool
like windows defender
or endpoint configuration manager this
can all be implemented through policy
and with all that knowledge out of the
way we have one last thing to talk about
in today's episode
and that is the best practices that you
need to be aware of
now i would memorize these because there
is a test
and of course there are many other
settings than what i'm about to tell you
and
that is linked in the description as
well so you can go to the fs logics doc
and look up all of those things
but the very first one that i'll mention
here is called delete
local profile when vhd should apply
now the reason for this is because in
windows profile logons
sometimes things go wrong maybe
something happened where the user didn't
have the right permissions
to fs logics and they could not mount or
create a profile
but for whatever reason the user ended
up with a local profile on that
particular bm
now you don't want to have to do
maintenance of checking around on every
virtual machine
if sally's profile is there so this
setting in fslogix will do that for you
anytime sally would go and log on to a
vm if there was
a local profile that profile would be
deleted
and sally would use the fslogix profile
instead now that's great because sally
will have the user experience that she's
had on every other machine
this can be bad if you're implementing
fs logics in any existing
environment because as the name implies
it will delete
the local profile so if you're
implementing fslogix in an existing
environment be
cautious with this setting make sure
that your user's
data and settings are all backed up into
one drive or on a file share centrally
before you implement this one but it is
a good best practice for all
new environments this next one is called
size
in megabytes this refers to new
virtual hard drives being created for fs
logic profiles
so if you already have a profile in
existence and you set
size in megabytes to be whatever it is
that you want
it's not going to do anything this only
works on new
disks and the recommended size for this
is 30 000 megabytes which is
30 gigabytes now why 30 gigabytes this
is a good
upper limit to set because people hardly
ever get there
and you will have a couple users of
course who have you know a profile of a
hundred gigabytes
and they'll have to do maintenance on
those guys but for everybody else
setting it for 30 gigabytes means you
can pretty much set it and forget it
now some of you might be thinking i must
be out of my mind because if i have
30 gigabytes for every user and i've got
4
000 users and we do the math properly
then it's 30 times 4 000 is 120
000 or 120 terabytes worth of space
see i can do math unlike in my last
video now some people will be very happy
to pre-allocate however much space they
need and then never worry about it
other people don't want to do that at
all so there is another
setting and although not technically
part of the best practices
but you can implement dynamic disks
which means the actual size of every new
profile disk you create will be
zero and then it will fill up with space
and if you prefer that approach in your
environment that's great
but it will take a little more math and
maintenance just to keep an eye on your
file share
that you don't run out of space but
either way it's up to you
i won't judge another best practice is
that of
volume type so when you create your
virtual hard drive you've basically got
two choices
dot vhd files or dot vhd
x files now the best practice choice
here is dot vhdx for one it's a newer
format for another one it allows you
more capabilities with powershell and
maintenance
and you can also implement those dynamic
disks and the last best practice setting
we'll talk about today
is flip flop profile directory name
this is to make it easier for you to
search for specific profile
containers and user folders on your
network shares so the default behavior
of
fslogix is to create this long guide and
then attach the username at the end
this flip flop profile directory name
setting will
flip flop it so that its username first
and then
the long guide and that'll just make
things easy for you to find
and there's a whole bunch more inside
the fslogix docs
in the resources section below like i
mentioned earlier so go and check that
out
so the important things to remember from
today's episode
is that you only really need a user
profile in wvd
but you should understand the office
profile so you know when it's good to
break it out
and you should be using one host pool to
one file share for your profiles
your profiles should not be using
concurrent connections
set up your antivirus exclusions to keep
your performance in your environment
good
and always configure those best practice
settings and make your decision
if you want to pre-allocate everything
with sizing megabytes or use dynamic
disks
and in both situations you should be
using vhdx files and flip flop that
directory name to make things
easier to find and in your new wvd
implementations
always use that delete local profile
when fslogix is found
but consider carefully before you
implement that in an existing
environment
and there's a couple more things that
you should always use like the subscribe
button
the like button the share button and the
more that all of you click on those
things that tells youtube that you like
my content and it should be shared out
with more people
which just helps the azure academy to
help more of you
but not only that it also earns you
magic bonus points that you can use on
the next azure academy video which is
right up there
or you can continue with the az140 study
guide
down here at the bottom thanks for
joining me today and i'll catch you in
our next episode
happy learning