Azure Files hosting fslogix profile containters and now Hot LRS Write Operations costs exploding

New Contributor

As per title.


I have configured WVD for approx 100 concurrent users with all profiles managed via fslogix sitting on Azure Files (standard).


We have had issues with our deployment (with not getting the expected user/vm density we expect) however an issue we did _not_ expect was the storage transaction costs we are seeing.


We currently are experiencing a transaction cost (hot lrs write) to storage cost ratio of about 25:1.


I have utilised redirections.xml to redirect as much (google chrome, teams. onedrive amongst others) as I can away from the profile but no real difference has been made to the azure storage stats. I have run process monitor with filters configured to record file writes but cannot see any smoking guns other than the afore mentioned applications.


Are other seeing the same? Or is there something fundamentally incorrect with this deployment.



12 Replies

@AU-Sensible   we are seeing the same. Have a support case open to investigate, will feed back any response, your mileage may vary of course. Would be interesting to compare/ contrast with profile containers on VM as store; will try and get that set up and monitor. 

@SteveMiles70 I am both glad and disappointed to hear that this experience is shared. I too have a case (multiple re: WVD performance) open with MS about this. I will let you know if anything of consequence comes of it.


In the discussions I have had with support personnel I have been made two recommendations:

- enable folder exclusions via redirections.xml for google chrome cache (completed, reduced write transactions by about 10% only)

- remove DFS for VHDLocations that I have setup (I created a namespace for \\domain.local\dfs\profiles > \\\filesharename) and used the optimised namespace in my golden image for the registry entry VHDLocations (completed, no change - also might add that it doesnt make alot of sense to me either but I will defer to the SMEs)

In your deployment would you mind sharing what you are currently redirecting via redirections.xml and any other specific fslogix configurations you might have made?


In many cases, you will not be establishing a net new file share for your organization, but instead migrating an existing file share from an on-premises file server or NAS device to Azure Files. There are many tools, provided both by Microsoft and 3rd parties, to do a migration to a file share, but they can roughly be divided into two categories:


Tools which maintain file system attributes such as ACLs and timestamps:

Azure File Sync: Azure File Sync can be used as a method to ingest data into an Azure file share, even when the desired end deployment isn't to maintain an on-premises presence. Azure File Sync can be installed in place on existing Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019 deployments. An advantage of using Azure File Sync as an ingest mechanism is that end users can continue to use the existing file share in place; cut-over to the Azure file share can occur after all of the data is finished uploading in the background.


Robocopy: Robocopy is a well-known copy tool that ships with Windows and Windows Server. Robocopy may be used to transfer data into Azure Files by mounting the file share locally and then using the mounting location as the destination in the Robocopy command.


Hi - thanks for the reply, but I am having difficulty understanding its relevance to my situation. Are you advocating that azure files is not the correct location for fslogix profiles given that 'in many cases you will not be establishing a new file share'?

Please elaborate - but thank you for taking the time to respond.

Hi @AU-Sensible @SteveMiles70 ,


do you have any update on your issue?

Just curios about what you changed or what was your decision?

Would changing to premium be an option? 



@Benjamin Graus+  @AU-Sensible + @SteveMiles70 ,

Coming in very late on this... same problem... 

My redir.xml file only has Teams folders...

How did you guys resolve this?


Very late reply to this, but why not to use Azure Files premium? With the cost blowout described it will make total sense both performance and cost-wise.

@Philip_doITflex  adding to this, what is the advantage of using azure files over hosting the FSlogix profiles on a file server and not have to worry about transaction costs? I also worry about performance.

0,09$ CAD for 10 000 transactions sems low cost in paper but in reality it is super expensive.
I don't use Azure files for profiles, but I think Philip got the point. You would probably better off paying for premium if you got a lot of users.

If you want to compare with a completly different use case as a pricing perspective. A backup to a blob storage would be $0,0704CAD Write and $0,0057CAD Read. (x15 pricing cost for read operations standard blob vs azure files).

@Travis_Qtech we are talking about PaaS over IaaS. Key question for decision making is how hard/easy it is to build and manage (TCO is important) redundant File Server *function* with comparable SLA and performance? I am a fan of Azure Files (premium in particular), as the answer to the question above was in favor of it every time for us. With end of last year price drop it is even more appealing:
As per the transaction cost for IaaS server - your server disk(s) (except Premium SSD) incur transaction cost as well, may be less impactful, but worth considering.
@fmartel Current MS recommended user profile size is 30GB. I think it is on a higher side, but the point is even with 10 users 10GB profile each you already on the minimum size of Azure Files premium. As per the performance, we have clear guidelines on the IOPS required for FsLogix profile containers:
Azure Files premium makes it easy to fulfill these requirements with no additional cost for transactions.
Hi all,

We actually had a semi-unique situation occur here. MS got their pricing wrong. We were in an affected tenant which had the correct quantities of operations being reported but had incorrect charges applied to them and thus our bill as CSP was ridiculous. Without knowing this I started to second guess and troubleshoot (and lean out the profiles) in any and every way possible to reduce the blow out.

This was ultimately an error condition which affected a group (no idea how many) of tenancies globally and has now been resolved.

With re: to Azure File Premium, this was never scoped or priced for with respect to my project. Azure premiums for fslogix was (at the time of my project) only in the mix if you had several hundred concurrent users, but this was not the case. I agree, it would be a better solution but simply was not budgeted for.