Connection

Whatever you do with your NoTouch-powered device, it will most likely have something to do with a "connection". In NoTouch terminology a "connection" is a stored object that determines how and where your device as to connect to, be it a Citrix, VMware Horizon View, FreeRDP or similar connection, a browser, whatever. A connection can be represented as a desktop icon or start menu entry; and/or it can be automatically started at boot time.

So to summarize - to an end user a "connection" is most likely synonymous with the desktop icons/menu entries; to a system administrator a connection is the place where the actual configuration how to talk to a VDI server goes. NoTouch devices can have multiple configured connections, run multiple connections at the same time, and even multiple instances of the same connection unless if not disallowed by server or client settings.

Commonly we refer to a started connection instance as a "session". Thus, to be really precise, a connection is the stored object, a session is the running instance. If you mix these terms up, don't mind.

You can add a connection easily:

  • Locally, follow these steps:
    1. Enter the configuration (Start Menu -> Configuration), log in with your client administration password (default is admin).
    2. Click on Connections (left side, rather at the top)
    3. Click on the "Add" button
    4. Click on "Edit", next to the newly added connection to enter the connection's parameters
  • In NoTouch Center, see here: Add connection (NTC)

You can configure your new connection then.

Contents

Connection parameters

Fundamentals

  • Connection name. Contains the human-understandable name of the connection. You can choose this freely, but choose wisely, to not confuse your end users, especially if configuring multiple connections.
  • Connection mode. Defines what type of connection is and what kind of software module to configure and start, for example the Citrix client in various ways, the VMware Horizon View client, the Mozilla Firefox browser, one of the RDP clients, etc. This setting defines also which parameter subsections are visible and will be used. For example, a Citrix connection would not evaluate RDP-specific options even if some are configured. On the other hand, a browser connection might evaluate Citrix options, since the browser can be used to connect to a Citrix web interface.
  • Connection target. A connection specific "target" where to connect to. This sounds a bit abstract, but it is actually simple and intuitive - but refer to the actual documentation of your desired connection mode:
    • Most connections just take a host name where to connect to.
    • Others might take a URL where the connection broker is located (vWorkspace, VMware Horizon View)
    • Citrix modes may wish to see a name of a published application or desktop here
    • Browser connections will take the browser startup URL from this setting

User authentication credentials and login behavior

For connections that end up in Windows VDI desktops, we suggest to set the domain parameter so that your users don't have to type it. We strongly recommend to not store username/password here as an attacker might be able to reverse-engineer and retrieve it; this is intended for absolutely non-critical things.

  • Username. Store a specific username that is automatically filled in. Not generally recommended.
  • Password. Store a specific password that is automatically filled in when connection. Not generally recommended.
  • Domain. Store a specific Windows domain name or comma-separated list of domain names. Recommended to set - makes life of end users easiers.
  • Show domain entry field. Default is "on", this switch controls if the login dialog allows to set a Windows domain or not. Of course this only has an effect if the NoTouch login window is shown. Connection modes that handle this internally, such as VMware Horizon View, ignore this field.

Note: These fields only have an effect for connections that deal with authentication. For example, browser connections will simply ignore these parameters.

GUI options

  • Window size. Usually connections open in a window, which can be fullscreen (default), or have a fixed size. Use this parameter to set the window size. Some connections have their own window size parameter equivalent in their #Connection-specific options, thus making this parameter ineffective.
  • Show in Controlcenter. The connection will be shown in Control Center with name and icon, allowing users to start. Only if Control Center is used.
  • Show in Menu. In the Start menu of the taskbar, as well as when right-clicking on the desktop, the connection will be represented by an icon and the connection name. Clicking on it will launch the connection.
  • Show on Desktop. A desktop icon will be shown with icon and connection name. Double-clicking on this icon will launch the connection. This will only work if desktop icons are generally enabled; this is the default setting, but you can deactive it totally in the window manager parameters.
  • Pin to startmenu. The connection will be shown (icon and name) in the main section of the start menu, not the "Connections" subsection.

Automation options

  • Autostart at boot. Start the connection automatically when the system boots up. See here for more information: Connection autostart
  • Action after exit. Defines what has to happen when the connection terminates. See here for more information: Action after exit

Restrictions

  • Exclusive mode. If this parameter is set to "on" and this connection is started, the system will not allow any other connection to start.
  • Allow to start more than one instance simultaneously. If this parameter is set to "on" and this connection is started, the system will not allow any other instance of the same connection to be started.

Other options

  • Use credentials of the local login feature. If you use the Local Login feature, NoTouch can take credentials from the user, store them in a reasonably safe location during system runtime and use it to authenticate to server connections, if this parameter is switched on "on". If you don't use this feature, this parameter has no effect.
  • Wait for network. This parameter contains a timeout value in seconds, default is 25. This is the maximum amount of time the system waits until the network is configured before actually starting the connection. If your network is already configured, there is no wait time at all.
  • Allow in-application configuration. This feature allows to store an application's modifications to its configuration files, which would otherwise regenerated freshly every time from NoTouch templates. Currently is exclusively used for creating Firefox profiles and may not even be visible with other connection modes.

Connection-specific options

There are several subtrees/subsections of even more parameters below a connection. While NoTouch OS will only show you those that are relevant to the currently set connection mode, NoTouch Center will show them all. Almost each connection mode comes with its own very specific set of options, so these have been put into subtrees accordingly.

Refer to the documentation of your desired connection mode to learn more about these connection-specific parameters:

Extended connection options

There are many more connection-specific options in the "Extended" subsection: Normally you will not have to change these options, but there are some specific use cases, see below for more information.


OS-en-ExtendedConnection.jpg


Extended GUI options

These options are depending on connection mode and the window size parameter. They will definitely be ignored if you have selected "full screen".

  • Position X. Pixel-position of top-left corner of connection window (X axis)
  • Position Y. Pixel-position of top-left-corner of connection window (Y axis)
  • Width. Window width.
  • Height. Window height.

Termination options

  • Process termination method. Determines how the connection should be terminated. You should leave this parameter on its default setting and only change when specifically instructed to do so.

Delay options

For situations where you want the system to wait, e.g. because there is some initialization in the background.

  • Delay on startup. Wait the number of seconds before starting the session. This makes the system unconditionally wait whenever the connection is started, be it a user clicking the icon, or when auto-started on boot-up.

Auto-start on system boot

The following options specifically target the auto-start of connections on system boot. There are situations where you just want to delay the start to ensure e.g. the network of VPN is established correctly.

  • Boot-up autostart: check and wait for connection URL. This option will work for Citrix, VMware, and browser sessions. It will take the target URL of these sessions and test out connectivity to this URL, in a loop with a maximum wait time of a bit less than a minute. The idea is that if the OS can't reach the URL, the respective client software for your VDI won't either.
  • Boot-up autostart delay. And delay in seconds that makes the system wait in this boot-up situation before launching this connection. It is like the delay on startup that is described above, but it applies only to the boot-up scenario.

Customization hooks

  • Command on startup. Linux shell command that is executed when the connection is started.
  • Boot-up autostart command. Linux shell command that is executed when the connection is started at system boot via the connection auto-start at boot. It is not executed when the user clicks the icon or in any other non-boot situation.
  • Command on exit. Linux shell command that is executed after the connection is closed.

There are many more "customization hooks" than just these two actually. If you are looking for things to automatically execute at system boot time, please see Eventscripts. To put custom code into the execution of the X server (=the low-level GUI subsystem), please see X11#Customization hooks.

Hotkey

  • Connection start hotkey. By default this field is empty. You can specify a hotkey combination here that will start this connection whenever this hotkey is pressed. Valid key designators are Alt, Ctrl, Shift, F1-F9, a-z, 0-9, and the special keys Up, Down, Esc, Tab, and the keys on the numeric keypad KP_Add, KP_Subtract, KP_Divide, KP_Multiply, KP_Enter. You can combine keys with the + plus sign, so for example Alt+Ctrl+x would have the effect that an instance of the connection is started whenever the user presses Alt, Ctrl and the x key simultaneously.

When dealing with hotkeys there are two caveats:

  • Some connection modes, such as fullscreen RDP, may "eat" all hotkeys away - so they would not have any effect at all
  • Do not define hotkeys that have effects in your VDI connections, such as the typical, well-known Windows hotkeys like Alt-F4 etc. This will confuse your users.

The "start banner" function allows for displaying important information, legal notices, disclaimers or a message of the day before connection start. Sysadmins can use it for people to read a legal disclaimer, acknowledge certain usage terms or simply for informing them about existing issues such as "Today we are working on our storage, it may be slower" or similar.

You may either type in your message directly into the short text parameter, or, if the message is longer, use a text file that is placed on a web server somewhere (e.g. [[Hosting files (VA)]

  • Start banner short text (max 250 characters). Your message that will be displayed to the end user.
  • Start banner URL. URL to a text file (text/plain) containing the banner text. This may be longer than 250 characters. It will be cached on the client system.
  • Start banner window title. The title of the window displaying the banner. If empty (default), the window title will be "Important notice" (regardless of configured language).
  • Start banner window geometry (WxH). If empty, the system will choose an appropriate window size. This may or may not what you want. If using the short text, you will most probably be fine without, if using the banner URL the system will default to 400x500.
  • Start banner label of OK button. By default, the "OK" button will be labeled "OK". You can specify a different label here, such as "Yes" or something nice in your language.
  • Start banner label of Cancel button (empty=no button). By default, there will only be an OK button. Only if using the short text (i.e. NOT when using the URL), you can have a second button that will essentially terminate the session start attempt. Use it for your users to decline or refuse, so choices like "No", "Cancel", "I decline" in your language would be natural choices if you really want to use this.

Note: We do not want to comment on the legal implications of users clicking Yes or No, that depends on your jurisdiction, and thankfully we are no lawyers.

Network authentication user credentials pass-through

Many connection modes involve a locally created login dialog that lets the user type in their credentials - username, password and potentially a login domain. These credentials can be passed on to the WiFi or Ethernet 802.1X authentication stack, resetting the existing WiFi/Ethernet connection and authenticating with these credentials. For this to happen, it must be enabled both in the network configuration and in the connection parameters.

These parameters govern the pass-through:

  • Pass-through of user credentials. Set this to on, if you want the pass-through to happen. By default, this is off.
  • Reset Wireless connection. Set this to on, if you want your credentials to be passed on to the wireless connection. By default this is off.
  • Reset Ethernet connection. Set this to on, if you want your credentials to be passed on to the Ethernet connection. By default this is off.

Please keep in mind that this functionality has to be active also in your wireless or wired interface configuration. However, by the settings there default to "on", so the key to activating this functionality is really here inside the Connection's Extended options. Read more about configuring the network's parameters here:

When the VDI connection exits, the WiFi connection will be reset. In that case, the preconfigured/stored credentials will be used, if some are defined, until the next user logs in.

Debugging/Error search

  • System trace. This runs the connection in trace modes, which means that operating system "syscalls" will be logged. This is useful if you plan to send us a support file afterwards. It severely degrades system performance, so please switch this parameter back to its default value "off" as soon as your tests are done.
  • Debug-Log. This turns an extended debug-log on. This is useful if you plan to send us a support file afterwards. It severely degrades system performance, so please switch this parameter back to its default value "off" as soon as your tests are done.
  • Show error message. This parameter controls the behavior how and if error messages on connection termination are shown. For example, you could turn off non-critical error messages with this parameter.

Environment

Under "Environment", you can define connection-specific environment variables. In NoTouch Center, this is a textual parameter that accepts a comma-separated list of key=value pairs, such as MYVAR=THISVALUE,A=B or similar. On the client, this is a subtree that you can navigate into and create new variable blocks, also consisting of key and value.