Random users get temporary session (insufficient resources) - FSLogix | AVD | Fileshare

Question

Hi everyone,

Coming here to see if anyone has any clue regarding a problem with FSLogix that we cannot solve despite looking everywhere.

 

We have the following setup :

-          Azure AVD hostpool with a single host having around 16 users peak time : D16as v5

-          FSLogix with profiles being hosted in an azure storage account

 

Issue :

Every day 2-3 users end up on a temporary session in the AVD and the same error appears in the FSLogix logs but we cannot figure out why.

 

The error is a 0x5aa : Error_no_system_resources

« Insufficient system resources exist to complete the requested service. »

FSLogix log show the following (+2 lines to see at which point in the process it arises) :

[08:36:25.479][tid:0000111c.000102b8][INFO]             Load user classes hive to perform operations for roam
[08:36:28.799][tid:0000111c.000102b8][ERROR:000005aa]   RegLoadKey: C:\Users\usename\AppData\Local\Microsoft\Windows\UsrClass.dat (Insufficient system resources exist to complete the requested service.)
[08:36:28.799][tid:0000111c.000102b8][ERROR:000005aa]   Failed to successfuly perform all roaming operations on the classes hive (Insufficient system resources exist to complete the requested service.)
[08:36:28.799][tid:0000111c.000102b8][INFO]             OneDriveTemp setup

 

At the same time, we get a 1509 windows event with :

Windows couldn’t load : C:\Users\usename\AppData\Local\Microsoft\Windows\UsrClass.dat

 

The issue happens randomly on users but when it happens to a user, it will not got away unless we the host, which we do every night.

It will keep happening to the user even when there are no users left on the host at 8pm and that we try to reconnect the user (which makes us think it is not really linked to insufficient resources).

It can happen when it’s the first connection of the day or the 15^th, no distinction seen so far.

 

For additional context, we also have another hostpool in the same environment (domain, network, …) with the same image except a specific software installed on the single host and we don’t have that problem on any of the 15 hosts in that hostpool.

 

What we have checked/tried so far :

-          Using every option of FSLogix related to profile cleaning

-          Every log we could find in windows/FSLogix/Azure

-          Every host and guest metrics around the time of connection/error for VM, network, file share

-          File lock on the VHD in file share

-          GPO applying to those users in case there’s something linked to another profile management system

-          On VM : temp profile files, registry keys linked to user/profile, ..

 

We have not yet been able to test if PreventLoginWithFailure/TempProfile could help, we are waiting for client’s approval.

 

We have checked tons of other things as well as scaled up the infrastructure without any success so far.

If anyone has seen this problem somewhere and/or has any clue on how to go from there, that would be much appreciated

Answer 1

Hello Robin Gielen

Welcome to Microsoft Q&A Platform, thanks for posting your query here.

It is recommend to have more than 1 VM in a pooled host pool to get HA and the ability to put 1 VM into maintenance mode while still keep the users productive.

This issue needs deeper investigation. Support team will be able to check and help on this. I would recommend you to open a azure support case.
Please make sure that you have the latest Windows updates as well as FSLogix version installed.  

Answer 2

Hi Robin,

Did you get this sorted in the end? We are experiencing the same issue with 2 AVD servers within different tenants and host pools, any insight would be helpful.

Answer 3

Same thing is happening to 2 AVD pools we manage under different tenants. Need a resolution asap.

Answer 4

For us it's caused by "HKLM:\System\CurrentControlSet\Control\RegistrySizeLimit". This registry value should not exist.

Procmon shows Netskope agent is setting this during its update process. Deleting the value and rebooting the host resolves the issue for the VM. Chasing Netskope for an answer on why its doing this and how we can mitigate against it.