Or why Microsoft killed the ConcurrentUserSessions setting in the new FSLogix versions and why you (probably) never needed it anyway…
By Mike Streetz, CTP
Often I would see this set as part of an FSLogix deployment under the misapprehension that it is required on Server OS to make multiple sessions work. It’s not required. It never was.
This setting doesn’t exist any more. Let’s talk about what it said originally and why Microsoft changed it.
Originally it said:
Enable FSLogix to handle concurrent user sessions on the same machine.
Note: If you are using the Windows server feature to allow concurrent logins for the same Windows account on the same server (seen most often with Citrix XenApp), you must enable this policy.
Most people seemed to have glossed over the part where it says “for the same windows account.”
The ONLY time you want to use this is if you’re sharing a generic account and everyone needs to log in to the same machine simultaneously with an individual desktop session.
This is a bit of an edge case but most commonly seen in manufacturing and sometimes healthcare. It’s also sometimes in play with public kiosks.
You can’t even do this by default in Citrix! You can’t have multiple desktop sessions on the same machine with the same user because by default you’ll get sent to your already established session on that machine, so you need to override many settings to even make this work.
FSingleSessionPerUser set to 0 is needed on the RDS side of things. This allows multiple sessions from the same user on the same machine. The default is that every user is limited to a single session.
On the Citrix side, you need to set session reconnection to disconnected sessions only and same endpoint only, otherwise it’ll assume you’re roaming the session and all new connections will go to the existing open session.
The wording around ConcurrentUserSessions has since been removed and so has the setting.
Hopefully this will stop people trying to configure this setting, but because the screenshots for the ADMX templates in the documentation still show this setting, people still ask about it.
https://docs.microsoft.com/en-us/fslogix/use-group-policy-templates-ht
It also gets mentioned indirectly in the What’s New notes for the latest version:
https://docs.microsoft.com/en-us/fslogix/whats-new
99.9% of people never needed this setting and so Microsoft removed it from FSLogix and it now just checks if you’ve got FSingleSessionPerUser set to 0.
If you’re one of the 0.1% that need this, please let us know why!
What about if you publish a desktop and published applications from the same catalog and delivery group? E.g user launches
a desktop and then later decides I want one of my apps to open in a separate session window so I can place it on a separate screen? Or vice versa, user opens an app first and then a published desktop, at some point those Those two can open on the same server and are created in separate Citrix sessions, so would that not then apply to make the second session read only? Could be wrong but need to clarify. Would this scenario not mean the user had logged on to the same machine twice with the same account?
They can’t open on the same server.
You can’t have a published app open on the same server as a published desktop, it will always pick a new server and if the only server available is the one you’re on it’ll fail, so this use case doesn’t really exist.
I don’t recommend anyone publish apps on the same servers as published desktops.
I’m afraid you are incorrect. A desktop and an app can launch from the same server, they just launch in separate sessions, so the multisession option is valid and exists for this type of scenario. And we use this at my company.
What version are you on? Did you have to change any defaults? Are you running more than 1 server? A lot of us tried to imagine how this would work and all thought that by default it wouldn’t, so it’s interesting to hear of an actual use case.
Out of interest, why did you not split apps and desktops out?
On version 1912 ltsr cu2. 16 servers in a pool. From time to time the least loaded server will be the one that the desktop session has already launched on, so it will launch the app on there in a separate session. This is not unheard of to me, been like this since I can remember. Splitting them out is possible, but it’s more efficient to just run apps and desktops from the same delivery group and also only have one fslogix profile, not one for apps and one for desktops. None of our apps are write, only read so nothing really to save and no problem with the vdisk being read only in this case. Citrix profile management is better suited to this task as it has the last write wins feature at least. The issue comes when a user launches an app first and then the desktop session, as we don’t want the disk to be read only for the desktop session. Again rare for us as users mostly either launch a desktop or an app only. It would be better if Citrix complimented this feature removal with preventing an app session and desktop session landing on the same server for the same user.
Hi @Mike Streetz realy need the FSLogix ConcurrentUserSessions