Jump to content
Welcome to our new Citrix community!
  • FSLogix and the ConcurrentUserSessions ​Controversy


    cugcblogs

    Or why Microsoft killed the ​​ConcurrentUserSessions setting ​​in the new FSLogix versions ​​and why you (probably) never needed it anyway...

    mikestreetz22rnd.png.78878bef0e66f85c928820084404455e.png 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

    streetz032322-01.png.e87d7b5ab2aa48f26e0b67bed56da2a1.png

    It also gets mentioned indirectly in the What's New notes for the latest version:

    https://docs.microsoft.com/en-us/fslogix/whats-new

    streetz032322-02.png.390e8176f2af19274fc6dd702f6b8d9a.png

    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! 

     

    Mike Streetz, CTP, Los Angeles CUGC Leader


    User Feedback

    Recommended Comments

    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?

    Link to comment
    Share on other sites

    Guest Mike Streetz (@O_P)

    Posted

    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.

    Link to comment
    Share on other sites

    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.
    Link to comment
    Share on other sites

    Guest Mike Streetz (@O_P)

    Posted

    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?

    Link to comment
    Share on other sites

    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.
    Link to comment
    Share on other sites

    Hi Berks, interesting to hear this exact use case as we are trying to accomplish this as well.

    ATM we just use one Desktop in a delivery group. Now we want to publish an app from the same delivery group for the reasons you already stated (efficiency etc). We do see the same behavior - the app is randomly opened on one of the servers in the delivery group and if i force it to open on the same server (maintenance mode every other server) it will open in a second session.

    VDA: Windwos Server 2019, CVAD 203, FSLogix 2.9.8440.42104

    Profiletype is 3

    ConcurrentUserSessions 1 (deprecated but still in place)

    fSingleSessionperUser is 1

    fDenyTSConnections 0

     

    We do also use office containers which are still set to profiletype 0

     

    I face two problems atm:

    1. Every user gets a RW.vhdx on the first logon.

    From the documentation i would expect since there is no handle on the profile it should open the first session in R/W mode and only when a second session is started it should create a RW.vhdx file

     

    2. Did you ever manage to configure it that an app opens always on the server a desktop is already launched?

    Link to comment
    Share on other sites

    Berks, do you know of a way to force the app and desktop to use the same server? I would rather their session be on the same server. We use FSlogix single sessions only. So our users are unable to launch apps if they have a desktop open. (And vice versa).

    Maybe I am doing it wrong but I thought multiple sessions with FSLogix containers was discouraged because of Outlook caching mode. Having said all that I'm not sure if forcing the apps and desktops to launch on the same server for a user would solve our issue. I would swear that it worked (apps and desktop) if they both launched from the same server during testing when I only had 2 VDAs.

    Link to comment
    Share on other sites



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...