Jump to content

Jeremy Saunders

Legacy Group
  • Posts

    21
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Jeremy Saunders

  1. Yep, confirmation for anyone that finds this as @Henrry Ortiz points out that the solution is you must build your projects with the platform target set to x64 when using the Remote PowerShell SDK. For reference I am using version 7.30. Many hours of debugging and researching to trace that. Glad I came across this thread. Terrible documentation from Citrix too for those of us who are not developers.

     

  2. On 2/22/2020 at 5:23 PM, Brijesh Shah1709161754 said:

    This question was posted quite a long time ago but I am facing the same problem with Citrix Cloud today. Can anyone know the reason? I am seriously failing because of this issue. With the Citrix Cloud I am having Cloud API Key and Secret. Moreover I am leveraging that profile to authenticate (XDAuthenticate). The final command (Get-BrokerSession) is working well with that through PowerShell ISE but not with the .net (C#) RunSpace and Automation module. I am getting same above error message.

     

    Hey @Brijesh Shah1709161754, Did you resolve this? I've got the same issue. I might rebuild my project for x64 instead of any CPU, but that will take quite a bit of work to address, Was hoping to find a quick and easy solution. Using Citrix.Broker.Admin.V2 and the cmdlets from Studio works, but when you remove that and use the ones from Cloud Remote SDK, it fails for Get-BrokerSession, even if it successfully does the Set-XDCredentials, Get-XDAuthentication, Get-XDCredentials. Cheers, Jeremy

  3. For those that experience this issue and are referring to setting the following keys via a Group Policy...

     

    [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Multiple Monitor Hook] "EnableWPFHook"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Multiple Monitor Hook] "EnableWPFHook"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] "CUDA"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] "CUDA"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] "OpenCL"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] "OpenCL"=dword:00000001

     

    You need to apply these in the image and not via a Group Policy. It's a race condition related to the CtxUvi driver. Any changes to the AppInit_DlLLs structure after it has started will cause the CtxUvi driver to disable itself until the next reboot. When it disables itself it can cause a grey screen and all sorts of issues for the users. This was a change Citrix made from 7.9 and above. References: CTX220418, CTX226605, CTX223973.

     

    Obviously applying via Group Policy would be hit and miss depending on when the policy applies and when the CtxUvi driver starts. Hence a race condition.

     

    I feel that instead of disabling the CtxUvi driver when changes to the AppInit_DlLLs structure are detected, it would be best ignoring those changes, log an event, and continue to function as expected. That's proper engineering!

  4. You need to apply this in the image and not via a Group Policy. It's a race condition related to the CtxUvi driver. Any changes to the AppInit_DlLLs structure after it has started will cause the CtxUvi driver to disable itself until the next reboot. This was a change Citrix made from 7.9 and above. References: CTX220418, CTX226605, CTX223973.

     

    Obviously applying via Group Policy would be hit and miss depending on when the policy applies and when the CtxUvi driver starts. Hence a race condition.

     

    I feel that instead of disabling the CtxUvi driver when changes to the AppInit_DlLLs structure are detected, it would be best ignoring those changes, log an event, and continue to function as expected. That's proper engineering!

  5. Hi Stefano,

     

    It's a bit dramatic to have to delete the whole "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main" key structure. Personally, I would need a good technical explanation as to why you need to delete that whole key structure. So I'm not sold that you need to do that, but I stand corrected if wrong. I would want to further fault find to a specific subkey or value. Then you may be able to just use one or two Group Policy Preference registry settings to resolve it for existing profiles. And it could be a bug that we could all learn from.

     

    Cheers,

    Jeremy

  6. Hi Clinton and All,

     

    Based on the fact that you've been dealing with Citrix representatives, I've changed it back to mirroring.

     

    Further testing has found that the “AppData\Local\Microsoft\Vault” folder and the “4BF4C442-9B8A-41A0-B380-DD4A704DDB28” subfolder are not consistently created. My customer manually created the folder structure, and was then able to save credentials. You can track this with Sysinternals Process Explorer. It will give you the error “PATH NOT FOUND” when trying to save web credentials. Kudos to my customer for discovering that.

     


     

    Here he created a login script. I’ve simplified it.

     

    IF NOT EXIST "%LOCALAPPDATA%\Microsoft\Vault" MD "%LOCALAPPDATA%\Microsoft\Vault"

    IF NOT EXIST "%LOCALAPPDATA%\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28" MD "%LOCALAPPDATA%\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28"

    IF NOT EXIST "%LOCALAPPDATA%\Microsoft\Vault\UserProfileRoaming" MD "%LOCALAPPDATA%\Microsoft\Vault\UserProfileRoaming"

     

    You'll also notice the reference in that thread to the "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main" key. This leads me to the reference to it on page 1 of this thread to create the “HKEY_USERS\Default Profile\Software\Microsoft\Internet Explorer\Main”. Perhaps there is a timing issue, sometimes referred to as a race condition or deadlock. ie. The key structure is missing when it looks to create the “vault” folder. Not sure yet, haven't looked that deep. Just thinking aloud as there was no substance to their instruction.

     

    Rens Hollanders from RES has some further paths documented that we should also be considering: http://renshollanders.nl/2014/10/res-workspace-manager-save-ie-and-windows-credentials/

     

    In fact testing across different Operating Systems seems to have a slightly different variation of where things are stored. Then try different versions of Office and it gets weirder. The last response in this thread is interesting in relation to the different builds of Office365: http://www.reddit.com/r/sysadmin/comments/2wbhm8/outlook_and_exchange_online_does_not_support/. I wonder if this relates to Office 2013 too?

     

    But also look at the second last response in that thread that talks about VMware View.

     

    So I think to cover all bases you need to make sure the following folders are "managed".

    %APPDATA%\Microsoft\Vault

    %APPDATA%\Microsoft\Credentials

    %APPDATA%\Microsoft\Protect

    %APPDATA%\Microsoft\Crypto

    %LOCALAPPDATA%\Microsoft\Credentials

    %LOCALAPPDATA%\Microsoft\Vault

     

    And be aware of the following registry keys:

    IE Forms AutoComplete (if enabled): HKCU\Software\Microsoft\Internet Explorer\IntelliForms\Storage1

    IE Password AutoComplete (if enabled): HKCU\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

     

    And perhaps even load the hive from the default profile and create the “HKEY_USERS\<Default Profile>\Software\Microsoft\Internet Explorer\Main” key.

     

    In all my deployments I do not redirect AppData (Roaming). I leave it as part of the UPM profile. I also have Profile Streaming enabled. Have thought about disabling it, but there is no evidence. And I’m using UPM 5.2.0 and 5.2.1 for testing.

     

    It would seem as though there is not a lot of great information known about this process. Microsoft have certainly muddied the waters with all the variations.

     

    So at the end of the day I believe this is a Microsoft issue to resolve, and we can only do our best to manage it by including everything possible in our profile mechanism of choice. Furthermore, it doesn’t hurt to run the suggested login script to ensure the “%LOCALAPPDATA%\Microsoft\Vault” folder structure is always created!

     

    Hope this thread gets some further discussion.

     

    Cheers,

    Jeremy

    • Like 2
  7. Awesome info Clinton.

     

    I'm trying your suggestion on a customer site where they are experiencing this issue. However I would suggest it needs to be synchronized and not mirrored. Mirroring is for transactional folders, which I understand the "Windows Vault" is not.

     

    With IE11 you need to "roam" the "Windows Vault" (%AppData%\Local\Microsoft\Vault).

     

    It's already a best practice to synchronize the following directories:

    - !ctx_localappdata!\Microsoft\Credentials
    - AppData\LocalLow\Sun\Java\Deployment\security
     
    I've now added the "Windows Vault" to this and we'll see how it goes:
    - !ctx_localappdata!\Microsoft\Vault

     

    Setting the "Process internet cookies on logoff" policy to Enabled is not required on IE10 or later, but it doesn't do any harm to leave it set. When referencing Cookies, you also set the following folders to mirror:

     

    - !ctx_localappdata!\Microsoft\Windows\INetCookies
    - !ctx_localappdata!\Microsoft\Windows\WebCache
    - !ctx_roamingappdata!\Microsoft\Windows\Cookies
     
    That's documented here:
    - http://support.citrix.com/proddocs/topic/user-profile-manager-5-x/upm-manage-cookies.html

     

    Anders, If synchronizing or mirroring the Windows Vault doesn't work for you, can you clear the profile and try again? I am wondering if the “%AppData%\Local Microsoft\Credentials” and “%AppData%\Local\Microsoft\Vault” need to be in sync with each other?

     

    Cheers,

    Jeremy
×
×
  • Create New...