Delete a ShareFile user

Delete or Downgrade an Employee

  1. People > Manage Users
  2. Browse or search for your user, then access the Manage icon located to the right of the user’s name and email address:
  3. In the Actions menu on the right, select Delete from System or Downgrade to Client.
  4. When a user is deleted or downgraded, the content of their Personal Folders must be reassigned.

NOTE:

Once the folders are reassigned, you can delete the folders. Inbox and Sent items can not be deleted.

Delete a Client

  1. People > Manage Users
  2. Browse or search for your user, then access the Manage icon located to the right of the user’s name and email address:
  3. In the Actions menu on the right, select Delete from the System.
  4. Unlike Employee Users, Client data cannot be reassigned to another user upon deletion.

Related:

  • No Related Posts

Information on Webcams in Citrix Virtual Apps and Desktops

This article contains information about using webcams with Citrix Virtual Apps and Desktops (formerly XenApp and XenDesktop) and explains the HDX RealTime Webcam Video Compression and HDX Plug-n-Play Generic USB Redirection features.

In addition to the two approaches discussed in this article, it should be noted that “optimized” solutions are available for certain leading Unified Communications applications. These optimized solutions shift the media processing workload to the user device, thereby maximizing server scalability. Optimized solutions exist for Microsoft Skype for Business, Microsoft Lync 2013, Cisco Jabber for VDI, and Avaya one-X Communicator.

1. Background

Webcams can be used by applications running within the Citrix Virtual Apps and Desktops session either by HDX RealTime Webcam Video Compression or by using HDX Plug-n-Play technology. Users can choose between the two based on their specific requirements. HDX RealTime Webcam Video Compression is generally recommended since it offers superior bandwidth efficiency.

2. HDX RealTime Webcam Video Compression

With HDX RealTime Webcam Video Compression, the video data is captured on the user device; it is then compressed and sent to the XenApp/XenDesktop session. Installation of the device drivers for the webcam is not required on the Virtual Delivery Agent (VDA). Device drivers are only required on the client device. It is recommended that the latest drivers are obtained directly from the webcam manufacturer’s website (or use the driver CD that came with the webcam). Sometimes, default drivers are installed when the device is first plugged in, but these drivers might not offer the video color space that the client’s codec is looking for, which might lead to higher CPU consumption on the user device as a result of color space conversion.

Note: 64-bit Application support for HDX RealTime Webcam Video Compression requires XenApp / XenDesktop 7.17 or later, and also Receiver for Windows 4.11 or later

HDX RealTime Webcam Video Compression allows less bandwidth consumption and is especially suited to deployments where the VDA and client reside across slow networks. HDX RealTime Webcam Video Compression uses upstream bandwidth in the rage of 300-600 kbps (for CIF resolutions).

User-added image

Further information regarding configuration of HDX RealTime Webcam Video Compression is available on the Citrix documentation site – see HDX video conferencing and webcam video compression.

HDX webcam video compression requires that the following policy settings be enabled (all are enabled by default).

  • Multimedia conferencing
  • Windows Media Redirection


User-added image


High Definition

In XenDesktop 7.16 and XenApp 7.18 (with Receiver for Windows 4.10 or higher) support was added for native resolutions beyond 352×288 (CIF).

This enhancement allows high-def webcam native resolutions for virtual sessions, up to 1080p.

Citrix Receiver now queries the webcams on the client for their list of supported capabilities (media type information and resolutions). Then, the HDX PnP virtual channel is used to send this information to the VDA. Server will then offer this list to the hosted application trying to use the webcam.

Media types that aren’t supported will be filtered out and not offered to the application.

At the moment, HDX supports the RGB formats, YUV420 formats and YUY2 packed formats.

Application running on the VDA picks the desired media type and resolution from the list that was offered.

(If for some reason this media type negotiation fails, HDX falls back to our legacy way of webcam redirection, which is to use hard coded 352×288 resolution).

The selected media type and resolution is then sent to the client and the webcam uses that to start the webcam feed.

The existing registries keys on the client to control the resolution will be honored, and this mechanism can be utilized to enforce a given resolution (see section 7.1 below).

If Bandwidth consumption is a concern, High Definition can be disabled by applying the following registry key on the VDA:

HKEY_LOCAL_MACHINESoftwareCitrixHDXRealTime

Name: Enable_HighDefWebcam

Type: REG_DWORD

Data: 0 = Disable the high definition webcam streaming

3. HDX Plug-n-Play Generic USB Redirection

With HDX Plug-n-Play Generic USB Redirection technology, the webcam is virtually detached from the client device and attached to the XenApp/XenDesktop session. This provides all the native functionalities of the webcam in the XenApp/XenDesktop session. HDX Plug-n-Play Generic USB Redirection requires the device drivers for the webcam to be available on both the client device as well as on the VDA.

Bandwidth usage for webcams using HDX Plug-n-Play Generic USB Redirection technology can vary based on the vendor and model of the device, but it is significantly higher compared to use it over HDX RealTime Webcam Video Compression. HDX Plug-n-Play for webcams is recommended to be used only under LAN conditions where bandwidth and latency are not constraints.

Refer the following link regarding more information on HDX Plug-n-Play configuration:

Configure USB Support.

4. Default Behavior

By default, webcams use HDX RealTime Webcam Video Compression technology. However, end users can override the default behavior and explicitly choose to use HDX Plug-n-Play Generic USB Redirection from the Desktop Viewer preferences tab of Citrix Workspace app, if the administrator has enabled remoting of USB devices through policies.

4.1 Whether to use Webcam Video Compression or Generic USB Redirection

HDX RealTime Webcam Video Compression is the default and preferred way of using webcams with XenApp/XenDesktop, except when an “optimized” solution is available such as the HDX RealTime Optimization Pack for Microsoft Skype for Business and Lync. HDX RealTime Webcam Video Compression uses significantly less bandwidth compared to HDX Plug-n-Play Generic USB Redirection and works well over WAN connections.

HDX Plug-n-Play is recommended only when there are application compatibility issues with HDX RealTime Webcam Video Compression or when advanced native functionalities of the webcam such as auto-focus are required. For better performance, Citrix recommends a XenDesktop VDA to have at least two virtual CPUs.

4.2 Configuring HDX RealTime Webcam Video Compression

HDX RealTime Webcam Video Compression feature is available on XenDesktop 5.0 and later versions with Online Plug-in for Windows version 12.0 and later version or Receiver for Linux 12.0 and later version. It is also supported on Mac and Chrome Receivers.

HDX RealTime Webcam Video Compression is enabled by default on the VDA and on the Windows client and no additional configurations are required.

With Receiver for Linux, it has to be explicitly enabled. Refer the following link regarding information on how to configure this – Citrix Documentation – Optimize.

4.3 Dependency on Windows Media Redirection

HDX RealTime Webcam Video Compression uses the same underlying technology as Windows Media Redirection. Enable Windows Media Redirection in Studio for HDX RealTime Webcam Video Compression to be functional. If Windows Media Redirection is disabled, HDX RealTime Webcam Video Compression will not work.

4.4 Application Compatibility

HDX RealTime Webcam Video Compression is compatible with most unified communications clients. The feature has been tested for compatibility with the following applications:

  • Cisco Webex Meetings and Webex Teams
  • GoToMeeting
  • Google Hangouts and Meet
  • Microsoft Teams
  • Microsoft Skype for Business 2015, 2016 and 2019
  • Microsoft Skype 7 or higher
  • IBM Sametime
  • Adobe Connect
  • Media Foundation-based video applications on W8.x or higher and WS2012 R2 and higher (see section 8.5)


Note: 64-bit Application support requires XenApp / XenDesktop 7.17 or later, and also Receiver for Windows 4.11 or later, and Receiver for Chrome.

The 7.17 VDAs and 4.11 Receiver for Windows (or higher versions of both) now include both 64-bit and 32-bit H.264 compression encoder/decoders. This means customers using 64-bit video conferencing hosted applications, such as Skype for Business x64, Google Chrome browser, and Google Hangouts, are now supported. Note that these 64-bit video conferencing apps must support H.264 for this feature to work.

Some ARM Chromebooks don’t support H.264 encoding – in that case, only 32-bit apps in the VDA can use the optimized HDX RealTime Webcam Video Compression.

5. Webcam Compatibility

HDX RealTime Webcam Video Compression is not directly dependent on specific models of webcams. Any webcam that is DirectShow compatible (including integrated ones) can be used with HDX RealTime Webcam Video Compression. Most Windows Driver Model (WDM) compatible webcams can be used. However, webcam bandwidth consumption can vary from webcam to webcam. Different webcams offer different frame rates and have different levels of brightness and contrast. Citrix used the following webcams for initial feature validation:

  • Microsoft LifeCam VX models (2000, 3000, 5000, 7000)
  • Creative LIVE! CAM Optia Pro
  • Logitech QuickCam Messenger
  • Logitech C600, C920
  • HP Deluxe Webcam

During production testing, the LifeCam vx-3000 or later and the Creative Optia Pro gave the best results in terms of bandwidth consumed and subjective video quality. Adjusting the contrast of the webcam can reduce upstream traffic significantly. This can be accomplished if the webcam ships with a system tray utility that runs on the user device.


6. Known Issues

Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

  • If Citrix GoToMeeting with HDFaces or Skype for Business (either hosted or when in fallback mode with RTOP) does not recognize the webcam of the user, edit the system registry.

    For 32-bit devices, access HKEY_CLASSES_ROOTCLSID{860BB310-5D01-11d0-BD3B-00A0C911CE86}InstanceCitrix HDX Web Camera.

    For 64-bit devices, access HKEY_CLASSES_ROOTWow6432NodeCLSID{860BB310-5D01-11d0-BD3B-00A0C911CE86}InstanceCitrix HDX Web Camera.

    Add a string value named DevicePath.

    Set REG_SZ as the data type and Citrix Client as the value [Reference 263277].

  • HDX RealTime Webcam Video Compression does not automatically reconnect if the session connection is interrupted mid-conference. The user must restart the video conference [Reference 233296].

  • On XenApp 7.17 or older (RDS VDA), only one webcam can be used with HDX RealTime Webcam Video Compression at a time; if the client device has multiple webcams configured, only the first one successfully detected is used in the XenApp session. On XenDesktop (VDI), multiple webcams are supported, along with client-side webcam switching.
  • XenApp 7.18 added support for multiple webcams. Applications dynamically detect a webcam being plugged in or removed on the client. Users don’t have to restart the application to detect these changes.
  • In XenApp 7.18 or higher, actual webcam names are displayed instead of the generic Citrix HDX Camera (which is the way they are displayed in 7.15 LTSR, for example)

Double Hops:

  • Xenapp 7.15 LTSR and double hops – [internal ref. LD1143] when installing Citrix Receiver 4.10 or higher, or any version of Citrix Workspace app in the VDA, webcam functionality will break if H264 encoding is used. Only Citrix Receiver for Windows 4.9 LTSR can be installed in a 7.15 VDAs for H264 encoding. This is because both Receiver/Workspace app and the VDA rely on (and are packed with) the same codec library (CtxVideoCodec.dll), and installing Receiver/Workspace app in the VDA will overwrite the dll of the VDA. As a work-around (if you must install 4.10+ or Workspace app in the VDA), you can try to disable H.264 encoding, and enable Theora using the following registry setting (on the client or on the VDA)
i. HKEY_CURRENT_USERSoftwareCitrixHdxRealTime

DWORD EnableDeepcompress_Client – set it to 0 to disable H.264 encoding (and use Theora instead). By default HDX always prefer H.264. Set it to 1 to go back to default behavior.

ii. If you want to disable H264 on the VDA side instead, it is also possible by setting:

HKLMSoftware Wow6432NodeCitrixHdxRealTime

DWORD EnableDeepcompress_Server – set it to 0 to disable H.264 support.

Please note that when H.264 is disabled, the webcam resolution must be integral multiple of 16. So, 1920*1080 is not supported. User can use other resolution like 1280*720, so apply the defaultwdith and defaultheight regkeys described in 7.1

  • HDX RealTime Webcam Video Compression supports ICA double-hop for webcams.


7. Advanced Configuration

Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

There are settings that can be configured on the user device that can assist in troubleshooting and solving problems with specific webcams and networks. Generally, these settings must be adjusted as a last resort. Changing the settings too much can lead to severe video artifacts and video sluggishness.

7.1 Resolution

As of XenApp 7.18 and XenDesktop 7.17 (with Receiver for Windows 4.10 or higher), all supported resolutions by the webcam are presented to the hosted app trying to access it, so it can pick the desired resolution.

By default, Citrix Receiver for Windows 4.10 or older and non-Windows Receivers use CIF resolution (352 x 288) to stream webcam video to the XenApp/XenDesktop host.

A scaling function allows applications to request resolutions other than the default. The CIF frames are scaled appropriately on the VDA before delivering them to the application.

To manually adjust (and force) the webcam video resolution, create (on the Client) two DWORD values named DefaultWidth and DefaultHeight under HKEY_CURRENT_USERSoftwareCitrixHdxRealTime.

The resolution directly affects the bandwidth consumed and the overall quality of the video.

Some Webcams (specially integrated) might not support CIF, and Webcam detection might fail on an older VDA (like 7.15 LTSR).

Editing the Registry for a known supported resolution (like 640 x 480 or 1280 x 720) might fix the issue.

Note that the higher the resolution, the higher the bandwidth consumption between Workspace app and the VDA.

Try a lower known supported resolution (e.g. 480p) to avoid high network traffic.

You can find this by launching the Camera app in Windows 10 and clicking on Settings:

User-added image

Client-side registry:

User-added image


User-added image

7.2 Frame Rate

The preferred video frame rate can be adjusted by creating (on the Client) a DWORD (32-bit) value named FramesPerSecond under HKEY_CURRENT_USERSoftwareCitrixHdxRealTime. Because it is possible to input a value that the webcam does not support (e.g 31 FPS), the actual frame rate might be different as seen by the hosted application (e.g. 10 FPS). When this key is not present, a default value of 15 frames per second is selected. The actual frame rate used is dependent upon the Webcam.

For example, an old WebCam device might only support up to 10 fps in 1280*720 resolution for I420, NV12, YV12, YUY2 video format (the formats supported in H.264 encoding, plus RGB with Theora encoding). To confirm this, use a third-party tool (like DumpVCap or GraphStudioNext) to verify.

–DumpVcap output–
Major Type Sub Type Format Type FixedSamples Temporal Compression Sample Size Max Input Size Min Output Size Max Output Size Min-Max FPS
Video YUY2 VideoInfo Fixed NotTemporal 1843200 1280×720 1280×720 1280×720 5.00-10.00 {none}

Video YUY2 VideoInfo2 Fixed NotTemporal 1843200 1280×720 1280×720 1280×720 5.00-10.00 {none}

Video MJPG VideoInfo Fixed NotTemporal 2764800 1280×720 1280×720 1280×720 5.00-30.00 {none}

Video MJPG VideoInfo2 Fixed NotTemporal 2764800 1280×720 1280×720 1280×720 5.00-30.00 {none}


From the output, it is clear that at 1280*720 resolution, the WebCam device can support 5~10 fps for YUY2 video format and 5~30 fps for MJPG video format (but not supported in HDX). In this case, only up to 10FPS can be used by the hosted app.

Most modern webcams like the integrated ones in a Surface device (e.g. OV5693) support at least 640×480 (480p 4:3) or 640×360 (wide 360p 16:9) and 15-30 FPS (see SETTINGS screenshot above).

7.3 Bandwidth

The bandwidth usage can be tweaked by creating a DWORD (32-bit) value named TargetBitrate under HKEY_CURRENT_USERSoftwareCitrixHdxRealTime. Values are in bits per second, so if 300 kbps is desired, the value should be set to 300000. When this key is not present, the default value is 350000. During testing, somewhere between 250000 and 300000 was found to be the minimum values for the default CIF resolution or 480p that still produced acceptable video quality. If the resolution and frame rate are set to lower values then it might be possible to lower the bit rate and reduce bandwidth consumption. Lastly, setting the bit rate to zero has special meaning – zero indicates that the codec should operate in VBR mode. However, during production testing, the codec would generate excessive video artifacts so VBR mode is NOT recommended.

7.4 Encoders

Citrix Workspace app for Windows supports H.264 (Default) and Theora (legacy) encoders. If for whatever reason you want to disable H264 (not recommended), the following registry key on the client can be used:

HKEY_CURRENT_USERSoftwareCitrixHdxRealTime

DWORD EnableDeepcompress_Client – set it to 0 to disable H.264 encoding. By default HDX always prefer H.264 decoding. Set it to 1 to go back to default behavior.

If you want to disable this on the VDA side instead, it is also possible by setting:

HKLMSoftwareWow6432NodeCitrixHdxRealTime

DWORD EnableDeepcompress_Server – set it to 0 to disable H.264 support.


8. Troubleshooting

8.1. Device Manager on the Client would list the same webcam names as done by the Citrix Workspace app Desktop Viewer. Although keep in mind that there is no single designated place where they show inside Device Manager. This is device specific. Most common place is under Imaging Devices. Integrated webcams might show in other places.

8.2. Citrix Workspace app Desktop Viewer preferences should list all the available webcams on the client. If that drop down does not show webcams at all, that means the Client cannot access the local webcams.

In this scenario, redirection will not work. If you run into this problem, try launching apps like Skype for Business, Skype or GoToMeeting LOCALLY to confirm that webcam devices are not available on the endpoint either.

This can happen because of various reasons, most commonly device drivers not installed correctly because of which Windows cannot recognize webcams.

For HDX Realtime webcam video compression, the device drivers are not needed on the VDA, only on the Client.

For Generic USB redirection, drivers are needed at both the VDA and on the Client machine.

8.3. Make sure the following Computer policies “Windows media Redirection” and “Multimedia Conferencing” are Enabled in Studio.

By default, all multimedia policies set on the Controller are stored in these registries:

Computer policies:

HKEY_LOCAL_MACHINESoftwarePoliciesCitrixMultimediaPolicies

User policies:

HKEY_LOCAL_MACHINESoftwarePoliciesCitrix{User Session ID}UserMultimediaPolicies

To locate the current user session ID, issue the qwinsta command on the Windows command line.

Keep in mind that these two policies are Enabled by default, and policies that are enabled by default will not show under those regkeys (only policies that are explicitly configured will).

8.4. Once you plug a webcam in your session, or if the webcam was already plugged when the session started,

the following registry entries should be seen on the VDA:

User-added image

Information on the MediaPropertyData values can be found here.

8.5 If some apps on the VDA can display the webcam, but some other app or self-preview window shows a black or grey screen instead of the video feed, you might need to whitelist the application. This applies to Workstation VDAs only (Windows 10 / Windows 7).

Add a key with the name of your app executable (e.g. myapp.exe) under:

HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCitrixCtxHookAppInit_DllsCtxMFPlugin

and

HKEY_LOCAL_MACHINESOFTWARECitrixCtxHookAppInit_DllsCtxMFPlugin

DWORD “HookProcess” = 1


User-added image

Related:

  • No Related Posts

How to Troubleshoot Browser Content Redirection

1. Browser Content Redirection feature description and details

Browser content redirection (BCR) allows the redirection of VDA-side browser viewports to the client-side. The benefits of BCR are achieved when offloading network utilization, page processing, graphics rendering to the endpoint, and improving end-user experience when browsing demanding webpages; especially those incorporating HTML5 or WebRTC video.

For BCR to work, the VDA must have access to the website you are trying to redirect – in other words, a navigation event must occur in the browser for BCR code to kick in. The webpage would then be uninstantiated , and immediately redirected.

Currently there are two browsers supported:

  • Internet Explorer 11: The VDA-side IE11 browser viewport is redirected and rendered on the client-side using the client-side installed IE11 and the Citrix Workspace app for Windows process HdxBrowser.exe. A BHO (Browser Helper Object) called CitrixHDXJsInjector is added by the VDA installer to IE11 on the VDA. This BHO injects HdxVideo.js into whitelisted webpages. This Javascript’s main goal is to connect via secure web sockets to a service called WebsocketService.exe running on the VDA.
  • Google Chrome: The VDA-side Chrome browser viewport is redirected and rendered on the client-side using the Citrix Workspace app for Windows embedded Chromium engine and the HdxBrowserCef.exe process. Note that the Browser Content Redirection Extension (which injects HdxVideo.js) must be installed and enabled on the VDA before using BCR with Chrome. The Browser Content Redirection Extension is available from the Chrome Web Store.
  • Please note that Chrome support requires CWA 1809 or higher and VDA 1808 or higher.


For further information, including BCR system requirements, please read the Browser content redirection section of the Citrix Virtual Apps and Desktops 7 Product Documentation.

2. Browser Content Redirection configuration for specific use cases

2.1 Server fetch and server render

Default behavior when BCR is disabled. No VDA-side viewport redirection to the client occurs. This could be due to the desired behavior as configured through BCR policies, or server fallback may have occurred unintentionally due to a client redirection failure. To configure for this use case:

Browser content redirection policy: If set to Prohibited, BCR is disabled.

Alternatively, if “server fetch and server render” is to be applied for some websites, while permitting BCR for others, use the Browser content redirection Access Control List (ACL) policy settings policy to whitelist sites and/or the Browser content redirection blacklist setting policy to blacklist sites.

In this alternative scenario, the Browser content redirection policy needs to be unconfigured [since the default value is Allowed] or set explicitely to Allowed.

Note that in this mode, server-side rendering uses ICA Thinwire to remote the graphics to Workspace app, the same way it is done for any application running in the virtual desktop.

2.2 Server fetch and client render

This mode allows endpoints with no direct access to the website (e.g. Intranet) to be able to proxy the HTTP traffic through the VDA, which then relays to the web server. A service in the VDA called “Citrix Port Forwarding” is in charge of this.

To configure for this use case:

When the Browser content redirection proxy setting policy has been configured with a proxy server IP:Port address, the client connects to the proxy server on the VDA’s network over the Port Forwarding virtual channel and renders the content locally.

Proxies that require explicit authentication are supported with CWA for Windows 1907 or higher.

TCPView running on the endpoint will show that HdxBrowser attempts to connect to a few localhost TCP ports (the aforementioned client-side Port Forwarding virtual channel):

User-added image

For Linux endpoints, running netstat will show WebKitNetworkProcess establishing connections to localhost:

User-added image

On a Linux client, also check if vdbrowser.dll and vdportfoward.dll (used for server fetch client render) have been loaded.

If they are not loaded, the redirection will fail and fallback to server-side rendering.

You can use the following command “cat /proc/<PID of wfica>/maps” to check:

User-added image


The TCP Port Forwarding service on the VDA is called CtxSvcHost.exe, and is the one making the final outbound connection to your Proxy Server (in the screenshot below it is 10.108.7.8:8888). This is how it looks on Process Explorer:

User-added image

Be aware that there are many Citrix Virtual Channels that can run under CtxSvcHost (Smart Card, Audio, Flash, etc).

The one used by Server Fetch Client Render in Browser Content Redirection uses the “PortFwdSvcs” flag, as seen above.

You can also use TCPView – but make sure you are tracking the right CtxSvcHost. You can use the PID value from Process Explorer (9196 in the screenshot above) to correctly identify it, or look at the Remote Address and identify your Proxy.

User-added image

If CtxSvcHost.exe is not seen, please restart the service “Citrix HDX Port Forwarding Service” on the VDA.


2.3 Client fetch and client render

This use case affords the maximum benefits for bandwidth efficiency and VDA resource usage.

To configure for this use case:

Browser content redirection policy: No need to configure but Allowed can be set. [Default value Allowed]

Browser content redirection Access Control List (ACL) policy settings policy: Acts as whitelist. Add any websites (wildcard * can be used) that you want to be redirected.

[Default value: https://www.youtube.com/*]

When this mode is configured, HdxBrowser.exe (Windows) or WebKitNetworkProcess (Linux) will contact a website directly:

User-added image

User-added image


2.4 Other BCR configuration options

To support whitelisted websites that navigate away to a 3rd-party site for authentication before redirecting back to the whitelisted site, configure the Browser content redirection authentication sites policy.

We’ll use YouTube as an example:

The Browser content redirection policy will include the value: https://www.youtube.com/* [note that this entry exists by default in the policy]

The Sign In button on the YouTube site navigates to https://accounts.google.com/… (the protocol/domain part will be consistent but the full path will vary).

To support the authentication-related navigation from https://www.youtube.com/ to https://accounts.google.com/ and back to https://www.youtube.com/, configure as follows:

In the Browser content redirection authentication sites policy, add the entry: https://accounts.google.com/* (note the wildcard * to accommodate variations in URL sub-folder values).

More info can be found in CTX238236.

3. Browser Content Redirection feature limitations

  • For websites with media content, only the following list of codecs are supported when the site is redirected:
Container Audio Codecs Video Codecs
MP4 (QuickTime / MOV / MPEG4)

Ogg

WebM

WAV
FLAC

MP3

Opus

PCM
VP8

VP9

Theora

H264
  • Websites that use Integrated Windows Authentication (IWA) might break BCR. Currently BCR is not able to handle and display the pop-up “Windows Security” dialog box (or any dialog box), and the user might end up in a blank page. Keep in mind that since now the endpoint is loading the website, the endpoint and website (running on IIS for example) might not be in the same domain (while VDA and IIS might). Hence IWA fails, a pop-up window should be displayed prompting the user for credentials but it is not, because of the aforementioned limitation in BCR. This issue has been fixed in CWA for Windows 1907 or higher.
  • Currently, when using Server Fetch Client Render (this policy in Studio), only a single Proxy FQDN / IP is supported. PAC files (for automatic proxy configuration) are not supported with Server Fetch Client Render.
  • When freshly installing CVAD 1811 (only), there is a known issue with BCR_x64.msi where it is not installed on the VM if the Admin selected “Enable brokered connections to a server” or “Enable Remote PC Access”. The workaround is to mount the .iso of CVAD, find the BCR_x64.msi in Image-Fullx64Virtual Desktop Components and run it. See CTX240182.
  • The Desktop OS Core Services Virtual Delivery Agent stand alone .exe (VDAWorkstationCoreSetup) does not include BCR_x64.msi. Same workaround CTX240182 fixes this.
  • Due to the limitation of CEF(Chromium Embedded Framework), client endpoint GPU needs to be disabled if DPI scaling factor is set to a number other than 100% in order for BCR feature to work. Otherwise BCR displays the website in a corrupted fashion (like zoomed in and cropped). To disable, configure on the Client:
    • HKLMSOFTWARECitrixHdxMediastream

      For 64-bit:

      HKLMSOFTWAREWow6432NodeCitrixHdxMediastream

      Key: GPU (DWORD)

      Value: 0
  • Currently, with Windows CWA, copying text from redirected webpages is only possible with Chrome browser content redirection. Use Ctrl-C / Crtl-V to copy and paste. Linux CWA support copy/paste for both IE11 and Chrome.
  • Currently printing from redirected webpages is not possible from Internet Explorer 11 and Chrome.
  • Currently, screensharing functionality will not work if the BCR user tries to initiate screensharing. Incoming sreensharing does work (HDX-16273).
  • Upgrades to Receiver 4.11 or 4.10 from any version might break BCR virtual channels. See CTX235183.
  • Currently, if Local App Access is Allowed then BCR will not work. You must set LAA to Prohibited (Default) for BCR to work.
  • Currently downloads aren’t enabled on redirected websites when using Chrome on the VDA (therefore files cannot be saved to the endpoint).
  • In IE11, after starting a YouTube video using the YouTube HTML5 video player, full-screen mode might not work. You click the icon in the lower-right corner of the video, and the video doesn’t resize leaving the black background in the full area of the page. As a workaround, click the full screen button, and then select theater mode.

    This issue is not seen on Chrome.

———————————————————————————————————————————————————–

4. Browser Content Redirection Troubleshooting

Before proceeding, please review the “Browser Content Redirection feature limitations” section.

4.1 General troubleshooting steps

Step May clear problem in
Close the browser, re-open, and navigate to a whitelisted site. Browser Add-On and HdxVideo.js file
Disconnect and reconnect the session. Citrix Workspace app, HdxBrowser.exe, HdxBrowserCef.exe, WebSocketAgent.exe, and services
Logoff and logon to a new session. Citrix Workspace app, HdxBrowser.exe, HdxBrowserCef.exe, WebsocketAgent.exe, and services
Stop the services: 1. Browser redirection service, 2. HTML5 redirection service, and 3. Port forwarding service. Restart them in reverse order listed. Logoff and logon the session. All components


4.2 Data to collect for troubleshooting

CDF modules to trace:

VDA Side Citrix Workspace app (client) Side
HDX_Multimedia_BrowserService
HDX_Multimedia_HdxjsInjector
HDX_Multimedia_PortForwardLibrary
HDX_Multimedia_PortForwardService
HDX_Multimedia_WebSocketAgent
HDX_Multimedia_WebSocketPipe
HDX_Multimedia_WebSocketService
PE_Library_GvchBase
IcaClient_Multimedia_HdxBrowser_CtlGuid
IcaClient_DriversVd_BrowserRedir_CtlGuid
IcaClient_DriversVd_PortForward_CtlGuid

4.3 HdxBrowser and Webcontainer (a.k.a Overlay Browser)

When using BCR with Internet Explorer 11, ensure HdxBrowser.exe is running with Citrix Workspace app for Windows (use Task Manager) while you are on a whitelisted site.

When using Google Chrome, the process is called HdxBrowserCef.exe.

Note: Chrome support requires CWA 1809 or higher, and VDA 1808 or higher.

This is how it looks on Process Explorer on the endpoint:

User-added image

For Linux endpoints (Fat Clients, or Thin Client minimum versions: Unicon eLux RP 6.2.3 CR, HP ThinPro 7.1 or higher only, iGEL OS 10.05 or higher) the process used is webcontainer (placed in ICAROOT /util folder. ICAROOT generally is /opt/Citrix/ICAClient for root user). (ThinOS Wyse Terminals do not support BCR).

i. Please check if webcontainer process is starting in your Linux client by running:

<ICAROOT>/util/webcontainer –version.

Sample output:

User-added image

ii. If it fails then you have to install WebKitGTK+ version greater than 2.16.6 for Browser Content redirection to work.

WebKitGTK+ is a full-featured port of the WebKit rendering engine (WebKit2 API with GTK3).

(This is not part of Citrix Receiver / Workspace app, so you will need to download the proper package for your Linux distribution and processor architecture, or contact your Thin Client vendor).

Therefore, libwebkit2gtk-4.0.so.37 system library will be required for webcontainer to link against:

User-added image

Note that glibcxx 3.4.20 or later is also required for BCR (#locate libstdc++.so.6 and then run #strings /<add the found location>/libstdc++.so.6 | grep GLIBCXX):

User-added image

iii. You can then check if webcontainer process can render the video content locally by running:

./webcontainer –url https://www.youtube.com/html5

./webcontainer –url https://www.youtube.com

This test verifies if the endpoint has the proper codecs available (specially the ‘ugly’ ones like H264). The test does not invoke any Citrix VDA components, it is a purely local test. Webcontainer (WebKitWebProcess) will in turn make calls to GStreamer 1.x – if H264 is not loaded, VP8 will be used instead (if the website supports WebM).

In order to check your GStreamer version, run ‘dpkg -l | grep gstreamer’.

More info on GStreamer requirements in CTX224988.

User-added image

Note: Currently, if WebKitGTK+ version is below 2.22.3, then Media Source Extensions (MSE) are not supported so YouTube videos will only play up to 720p (with H264).

If H264 is not available or licensed, YouTube will attempt to use WebM container format (VP8/VP9 video codecs from gst-plugins-good and Opus audio codec from gst-plugins-base).

YouTube now requires MSE to play videos in WebM format, so a proper WebKitGTK+ version has to be present.

WebKitGTK+ version 2.22.5 or higher and GStreamer 1.14.4 or higher are recommended for YouTube.

​​​

iv. Running the top command while BCR is active will show:

User-added image

While webcontainer is in use, there are 2 associated WebKit processes that run: WebKitNetworkProcess and WebKitWebProcess. The actual network outbound connections are made by WebKitNetworkProcess).


4.4 Browser JavaScript log live debugging in IE11 and Chrome:

  1. If you want to debug in IE11, Open %programfiles%CitrixHdxVideo.js

    (or depending on your VDA version, the Javascript can also be located inside a folder called %programfiles%CitrixICASERVICE)

    You might need to do this running Notepad as an Admin and opening the .js file from the Open menu

    Change the line var DEBUG_ONLY = false; to var DEBUG_ONLY = true;

    Save the file and close your Editor.

  2. If you want to debug on Chrome, skip step #1. Make sure your Extension is at version 2.0. Right click on the icon, select Options and tick “Activate debug logging’.

  3. Close Internet Explorer / Chrome and reopen it, hit F12 or Ctrl+Shift+I, and go to the Console tab in Developer tools. Browse to a whitelisted site, e.g. https://www.youtube.com

  4. You should see traces from [HdxVideo.js] (example below). Collect the entire log.

    Key messages to look for are highlighted in bold, with additional comments inside brackets [ ]:

    [HdxVideo.js] OnUnload (window): [object Window]

    [HdxVideo.js] DocumentBodySuppressor.start()

    [HdxVideo.js Events] interceptEventListeners()

    [HdxVideo.js] DocumentBodySuppressor.trySetBodyStyle(): stopping observer

    [HdxVideo.js] OnLoad (window): [object HTMLDocument]

    [HdxVideo.js] Unredirected video count: 0

    [HdxVideo.js] HDX_DO_PAGE_REDIRECTION: true [if false, redirection is not even attempted. Problem with policies or browser Extension?]

    [HdxVideo.js] infallback: undefined

    [HdxVideo.js] Installing event listeners.

    [HdxVideo.js] msexitFullscreen – Found!

    [HdxVideo.js] onWSOpen: [Websocket opening to WebsocketAgent.exe 127.0.0.1:9001 succeeded. If failed, check your IE Security Settings]

    [HdxVideo.js] >>> {“v”:”pageurl”,”url”:”https://www.google.de/”}

    [HdxVideo.js] onVisibilityChange:

    [HdxVideo.js] >>> {“v”:”vis”,”vis”:true}

    [HdxVideo.js] onResize:

    [HdxVideo.js] >>> {“v”:”pageredir”}

    [HdxVideo.js] sendClientSize: w: 1316 h: 755

    [HdxVideo.js] >>> {“v”:”clisz”,”w”:1316,”h”:755}

    CSI/tbsd_: 15.599,072ms

    CSI/_tbnd: 15.658,128ms

    [HdxVideo.js] <<< {“v”:”winid”,”title”:”CitrixVideo:{1b83a2dc-39ae-4455-ad7d-d56e71fbb45d}”}

    [HdxVideo.js] onWSMessage: winid: CitrixVideo:{1b83a2dc-39ae-4455-ad7d-d56e71fbb45d}

    [HdxVideo.js] setWindowTitle: CitrixVideo:{1b83a2dc-39ae-4455-ad7d-d56e71fbb45d}

    [HdxVideo.js] documentTitleMutator.start()

    [HdxVideo.js] >>> {“v”:”winid”}

    [HdxVideo.js] <<< {“v”:”pageredir”} [VDA is instructing Receiver to start the redirection process]

    [HdxVideo.js] onWSMessage: pageredir

    [HdxVideo.js] Redirecting page — 화이팅! https://www.google.de/ [Korean characters means the redirection was successful]


    A common error is:

[HdxVideo.js] OnUnload (window): [object Window]

Navigation Event Separator HTML1300: Navigation occurred.
www.youtube.com

[HdxVideo.js] DocumentBodySuppressor.start()

[HdxVideo.js Events] interceptEventListeners()

[HdxVideo.js] DocumentBodySuppressor.trySetBodyStyle(): stopping observer

[HdxVideo.js] OnLoad (window): [object HTMLDocument]

[HdxVideo.js] Installing event listeners.

[HdxVideo.js] msexitFullscreen – Found!


[HdxVideo.js] doRedirection(): exception connecting to WebSocket: SecurityError

[HdxVideo.js] onWSError:

[HdxVideo.js] Showing content — suspendRedirection.

In the Developer Tools console this can be seen as:

User-added image

This is caused by security configurations in IE11’s Security Zones, and the root of the issue is 127.0.0.1 being classified under the intranet zonewhile the redirected whitelisted site is in the internet zone.

Redirection might work as intended on Chrome (since it has no concept of Zones).

Internet Explorer automatically assigns all websites to a security zone: Internet, Local intranet, Trusted sites, or Restricted sites.

Important: 127.0.0.1 will be classified as either Intranet or Internet zone, depending on your IE11 Proxy configuration in Tools > Internet Options > Connections > LAN Settings (either PAC files – WPAD Proxy Script-, or Explicit Proxy -manual-). More info here.

User-added image

If 127.0.0.1 ends up being classified as Intranet, then Zone elevation restrictions prevent connections from Internet zone to Local intranet zone, and BCR will fail.

The Local intranet option “Include all sites that bypass the proxy server” should be unchecked (disabled).

Rationale : If “Include all sites that bypass the proxy server” is enabled, 127.0.0.1 connections are considered to be in the Intranet zone. Zone elevation restrictions prevent connections from Internet zone to Local intranet zone. Most of the external redirected sites like Youtube will be in the Internet zone and the injected script HdxVideo.js will attempt a connection to 127.0.0.1:9001 in the Intranet zone which will be blocked. So, “Include all sites that bypass the proxy server” should be unchecked.

Internet Properties –> Security –> Local Intranet –> Sites, and uncheck “Include all sites that bypass the proxy server”

User-added image

The equivalent configuration can be made by setting these regkeys via GPOs (ADM Computer template):

HKLMSoftwarePoliciesMicrosoftWindowsCurrentVersionInternet SettingsZoneMapAutoDetect [REG_DWORD value 0]

HKLMSoftwarePoliciesMicrosoftWindowsCurrentVersionInternet SettingsZoneMap IntranetName [
REG_DWORD value 1]

HKLMSoftwarePoliciesMicrosoftWindowsCurrentVersionInternet SettingsZoneMapProxyByPass [
REG_DWORD value 0]

HKLMSoftwarePoliciesMicrosoftWindowsCurrentVersionInternet SettingsZoneMap UNCAsIntranet [
REG_DWORD value 1]

Each zone has a different default security level that determines what kind of content might be blocked for that site.

Zone Description Default Setting
Internet Contains all websites that are not assigned to any other zone Medium-high
Local intranet Contains all websites and content that is stored on a corporate intranet and don’t require a Proxy Server Medium-low
Trusted Sites Contains all Internet sites that you have specifically indicated to be ones that you trust not to damage your computer or information Medium
Restricted Sites Contains all the sites that might potentially damage your computer or your information High

(Depending on the security level of a site, some content might be blocked until you choose to allow it).

You can check the Zone a website is assigned to by navigating to it and then right clicking –> Properties

User-added image

If the website you are trying to redirect is in your Internet Zone (see example above), then please try to add the following entry to the Trusted Zone Sites in IE11

(Internet Options -> Security)

  • https://127.0.0.1:9001


You can verify if websockets are opened by going to Developer Tools -> Console and type:

var exampleSocket = new WebSocket(‘wss://127.0.0.1:9001’); exampleSocket.onmessage = function(messageEvent) { console.log(JSON.stringify(messageEvent)); };

wait a few seconds and then type:

exampleSocket.readyState

The expected output from the 2nd line, is ‘1’, which indicates that the WebSocket connection was successfully formed.

0 (CONNECTING) The connection is not yet open | 1 (OPEN) The connection is open and ready to communicate.

2 (CLOSING) The connection is in the process of closing | 3 (CLOSED) The connection is closed or couldn’t be opened
User-added image

4.5 Pac files

The PAC file does not need to return DIRECT for 127.0.0.1:9001 (WebSocketService.exe on the VDA), IE11 makes direct connections for localhost/127.0.0.1 by default.

Zone elevations restrictions might, again, prevent HdxVideo.js to connect to 127.0.0.1:9001, so make sure it is classified as Internet Zone (see 4.4).

4.6 Content Security Policy

Another possible error is that some websites use a technology called CSP (Content Security Policy) which prevents any outside resource (like the Javascript used in BCR) from being executed in the trusted webpage context. Therefore Browsers prevent the injection of HdxVideo.js and BCR fails, falling back to server-side rendering.

User-added image

This can be overcome if you have a Proxy server in your network (like Bluecoat) and you are able to apply HTTP Rewrites.

wss://127.0.0.1:9001 needs to be added to connect-src


4.7 Browser Helper Object (BHO for IE11)

The BHO is not currently compatible with Enhanced Protected Mode in IE11.

BHO is explicitly enabled upon install time of Citrix Virtual Apps and Desktops. If you want to disable it, please check the registry key created for the CLSID of the extension in the following path:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesExtCLSID

There should be a key created with the CLSID of the extension ie {CA076BDE-8E41-44EE-B775-E791F26D0483}

The value of the key is set to 1. This means the extension is enabled and users cannot change it.

If changed to 0 , the extension will be disabled and users cannot change it.

If changed to 2 , the extension will be enabled and users can enable or disable it in the browser’s “Manage add-ons”.


4.8 How to verify the webpage is redirected

Method #1: Drag the IE11 or Chrome window quickly. You will notice a ‘delay’ or ‘out of frame’ between the viewport and the User Interface.

Also you will notice a quick change in the title on the Tab (CitrixVideoId) before the original title is placed back

User-added image


Method #2: When the right mouse button is clicked on window area, a customized context menu is displayed. Back/Forward menu items are currently disabled for the initial releases. The remaining menu items perform the following tasks:

  • Refresh: refreshes current client side web page.
  • Open: if the mouse point is focused on a hyper link, the link will be opened; otherwise, nothing will happen.
  • Open in New Tab: if the mouse point is focused on a hyper link, the link will be opened in a new Tab; otherwise, nothing will happen. (Note: for the initial release, this works only when pop-up is enabled on VDA side IE instance.)
  • Open in New Window: if the mouse point is focused on a hyper link, the link will be opened in a new Tab; otherwise, nothing will happen. (Note: for the initial release, this works only when pop-up is enabled on VDA side IE instance and the link is opened in a new Tab rather than in a new Window)
  • About HDX Browser Redirection: Browse to Citrix support site in a new Tab
User-added image

Related:

  • No Related Posts

How to Setup Work from Home (BCP) with Citrix due to COVID-19

Citrix is committed to providing the support you need to keep your employees safe and operations running throughout the COVID-19 (coronavirus) pandemic. If you are looking to provide access for additional remote users working from home in response to COVID-19, please refer to our Business Continuity and Disaster Recovery Guidance.

For assistance with licensing, remote access, scalability, etc. please click here to navigate below.

Please follow these links for rapid deployment solutions in Business Continuity:

  • Please visit the following link for quick deployment solutions.
  • For detailed technical information on business continuity please go here.
  • Follow this Citrix Blog post for tips on Business Continuity Plan and live Q&A.

Related:

  • No Related Posts

Citrix Cloud Connector Installation does not complete: Unable to validate certificate chain

The Root and Intermediate Certificate authority used to sign the Citrix Cloud Connector need to be trusted on the local machine where the Citrix Cloud Connector is being installed. Cloud Connector binaries and endpoints that the Cloud Connector contacts are protected by X.509 certificates issued by DigiCert, a widely respected enterprise certificate authority (CA). DigiCert employs Certificate Revocation List (CRL) servers using HTTP on port 80 instead of HTTPS on port 443 to verify these certificates during Cloud Connector installation. Cloud Connector components, themselves, do not communicate over external port 80. The need for external port 80 is a byproduct of the certificate verification process that the operating system performs.

Here is the primary way to resolve this issue:

Installing the certificate

  1. Open the MMC certificate store on the Citrix Cloud Connector exhibiting the behavior

    https://msdn.microsoft.com/en-us/library/ms788967(v=vs.110).aspx. Make sure to select the Computer account option when prompted by the Certificates snap-in.

  2. Navigate to https://dl.cacerts.digicert.com/DigiCertAssuredIDRootCA.crt and download the Root certificate.

  3. Open the certificate and choose “Install Certificate…”

  4. Ensure that the “local machine” option is targeted

  5. Validate that the Root certificate shows up under the proper Certificate Store

  6. Navigate to https://dl.cacerts.digicert.com/DigiCertSHA2AssuredIDCodeSigningCA.crt and download the Intermediate certificate.

  7. Open the certificate and choose “Install Certificate…”

  8. Ensure that the “local machine” option is targeted

  9. Validate that the Intermediate certificate shows up under the proper Certificate Store.

Related:

  • No Related Posts

Impact of SameSite Cookie on Citrix ADC After Chrome Upgrade

Permanent Fix

The permanent fix for the configuration level options to accommodate this change will be available in versions 13.0, 12.1, 12.0 and 11.1 and following are the targeted dates.

ADC Versions Release Target Dates Status
13.0 52.24 March 24th 2020 Released
12.1 55.24 March 6th 2020 Released
12.0 March 27th 2020 Pending
11.1 64.11 March 25th 2020 Released

The following are the available workarounds:

Workarounds

Workaround through Chrome

In Chrome 80 there is an option which will allow you to revert to the legacy cookie behavior. This will be available for at least 12 months after the release of Chrome 80 stable.

Refer to SameSite Updates for more information.

Workaround Steps for Case: 1 App cookie

One can configure a response-based rewrite policy to look into “Set-cookie” header in the response sent by the backend server and append the “SameSite” cookie attribute.

Sample rewrite policy looks like:

add rewrite action rewrite_http_header replace_all http.RES.full_Header ""SameSite=None; Secure; path=/"" -search "regex(re!(path=/\; SameSite)|(path=/)!)"add rewrite policy append_samesite_cookie "http.RES.HEADER("Set-Cookie").EXISTS" rewrite_http_header

above rewrite policies needs to be bound application specific virtual server on Citrix ADC.

Workaround Steps for Case: 2 ADC cookie (Persistence Use case)

Currently there are two workarounds to prevent breakage if any (due to the chrome update) to applications with COOKIEINSERT persistence configured on LB vserver.

1. Use response RULE based persistence

If the back end application sends a unique cookie for each of the client session, Citrix ADC can use this unique cookie value as a key and create a RULE based persistence entry storing the back end server information corresponding to the cookie received. When the client request comes back with this Cookie, Citrix ADC will use the cookie value as the key and fetch the corresponding back end server to forward the request, hence maintaining the stickiness as achieved by COOKIEINSERT persistence. This approach works only if the back end server sends a unique Cookie key:value pair for each client in the response.

Below is a sample config where back end server sends cookie with the key as SESSIONID. The SESSIONID in the below config must be replaced with the unique cookie key sent by the back end.

set lb vserver lbvs -persistenceType RULE -rule "HTTP.REQ.COOKIE.VALUE("SESSIONID")" -resRule "HTTP.RES.SET_COOKIE.COOKIE("SESSIONID").VALUE(0)"

Note: The persistence timeout value must be chosen appropriately based on the application requirement.

2. Two Tier topology with a new Citrix ADC front ending the existing Citrix ADCs

Customer can have a two-tier topology with a new Citrix ADC front ending the traffic for the tier-2 Citrix ADC (existing Citrix ADC). The first tier Citrix ADC does response rewrite to include the SameSite attribute for all the cookies received from the tier-2 Citrix ADC.

There are no configuration changes required on the tier-2 Citrix ADC.

Below is a sample configuration on the tier-1 Citrix ADC.

enable feature lb rewriteadd lb vserver tier-1-lb <protocol> <IP> <port>add service tier-2-lb-svc <tier-2-vserver-IP> <tier-2-vserver-protocol> <tier-2-vserver-port>bind lb vserver tier-1-lb tier-2-lb-svcadd rewrite action rewrite_http_header replace_all http.RES.full_Header ""SameSite=None; Secure; path=/"" -search "regex(re!(path=/\; SameSite)|(path=/)!)"add rewrite policy append_samesite_cookie "http.RES.HEADER("Set-Cookie").EXISTS" rewrite_http_headerbind lb vserver tier-1-lb -policyname append_samesite_cookie -priority 10 -type RESPONSE

Note:- This should work even if the back end server does not include any cookie of its own.

We are reviewing on any other ADC use case which may have impact due to the change in default Chrome behavior, Document will be updated with Impact and mitigation steps accordingly.

Related:

  • No Related Posts