Jump to content
Updated Privacy Statement

James Kindon

Moderators
  • Posts

    1,344
  • Joined

  • Last visited

  • Days Won

    66

James Kindon last won the day on January 19

James Kindon had the most liked content!

2 Followers

Profile Information

  • User name display option
    Full name

Recent Profile Visitors

28,203 profile views

James Kindon's Achievements

Mentor

Mentor (12/14)

  • Dedicated Rare
  • Week One Done
  • One Month Later
  • One Year In
  • First Post Rare

Recent Badges

2.4k

Reputation

  1. PowerShell is the long and short of it - you can have a look at Websters documentation scripts for a jump start https://github.com/CarlWebster/Citrix-XenApp-XenDesktop-7-V2 For the new LTSR there is also an API approach, but ultimately the same
  2. Add-AppxPackage 'C:\Program Files\WindowsApps\Microsoft.WindowsStore_11811.1001.18.0_x64__8wekyb3d8bbwe\AppxManifest.xml' -Register -DisableDevelopmentMode Make sure your version number is accurate in the above
  3. There are so many avenues that have been explored in this space. Start here with Rankins article and work from there https://james-rankin.com/features/the-ultimate-guide-to-windows-logon-time-optimizations-part-1/
  4. You might also like to look at transformer via WEM for some more advanced features and controls https://docs.citrix.com/en-us/workspace-environment-management/current-release/user-interface-description/transformer-settings.html
  5. You can't do that - you must logon to the VDA using the same user that brokered the session. Security 101 in the Citrix world. You could look at anonymous access configurations which is a StoreFront feature
  6. That would imply (I would think) that you have an underlying issue if that evaluation cannot apply - In all my years of doing Citrix work, I have never touched that setting, and would be dubious on doing so given that typically policy is there to lockdown/secure/control and environment, and if it cannot be guaranteed/evaluated to say "all is ok" then I wouldn't want people in those sessions
  7. https://support.citrix.com/article/CTX140522/how-to-support-virtual-machines-with-long-startup-times-in-xendesktop-environment Are you on Prem or Cloud? If Cloud, I am not 100% sure if this works via Cloud Connectors
  8. You don't need to change it - you should as a best practice, but it won't stop working if you let it lapse - we see this with cloud connectors all the time, new version or update, the hash changes and the bindings are skewed - became obvious when I was working on this https://github.com/JamesKindon/Citrix/blob/master/EnableSSL.ps1
  9. SetUserFTA can be used but you will need to pay WEM can also do the job But to your point, this should be working fine with the tools Microsoft give you - is it just one application failing to apply or are no extensions being honored? It might be worth applying to the local machine policy in the first instance to see if it's a GPO failure or an XML failure etc
  10. You don't need to do anything with ADMX on the endpoint - they ADMX is the frontend for Admins to configure and play with, ultimately, policy settings are written as reg keys on end the endpoint. I would not put your BIS-F config in via WEM, BIS-F will help with resetting the WEM cache, which in turn could remove your configurations - I am not sure how well that would pan out. You could use BIS-F locally ADMX on the base image (I know you want to avoid that), or you could use BIS-F shared configuration instead.
  11. A standard Cloud connection flow does this assuming you are using the Gateway Service: Citrix Workspace handles Authentication and Resource Enumeration -> The user launches a desktop -> The connection is tunneled via the Gateway Service -> through the Cloud Connector -> To the VDA If you turn on Rendezvous Protocol, the following occurs: Citrix Workspace handles Authentication and Resource Enumeration -> The user launches a desktop -> The connection is tunneled via the Gateway Service directly to the VDA. The Cloud Connector is no longer in the connection path. The VDA reaches out to the Gateway Service on 443 to make this happen Direct Workload Connection changes things again: Citrix Workspace handles Authentication and Resource Enumeration -> The user launches a desktop -> IF the network where the user lives has been defined as a network location in Citrix Cloud AND that location has direct line of sight to the VDA -> The Gateway Service is bypassed entirely, and the user connects straight to the VDA This makes it very similar to a traditional storefront flow on-prem. You now have a single connection from endpoint to VDA HDX Direct is the future of Direct Workload Connection, it will effectively do the same thing, but you will not need to define network locations for the behavior to occur. It uses the Gateway Service to establish a connection, and then learns if there is a direct connection to the VDA possible. There are certs and other info passed around along with some use of STUN etc to make this secure a bit more robust
×
×
  • Create New...