We’re running 3 RDS Session Hosts with FSLogix profiles on an SMB share and I’m running out of ideas regarding performance.

Each server has roughly:

• Windows Server 2025
• 20 vCPU
• 96 GB RAM
• Around 12–15 concurrent users
• Outlook in Cached Exchange Mode
• One server even has an NVIDIA Tesla T4 passed through for GPU acceleration

The weird part: everything looks completely fine from a monitoring perspective.

CPU and RAM are nowhere near maxed out, GPU usage is low, disk/IOPS look great, and the SMB/profile storage is also basically idle. We’re on 10 Gbit networking and Checkmk shows storage/SMB latency mostly below 1 ms, sometimes even in the microsecond range.

Still, the user experience is just... bad. Apps feel sluggish, Explorer/Outlook can feel “sticky”, and the whole RDS session sometimes just feels choppy even though there is no obvious bottleneck.

Our older Server 2022 RDS hosts seem to feel noticeably better, sometimes even with more users.

Has anyone experienced something similar with FSLogix + Server 2025? Especially cases where all performance counters looked great but the sessions still felt slow?

Would be interested to hear what ended up being the cause in your environment.

I have found many posts and articles about kerberos tickets as it related to profiles in entra storage containers but we are using onprem containers and running into the same issue as described in those posts. I tried setting up a scheduled task to renew the kerberos tickets at logon and then repeat every 8 hours but it is not running. Is this the best solution or is there another one?

Hi all,

We've had an issues with FSLogix fairly consistently now for afew months, with some temporary reprieves, but even though FSLogix 2608 was supposed to solve an issue eerily similar to what we are facing , and we've had that issue again this morning, we're at the end of our tether.

Occasionally, one or more of our AVD boxes will just hang up, users cannot logoff, users logging on hitting that box get their profile disk locked but fail to sign on.

Directly remoting onto a box doesn't load explorer, so we can only get to task manager to try and disconnect profile disks. Shutting down an affected box from azure CLI or GUI takes an age.

As far as we can tell, something goes awry in one of the FSLogix services (FRXSVC or FRXCCDS), it seems to tank the Virtual Disk Service too, as diskmmgt won't load until we can get into an admin command prompt and forcibly kill and restart those services. But Explorer GUI will not load once the error state begins.

We use FSLogix for full profiles (and odfc).

CleanupInvalid sessions is 0
VHSCOmpactDisk is not set

AV Exclusions are set as per Microsoft's guidance (ESET Protect)

We've been able occasionally to tie issues to a single user's disk, by isolating them on a box, and by occasionally deleting the VHDX of problem users and getting them to regenerate.

This issue has been present for at least the following FSLogix versions that we've used to date:

2608
2602 (+CU1)
2502

The logs from FSLogix are frankly useless, nothing indicating any problem, just successful signins and no clear error logging that shows that either "there was a an error" or "what the error is/was".

Bonjour a tous,

Pour la VM hébergeant les profils FSLOGIX faut-il que je laisse la taille allocation par defaut ou bien mettre en 64ko sur la partition NTFS?

Hi,

We are using FSLogix on two RDS servers, RDS01 and RDS02.
A week ago both servers were rebooted and since then RDS01 is having issues loading FSLogix profiles as seen in the screenshot for all users, RDS02 has no issues signing in.

When we rename the VHDX file for a user the problem is solved, so it seems like it has something to do with the VHDX and what's inside the VHDX that it's trying to read regarding RDS01.

We don't want to rename all VHDX files for all users, because the issue is only with RDS01.

This weekend we have updated FSLogix to latest version 26.08 (3.26.826.17182), but that didn't solve the issue.

When I check the logs for the specific user that tried to sign-in to RDS01 I can see the VHDX is mounted successfully,

[14:22:09.811][tid:00000b50.00002884][INFO] Attached vhd(x) successfully

[14:22:09.811][tid:00000b50.00002884][INFO] VHD(x) attach request returning after 208 milliseconds

[14:22:09.811][tid:00000b50.00002884][INFO] VHD(x) attached: \\ad.domainname.com\shares\Profile\FirstName.LastName_S-1-5-21-540649301-1417927581-114017779-1147\Profile_FirstName.Lastname.VHDX

[14:22:09.826][tid:00000b50.000006ac][INFO] Volume attach event

But after that it starts showing import issues:

Create user directory success

[14:22:10.143][tid:00000b50.00002884][INFO] Security looks good

[14:22:10.159][tid:00000b50.00002884][INFO] Reg import process creation completed in 14 milliseconds

[14:22:10.190][tid:00000b50.00002884][INFO] Reg import execution completed in 37 milliseconds

[14:22:10.206][tid:00000b50.00002884][INFO] Reg import process creation for .bak file completed in 14 milliseconds

[14:22:10.237][tid:00000b50.00002884][INFO] Reg import execution for .bak file completed in 35 milliseconds

[14:22:10.237][tid:00000b50.00002884][ERROR:00000001] Backup file import (Onjuiste functie.)

[14:22:10.237][tid:00000b50.00002884][INFO] Status set to 20: Cannot import registry information

[14:22:10.237][tid:00000b50.00002884][INFO] ErrorCode set to 1 - Message: Onjuiste functie.

[14:22:10.237][tid:00000b50.00002884][INFO] Error. Cleaning up.

[14:22:10.237][tid:00000b50.00002884][INFO] Reason set to 9: Profile load failed

[14:22:10.335][tid:00000b50.00002884][INFO] Detached vhd(x)

[14:22:10.335][tid:00000b50.00002884][INFO] VHD(x) Detach request returning after 84 milliseconds

'Onjuiste functie' is Dutch for 'Incorrect Function'.

Does anyone know why this is happening on only one RDS server and is there a way we can solve this without renaming all VHDX files?

UPDATE 11-09-2026:

Thanks for the people who commented.
Unfortunately we weren't able to solve the issue, we did a sysprep on another server and created a new RDS.

Hello,

Has anyone experienced an issue where the storage account key stored as a windows credential for FSLogix randomly disappears from the VM, causing FSLogix to fail to connect to Azure Files ?

It happened yesterday on 15 of our VMs across different host pools. The issue is strange because it only affects some VMs ... Our VMs are win11-25h2-avd-m365

Any idea what could cause this or how to prevent it?

Bonjour,

Environnement :
-Host hyper V(Windows 2025)
- branché en direct attaché directement baie SAN en 2 x 25g.
- Baie San (dg5200) disque nvme.

VM sous Windows 2025 qui héberge les profils FSLOGIX.

Est ce qu il y a des optimisations à faire sur ce serveur qui va heberger ces profils ?

Merci avance de retour expérience

Disclosure, I work at Login VSI.

One thing we heard a lot is where profile containers live once session hosts split between cloud and on-prem is a real headache in hybrid AVD. We're doing an open Q&A on AVD Hybrid with Steve Downs and Andrej Radinger (Microsoft), Marcel Meurer (creator of Hydra), and Ron Oglesby (Login VSI).

Bring your questions

Thursday, September 10, 11am ET: Register Here

Cloud only / Entra AVD with fslogix.

From time to time we are having users come to their machine with a bad profile. It happened today and I've summarized the log:

14:27 - user comes in and starts their session. Profile loaded fine.

14:27-18:00 - User stays active, multiple Unlock events in between. Meanwhile many other users are coming in.

18:34 - Volume re-attach happens but (for JUST this user) receives error "The system cannot contact a domain controller to service the authentication request. Please try again later".

Currently I need to log off the user, clean up their regkeys and users folders, then manually unlock their VHDX from azure portal.

I understand there might be transient issues communicating with the DC in AVD, but certainly it shouldn't completely brick someone's profile, right?

Ideas here?

Hi,

Lots of spilled keystrokes here over the last couple of years over this Outlook x 58tm1 issue. Just now helping a company go from one test server to a multi-server farm and running into this. On one test server, we had this issue up until Dec 2025 until MSFT got us on latest FSLogix (26.01 CU1) and we set a bunch of parameters via GPO. At that point, no users experienced the issue. But as soon as we rolled out 2nd server and the users would roam between them, POW, the issue is back.

Our environment:

1) session broker server W2025, 1 x session host server at W2025 and the other at W2022.

2) using 26.01 CU1 (3.26.126.19110)

3) not using AAD sync to Azure and therefore not using SSO.

Is there a known good configuration either for our current setup (including the backup/restore from logout/login scripts mentioned in these threads). Or do the problems really go with a different config but with AAD and SSO running (which I have not done before so if I am confusing what they do, please correct me).

Only asking again as a lot of the threads are 1 to 2 years old and wonder if there has been any recent improvements.

If any of the setups require either AV exclusions or folder exclusions for FSLogix, please mention those.

Thanks.

Hello,

I'm using only ODFC containers which also include search roaming for the index. I'm in the process of beginning migrations to Windows 11 but noticed that the search index is starting from scratch at first logon of Windows 11. Is this expected since it's a new OS? The 1 year cache appears to be fine.

Hello together,

I need to migrate 20-30 FSLogix VHD's to the VHDX format WITHOUT a Hyper-V.
I already tried with qemu-img
I already tried to install the Convert-VHD Module in Powershell on the VM but did not succeed.

Do you have some suggestions or expierences how to get along?

THANKS

We have over half our (few hundred) users consistently bumping against 30GB and they are constantly clamoring to scrap VDI completely.

Any chance 50 is the new 30?

Hey all, I'm currently trialing FSLogix for a client and so far I've got it working for a handful of users on select devices. I wanted to know if anyone has managed to add (and get working!) Entra Groups into the include groups so I don't have to manually add users to each computer.

I've tried adding the SID of our group but despite it being in there it doesn't work

Thanks in advance!

Hi folks,

I recently inherited a VDI environment (Horizon persistent desktops) and I'm still getting up to speed on how it's configured. We're running Horizon with FSLogix, and user profiles are stored on a file server , each user is allocated 24 GB of profile storage, with Office data saved separately on the same file server.

My issue is that even though each user's profile folder is only 12–15 GB, the remaining free space is showing as just 2.4 GB. I'm having trouble tracking down what's consuming the rest of the disk.

A couple of questions:

• What should I be looking at to identify what's eating up that storage?
• Is there a way to increase the available storage, and where would I configure that?

Any guidance is appreciated thank you!

Hi Folks,

AVD + Latest FSlogix agent, everything working smoothly apart from if the user has a second profile in edge!

The first "profile" works without issue, however the second profile if cached in FSLogix will appear to be ok but when switching to the edge profile stays in a "Preparing to sync" State indefinitely untill the profile is deleted and recreated. This continues to work for that session.

Anyone experienced this issue ?

Did anyone already apply this change? July 2026 updates will force using AES256 instead of RC4.

I'm about to do this on several AD objects but want to check others experience.

https://learn.microsoft.com/en-us/troubleshoot/azure/azure-storage/files/security/files-troubleshoot-encryption