Day 37: AZ-140 Pt.4 - Managing Users & Apps - FSLogix


Section 4: Manage User Environments & Apps (20-25%)

Implement and manage FSLogix

The below should cover the following criteria for this section of the exam:
  • Plan for FSLogix
  • Install and configure FSLogix
  • Configure Profile Containers
  • Configure Cloud Cache
  • Migrate user profiles to FSLogix
In the below steps, it should be noted I am not going to say click this n that, I will give a general overview but you will need to fill in the gaps with your knowledge of Azure.

Plan for FSLogix

So we've already touched on FSLogix in our planning phase and gold image.

However, FSLogix is essentially split into a few factors:
  • Profile Container
  • Office Container
  • Application Masking
  • Java Version Control
Profile & Office Containers

In traditional environments, you want a user profile to follow you around. On laptops and desktops, normally everything would stay on the machine itself, which is fine and great for performance and space, but its limited in the fact if that machine dies, then your stuck.

In virtual environments, you try to replicate the above but give some resilience. In comes things like user layers in a Citrix environment. The profile is stored on a server, somewhere - ideally a stones throw away from where the actual host for the virtual desktop is. The profile will load and attach itself seamlessly in the background for the user as a .vhd file, but to the user it's just for example a C:\ drive.

These types of profiles are great, but what FSLogix allows us todo is split up the profile a little more, split off some of the tasks each do a little more.

So, for example the profile and office containers are split up meaning if an issue arises with the office profile, it can be safely removed and not affect the user. In traditional Citrix environments, you're stuck with the user profile and if that's corrupt, then a a lot of time is spent rebuilding that, which means a few things.
  • User has to install and configure everything, this includes any custom apps not layered for the user.
  • User has to load up outlook again, and download the .pst file, which is taxing on the vm i/o and net.
  • User has a lot of downtime due to the above, might need ongoing support from the service desk.
  • It undermines the benefits of virtual environments.
So, essentially lets use FSLogix for the user and office containers to help with the above, in the end only having to fix 1 issue is better than having to start over in the extreme cases. 

However, its worth noting that best practice is to have just 1 profile, so it depends on your environments and how you want to split up the profiles.

The following link goes into more detail, I think this will be a big thing in the exam so definitely look this up.

Application Masking

App masking is essentially a fancy way of managing your applications, essentially you would install all your "base apps", so apps everyone uses onto the gold image, and then whenever an app would need updating, you could do it from one location rather than having to mess about with multiple images. 

You control how that app is masked, who can access the apps etc. via rule sets.  Personally, while this is great I don't see a need for this in my environment as I will be using MSIX, plus it doesn't work with Linux (nor does MSIX yet either I think, imagine that will change however I'd rather containerize my apps) - you can find more details about app masking then use the below link.

Lastly, in using MSIX for my WVD environment I can also leverage this for other environments, meaning less duplication of work / migration down the line should it be needed.

Install and configure FSLogix

Installing FSLogix was covered in my gold image post. 

However, in regards to configuring the actual containers I've not done anything. 

I haven't yet specified a location for that nor have I configured any GPOs to set the locations for them. 

Lastly, although FSLogix is installed on my gold image, it wont do anything either as the registry value isn't configured, this being:

Value Enabled Type DWORD Value 1 - 0: Profile Containers disabled. 1: Profile Containers enabled.

You can use the following links for more information about these profiles.

So, we need todo the below, some of which I've covered in a previous post:
  • Create a storage account 
  • Create some file shares 
  • Join the storage account to AD
  • Grant AD users access to write to the storage account file shares
  • Create a GPO with our storage locations
  • Create an OU with above GPO linked in
  • Move machines/users into OU

If we check the account in storage viewer, nothing is showing as expected as no-ones logged in yet.

The storage viewer is a handy place to be if you want to manage accounts like below.

Create FSLogix GPO 

You need to download FSLogix and you need to grab the admx and adml files from the .zip file.

You then need to import these into your on prem environments central store.

Now, its probably just me but the above states to only copy the .admx file, but after doing some research, you actually need to configure it like the below else you get an error when trying to load the template in gpedit.

You need to create the PolicyDefinitions folder, and en-US within it (which you need to copy the .adml file to), you also need to copy the .admx file to the below location, this should stop any errors.

So now we can go ahead and create an OU.

In AD I have created an OU called WVD. In this OU I will put all my Users and Machines, normally you would split these out but for purposes of this test environment they'll all live under the same roof.

I then went into group policy management and linked the FSLogix policies into that OU.

Ok, now I am only concerned with a few things for FSLogix at the bare minimum:
  • Ensure its enabled.
  • Ensure my .vhd locations are specified.
In the below image I have done a couple things:

In both container folders I have set the Enabled value to Enabled and ticked the box for enabled.

I have also specified some cloud cache locations, now you might be thinking what are those for? 

I will get onto this in a bit, but in my storage account I created user profiles initially and then thought I would create some cloud profiles as-well instead, along with some office profiles for the same thing.

You need to enter your folder locations like below and separate them using ; if you're using more than 1.

So once I have applied the above, I need to add a machine into my hostpool and ensure it joins the OU I have created, this is done when building a VM via the hostpool (see below image), its in the same section as the domain join account. I also need to add the user/s into the OU (or user group) so that those users get any policies we want for WVD users.

Cloud Cache

As I want to be as modern as possible - I'm going to use Cloud Cache instead.

A very simple way of saying what cloud cache is this.

Cloud cache allows us to replicate profiles to more than one location for resilience and not be affected by outages such as a storage location becoming unavailable.

Now, you might think that you can do this already with DFS, which allows us to replicate data, however its a bit of a pain and really, why would you if you have something cool like cloud cache.

In addition to the above, another key thing is that this will boost your IO on the disks, in that with cloud cache, essentially only delta information is synced back and forth, in traditional profile containers the data is synced irrespective if its changed or not, causing unnecessary IO on your systems. Instead, any IO is done locally and backed up as/when changes occur to up to 4 different locations based on how you configure your provider settings.

So, ultimately we can:
  • Utilize active-active sync connections on 4 different locations to provide high availability.
  • Reduce overall IO on our resources, by localizing changes and then uploading deltas to all locations.
  • Modernize our approach into using a solution which gives us more control over our environments.
A few negatives with cloud cache is a lot of the work is now performed locally, meaning greater strain on the host. So ensure the host has enough juice to handle the amount of users that will be using it, along side adjusting the disk size and possibly the type. I have seen this mentioned a few places. Also, logon/off time is slightly increased due to the data being synced and depending of if you wipe local cache or not.

The following links go into the above and configuration in better detail.

So, back to the profiles themselves, let check my host is online and that its in the correct OU.

Looks good, so jumping onto the host itself via the RDP tool I am prompted for my password and MFA.

Now I can see a profile has been created - I'm using azure storage explorer for this and I have popped a file on my desktop on the VDI.

Migrate user profiles to FSLogix

So this is a tricky one, because from what I can see, aside from MVP log posts, there isn't any official guides from Microsoft on this. 

However, it essentially boils down to running a migration tool supplied by FSLogix, which converts a user profile into a .vhd file.

See this handy guide for more information:

So this concludes this section, hopefully it helped. As FSLogix is a big part of WVD, I will revisit this section as I learn more. 


Popular posts from this blog

Day 34: AZ-140 Pt.2.3 - Create Gold Images & Deploy

Day 43: AZ-140 Pt.6 - Summary

Day 39: AZ-140 Pt.4.2 - Managing Users & Apps - Configure Apps