Windows network provider order

Just a quick post today to show you how to change the NIC (Network Interface Card) Binding Order on your Windows 2019 server.

Why would you want to do this? You may feel like access to your server file shares or other services may seem like it’s slightly delayed or unresponsive. This in my experience is due to the order that Windows sets your Network Providers when you initially installed the operating system.

In most cases, you’d want the Microsoft Windows Network as the primary or first listed provider and then other providers in the order you wish them to be considered by Windows as a Network Connection.

This is primarily because your file shares and other services will be delivered over the Microsoft Windows Network connection, rather than say an RDP Session Host Server Network Provider.

So how is the order changed? It’s pretty simple really, but there is a small trick that you need to be aware of that enables you to access the Advanced Settings menu.

To start process, open Control Panel and click on Network and Sharing Center. Once the Network and Sharing Center window is opened, click Change adapter settings and you should see a window similar to the following:

Картинка с сайта: www.matrix7.com.au

As you can see by the image above, there are no menu items displayed other than Organize. To display the advance menu you need press the <Alt> key on your keyboard. Once that is depressed the advanced menu becomes available as in the following screenshot:

Картинка с сайта: www.matrix7.com.au

Once the Advanced Settings window is displayed follow the instructions on the screenshot below:

Click OK to save the order and that’s all there is to it, you’re task is complete.

If you’ve found this useful, you may want to sign up to our newsletter where you’ll receive notices on when we post new articles and helpful «how tos». Just fill out your details below and we’ll do the rest…

This article explains how to build your Citrix Workspace app unattended installation with PowerShell and shows you how to tweak its configuration.

Change Log
24.09.2018: added Prevent an unexpected MSI repair from launching.
12.10.2018: added Prevent the splash screen “Citrix Receiver is now Citrix Workspace App” from showing. Thanks to Thorsten Enderlein (@endi24) for bringing this to my attention.
27.12.2018: updated article and complete installation script to version 1812 released on the 14th of December 2018 (previous version described in this article: 1809).
04.05.2019: updated article and complete installation script to version 1904 released on the 30th of April 2019 (previous version described in this article: 1812).
29.07.2019: updated article and complete installation script to version 1907. I also updated the handling of the return code of the Workspace app installer as described in the following article: https://support.citrix.com/article/CTX257546. This new handling of the return code first appeared in version 1904.1 of Citrix Workspace (in version 1904 this was not changed yet). Rest assured, the new handling of the return code in the complete installation script also works when installing versions before 1904.1.
02.10.2019: updated article and complete installation script to version 1909 released on the 19th of September 2019.

Introduction

Citrix Workspace app is a client component in a Citrix infrastructure that allows a user to launch resources in a Citrix Virtual Apps and Desktops (CVAD) environment, formerly known as XenApp and XenDesktop. With resources, I mean for example (Saas) applications and virtual desktops.

Installing and configuring Citrix Workspace app for Windows requires careful planning. You need to decide which components to enable, how to configure the default device access behavior, how to configure Citrix Workspace app group policies, whether or not to allow single sign-on, and more. In this article, I do my best to clarify most of these challenges.

Citrix Workspace app replaces Citrix Receiver. The latest (and last) version of Receiver is 4.12. The last LTSR release is version 4.9.6000. The version of Citrix Workspace app described in this article is 1909, released in September 2019.

So what is different in Citrix Workspace app compared to Receiver? Well, concerning files, folders, registry keys, and values, Citrix Workspace app is very similar to Receiver, with the following differences:

• The name changed from Receiver to Workspace app. However, many of the known installation paths and registry keys did not change, for example:
  • C:\Program Files (x86)\Citrix\ICA Client
  • C:\Program Files (x86)\Citrix\ICA Client\Receiver
  • HKLM\SOFTWARE\WOW6432Node\Citrix\ICA Client
  • HKLM\SOFTWARE\WOW6432Node\Citrix\Receiver
  • HKLM\SOFTWARE\WOW6432Node\Citrix\ReceiverInside
• The icon color changed from black to blue.
• An embedded browser for SaaS applications was added (read more about this here).
• With each new version, new features are released, for example, support for Citrix Casting (to a Workspace Hub) and support for Citrix Files (the new name for Citrix ShareFile). In most cases, this means that a new MSI installation file is added to the Workspace app installer.

Please see the Citrix documentation What’s new in Citrix Workspace app for Windows for more details.

I strongly suggest you read the excellent article Citrix Workspace app 1909 written by CTP Carl Stalhood. This is the most detailed article on Workspace app available.

Installing and configuring Citrix Workspace app

Installing and configuring Citrix Workspace app is not as straightforward as one might think. Many details can either make or break your deployment. Read and implement the sections below to ensure a smooth and successful deployment.

Summary

• Target device:
  Workspace app can be installed both on your virtual servers and desktops (alongside the VDA) as well as on the local client device. This all depends on your Citrix infrastructure and your access scenarios.
• Installation file name:
  CitrixWorkspaceApp.exe (or, after renaming, CitrixWorkspaceAppWeb.exe)
• File size:
  You may have noticed that the size of the file CitrixWorkspaceApp.exe is more than twice the size compared to the file CitrixReceiver.exe (version 4.12).

  The reason for this is the new embedded browser for secure Saas applications and the new feature Citrix Screen Casting. The Citrix Receiver 4.12 executable includes 53 files. The executable of Citrix Workspace app includes three more, namely the new MSI installer file CtxBrowserInstaller.msi, which is more than 50 MB in size, the new installer file WinDockerInstaller.msi (5 MB in size) and the new installer file AppProtection.msi (1,5 MB in size). The file CtxBrowserInstaller.msi was introduced in Workspace app version 1808. The file WinDockerInstaller.msi was introduced in version 1809. The file AppProtection.msi was in introduced in Workspace app version 1909 (protects against keyloggers and screen scrapers). The name WinDockerInstaller is a bit cryptic, but it contains the new feature Citrix Screen Casting. Versions 1810 to 1907 do not include any new MSI files (only updated ones).

  

  Картинка с сайта: dennisspan.com

  Citrix describes the embedded browser as follows: “The Citrix Workspace-embedded browser is a native browser running on the client machine embedded in the Citrix Workspace security sandbox. This gives end-users the best performance for rendering web pages of SaaS applications. The secure sandbox protects the end-user and the enterprise against malware, performance degradation, data loss, and unintended end-user behavior.” The embedded browser is launched automatically when a SaaS application is started. The embedded browser is not the same as the Citrix Secure Browser (for more information see the article Citrix Workspace: Embedded Browser vs Secure Browser Service vs Secure Browsing). The installation path for the embedded browser is: C:\Program Files (x86)\Citrix\ICA Client\Browser.

• Version (latest):
  1909 (released in September 2019)
• Installation parameters (command-line switches):
  See the section Workspace app command-line switches below.
• Uninstallation parameters (command-line switches):
  The following two command line switches are required to uninstall Citrix Workspace app: /silent /uninstall. The /noreboot parameter is not needed during a silent installation according to the Citrix documentation.
• Installation dependencies:
  No
• Other dependencies:
  No
• Reboot required:
  Yes (for certain components such as Single Sign-on, /includeSSON)
• ADMX files:
  Yes (see the section on Group Policies in the conclusion of this article)
• Ports and firewall:
  No (outbound communication only, e.g. port 80, 443, 1494, 2598)
• Download location:
  Workspace app 1909 for Windows
• Reference:
  Configure and install Citrix Workspace app using command-line parameters

Citrix Workspace app installation file (CitrixWorkspaceApp.exe)

The latest version of Citrix Workspace app can be downloaded here. The download contains one file: CitrixWorkspaceApp.exe. This file contains several MSI files; one MSI installer per component. This is the list of components for Workspace app 1909:

1. AppProtection.msi (new since Workspace app 1909)
2. AuthManager.msi
3. CitrixHDXMediaStreamForFlash-ClientInstall.msi
4. CtxBrowserInstaller.msi (new since Workspace app 1808)
5. DesktopViewer.msi
6. GenericUSB.msi
7. ICAWebWrapper.msi
8. RIInstaller.msi
9. SelfServicePlugin.msi
10. SSONWrapper.msi
11. Vd3dClient.msi
12. WebHelper.msi
13. WinDockerInstaller.msi (new since Workspace app 1809)

The version is not displayed in the file name, so the file name is the same for each version of Workspace app. To see the version of the executable, you have to take a look at the Details tab in the file properties.

The version displayed in the details tab is always a little bit different than the commercial version displayed on the official Citrix download page.

Example:

Картинка с сайта: dennisspan.com

Version 1904 of Citrix Workspace app has product version 19.4.0 and file version 19.4.0.34.

Картинка с сайта: dennisspan.com

Another thing you should know about the installation file is that renaming it from CitrixWorkspaceApp.exe to CitrixWorkspaceAppWeb.exe changes the installation behavior. See the section Prevent the Add Account Window for more details.

Do you know what renaming the file name does under the hood? It sets the registry value CitrixReceiverWeb (DWORD) in the registry key HKLM\Software\Wow6432Node\Citrix\Installer to 1. This registry value is also created when the original file name is used, but then the value is set to 0. And no, I did not make a spelling mistake; the name of the registry value does include the old name Receiver and not WorkspaceApp.

Картинка с сайта: dennisspan.com

Citrix Workspace app command-line switches

There are various parameters you can parse. For a detailed overview of all parameters please refer to the article Configure and install Citrix Workspace app for Windows using Command Line parameters. I strongly suggest reading the entire article before deploying Citrix Workspace app.

You can also use the Citrix Receiver Commandline Helper Tool to help you build the exact command line syntax. This tool has not yet been renamed to Citrix Workspace app Commandline Helper Tool.

Картинка с сайта: dennisspan.com

It is difficult for me to tell you exactly which command line switches (= parameters) you should use. This all depends on your environment. However, you should be aware of the following:

• Some parameters are required to work together with server-side components, such as enabling bidirectional content redirection.
• Some parameters require local administrator rights, such as /includeSSON to enable single sign-on authentication.
• In some cases, a reboot may be required. For example, USB devices that are in a suspended state when Citrix Workspace app for Windows installs are not recognized by Citrix Workspace app for Windows until after the user device is restarted (reference).

Here are some of the parameters I use for my environments:

• /silent
  All of my deployments are automated, including Citrix Workspace app. I therefore need to use the /silent parameter.
• /includeSSON
  This enables single sign-on (pass-through authentication) so a user does not need to enter authentication information for a second time after logging on to Windows.
• /FORCE_LAA=1
  This enables Local app Access.
• EnableCEIP=false
  Do not enable participation in the Citrix Customer Experience Improvement Program (CEIP). CEIP collects anonymous statistics and usage information and sends them to Citrix.
• /AutoUpdateCheck=disabled
  I personally prefer to test new versions of Citrix Workspace app before implementing them in production (so no automatic updates are allowed). You can also omit this parameter entirely and manage the auto-update behavior using Group Policy. See also the Auto-Update section in Carl Stalhood’s article Citrix Workspace app 1909.

Note: In case you are updating to Citrix Workspace app from an unsupported version, make sure to use the parameter forceinstall (this command replaces the rcu parameter used for Citrix Workspace app version before 1909). This will execute the Receiver Cleanup Utility.

The /noreboot parameter is not required for silent installations according to the Citrix documentation. If possible, I recommend rebooting the machine before using Citrix Workspace app.

Citrix Workspace app log files

The installation of Workspace app generates multiple log files: one general log file (“Trolley Express”) and one log file per MSI installation, for example:

• TrolleyExpress-%Date%-%Time%.log
• CtxInstall-CitrixHDXMediaStreamForFlash-ClientInstall-%Date%-%Time%.log
• CtxInstall-DesktopViewer-%Date%-%Time%.log
• CtxInstall-SelfServicePlugin-%Date%-%Time%.log

The total number of log files depends on the number of components you install. Each MSI log file represents one component; the more components you install, the more log files will be generated (up to a total of 12).

The installation log files generated by Citrix Workspace app are always created in the TEMP folder in the subfolder CTXReceiverInstallLogs-%Date%-%Time%. The log directory still includes the name Receiver.

Note: in the section Troubleshooting the installation in the Citrix support article Configure and install using command-line parameters it is stated that the log files are stored in the directory %TEMP%/CTXWorkspaceInstallLogs, but this seems to be an error. The directory is still the same as it was for Citrix Receiver, namely CTXReceiverInstallLogs-%Date%-%Time%.

The location of the TEMP folder in most environments is one of the following:

• C:\Users\%UserName%\AppData\Local\Temp
  This directory is for sure used in many environments. Each user has a temporary directory.
• C:\Users\%UserName%\AppData\Local\Temp\%SessionNumber%
  This is almost the same directory as the previous one. The difference is that each user has a temporary directory per session. If allowed by the administrator, a user can have multiple sessions on one system.
  
• C:\Windows\Temp
  This is the TEMP of the local SYSTEM account. Software deployment tools such as Microsoft SCCM use the SYSTEM account for installations on the local machine.
• C:\Temp
  This directory may be used on a FAT client. On a multi-user system, it is not typical to use one temp directory for multiple users.

Of course, the TEMP directory in your environment may be different than the ones listed above. The environment variable %TEMP% will always contain the correct location of the TEMP directory.

Unfortunately, there is no installation (or uninstallation) parameter that allows the log files to be written to another directory besides TEMP. There is no command-line switch like /Logfile or /Log.

The only way to capture the log files in a directory other than TEMP is to copy them from the TEMP folder after the installation has finished.

In the complete installation script below, the script starts by deleting any existing Citrix Workspace app log files from the TEMP directory (lines 71 to 80). By using the environment variable %TEMP% the script makes sure that the correct TEMP directory is used.
After the installation (or uninstallation), the script copies the newly created log files to the log directory declared in the variable $LogDir. The log directory ($LogDir) is a combination of the variables $BaseLogDir and $PackageName. You can change these variables in lines 45 and 46.

Updating from Receiver to Workspace app (warning)

I experienced an issue updating the last version of Citrix Receiver (4.12) to the new Workspace app version 1909 and it had to do with the HDX RealTime Media Engine.

The warning message I received was:

“You might be having an issue with a Citrix virtual driver (HDX RealTime Media Engine). Contact your system administrator for further assistance.”

Картинка с сайта: dennisspan.com

Although this is a warning message, I was not able to start any published applications.

Even reinstalling the HDX RealTime Media Engine (forcing a repair) did not work. At the end, I did the following, which worked:

• Uninstall the HDX RealTime Media Engine
• Uninstall Receiver
• Reboot machine*
• Install Workspace app
• Install the HDX RealTime Media Engine
• Reboot machine*

A reboot may not have been strictly necessary, but since I installed Receiver including Single Sign-On I decided to restart the machine.

Configure default device access behavior (Client Selective Trust)

As per Citrix: “With the introduction of Receiver 3.x (Workspace app) client, administrators can configure the default behavior for device access when connecting to a Citrix XenDesktop or XenApp environment. By default, the Desktop Viewer client device restrictions are based on the Internet region and this behavior can be changed by creating the Client Selective Trust feature registry keys under the HKEY_LOCAL_MACHINE hive in the registry and by modifying the required values.”

For example, when you allow the user to access files on the local client device, you may see the following security warning:

The security popup can concern the following local resources:

• Client Drives
• Microphones and Webcams
• USB and other Devices

The default behavior of Workspace app is to prompt the user. As an administrator, you can define the access level by modifying the registry or by using the ADMX group policy template. There are four access levels:

• 0 = No Access
• 1 = Read Only Access
• 2 = Full Access
• 3 = Prompt User for Access

Please see the Citrix article How to Configure Default Device Access Behavior of Receiver, XenDesktop and XenApp for more information.

I decided to modify the default behavior using the registry. I downloaded the ZIP file from the aforementioned article and modified the file ReceiverCSTRegUpx86.reg. I set all relevant registry entries to 2 (= Full Access) except for the Restricted Sites region/zone (these values remain on 0 = No Access).

Note:
Yes, I used the file ReceiverCSTRegUpx86.reg even though I installed Workspace app on a 64-bit operating system. On a 64-bit operating system, Workspace app installs itself in the folder C:\Program Files (x86) and all processes run in 32-bit mode.

Картинка с сайта: dennisspan.com

You can download a copy of this modified file here:

In the complete installation script below, the script imports the registry file in lines 201 to 205. Please make sure that you copy the actual file to the subdirectory Files. Also, in case you rename the registry file, please make sure to change the file name in the script as well (line 204).

Please be aware that pre-configuring the Client Selective Trust settings does NOT prevent a user from changing these settings! A user can configure his or her connection preferences in the Connection Center under Preferences.

Картинка с сайта: dennisspan.com

In case you want to prevent the user from changing the preferences, set the value (Default) in the following registry key to false:

HKLM\SOFTWARE\WOW6432Node\Citrix\ICA Client\Client Selective Trust\oidPredefinedSecurityPolicySettings\InstantiatedSecurityPolicyEditable

Like this:

Картинка с сайта: dennisspan.com

As you can see in the screenshot below, after changing the (Default) value (REG_SZ) to false, the user is no longer able to change the preferences.

You do not even need to close the active session for this setting to work. You only have to close the Preferences window and open it again after changing the registry value. The change is active instantly.

The complete installation script below does NOT change the (Default) registry value. In case you would like to change it, please add the following code:

Place it somewhere between lines 199 and 266.

A big thanks to my colleague Wolfgang Thürr (X, Twitter) for bringing this to my attention.

Prevent the Add Account window from launching

In the Add Account window, as per Citrix “users can […] set up a Citrix Workspace app account by entering an email address or a server URL. Citrix Workspace app determines the NetScaler Gateway, StoreFront server, or AppController virtual appliance associated with the email address and then prompts the user to log on for enumeration.”

The Add Account wizard can be triggered in three ways:

• At the end of the installation by clicking the Add Account button.
• At logon time.
• By double-clicking the Workspace app icon in the system tray.

By default, at the end of the installation, the Add Account button is shown.

Картинка с сайта: dennisspan.com

To prevent this button from appearing you can do one of two things:

1. Rename the installation file CitrixWorkspaceApp.exe to CitrixWorkspaceAppWeb.exe (this name has to be exact including camel-case letters). Reference: Deploy Citrix Workspace app for Windows using Workspace for Web.
2. Use the group policy setting EnableFTU* or create the registry item EnableX1FTU in the registry key HKLM\SOFTWARE\Wow6432Node\Policies\Citrix with a DWORD value of 0 before running the installation.

*You can now configure the EnableFTU setting using a Citrix Workspace app group policy. See the section below on the Workspace app ADMX files. This group policy setting sets the following two registry values:

• HKLM\SOFTWARE\Policies\Citrix -> EnableX1FTU -> DWORD 1
• HKLM\SOFTWARE\Wow6432Node\Policies\Citrix -> EnableX1FTU -> DWORD 1

Картинка с сайта: dennisspan.com

The result is that the Add Account button is not shown.

Картинка с сайта: dennisspan.com

In the complete installation script below, the registry item EnableX1FTU is created before installation, although strictly speaking it is not necessary since the PowerShell script triggers a silent installation (so no GUI is shown anyway).

By default, the Add Account window is also triggered at user logon.

Картинка с сайта: dennisspan.com

To prevent this window from appearing, there are three options:

1. Add the registry item HideAddAccountOnRestart (DWORD) with a value of 1 to the registry key HKCU\Software\Citrix\Receiver (yes, the old name Receiver is still used). The tick box “Do not show this window automatically at logon” creates the same registry entry. Please be aware that this is a current user setting. I therefore recommend using a Group Policy Preference (the article Configuring the time zone and code page with Group Policy demonstrates how to configure Group Policy Preferences).
2. Set the value of the registry item AllowAddStore (REG_SZ) to N in the registry key HKLM\SOFTWARE\WOW6432Node\Citrix\Dazzle. You can also control this setting using a Group Policy.
3. Rename the installation file CitrixWorkspaceApp.exe to CitrixWorkspaceAppWeb.exe (this name has to be exact including camel-case letters).

The complete installation script does not prevent the Add Account window from appearing at user logon. In case you want to prevent this from happening and you do not want to configure a Group Policy Preference, simply rename the file CitrixWorkspaceApp.exe to CitrixWorkspaceAppWeb.exe as mentioned previously (this is the simplest solution).

Prevent an unexpected MSI repair from launching

It may happen that when you try to start a published application, an MSI installer repair of the component “Citrix Online Plug-in” is started.

The exact cause for this behavior is unknown to me, but I can offer you a workaround. To solve this issue, you simply have to delete all data from the registry value WEB_CLIENT (part of the Citrix Online Plug-in MSI). Do not delete the registry value itself! Just remove the data from it (“empty” it) as shown in the screenshot below.

Картинка с сайта: dennisspan.com

The registry value WEB_CLIENT (string / REG_SZ) is located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\%ProductGUID%\Features

The product GUID is different for each version of Citrix Workspace app:

• D40311B1F8DD0004B8715A85DAECC4CF -> Workspace app version 1808
• 65DDBF745D30EBA42B298EB9F8EF598B -> Workspace app version 1809
• 230369BA6C7C7464683823509A70DF6E -> Workspace app version 1810
• 691BFE598F3E06243B378CC91B536771 -> Workspace app version 1812
• 52593DD2E7A97DE41BF6EED7F1579FA5 -> Workspace app version 1902
• 9BBCC4F9C00B64B4990698B41BB1A3AF -> Workspace app version 1903
• 88759762CEE8CF04C85B2D3727441362 -> Workspace app version 1904
• D2C5650F878893E40B9B9562ED9373CA -> Workspace app version 1904.1
• 6A325AD5754E1B044A29EBB5065A2C67 -> Workspace app version 1905
• 195324F90296A2B46A9766A17E548F7D -> Workspace app version 1907
• ACD95015F191DC94A873EF5561AE259C -> Workspace app version 1909

In the complete installation script below, the data in the WEB_CLIENT registry value for Citrix Workspace app 1909 is removed (lines 209 to 225).

Prevent the splash screen “Citrix Receiver is now Citrix Workspace App” from showing

When a user opens Citrix Workspace app for the first time, the splash screen “Citrix Receiver is now Citrix Workspace App” is shown:

Картинка с сайта: dennisspan.com

The following registry value prevents the splash screen from appearing:

• Key: HKEY_CURRENT_USER\Software\Citrix\Splashscreen
• Value name (REG_SZ / string): SplashscreenShown
• Value: 1

Картинка с сайта: dennisspan.com

This value is not included in the complete installation script below. I recommend using a Group Policy Preference to configure this setting (the article Configuring the time zone and code page with Group Policy demonstrates how to configure Group Policy Preferences).

Remove Citrix Workspace app shortcuts

During installation, Citrix Workspace app creates a shortcut in the Programs folder in the Start Menu of the public user (= All Users):

C:\ProgramData\Start Menu\Programs\Citrix Workspace.lnk

In the complete installation script below, this shortcut is removed (lines 261 to 264).

Note:
In the past, Citrix Receiver (now Workspace app) created a shortcut in the public Programs\Startup folder in the Start Menu (= All Users). This is no longer the case, but the installation script does check for this value and removes it in case it exists.Citrix Workspace app automatically starts at logon time by running the command “C:\Program Files (x86)\Citrix\ICA Client\concentr.exe” /startup (HKLM\SOFTWARE\WOW6432Node\Microsoft\ Windows\CurrentVersion\Run -> ConnectionCenter).

Prevent Windows 10 Game Bar popup (Win+G)

As per Citrix: “When launching published apps or desktops from a Windows 10 OS a […] popup windows briefly appears prompting to press Win + G for the game bar or the search bar.”

As described in the article, you can disable the game bar with the following registry entry:

• Key: HKLM\SOFTWARE\Policies\Microsoft\Windows\GameDVR
• Item: AllowGameDVR
• Value: 00000000
• Type: DWORD

The complete installation script below sets this registry value (line 237).

Modify the Network Provider order (for Windows 10 1709 only)

When you install the Workspace app Single Sign-on feature (/includeSSON), an entry is created in the network provider order.

Citrix adds the entry PnSson (= Citrix Single Sign-on). Citrix recommends that this entry be listed as number four, after the three default Windows network providers (see the info box above).

With Windows 10 version 1709, two things are important to know:

1. There is a known bug with the network provider
2. The network provider order is handled differently compared to older operating systems

Let’s start with the bug. As described by Citrix in the article Windows 10 Fall Creators Update (v1709) – Citrix Known Issues, the network provider has a bug (which is fixed in Windows 10 version 1803 and higher). The bug is that no third-party network provider, including Citrix’s PnSson value, is populated under the newly introduced registry key ProviderOrder under HKLM\System\ CurrentControlSet\Control\NetworkProvider. This bug causes the error “failed to get network providers” when you try to display the network provider order graphically.

Please be aware that the actual functionality of the network provider still works.

In the past, the order of the network provider was determined by the order of the entries in the registry item ProviderOrder under HKLM\System\CurrentControlSet\Control\NetworkProvider\Order. With Windows 10, this is no longer the case. The order is now determined by the decimal value of the network provider (HKLM\System\CurrentControlSet\Control\NetworkProvider\ProviderOrder). The item with the lowest number is executed first and the item with the highest number last.

Картинка с сайта: dennisspan.com

In the article Windows 10 Fall Creators Update (v1709) – Citrix Known Issues, Citrix recommends creating the missing item using the decimal DWORD value of 4000. I recommend using a different number, for example, 3001 or 3500. The reason for this is simple; you may have another third-party product that already occupies the number 4000. This is for example the case when you install a product such as Lotus Notes including the Notes Single logon service. The main goal is that the PnSson value is listed as the fourth item, after the three default Microsoft ones. The third Microsoft entry has a value of 3000, so the value PnSson needs to have a higher value (at least 3001 or higher).

In the complete installation script below, the missing network provider registry item is created in lines 241 to 251, but only for Windows 10 version 1709.

Performance optimizations

There seem to be a couple of registry values that may improve the performance of Workspace app. I did not add these to the complete installation script. In case you experience slow enumerations of (start menu) icons, please test the following registry values:

• InitialRefreshMinMs (REG_SZ) = 1 – minimizes the launch delay before contacting the store
• InitialRefreshMaxMs (REG_SZ) = 1 – minimizes the launch delay before contacting the store
• MaxSimultaneousFetches (REG_DWORD) = 6  – improves the time of loading icons in the Start Menu
• MaxSimultaneousSubscribes (REG_DWORD) = 6 – improves the time of loading icons in the Start Menu

See the example in the previous section on how to add these values to the complete installation script.

Complete installation script

I packed the complete Citrix Workspace app installation in my installation template. The script below contains the installation and all configurations for Citrix Workspace app as described in the previous sections, including detailed logging and error handling. The functions used in the scripts require my PowerShell Functions Library to be present on the local system. This means that before you can use the script, you need to copy the PowerShell module file DS_PowerShell_Function_Library.psm1 to the local system first.

The script was created for Windows 10 (all versions) and Windows Server 2016 version 1607 and higher. I tested this script on Windows 10 version 1803.

To use this script, please follow these steps:

• Create an installation directory on the local computer or a file share (UNC path). For example C:\Temp\Citrix\WorkspaceApp.
• Create a subdirectory called Files.
• Download and copy the Workspace app CitrixWorkspaceApp.exe to the folder Files in the installation directory.
• Optional: rename the CitrixWorkspaceApp.exe to CitrixWorkspaceAppWeb.exe.
• Download and copy the registry file (*.reg) containing the Client Selective Trust registry keys and values to the folder Files in the installation directory.
• Download and copy the PowerShell module file DS_PowerShell_Function_Library.psm1 to a directory on your local system.
• Copy the complete PowerShell script below to a new PS1 file (e.g. Install_CitrixWorkspaceApp.ps1) and add this file to the root of the installation directory (not in the subdirectory Files).
• Modify the PowerShell script:
  • Optional: modify the location of the log directory and log file name in lines 45 and 46.
  • Optional: in case you renamed the CitrixWorkspaceApp.exe to CitrixWorkspaceAppWeb.exe, enter the correct file name in line 100.
  • Optional: in case you use a different sub-directory name instead of Files, change it in line 106.
  • Enter the correct path to the PowerShell module file in line 62.
  • Enter the correct product ID of the version of the Workspace app you are installing in line 223. You find all product IDs in the comments above line 223 as well as in this section of this article.
• Execute the PowerShell script as follows:
  powershell.exe -executionpolicy bypass -file C:\Temp\Citrix\WorkspaceApp\Install_CitrixWorkspaceApp.ps1

To uninstall Workspace app, execute the script as follows:

powershell.exe -executionpolicy bypass -file C:\Temp\Citrix\WorkspaceApp\Install_CitrixWorkspaceApp.ps1 Uninstall

The uninstallation removes any custom configuration the installation may have set as well as the following two registry keys:

• HKLM\Software\Policies\Citrix\ICA Client
• HKLM\Software\Wow6432Node\Policies\Citrix\ICA Client

Removing these two registry keys is recommended by Citrix in the section To uninstall Citrix Workspace app for Windows using the command line interface in the article Install and uninstall Citrix Workspace app for Windows manually.

If you want to go one step further and create an SCCM package as well, please follow the step-by-step explanation in the article Deep dive creating SCCM packages for Citrix.

Conclusion

Installing and configuring Citrix Workspace app can get quite complicated and requires a bit of planning. Also, please be aware of the following:

• More settings can be directly configured during the installation of Citrix Workspace app. Most of these configurations concern the Windows registry. Please see the section Registry Values in Carl Stalhood’s article Citrix Workspace app 1909 for more information. In case you want to add additional configurations to the complete installation script, I recommend copying and reusing existing lines of code. Please be aware that many settings can nowadays be managed using Group Policy.
• Citrix Workspace app comes with a large collection of Group Policy settings. Please see the section Workspace app / Receiver Group Policy ADMX Template in Carl Stalhood’s article Citrix Workspace app 1909 for more information. The actual ADMX files can be downloaded on the Citrix website (in the section Downloads for admins), but they are also included in the installation directory of Workspace app (C:\Program Files (x86)\Citrix\ICA Client\Configuration).
• Pass-through authentication (or single sign-on) requires many different settings to be correctly configured, such as Trusted Sites, Trust XML Requests on the Delivery Controller, installing the Single Sign-On component in Workspace app, and more. Please see the section Pass-through Authentication in Carl Stalhood’s article Citrix Workspace app 1909 for a complete overview of what needs to be configured. Citrix Workspace app comes with a built-in tool for checking the SSON configuration (see the Citrix article SSON Configuration Checker for Citrix Receiver for Windows for more information).
  

  Картинка с сайта: dennisspan.com

  

  Картинка с сайта: dennisspan.com

• The latest version of Workspace app is also included in the installation sources of the Virtual Delivery Agent. On a Citrix worker, there are two possible strategies you can follow:
  1. You install Workspace app as a stand-alone installation (as described in this article) and install the Virtual Delivery Agent excluding Workspace app. This is accomplished by using the command line /components VDA as described in the section Citrix Virtual Delivery Agent in my article Scripting the complete list of Citrix components with PowerShell.
  2. You install the version of Workspace app included in the Virtual Delivery Agent installation sources (in this case you do the parameter /components VDA,PLUGINS). In this case, you do NOT install Workspace app as a stand-alone installation.
• When using Skype for Business in your environment, you may want to install the HDX RealTime Media Engine on your client device together with Citrix Workspace app. Citrix Workspace app is a prerequisite for the Media Engine; without Workspace app, Media Engine cannot be installed. To automate the installation of the HDX RealTime Media Engine, please see the section HDX RealTime Media Engine for Windows in my article Scripting the complete list of Citrix components with PowerShell. Also, for extensive information on Skype for Business, Citrix, and the HDX RealTime Optimization Pack, please see the section Skype for Business in Carl Stalhood’s article Citrix Workspace app 1909. I also highly recommend you to read the article Skype for Business with XenApp & XenDesktop written by Citrix CTP George Spiers.
• Citrix Workspace app 1809 and higher supports Citrix Screen Casting for the Citrix Ready workspace hub.
  

  Картинка с сайта: dennisspan.com

I hope the information in this article was of some help to you. Happy scripting!

Problem: I needed to put the «Microsoft Windows Network» network provider on top of the other (Novell Netware) providers. This is to get rid of the 15 second delay the Novell client does when trying to access a Windows file server.

This is pretty easy to do manually (Network Connections->Advanced->Advanced Settings->Provider Order), but a little more difficult to do manually. The registry key «HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder» lists the providers as a comma separated string, for example «NetwareWorkstation,RDPNP,LanmanWorkstation,WebClient»

Unfortunately, the installed providers aren’t really predictable. For example, if the computer has PointSec drive encryption installed, a provider named «PssoCM32» is listed somewhere in the end of the string.

Solution: Read the string from the registry, split it up, create a new string beginning with «LanmanWorkstation» (which of course is the «Microsoft Windows Network» provider), attach the rest of the providers to the new string, in the same order they were originally listed.

VBScript Code (successfully made unreadable by blogger.com, but is copy-pasteable to Notepad):

‘
‘ ChangeProviderOrder.vbs, by Anders Olsson, Kentor Teknik AB, 2006-10-31
‘
‘ Reads the «Network provider order» from the registry and reorders it putting
‘ the «Microsoft Windows Networking» provider on top.
‘
‘ Example: Before — «NCredMgr,NetwareWorkstation,RDPNP,LanmanWorkstation,WebClient»
‘ would become «LanmanWorkstation,NCredMgr,NetwareWorkstation,RDPNP,WebClient» after
‘ running this script.
‘

Set WshShell = WScript.CreateObject(«WScript.Shell»)

‘ Read the reg value of the providers
strKey = WshShell.RegRead(«HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder»)

‘ Split the strings up using comma (ASCII #44) as the delimiter
arrProvs = Split(strKey, chr(44), -1, 1)

‘ If LanmanWorkstation is already first, we don’t have to do anything
If arrProvs(0) = «LanmanWorkstation» Then
Wscript.Quit(0)
end if

‘ «LanmanWorkstation» should always start the string
strNewProvs = «LanmanWorkstation»

‘ Loop through the old provider strings, and add them to the new string. Don’t
‘ write LanmanWorkstation, since it’s already written at the start of the string.
For Each strProv In arrProvs
Select Case strProv
Case «LanmanWorkstation»
Case Else strNewProvs = strNewProvs & «,» & strProv
End Select
Next

‘ Write the new string back to the registry
WshShell.RegWrite «HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder», strNewProvs, «REG_SZ»

Networking / Beginners

There are several networking options not covered thus far because they’re not usually needed in a standard network setup.

Adapters and Bindings

You can control which protocols and services are associated with each network adapter using the check boxes on each adapter’s properties page. For example, you can uncheck Client for Microsoft Networking and File and Printer Sharing for Microsoft Networks on a network adapter that is used only to connect to a broadband Internet modem, to gain additional security above that provided by the Internet Connection Firewall.

You can also monitor and modify all network bindings in one place with the Adapters and Bindings dialog. To view this, open the Network Connections window and select Advanced, Advanced Settings.

Provider Order

If you have installed clients for both the Novell NetWare and Microsoft networking, you can adjust the network provider order, which determines which computer name service, Novell’s or Microsoft’s, is queried first to find a given named file or print server. For example, if you choose a shared printer named \\munich\laserjet, Windows has to locate the machine named munich. It might need to query both the Windows computer name service (Active Directory or the browser service) and the NetWare naming service before it finds the name. When you use a mix of Microsoft and NetWare servers, you might be able to speed up network operations by setting the provider order so that the most likely name service is examined first.

In most cases, you won’t need to make any changes to Windows’s Provider Order list. If your network administrator suggests that you do, just follow these steps:

1. Open Network Connections by selecting Start, My Computer, My Network Place, View Network Connections.
2. From the Advanced menu, select Advanced Settings, and select the Provider Order tab. The dialog lists services used to find access to file servers and print servers, respectively.
3. Arrange the services so that the type you use most frequently is listed on top, followed by less-often-used services. Highlight a service type, and click the up- or down-arrow button to rearrange the types.

When finished, click OK to close the dialogs.

Optional Networking Components

Windows comes with several additional network services and components that are not installed by default. These components are

• Network Monitor Driver- Allows your computer’s network communications to be recorded and monitored by a network supervisor, for diagnostic purposes. Install this only if requested by your network administrator.
  To install this driver, open the properties page for a selected network adapter, click Install, and select Protocols.
• Simple Network Management Protocol (SNMP)- Used on larger networks to monitor computer and router configuration. See the additional notes on SNMP later in this section.
• WMI SNMP Provider- Gives Windows Management Interface application software (for example, Windows Script Host programs) access to SNMP data.
  To Install SNMP or the WMI SNMP Provider, open the Network Connections window. Select Advanced, Optional Networking Components. Select Management and Monitoring Tools, and click Details.
• Internet Gateway Device Discovery and Control Client- Allows other computers on the network to monitor and control the dial-up or PPPoE Internet connection on the computer running Windows Internet Connection Sharing. Requires the Universal Plug and Play service as well. This service was discussed earlier in the tutorial. (Not available on 64-bit versions of Windows XP.)
• RIP Listener- Lets Windows configure the TCP/IP routing table automatically when network routers broadcast path information using the Router Information Protocol.
• Simple TCP/IP Services- A set of primitive TCP/IP services such as character stream generation and data echo. They’re rarely needed and can make you an easy target for Denial of Service (DOS) attacks by hackers if installed.
• Universal Plug and Play (UPnP)- Lets your computer automatically discover and connect to networked appliances and other new network devices. UPnP is a new technology that lets network hardware and future network-ready appliances communicate without manual setup.
  To install the Discovery and Control client, RIP Listener, Simple TCP/IP Services or UPnP, open the Network Connections window. Select Advanced, Optional Networking Components. Select Networking Services, and click Details.
• Print Services for Unix- Lets Unix/Linux users use your computer’s printers (and other shared printers on your network). Also installs the lpr and lpq programs so you can send print jobs to Unix/Linux printers.
  To install the Discovery and Control client, RIP Listener, Simple TCP/IP Services or UPnP, open the Network Connections window. Select Advanced, Optional Networking Components. Select Other Network File and Print Services, and click Details.

You must be logged on as a Computer Administrator to install these components.

More on SNMP

SNMP should not be installed unless your network administrator requires its use, as there are some security risks attached to it. If you do choose to install SNMP, you should immediately configure the SNMP monitor to protect your computer’s information with a secret «community name.» This name is like a password that remote monitors need to supply before they can extract information from your computer. The default community name is public. Your network manager might supply you with an alternative community name. To set it, do the following:

1. Click Start, right-click My Computer, and select Manage.
2. Open Services and Applications, select Services, and locate SNMP Service in the right pane. Double-click it to open its Properties page.
3. Select the Security tab. Select Public, and then click Remove. Next, click Add to enter any community names provided by your network manager. Generally, assign only read-only community rights unless your network manager specifies otherwise.
4. You can additionally restrict SNMP access to specific network hosts (namely, management computers) by selecting Accept SNMP Packets from These Hosts and adding the appropriate IP addresses.

NOTE
SNMP can be a security risk because it reveals the names of user accounts on your computer and your computer’s network routing information. A community name with write or create permission can alter network routing tables. For this reason, SNMP should be blocked by your network’s firewall, and you should not install it unless it’s necessary.

TIP
If you’re a network manager and use SNMP to monitor equipment health, you might find it valuable to know that Windows XP and 2000’s Professional and Server versions come with a utility that can turn specified Windows Event Log entries into SNMP traps (messages) as they happen. This feature is configured by the undocumented program evntwin, which is installed when you install SNMP. This utility can let your network monitor detect and report on full hard drives, security violations, and other significant events.

evntwin can save a list of event-to-trap mappings to a file. Another undocumented utility, evntcmd, can instantly install this file on another Windows XP or 2000 computer, even remotely.

Multihoming

In some instances it is desirable to assign multiple IP addresses to a single network adapter. You might do this if you are providing Internet services and need a single computer to take up the job of one that has gone offline.

To assign multiple IP addresses, open the adapter’s Properties page. Select Internet Protocol (TCP/IP) and click Advanced. On the IP Addressing tab, you can click Add to enter multiple IP addresses and network masks, as well as multiple default gateways. The addresses you assign don’t necessarily have to belong to the same subnet, although it is not recommended practice to run multiple TCP/IP subnets over the same wire.

NOTE
If you install multiple network adapters or multiple subnet addresses in one Windows XP computer, you should configure the computer never to be the Master Browser. This is discussed earlier in the tutorial.

When mounting NFS, network error – 53 may appear. In this latest blog, we’ll seek answers to the questions such as what does the error means, what cause the error, and how we fix the error easily. As part of our Windows Support Service, Bobcares provides answers to all of your questions.

Overview

1. What Is Network Error – 53 When Mounting NFS?
2. Common Causes and Fixes for Network Error 53
3. Conclusion

What Is Network Error – 53 When Mounting NFS?

Network Error – 53 is a common issue encountered when trying to mount an NFS (Network File System) share on Windows. This error occurs when Windows is unable to locate the specified NFS server or share, often causing frustration for users trying to access shared files across networks. The root of this problem can stem from various causes, such as incorrect configuration, missing components, or network issues.

Here, we will break down the potential causes of Network Error – 53 and provide simple fixes to help the user resolve the issue and successfully mount the NFS shares on a Windows system.

When we try to mount an NFS share on a Windows machine and face Network Error 53, the associated message will typically read: “The network path was not found.” This indicates that Windows cannot locate the NFS server or the shared directory on the network. The syntax for mounting an NFS share in Windows typically looks like this:

Картинка с сайта: bobcares.com

For example:

mount \\192.168.1.100\data N:

If this command fails, there are several potential causes and corresponding fixes.

Common Causes and Fixes for Network Error 53

1. Incorrect NFS Server Address or Share Name

Cause: The IP address or share name specified in the mount command may be incorrect.

Fix: Verify the correct IP address and share name by using the command showmount -e on the NFS server. This command lists the available NFS shares on the server. We must use the correct path in the mount command.

2. NFS Client Not Installed on Windows

Cause: The NFS client feature may not be installed on your Windows machine.

Fix: Install the NFS client by enabling the “Services for NFS” feature. To do this, we must run the following steps:

i. Go to “Control Panel” > “Programs” > “Turn Windows features on or off.”

ii. Scroll down and check the box for “Services for NFS.”

iii. Click “OK” and let Windows install the necessary components.

3. Firewall or Network Issues

Cause: Firewalls on either the NFS server or the Windows client may be blocking the necessary network ports required for NFS communication.

Fix: Temporarily disable the firewalls on both the server and client to see if this resolves the issue. If it does, configure the firewall to allow NFS traffic. Specifically, we need to allow port 2049 for NFS and port 111 for RPC traffic. Also, make sure these ports are open in both the Windows firewall and on the NFS server’s firewall.

4. Network Provider Order on Windows

Cause: Windows may prioritize other network providers over the NFS client, which can cause the NFS mount to fail.

Fix: Modify the network provider order in the Windows Registry with the following steps.

i. Open “Registry Editor” (press Win + R, type regedit, and press Enter).

ii. Then, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order.

iii. Modify the ProviderOrder value to prioritize NFS. The value should start with Nfsnp,RDPNP,LanmanWorkstation.

iv. Restart the system to apply the changes.

5. DFS (Distributed File System) Client Interference

Cause: The DFS client may interfere with NFS mounts, leading to Network Error 53.

Fix: Disable the DFS client in the Windows Registry with the below steps.

i. Open “Registry Editor.”

ii. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup.

iii. Create a new DWORD (32-bit) value named DisableDfs and set its value to 1.

iv. Restart the system to disable DFS and try mounting the NFS share again.

6. Permissions Issues

Cause: The user account trying to mount the NFS share may not have the necessary permissions on the NFS server.

Fix: Ensure that the correct permissions are set on the NFS server. To check permissions:

i. Log in to the NFS server and run ls -ld /path/to/nfs/share. This command will show the permissions for the shared directory.

ii. If the user or group trying to access the share doesn’t have proper permissions, adjust the access control.

iii. Also, verify the /etc/exports file on the NFS server, which defines the directories shared via NFS:

bash

/path/to/nfs/share (rw,sync,no_subtree_check)

iv. After modifying the /etc/exports file, refresh the NFS exports with the following command:

exportfs -ra

7. NFS Configuration Errors

Cause: Misconfigurations in the NFS server setup could be preventing access.

Fix: Open the /etc/exports file on the NFS server and verify the syntax for each share entry. Make sure the paths are accurate and there are no typos or syntax errors. After making changes to the file, restart the NFS service to apply the new configuration:

sudo systemctl restart nfs-server

Or, if we’re using an older system:

sudo service nfs restart

We can also use the showmount -e command to ensure the shares are correctly configured and accessible.

[Want to learn more? Click here to reach us.]

Conclusion

Network Error 53 when mounting NFS shares on Windows can be caused by several factors, from incorrect server addresses to firewall issues or even NFS client installation problems. By systematically troubleshooting the potential causes, such as verifying server information, checking firewall configurations, and ensuring proper user permission, we can resolve this error and successfully mount the NFS share.

It’s always a good practice to ensure that all systems involved in NFS sharing are correctly configured and that any necessary services or features are enabled on both the server and the client. Our Tech team also suggests to keep the system up to date and regular setup checks to prevent future issues when working with NFS shares in a mixed Windows and Linux environment.