AVD Storage Requirements
AVD Storage Requirements

Your Storage is your data, so in Azure Virtual Desktop we need to address your storage needs. This comes in a few flavors: FSLogix User Profiles and Office Profiles as well as the Storage solution that they will be mounted from and the disks for your Operating Systems and data drives.  

In this course, we will help you design your Azure Virtual Desktop storage components so you can get the most out of them in your AVD solution but also control cost to make AVD a more cost-effective solution with a dedicated focus on preparing you for the Azure Virtual Desktop Specialty exam.

Learning Objectives

  • Understand Azure Virtual Desktop Storage requirements
  • Recommend an appropriate storage solution 
  • Configure storage for FSLogix components
  • Configure storage solution
  • Configure disks
  • Create and configure file shares
  • Protect your storage using Azure Backup
  • Understand high availability and disaster recovery

Intended Audience

  • Azure administrators with subject matter expertise in planning, delivering, and managing virtual desktop experiences and remote apps, for any device, on Azure
  • Anyone looking to learn more about Azure Virtual Desktop


To get the most out of this course, you should already have some knowledge of:

  • Azure Storage accounts
  • Storage capacity planning
  • Storage performance 
  • Windows PowerShell

The storage side of Azure Virtual Desktop comes in two main forms, Virtual Machine Disk resources, and FSLogix profile storage. FSLogix is a profile management solution that enhances and enables user profiles in Windows remote computing environments. For this discussion, FSLogix has two solutions that we need to discuss, user profiles and Office profiles. These profiles are stored on an SMB file share and mounted on demand to the AVD session hosts when a user logs in.

Inside Windows, a virtual hard drive file containing the user profile gets mounted without getting a drive letter, and the user's folder appears in the C:\ user's location, like all the other profiles, so it appears to windows as if the profile is local. The main benefit of this is that the user profile doesn't have to do any gymnastics like you would have to with roaming profiles or streaming profiles, so performance is not impacted at all. The profile will also be able to travel from machine to machine with the user, which means that the session host does not retain any of the user's data and no longer needs to be backed up and protected. However, the file share that contains the data must be backed up and thought about in your disaster recovery solutions, which will be discussed in another course.

User profiles contain all of your data. It's the things that are on your desktop or your wallpaper, documents, pictures, music, et cetera. It also contains those things that are in your user's app data folder and some other systems stuff. Think of it as all the data that you would cry over if you lost it. This means that the user profile should be backed up and protected during disaster recovery.

Now, to understand the Office profile, we need to step back out of the cloud and back to the on-premises days. Back in the day we all had other solutions like Exchange and SharePoint and things like that on-prem, latency, generally, wasn't a big issue 'cause you were on the same network as those servers. As mobile computing became a thing caching was introduced to offset the latency users in the field would experience. Then Microsoft started building out their Office 365 online services like Exchange Online and SharePoint Online. And this took those bulky multi-server infrastructure solutions that you had to manage yourself and centralized those into cloud services that you can just consume. But since latency is the enemy of good performance in those latency-sensitive environments, this caused the on-premise VDI users some performance issues.

Then along came FSLogix. They set up an Office profile to function as a cache for those Office Online services to give VDI users better performance. Since the Office profile only contains cached data, it doesn't need to be backed up or protected in a DR. If all of it was lost the profile would just re-cache it from the Office 365 services. Now I know that sounds great but in Azure Virtual Desktop it's recommended to only use the User profile. This is because AVD is sitting in the cloud right next to the Office 365 services, so latency is not an issue and caching is not needed. Another reason is that the Office profile cache data is contained in the user profile already. You can of course still use the Office profile if your situation specifically calls for it, however, just going with the user profile will minimize your complexity and simplify your storage solution, which is always a good thing.

About the Author

Dean Cefola is a Principal Azure Engineer at Microsoft and has worked in the IT industry for over 20 years. Dean has been supporting Azure Virtual Desktop from the beginning and is the Microsoft FastTrack Global Leader for AVD.