Before we start building our storage solution, there are a few best practices to keep in mind. The first is that an Azure virtual desktop host pool is a collection of identical session hosts that are meant to contain a single workload. So, the best way to map your FSLogix file shares are in a one-to-one relationship, meaning each host pool should have their own FSLogix file share. This would isolate each workload from the others in your environment, so you won't have to deal with the "noisy neighbor" syndrome. But another protection to think about is antivirus scanning.

Now, this might seem counter-intuitive, but the best practice here is to exclude all FSLogix file shares and virtual hard drives from your session host antivirus. The reason for this is that when a new disk or file share is mounted onto a system, Windows would attempt to scan those resources by default. If this happens then the session host processor will be bogged down hindering user performance and experience.

Now, the file share that contains user profiles should be scanned for viruses, but this should be done on a regular basis from another system like a management server, so you don't impact the AVD environment. The way to implement this is to set antivirus exclusions on your session host. The details are in the Azure Docs, as shown here. 

Now, how exactly you would implement this in your environment is going to depend on which antivirus solution you are using. If you're using Microsoft Defender, this can be configured in your Group Policy settings. There's another best practice to keep in mind when talking about your FSLogix file shares around capacity and performance. User profiles grow over time. One of the tricky things is that even if you delete files inside your profile, the profile disk itself never shrinks on its own.

In Azure Premium Files, the cost and performance of your file share is based on the size of the file share. The specific size of your file share should be determined based on how many users you have and the approximate size of all those users' profiles. As I said before, Azure virtual desktop host pools are a collection of identical session hosts whose purpose is to be consumed by the users of a specific workload, for example, users in the accounting department or developers. Each one of those workloads is unique and therefore they should be on separate host pools and each of their host pools should be aligned with their own FSLogix file share for the same reason.

Here's a quick example. There are 200 users in the accounting department. Each user needs a 10-gigabyte user profile. Just multiply 10 gigabytes by 200 users in that group and you should use a two-terabyte File Share. But wait, there's more: each user profile will grow over time, which means we need to add some extra size for overhead while keeping in mind-controlling cost. I generally add an additional 20% to account for growth, so in this case I'd create a 2.5-terabyte file share and then would set up alerting through Azure monitor to keep an eye on capacity.

The last thing to think about in this section is performance. When a user profile is mounted to the system, this will consume approximately 50 IOPS of storage performance per user on your file share. After the user logon is complete, which takes about a minute or so depending on what startup sequences you have, you'll have reached what we call steady state. In steady state, the user profile will consume roughly 10 IOPS of storage performance.

So, if we break out our slide rule once again, 200 users at 50 IOPS would equal 10,000 IOPS of storage performance if they all logged in at the same time. This is what we would call a logon storm, and it usually happens first thing in the morning. After the logon process is complete, your storage performance load will come down to roughly 2,000 IOPS

Even though this was an easy scenario, at larger scales you may need to increase the file share size well beyond your capacity needs to get the performance you require. But be aware, the larger the file share you create, the more expensive it will be. This is another reason why each host pool can have its own file share; it helps to control cost. 

There's another way to reduce cost of your FSLogix file share that I'll just touch on, because it's more well-suited to an in-depth course on FSLogix User Profiles. You can use this PowerShell script from the official FSLogix GitHub repo to delete the whitespace within your user profiles, which will shrink the virtual hard drives sizes and decrease the amount of total space you need on your file shares, which is where you can save cost.

So, let's recap. We know in this example that we need at least a 2.5-terabyte capacity file share, and we also need a file share that can get up to 10,000 IOPS of burst performance and 2,000 IOPS of steady state performance. When we create our 2.5-terabyte Azure premium file share, this will give us the burst IO of 10,000 IOPS and the normal maximum IO of 5,500 IOPS. So, in this case, we know that a 2.5-terabyte share is the correct size. Then over time, when our profiles grow, we can use the FSLogix PowerShell script to shrink them, which will reduce the overall size requirements for our file share and could reduce our cost.