Jump to content

Daniel Vester

Members
  • Posts

    11
  • Joined

  • Last visited

Posts posted by Daniel Vester

  1. We have a case where we need to use common/generic user accounts (same user accounts in different stores, for example store1 have 5 users with shop cashier) with O365 cache for Outlook.
    I have tried with FSlogix, both with ODFC and Profile solution with multisession and concurrent configuration:
    Concurrent or multiple connections to a single container - FSLogix | Microsoft Learn

    It works the user connects from different VDAs, then it looks like this:
    image.thumb.png.27e69384c4b5640380473e64e2103fe1.png

    But when connecting from the same VDA there is no new session created and it tries to use the same OST file for Outlook and that user get this error:
    image.thumb.png.e15dd02f32b393a264783fdb4ffe67fb.png

     


    I have tried to restrict so that the "store1 account" should not end up on the same server as another session with "store1 account" with Citrix Cloud policy "Concurrent logon tolerance" and set that to 1.
    But its not strictly enforced and there is a regkey that I have added to Cloud Connectors but I am not sure if this is only for on prem Delivery Controllers.
    Load management policy settings | Reference (citrix.com)
    HKLM\Software\Citrix\DesktopServer\LogonToleranceIsHardLimit Type: DWORD Value: 1

    I can maybe add a lots of VDAs and hope that the common user accounts will not end up on the same server but I would like to avoid that :).

     

    More info:
    Citrix DaaS
    Latest VDA
    FSLogix 2.9.8612.60056
    Windows OS 2019 Standard

     



     

  2. On 5/7/2021 at 5:53 PM, Graeme Dunkley said:

    Hi Folks, 

    RE: Grey Screen and Trend Micro 

    Quick update on this issue. Citrix engineering have been investigating and the issue with CTXUVI stopping with error 1003/1005 with Trend Micro AV installed. The error occurs when the CTXUVI driver receives an ACCESS DENIED error when attempting to load one of the Citrix hooks into a process. We believe the ACCESS DENIED is caused by Trend Micro AV opening Citrix hook DLLs with exclusive access when being scanned, instead of opening them with a share access flag (eg FILE_SHARE_READ) 

     

    Note that Microsoft Defender and other vendors do not appear to have the same effect and we have customer evidence that the issue is resolved by removing Trend from their VDAs, because of this we are encouraging customers to contact Trend Micro support so they are aware of the scale of the issue.  

     

    The investigation is on-going but the following workaround to exclude the following executables from hooking has been known to reduce the frequency of the issue (These are active during logon/logoff, and so are often being scanned when the issue occurs)

    Add Citrix hook exclusions for:
    SelfService.ex;CtxWebBrowser.;Receiver.exe
    Append the above to: the end of:  UviProcessExcludes under: HKLM\SYSTEM\CurrentControlSet\services\CtxUvi\
    then reboot the VDA.

     

    Please note: The misspelling is deliberate, you need to ensure that the exe names added to exclusion list does not exceed 14 characters for the exclusion to take effect. (see: https://support.citrix.com/article/CTX107825 for more information)

     

    Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

     

    @ReneBalz, @ChrisGundry @JamesKindon - can you confirm that disabling behavioural monitoring in Trend AV resolved the issue for you?

     

    RE: Grey Screen and Sophos 

    The issue is slightly different in that it is not ACCESS DENIED but OPERATION CANCELLED when trying to load hooks, this seems to be resolved by adding the folders to Sophos' exclusion list.

    1912:

    C:\Program Files (x86)\Citrix\HDX\bin

    C:\Program Files\Citrix\HDX\bin

    7.15:

    C:\Program Files (x86)\Citrix\System32

     

    Citrix Engineering have made improvements to try and workaround these issues and this is on going, but ultimately the fix needs to come from the AV vendor.

     

    Best Regards,

     

    Graeme

    Thanks a lot! I think this fixed our issues also after adding the exclusions. Cross my fingers that it will stay this way :)

  3. 18 hours ago, Carl Stalhood1709151912 said:

    If you're launching Citrix published apps from within the virtual desktop, then there's vPrefer. https://docs.citrix.com/en-us/citrix-workspace-app-for-windows/configure.html#vprefer-launch

     

    Otherwise, you might have to assign them to separate Delivery Groups and assign different FSLogix paths to each Delivery Group.

    Thanks Carl,

    we are not launching them inside from the virtual desktop unfortunately. 

    Ok, will think about that option to create more delivery groups.

     

    I was hoping that there were some kind of a PowerShell command that would force all sessions to the same server but maybe that not exists then :).

     

     

  4. Hi,

    This is our environment:
    Citrix version: 1912.0.1000 ltsr, OS 2019 with Fslogix profile containers.


    We have an issue that if a user is starting a desktop on VDA1 and then also want to start a published rdp app (both from StoreFront) it usually starts from an another VDA, for example VDA2.
    The problem is that the fslogix vhdx file is then locked (attached to VDA1 ) so the application will not launch on VDA2. 

     
    If i publish desktop and the application on one server only it works fine.

     

    I tried to disable "LOAD CHECK" with this seamless flag but I am not sure if these values are used anymore because it still opened on a different VDA,

    Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Citrix\wfshell\TWI
    Value Name: SeamlessFlags
    Value Type: REG_DWORD

    Value: 0x100

     

    Thanks in advance!

×
×
  • Create New...