Forum Discussion
Ongoing FSLogix Profile Issues
Hi, We have recently gone live with a WVD setup of 2 Session hosts using FSlogix's profiles on an Azure File Server VM. It's not a massive deployment. Maximum of 38 users with general usage ...
Are you using an 127GB SSD to house 38 profiles? That is like 3.3GB average per user, isn't that kinda small? Hower this is not the cause of your issue I think.
It is but storage is ok at the moment. They are using it primarily to access a couple of applications rather than storing large amounts of data.
Do I understand correctly that you updated your FSLogix agent just now after reading the post above?
That's correct
What is the exact experience, do users get an error message or can't they login at all?
Either they log in with what looks like a local profile despite the reg keys or they get a message advising the fslogix profile container is unavailable. the messages I see in the FXtray app is below
Did you also disable the BrokerInfrastructure scheduled task from the post above?
schtasks /change /tn "\Microsoft\Windows\BrokerInfrastructure\BgTaskRegistrationMaintenanceTask" /disable
I did just this morning.
Please give feedback end of the week while testing the latest version, looking forward to the results!
Are your users working in a full desktop environment on WVD or launching Remote Apps?
I've seen this error when trying to launch a remote app when another app is already using the FSLogix profile.
Are your users working in a full desktop environment on WVD or launching Remote Apps?
I've seen this error when trying to launch a remote app when another app is already using the FSLogix profile.
- Quick question if you don't mind what VM are you using for your profile storage?
- That might well be it. We have since put together a larger deployment and wen't straight to the D16sv3 and have had no issues like the previous one.
- The experience with Microsoft support was slow and tedious however what does seem to have stabilised it considerably was increasing the resources. I swapped from a B8MS although the resource usage seemed fine and I was accruing plenty CPU credits to a D8 and the issue seems to have gone away,
I'm not sure if this is a coincidence or not, could I ask what VM size you are using? Hey,
Did you get any reply from Microsoft on your issues? We seem to be having the same problems aswell..
Hi Jason,
Thanks for checking in, i'm still having a few issues but i'm currently trying to deal with the hell that has become Microsoft support... Its been a month with them and they have been of little help beyond suggesting enabling concurrent sessions on a test account...
Once I get a bit of an update I'll post it here .
R_AkersThe nightly reboots are handled through a Powershell script that runs from the Azure AD controller. It looks up the pool members by -like {name*} and then uses test-connection to verify each is online before issuing the reboot. Has been working well.
We use scaling sets so this lookup then returns only those that are present since it creates different named instances whenever they are scaled down then back up.
If yours are static a simple remote reboot would work and you can log it into a file as well to keep track of it.
R_AkersI don't believe using an Azure file share is ready yet. We also use a dedicated Azure VM running the file server role and have an OS volume and then a separate Data volume where the profiles are housed.
Here are the reg keys we are using although we are doing full desktops and not remote apps.
- Thanks for the response. We can extend the profile container to give it a go. Its a dedicated Azure VM only running the fslogix profile storage. Does anyone know what would be involved in migrating them to an Azure File share, we started this before it was an option during the public preview.
The VHDX files are excluded by the AV. The AV we are using is webroot.
I had considered the nightly reboots but I had hoped the need for such a thing had long gone! I will give it a go as a mitigation however a more permanent solution would be ideal. R_AkersOne of the things we do to keep things running smoothly is a nightly reboot of the Hosts. I have found that after a few days the hosts start to have strange issues but nightly reboot keeps that from happening.
I would suggest using a larger Profile container on your file server and dedicated to the profiles. I hope you aren't using the OS volume for profile VHD's.
Also, as someone else posted, make sure your AV on any of these is excluding the .VHD's from being scanned. We also disable real-time scanning on the hosts and just do scheduled scans.
One more thing, I would use the disable concurrent logins reg key to keep it from allowing multiple logins.
- Can you try to troubleshoot (I know, this is a inconvenient time to troubleshoot) with process explorer which process is using the VHD file that FSLogix is trying to open?
What AV solution are you using on the fileserver? Did you make any exclusions for FSLogix? - A reboot of the profile server has resolved this issue. Does anyone have any suggestions of what is going on here? I can't believe it's this unreliable for others.
- Again a re-occurrence of 'the process cannot access the file because it is used by another process'
- Again after running fine for a few days the fslogix service seems to have randomly stopped. I'm looking to see if I can find a reason now. The unreliability is really starting to cause issues.
So after a week of everything running pretty smoothly with one session host. Something happened over the weekend that has sent it off in a huff again.
Its seems to be working after a reboot of the profile server. Logs below:
From what I can see so far there was no issues with the domain controllers over the weekend.
- I will do. I'm hoping desperately this resolves it! Thnk you for helping.
It's a Remote App setup. These error messages seem to happen when it's trying to sign the user in.
