7023391: Reflection end-user folders get created in C:Micro FocusReflection instead of under My Documents

This problem is caused because the user’s My Documents location has been redirected to the root of the C: drive. (This is an unusual location and is not typically used as the destination of Re-directed My Documents)

The path for the Reflection user configuration files is determined by a Windows registry key called “UserDir” under HKEY_LOCAL_MACHINESoftwareWow6432NodeWRQReflection. This value is typically set to the default of %personalfolder%Micro FocusReflection. This unique variable allows the Reflection software to resolve the location of the configuration files “on-the-fly” as it may be changed from defaults for the user and variable prevents issues that can occur if a fixed or static entry is used to point to the end-users Documents folder. The %personalfolder% is not a Microsoft Windows environment value, and actually pre-dates the Windows PersonalFolders variable. The %personalfolder% value will typically expand to the same value used by the Windows Environment variable called “UserProfile” (via a Windows 32-bit API call) and can also resolve to where the users Re-directed My Documents is located, if it is on a network drive. Problems only occur if the the Re-directed My Documents is pointed to the root of the C: drive, as all other locations will work correctly.

To resolve the issue set the following registry keys:

HKEY_LOCAL_MACHINESoftwareWow6432NodeWRQReflection

Key Name: UserDir:

Key Value: %UserProfile%DocumentsMicro FocusReflection

HKEY_LOCAL_MACHINESoftwareWow6432NodeWRQReflection

Key Name: LogDir:

Key Value: %UserProfile%DocumentsMicro FocusReflection

Note: The trailing backslash on this path is important. Without the trailing backslash the pathing will not work correctly.

Related:

XenApp/XenDesktop 7.X : Basic Powershell Cmdlets for Delivery Controller’s Health Check

Please run the following command to do a Delivery Controller’s health check from an elevated powershell window:

To load the Citrix modules run asnp citrix*

1. Run Get-BrokerController to list the information about all the Delivery Controllers in the site.

Note down the SID of the controller and match it with the SID value in the chb_configcontrollers XenApp/XenDesktop Site database table (Browse to the database for your XenDesktop environment, expand tables and then check for the table by the chb.config controller)

Also ensure that the status of all the Delivery Controllers is “Active”

2. To check the service status of all the Citrix Services , run the following command:

Get-command get-*servicestatus

Copy all the values in ‘Name’ and paste it in the next command line

OUTPUT: Service status should come up as ‘OK


3. To measure the number of instances getting registered from the controller with the database:

Get-ConfigRegisteredServiceInstance | measure

OUTPUT: Will give the consolidated number. (With every version we have few new services and instances which get added, i.e, with 7.6 we have 49 instances. If you have 2 controllers in the environment then the value will come up to be 49*2=98)


4. For environment where we have separate databases for Logging and Monitor service, the following command can be run to check the status:

(In case you have a single database for Ste, Monitoring and Logging the String value will be same. For environment with different databases, the string value will be different for Logging and Monitor datastore)

Get-LogDatastore

Get-MonitorDatastore


5. To check the connection string which connects the Delivery Controller uses to communicate to the site database, run the following command:

Get-BrokerDbconnection

OUTPUT: Server= SQL Server name;Initial Catalog=Name of the XenApp/XenDesktop database


6. Run the following command to verify the installed db version for all the services. Example for Broker Service run:

Get-BrokerInstalledDbVersion

Similarly, you can check for the other services as well:

Get-AdminInstalledDbVersion

Get-AnalyticsInstalledDbVersion and so on.

You will get the list of Citrix services from Get-command get-*servicestatus as stated earlier.

7. To check the Connection strings in the registry, browse to the following location and check the value of the connection string:

HKLMComputerHKEY_LOCAL_MACHINESOFTWARECitrixDesktopServerConnectionsController

This can as well be checked for all the services installed:

Browse to the following location and verify the value for the Connection String:

HKLMComputerHKEY_LOCAL_MACHINESOFTWARECitrixXDServices”Service name”DatastoreConnections

8. Run the below cmdlet to test Database connectivity of individual Citrix Services.

Example:

Test-BrokerDBconnection “<connection strings>”

Test-ConfigDBConnection “<connection strings>”

Related:

Boot failure 0xc000000f: Windows failed to load because the NLS data is missing, or corrupt.

This means that an NLS file (international code page) that Windows wants is not on the boot image, which means App Layering didn’t recognize it during our boot analysis. When you import an OS layer, the ELM reads the list of drivers and services to determine what needs to be on the boot image and what can wait until layers are available. Unfortunately, NLS files are not recognized. We automatically include only US and Western Europe code pages.

However, there is a way to include a file on the boot disk that our drivers do not automatically detect. You can do this on the Gold VM and reimport, but it’s usually easier to add a version to your existing OS layer and fix it there.

In the OS Layer, edit “C:Program FilesUnideskUniservicebootfile.txt”. This is a list of all files in this VM that we identified as being critical system boot-time files. Add the files you need, save the file, and finalize the OS layer.

Unfortunately, App Layering does not in general know all the files that are necessary for a particular language. We have successfully tested this procedure with only a handful of regionalized Windows 7 systems: Greek, Russian, Slovenian, Japanese, and a few others. So you will need to do the analysis to determine what you need.

But a good first step is to edit bootfile.txt, search down to the other NLS files, and add lines like this (these are the two additional NLS files necessary for Japanese, for instance):

C:/Windows/System32/C_10001.NLS

C:/Windows/System32/C_932.NLS

Note the slashes – they go forwards. Then finalize the OS layer and test.

If you are unsure what code pages you are currently using, you can get that information from the registry. Look for the three values in this key:

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlNlsCodePage]

“ACP”=”932”

“OEMCP”=”932”

“MACCP”=”10001”

You would need to include the appropriate NLS file for each of those entries. However, if you expect to need to support additional languages, remember to add them as well. A list of NLS tables for many languages is here, and that’s what I derived the above files with (you will want the ANSI, MAC and OEM pages).

http://www.bullzip.com/products/pdf/cultureinfo.php

It’s not clear that the NLS files alone will be sufficient in all cases. Yuo may wind up with an iterative process trying to identify what else might be required. However, if you determine that other files are necessary, you can always add those to bootfile.txt as well.

Do not be tempted to include all Windows files in bootfile.txt without a clear reason. Unidesk provides only 1GB of space for files in the boot image, and all the NLS files add up to at least 10MB. However, we have seen at least one case where the end-user was unable to determine what additional language was required, and they would up adding all of the NLS files anyway. Their boot image did not run out of space, and they were able to boot with that. So, as a last ditch effort, it’s possible to just add all of them.

NOTE: It has been reported that “C:/Windows/System/vgaoem.fon” might be required and might not be present, so if this KB doesn’t work, try adding that file as well if it is not already listed in bootfile.txt.

(Supplementary information for Unidesk V2 and V3 customers: you may not be able to fix this in a new version of the OS layer. You might need to fix it in the Gold VM and reimport the OS layer, if you have never gotten your OS laer to work. Or if the damage was introduced in a newer version of the OS layer, delete that new version, recreate it, and make sure you add the appropriate files to the bootfile.txt file before finalizing.)

Related:

How to determine the version of Citrix license server installed

To determine Citrix License product version, follow the steps below on the License server —

1.) Launch Registry Editor

2.) For 64-bit OS, navigate to HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixLicenseServerInstall

3.) For 32-bit OS, navigate to HKEY_LOCAL_MACHINESOFTWARECitrixLicenseServerInstall

3.) Look for REG_SZ called Version — This key contains the License server version as shown in the screenshot below

User-added image

Related:

HID and some other type of USB device fail to redirect

Registry setting DeviceRules on the client computer take precedent over Citrix Studio, AD, and Receiver.admx policies. (The client computer is the computer with Receiver for Windows installed).

Review the registry data on the client computer in the registry setting DeviceRules.

Path: HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCitrixICA ClientGenericUSB

Name: DeviceRules

Type: REG_MULTI_SZ

Observe that specific devices classes and subclasses are denied in the DeviceRules setting.

If the device class you are attempting to redirect is listed as Deny in the DeviceRules- then create a new entry above the Deny related to device class or place a # in front of the target class / subclass or delete the entry to remove the device rule that is blocking the redirection.

A walkthrough – How to enable Imprivata HDW-IMP-60 device.

Step 1. Review the device on the client computer. Record the class, subclass, VID and PID settings. Open device manager and find the target USB device.

User-added image

The target device has a Class 03 and SubClass 01. Note this matches a DENY rule in the client registry DeviceRules.

User-added image

Modify the DeviceRules registry entry on the client computer (highlighted below). Add an ALLOW rule for the target device above the DENY rule that matches the class and subclass or optionally comment the line with a ‘#’ character …

User-added image

Now create a Client USB device redirection and Client USB device redirection rules policy that applies to the target.

User-added image

Once the policy applies and the client computer registry is modified now the device appears in Device manager as a Generic device. The device is ready for redirection as a generic device.

User-added image

After selecting the Redirect in the Device manager the device is available in the VDA ICA session. Open device manager on the VDA and confirm that the Imprivata HID type device appears in the VDA session- by reviewing the VID and PID of the device.

User-added image

Related:

Creating a New Site After Receiving Error: There Was a Problem Communicating with the Citrix Delegated Administration Service

1. Stop the Citrix Services. Open elevated PowerShell and run:

Get-Service Citrix* | Stop-Service -force

2. Remove the connection strings value manually via registry on all DDCs in the site:

Connection String in XenApp / XenDesktop 7.6

HKEY_LOCAL_MACHINESOFTWARECitrixDesktopServerDataStoreConnectionsController

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesADIdentitySchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesAnalyticsDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesConfigLoggingSiteSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesConfigurationSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesDASDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesDesktopUpdateManagerSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesEnvTestServiceSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesHostingUnitServiceSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesMonitorDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesStorefrontSchemaDataStoreConnections

Connection String in XenApp / XenDesktop 7.15

HKEY_LOCAL_MACHINESOFTWARECitrixDesktopServerDataStoreConnectionsController

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesADIdentitySchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesAnalyticsDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesAppLibrarySchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesConfigLoggingSiteSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesConfigurationSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesDASDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesDesktopUpdateManagerSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesEnvTestServiceSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesHostingUnitServiceSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesMonitorDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesOrchestrationSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesStorefrontSchemaDataStoreConnections

HKEY_LOCAL_MACHINESOFTWARECitrixXDservicesTrustSchemaDataStoreConnections​


Example

Delete the value for the ConnectionString Registry Key:

User-added image
3. Restart the Citrix Services. Open elevated PowerShell and run:

Get-Service Citrix* | Start-Service

4. Open Studio. You will see the option to create a new site. Follow the wizard to create a new database for your site.

5. Once completed, add any additional DDC(s) as needed.

Related:

Seamless Flags Configuration for Epic Hyperspace

This article includes recommended configuration for delivering Epic Hyperspace as a published application via Citrix XenApp.

Configuration Instructions

Citrix XenApp includes server-side seamless configuration settings in the Windows Registry that can be used to improve performance of the Epic Hyperspace application. To configure the recommended settings, modify the registry on the XenApp server where the application is installed.

XenApp 6.5 and 7.6 LTSR

The general guidance from Citrix for Epic Hyperspace deployed on XenApp 6.5 and 7.6 LTSR is to disable Active Accessibility Hook.

Create a new value in under the following “TWI” registry key:

  • HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Citrix/wfshell/TWI
  • Value Name: SeamlessFlags
  • Value Type: REG_DWORD
Deployment Type Data Description
For all Hyperspace deployments on XenApp 6.5 and 7.6 LTSR 0x00000004 DISABLE ACTIVE ACCESSIBILITY HOOK (0x4)
For a double hop topology where users launch the Hyperspace published application from within an existing remote session such as a XenDesktop session or a published XenApp desktop. 0x00004004 DISABLE ACTIVE ACCESSIBILITY HOOK (0x4)

DISABLE CLIENT INFO SYNC (0x4000)

Data: (Refer to table directly below for Hexadecimal-formatted data to use.)

XenApp 7.15 LTSR

The general guidance from Citrix for Epic Hyperspace deployed on XenApp 7.15 LTSR is for Active Accessibility Hook to remain enabled but with the addition of a value named “AAHookFlags” value set to “1” in the “TWI” registry key:

  • HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixwfshellTWI
  • Value Name: AAHookFlags
  • Type: REG_DWORD
  • Data: (Refer to table directly below for Hexadecimal-formatted data to use.)
Deployment Type Value: Data: Description
For all Hyperspace deployments on XenApp 7.15 LTSR AAHookFlags 1 The purpose of setting this value to “1” is to activate newer performance improvements that have shown to be effective for some 3rd party

applications such as Epic Hyperspace that may require fine

tuning

For double hop deployments, in addition to setting the AAHookFlags value set to “1” as above, create a new value under the following “TWI” registry key:

  • HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Citrix/wfshell/TWI
  • Value Name: SeamlessFlags
  • Value Type: REG_DWORD
  • Data: (Refer to table directly below for Hexadecimal-formatted data to use.)
Deployment Type Value: Data: Description
For a double hop topology where users launch the Hyperspace published application from within an existing remote session such as a XenDesktop session or a published XenApp desktop. SeamlessFlags 0x00004000 DISABLE CLIENT INFO SYNC (0x4000)

Related:

How to Configure MTU when using EDT across VPN solutions

If there is a modification to the MTU on the VPN, then EDT connections might fail and fall back to TCP. This is a limitation of the VPN which is not handling IP fragmentation properly.

The workaround involves lowering the ICA/EDT MSS to a known value that will not cause fragmentation.

This MTU value needs to be determined by the customer, for example by using a tool like mturoute.exe.

In the case of Azure-hosted NetScaler VPX, Azure limits MTU to 1400 on the Azure Gateway. Therefore the EDT MSS and Output Buffers Length must be set to 1350.

Steps

1. Define the EDT MSS and Output Buffers Length in the ICA file template in the Storefront server:

Open the default.ica file for editing (by default it is located in C:inetpubwwwrootCitrix<StoreName>App_Datadefault.ica)

Add the following options under the [Application] section:

OutBufLength=1480

udtMSS=1480 (add this line if using Receiver for Windows 4.7 – 4.12, Receiver for Mac 12.5 – 12.9, Receiver for Linux 13.6 – 13.10, Receiver for iOS 7.2 – 7.5.x, Receiver for Android 3.12.3 – 3.13.x, or Workspace app 1808 for Mac, Linux, iOS, or Android)

edtMSS=1480 (add this line if using Workspace app for Windows 1808+)

Note: 1480 was used as an example. Replace the value with the appropriate value determined by the customer, or with 1350 if using an Azure-hosted Citrix Gateway. The client and server will agree on sizes during the connection negotiation.

User-added image


2. Enable Receiver/Workspace app to read the custom EDT MSS and Output Buffers Length values.

If using Receiver for Windows 4.7- 4.12 (Receiver for Windows 4.9 CU4+ and Workspace app for Windows 1808+ do NOT require these modifications on the Client):

Create UDPStackParameters registry key, which is missing/off by default:

HKCUSOFTWARECitrixICA ClientEngineConfigurationAdvancedModulesUDPUDPStackParameters

User-added image


If using Receiver for Windows 4.7 / 4.8 / 4.9 / 4.9 CU1 / 4.9 CU2 / 4.9 CU3:

There is a legacy issue in these Receivers for Windows where OutbufLength, when passed in an ICA file, is ignored.

Even if the registry value is modified to “*”, meaning accept everything from the ICA file, the ICA file setting is still ignored.

For this to work, in addition to creating the “UDPStackParameters” key as mentioned above, it is also necessary to modify the OutbufLength value in the registry and set it to the desired value determined above (1480 in the example):

  • 64-bit Windows

    HKLMSOFTWAREWow6432NodeCitrixICA ClientEngineConfigurationAdvancedModulesTCP/IPOutbufLength
  • 32-bit Windows

    HKLMSOFTWARE CitrixICA ClientEngineConfigurationAdvancedModulesTCP/IPOutbufLength

If using Receiver for Mac:

Modify the appropriate App Property to allow Receiver to read the customer parameters in the ICA file. This property is set to NO by default.

To do this, open Terminal and run:

defaults write com.citrix.receiver.nomas UDPStackParameters -bool YES


If using Receiver for iOS:

Toggle the the “Read EDT stack parameter” option, which is disabled by default:

Settings > Advanced > Adaptive Transport Settings > Read EDT stack parameter

User-added image

Related: