Uds 21 User Administration Guide Rev1

Installation Manual,
Administration and User

Guide of UDS Enterprise
Version 2.1 Rev. 1

21, June, 2017
Installation Manual, Administration and User
Guide of UDS Enterprise 2.1
www.udsenterprise.com
Index
1 INTRODUCTION ............................................................................................. 7
1.1 Free & Evaluation versions vs. Enterprise version ........................................ 8
1.2 Caracteristics ................................................................................................ 9
1.3 Architecture of the Platform with UDS Enterprise ....................................... 10
1.3.1 Architecture of the Network ...................................................................... 12
1.4 Components of UDS Enterprise .................................................................. 15
1.4.1 UDS Server............................................................................................... 16
1.4.2 UDS Tunneler ........................................................................................... 17
1.4.3 UDS Database .......................................................................................... 18
1.4.4 UDS Actor ................................................................................................. 19
1.4.5 UDS Plugin ............................................................................................... 20
2 BEFORE INSTALLING UDS ......................................................................... 21
2.1 Installing Enterprise on VMware vSphere Virtual Platform ......................... 22
2.1.1 Requirements of the Virtual Platform........................................................ 22
2.1.2 Network Connectivity ................................................................................ 23
2.2 Installing UDS Enterprise on oVirt Virtual Platform ..................................... 24
2.2.1 Virtual Platform Requirements.................................................................. 24
2.3 Installing UDS Enterprise on RHEV Virtual Platform .................................. 26
2.4 Installing UDS Enterprise on Microsoft Hyper-V ......................................... 28
2.5 Installing UDS Enterprise on XenServer Virtual Platform ........................... 31
Page 1 of 253
2.6 Installing UDS Enterprise on Nutanix Acropolis Virtual Platform ................ 33
2.7 Installing UDS Enterprise on OpenStack Platform ...................................... 35
2.8 Installing UDS Enterprise on OpenNebula Platform ................................... 37
3 INSTALLING UDS ENTERPRISE ................................................................. 39
3.1 Requirements of UDS Enterprise Environment ........................................... 40
3.1.1 Infrastructure Requirements ..................................................................... 40
3.1.2 Network Requirements ............................................................................. 40
3.2 Installing UDS Enterprise Environment ....................................................... 41
3.2.1 Install and configure the Database ........................................................... 41
3.2.2 Installing UDS Server ............................................................................... 45
3.2.3 Installing UDS Tunneler ............................................................................ 51
3.2.4 Install and configure UDS Actor ............................................................... 56
3.2.4.1 Install UDS Actor. Windows Virtual Desktops ....................................... 58
3.2.4.2 Install UDS Actor. Linux Virtual Desktops ............................................. 62
3.2.4.3 Install UDS Actor. Microsoft RDS Virtual Applications .......................... 66
3.2.5 Installing UDS Plugin for Windows ........................................................... 70
3.2.5.1 Instalacin Plugin UDS Windows .......................................................... 72
3.2.5.2 Installing UDS Plugin for Linux ............................................................. 75
4 ADMINISTRATION OF UDS ......................................................................... 78
Page 2 of 253
4.1 Configure Service Providers ..................................................................... 81
5 DEPLOYMENT OF VDI PLATFORM VIA VMWARE VSPHERE VIRTUAL

INFRASTRUCTURE. ....................................................................................... 82
5.1.1 VDI Platform with VMware vSphere ......................................................... 82
5.1.1.1 Register Service Provider VMWare vCenter Platform Provider .......... 82
5.1.1.2 Configure a service based on VMware Linked Clones Base .............. 85
5.1.2 VDI Platform with oVirt or RHEV .............................................................. 89
5.1.2.1 Register a Service Provider of the Service oVirt Platform Provider .... 89
5.1.2.2 Configure a service based on oVirt/RHEV Linked Clone .................... 92
5.1.3 VDI Platform with Microsoft Hyper-V ........................................................ 96
5.1.3.1 Register a Service Provider of the Service Hyper-V Platform Provider

.......................................................................................................................... 96
5.1.3.2 Configure a service based on Hyper-V Linked Clone ......................... 99
5.1.4 VDI Platform with Citrix XenServer......................................................... 102
5.1.4.1 Register a Service Provider of the Service XenServer Platform

Provider ......................................................................................................... 102
5.1.4.2 Configure a service based on Xen Linked Clone .............................. 105
5.1.5 VDI Platform with Nutanix Acropolis ....................................................... 107
5.1.5.1 Register a Service Provider of the Service Nutanix Acropolis Platform

Provider ......................................................................................................... 107
5.1.5.2 Configure a service based on Nutanix KVM ..................................... 110
5.1.6 VDI Platform with OpenStack ................................................................. 112
5.1.6.1 Register a Service Provider of the Service OpenStack Platform

Provider ......................................................................................................... 112
5.1.6.2 Configure a service based on OpenStack Live Volume.................... 115
5.1.7 VDI Platform with OpenNebula............................................................... 118
5.1.7.1 Register a Service Provider of the Service OpenNebula Platform

Provider ......................................................................................................... 118
5.1.7.2 Configure a service based on OpenNebula Live Volume ................. 121
5.1.8 Direct Connection to Persistent Devices ................................................ 123
Page 3 of 253
5.1.8.1 Register a Service Provider of the Service Static IP Machines Provider

........................................................................................................................ 123
5.1.8.2 Configure a service based on Static Multiple IP ............................... 125
5.1.8.3 Configure a service based on Static Single IP .................................. 127
5.1.9 RDS Platform Provider ........................................................................... 128
5.1.9.1 Register a Service Provider of the Service RDS Platform Provider .. 128
5.1.9.2 Configure a service based on RDS Platform RemoteAPP ............... 130
5.2 Configure Authenticators ........................................................................ 133
5.2.1 Active Directory Authenticator ................................................................ 134
5.2.2 eDirectory Authenticator ......................................................................... 136
5.2.3 Internal Database ................................................................................... 139
5.2.4 IP Authenticator ...................................................................................... 142
5.2.5 SAML Authenticator ................................................................................ 144
5.2.6 LDAP Authenticator ................................................................................ 146
5.3 Configure users, groups and user metagroups ......................................... 149
5.3.1 Creation of groups and users "Internal Database" ................................. 155
5.3.2 Creation of groups and users "IP Authenticator" .................................... 156
5.4 Configure OS Managers ......................................................................... 158
5.4.1 Linux OS Manager .................................................................................. 159
5.4.2 Linux Random Password OS Manager .................................................. 161
5.4.3 Windows Basic OS Manager .................................................................. 163
5.4.4 Windows Domain OS Manager .............................................................. 165
5.4.5 Windows Random Password OS Manager ............................................ 167
5.4.6 RDS OS Manager ................................................................................... 169
5.5 Configure Networks ................................................................................ 170
5.6 Configure Transports .............................................................................. 171
5.6.1 HTML5 RDP Transport ........................................................................... 173
5.6.2 NX Transport (direct) .............................................................................. 177
Page 4 of 253
5.6.3 NX Transport (tunneled) ......................................................................... 180
5.6.4 PCoIP Transport ..................................................................................... 183
5.6.5 RDP Transport (direct) ........................................................................... 185
5.6.6 RDP Transport (tunneled) ...................................................................... 189
5.6.7 RDS Transport (direct) ........................................................................... 194
5.6.8 RDS Transport (tunneled) ...................................................................... 198
5.6.9 RGS Transport (direct) ........................................................................... 202
5.6.10 SPICE Transport (direct) ...................................................................... 205
5.6.11 SPICE Transport (tunneled) ................................................................. 207
5.6.12 X2Go Transport (direct) ........................................................................ 210
5.6.13 X2Go Transport (tunneled) ................................................................... 214
5.7 Access Calendars and Scheduled Tasks .................................................. 217
5.7.1 Configure Calendars ............................................................................ 217
5.7.1.1 Grant or Deny Accesses to Users ....................................................... 220
5.7.1.2 Configure Scheduled Actions:............................................................. 221
5.8 Configure Services Pools ....................................................................... 223
5.9 Configure Permissions .............................................................................. 229
6 ACCESS VIRTUAL DESKTOPS WITH UDS ENTERPRISE....................... 232
7 ADVANCED CONFIGURATION OF UDS ENTERPRISE ........................... 236
7.1 Image Gallery ............................................................................................ 237
7.2 Service Pool Group................................................................................. 239
7.3 Reports...................................................................................................... 242
7.4 ADvanced Parameters of UDS Enterprise ................................................ 246
7.4.1 UDS ........................................................................................................ 247
7.4.2 RGS ........................................................................................................ 248
7.4.3 SAML ...................................................................................................... 248
7.4.4 IPAUTH ................................................................................................... 248
Page 5 of 253
7.4.5 NX ........................................................................................................... 249
7.4.6 CLUSTER ............................................................................................... 249
7.4.7 WYSE ..................................................................................................... 249
7.4.8 ENTERPRISE ......................................................................................... 249
7.4.9 SECURITY.............................................................................................. 250
7.4.10 VMWARE.............................................................................................. 251
7.5 Flush System Cache ................................................................................. 252
8 ABOUT VIRTUALCABLE ............................................................................ 253
Page 6 of 253
1 INTRODUCTION
UDS Enterprise is a multiplatform connection Broker for Windows and Linux. It

manages user access to virtual and remote desktops, applications remote session
established by the system.
UDS Enterprise provides a set of software elements for services lifecycle management,
administration and deployment of virtual services.
This document contains basic instructions to setup UDS software on a virtual

infrastructure and procedure for a proper administration of the different services.
Page 7 of 253
1.1 Free & Evaluation versions vs. Enterprise version
There are different versions of the UDS software, each of them oriented to different
uses and scenarios:
UDS Enterprise: Ideal for VDI environments of any size, it allows to have
technical support in case of any doubt with the software or updates to new
versions. Requires subscription purchase.
UDS Free: Valid for small VDI environments (maximum of 10 users). Includes
all the features of the Enterprise version. It does not require a subscription
purchase.
UDS Evaluation: Designed for conducting Pilots, PoCs and in general tests
with a limited duration (60 days). It has no limitation on the number of users and
does not require acquisition of a subscription.
UDS software requires a Data Base (DB) to storage system configuration parameters.
To perform this function, UDS is compatible with MySQL starting version 5.5.
UDS Enterprise paid version requires an external Data Base. In case you dont have
one, VirtualCable will provide a DB in virtual appliance format, which is not included in
UDS software support.
UDS Enterprise Free Edition & UDS Enterprise Evaluation Edition feature an internal
MySQL Data Base. External DB integration is not supported in these versions.
NOTE: In case youre about to setup UDS Enterprise Free Edition or UDS Enterprise
Evaluation Edition, the sections included in this guide regarding UDS Data Base dont
apply, since as we explained before the DB is embedded in the UDS Server
component.
The main differences between the available UDS versions are shown in the following
comparative table:
Enterprise Free Evaluation
N of users Until illimited 10 Illimited
Duration Illimited Illimited 60 days
New Hypervisors? Yes No No
Database? External required Internal Internal
WAN Tunneler for conections? Yes Yes Yes
Security updates? Yes No No
Upgrade between versions? Yes No No
New modules? Yes No No
Support? Yes By incidence No
Premium Support? Yes No No
Page 8 of 253
1.2 Caracteristics
The main features of UDS Enterprise include:
Very easy installation and administration
Automated deployment of virtual desktops and management of access to

remote desktop sessions
Virtualization of Windows application sessions for users of Windows / Linux

environments using Remote Desktop Services (RDS)
Multi-hypervisor, able to migrate the platform to more efficient future solutions

(currently compatible with VMware vSphere, KVM RHEV / oVirt, Microsoft
Hyper-V, Citrix XenServer, OpenNebula, OpenStack and Nutanix Acropolis)
Multi-authenticator. It allows to define users and groups of users from different

external sources and with configurations practically unlimited
Authentication system through multiple connectors, eg Active Directory,

eDirectory, OpenLDAP, SAML, LDAP, CAS, Internal Authentication System,
Device Authentication System, IP
Generation of reports of the status and use of the platform
Tasks scheduling system (service deployment, user access control, etc ...)
through calendars
Secure WAN access for desktops and virtual applications using an SSL-
tunneler included in the subscription
Full customization of the login portal and user service pages
Product roadmap based on customer and community requests
Prepared for heterogeneous environments where other solutions do not have

access by functionalities or scaling of costs, eg: AAPP or academic
environment
Model of costs per subscription that entitles to support, new versions, updates
and patches of UDS Enterprise
Non-redistributable subscription model for user segments to unlimited users
Page 9 of 253
1.3 Architecture of the Platform with UDS Enterprise
An optimal design of a services platform is essential in order to obtain all the benefits
which may be provided by the architecture. Each layer that forms this architecture may
be designed to fulfill its function without affecting the other ones.
The main elements that form an architecture with UDS are:
Connection clients: Devices used to access the virtual desktops and

applications, such as thin clients, zero clients, PCs, etc. It is important to
identify if the access to the desktop services will be carried out from a LAN or
from WAN
UDS Servers: They are formed by a database (DB) to storage all the data
related to the environment, a connection Broker which will manage the desktop
services lifecycle and communication with the hypervisors and other service
providers; and a tunnel server to allow secure access from outside. All of them
will be served in virtual appliance format
Authenticator/s: Active Directory, OpenLDAP, eDirectory Servers, etc

Through their integration with UDS they will control the users access to desktop
services. Depending on the environment, you may have from one to unlimited
number of authenticators
Service Providers
o Hypervisor platform: It executes the creation, switch on and

removal of the virtual desktops which are managed from the Broker.
UDS integrates itself with Microsoft Hyper-V, VMware vSphere, KVM
(oVirt and Red Hat Enterprise Virtualization), Citrix XenServer and
Nutanix Acroplis hypervisors
o RDS Applications: It provides virtualized applications which will be

administered by UDS Enterprise
Storage: They will host the servers, virtual and remote desktops, applications
and other services of the platform. The choice of the type of storage is an
important part of the design. Depending on the needs demanded by the users
in the desktop services, we may select the most appropriate one regarding
performance
With a clear idea of the architecture design, you may start scaling the platform, bearing
in mind the number of users that will access to it.
Page 10 of 253
In the following image, you can see an example of an architecture with UDS
Enterprise:
Page 11 of 253
1.3.1 Architecture of the Network
UDS Enterprise can be configured to be accessed by users located in a local network,

or users from a WAN (internet) without VPN or LAN Extension.
Example of deployment of services and virtual desktop applications for user access
through a LAN (extensible to users accessing from a VPN or LAN_extension):
Page 12 of 253
Example of deployment of services and virtual desktop applications for user access
across a WAN (internet).
In order for UDS to be published on the internet, and that its services can be accessed
by users; two public IP addresses will be needed (this process is possible with a single
public IP address by changing default ports and setting internal NATs).
Page 13 of 253
Example with 1 unique public IP:
Page 14 of 253
1.4 Components of UDS Enterprise
UDS Enterprise is made up of 5 elements that interact with each other.
UDS Server (Broker). It is installed as a virtual machine (VM) and it is provided

in virtual appliance format
UDS Tunneler: It is installed as a VM and it is provided in virtual appliance

format.
UDS Data Base: It is installed as a VM and it is provided in virtual appliance

format (It doesnt apply to UDS Enterprise Free Edition & Evaluation Edition))
UDS Actor: It is installed on the VM as a service that will be used as a template

for deploying the desktop groups, and in RDS application servers to provide
virtualized applications.
UDS Plugin: It is installed on the client device to connect to the desktop

services (with all connection protocols except HTML5)
The features and technical requirements of each component are defined below:
Page 15 of 253
1.4.1 UDS Server
This is the software that mediates among connection clients and service providers.
This is the basic element of UDS, as it performs the functions of connection Broker to
the desktop services and enables the administration and management of virtual
desktop platforms defined as implemented services.
Virtual Appliance with the following caracteristics:
Virtual hard drive: 5 GB
Memory: 1 GB
CPU: 2 vCPU
Network: 1 vNIC
Requirements:
1 IP Address
IP DNS
Network mask
IP Gateway
Domain name
Database IP
DB port and instance name
Activation code
Page 16 of 253
1.4.2 UDS Tunneler
Software that establishes secure connections to desktop services through WAN. It also
provides HTML5 access to the services.
UDS tunneler allows the connection from any device/browser/client to the desktop
services through a SSH tunnel without having installed any software beforehand.
Moreover, it allows RDP access to desktop services through HTML5.
Hard drive: 5 GB
Memory: 1 G
CPU: 2 vCPU
Network: 1 vNIC
Requirements:
1 IP Direction
IP DNS
Network mask
IP Gateway
Domain name
IP UDS Server
Page 17 of 253
1.4.3 UDS Database
This component is responsible for storing all system UDS data, such as service
providers, authenticators, connectivity and all the information needed to generate
statistics.
Currently, in UDS 2.1 version, database manager MySQL 5.5 version onwards are the
only ones supported.
It is necessary to have an appropriately configured MySQL database with a valid

instance and user at the time of installation.
IMPORTANT! In the event that you do not have said database manager, VirtualCable
can provide this component as a virtual appliance. This component is not included in
UDS Enterprise support.
Hard drive: 8 GB
Memory: 1 GB
CPU: 1 vCPU
Network: 1 vNIC
Requirements:
1 IP address
DNS IP
Network mask
IP Gateway
Domain name
User with instance permission
*THIS COMPONENT DOES NOT APPLY TO UDS ENTERPRISE FREE EDITION &
UDS ENTERPRISE EVALUATION EDITION.
Page 18 of 253
1.4.4 UDS Actor
This software performs the communication and interface functions for transmitting data
(virtual desktop status, machine name) and commands among the Broker and the
desktop services managed by UDS.
It is installed on the virtual machine as a service that will be used as a template (Gold
image) for generating desktop services groups based on Llinked Clones.
The supported operating systems for generating virtual desktops are:
Windows 10
Windows 8.1
Windows 8
Windows 7
Windows 2008
Windows 2012
Linux (Debian, Ubuntu, CentOS, Fedora, OpenSuse, etc)
Supported Operating Systems for generating Virtual Applications are:
Windows 2012 R2
Requirements:
.Net Framework 3.5 SP1 (Windows machines)
Python 2.7 (Linux machines)
UDS Server IP
UDS Master key (located in the UDS administration panel)
Page 19 of 253
1.4.5 UDS Plugin
This software allows the connection to the connection protocol to run desktop services.
It is installed on the client device to connect to desktop services.
The supported operating systems are:
Windows 10
Windows 8.1
Windows 8
Windows 7
Windows 2012
Windows 2008
Linux (Debian, Ubuntu, CentOS, Fedora, OpenSuse, etc)
MAC OSX (10.5 onwards)
Page 20 of 253
2 BEFORE INSTALLING UDS

The UDS Enterprise components can be hosted on different virtualization platforms.
Even though the UDS Enterprise components are hosted on a single virtual platform,
UDS is capable of managing the deployment of virtual desktops on multiple virtual
platforms that are completely independent of the virtual platform where UDS Enterprise
is hosted.
This section describes the requirements for installing UDS Enterprise on different
virtualization platforms and the requirements of the virtual platform on which the
software is to be installed.
Page 21 of 253
2.1 Installing Enterprise on VMware vSphere Virtual

Platform
2.1.1 Requirements of the Virtual Platform
UDS Enterprise can be hosted on VMware vSphere 5 or above.
To find out the requirements of a VMware vSphere platform, you can access the
following documentation:
VMware Compatibility Guide
vCenter Server and vSphere Client Hardware Requirements
The VMware platform on which UDS will be deployed must meet the following
requirements:
At least one VMware ESXi server with a valid license is needed for hosting the
UDS servers and generating the virtual desktops
The vSphere platform must be administered by a vCenter with a valid license
For UDS to be integrated and capable of sending requests to a vCenter, and for
these requests to be carried out, the user must have credentials with
administration rights on the VMware vSphere platform on which the virtual
desktops and applications are to be deployed
At least one Virtual Machine Port Group to which the virtual appliance of the
UDS platform is going to be connected must be established
At least one Virtual Machine Port Group to which the different virtual desktops
managed by UDS are going to be connected must be established
There must be at least 18 GB of free space on the hard drive to host the virtual
appliance that makes up UDS
There must be at least 3 GB of free RAM to host the virtual appliance that
makes up UDS
Page 22 of 253
2.1.2 Network Connectivity
The following connections between the different elements which make up the
UDS Enterprise platform must be enabled:
Source Destination Port

UDS Server UDS MySQL 3306
UDS Server vCenter 443
UDS Server Autenticator 389, 636, XXX
UDS Server Virtual Desktops 3389 (RDP), 22 (NX), XXX
UDS Server UDS Tunnel 80
UDS Server (Actor) Virtual Desktops 43900 - 44000
Virtual Desktops UDS Server (Actor) 80/443
UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), XXX
UDS Tunnel UDS Server 80
Users UDS Server 80/443
Users (LAN) Virtual Desktops 3389 (RDP), 22 (NX), XXX
Users UDS Tunnel 443
Users UDS Tunnel (HTML5) 10443
Page 23 of 253
2.2 Installing UDS Enterprise on oVirt Virtual Platform
2.2.1 Virtual Platform Requirements
UDS Enterprise can be deployed on oVirt 3.3, 3.4, 3.5.4, 4.0 and 4.1 platforms
The oVirt platform on which UDS will be deployed must meet the following
requirements:
At least one oVirt node server is required to host the UDS servers and generate
the virtual desktops
It is necessary that the platform oVirt is administered by an oVirt-engine
In order for UDS to be installed and able to send requests to oVirt-engine and
execute them, it is necessary to have the credentials of a user with
administration permissions on the oVirt platform on which the virtual desktops
are to be deployed
It is necessary to have defined at least one cluster to create and configure the
different virtual desktops managed by UDS
It is necessary to have defined at least one "Logical network" to which the

virtual servers of the UDS platform will be connected
It is necessary to have defined at least one "Logical Network" to which the

different virtual desks managed by UDS
At least 18 GB of free disk space is required to host the virtual servers that
make up UDS
At least 3 GB of free RAM is required to host the virtual servers that make UDS
Page 24 of 253

UDS Server oVirt-Engine 443
UDS Server Virtual Desktop 3389 (RDP), 22 (NX), XXX
UDS Server (Actor) Virtual Desktop 43900 - 44000
Virtual Desktop UDS Server (Actor) 80/443
UDS Tunnel Virtual Desktop 3389 (RDP), 22 (NX), XXX
Users (LAN) Virtual Desktop 3389 (RDP), 22 (NX), XXX
Page 25 of 253
2.3 Installing UDS Enterprise on RHEV Virtual Platform
UDS Enterprise can be deployed on Red Hat Enterprise Virtualization platforms

version 3 and 4.
The RHEV platform on which UDS is going to be deployed must meet the following
requirements:
At least one RHEV server is needed to host the UDS servers and create the
virtual desktops
The RHEV platform must be administered by a RHEV-Manager server
For UDS to be installed and capable of sending requests to a RHEV-Manager,

and for these requests to be carried out, the user must have credentials with
administration rights on the RHEV platform on which the virtual desktops are to
be deployed
You must have at least one setup cluster for creating and configuring the
different virtual desktops managed by UDS
You must have at least one setup Logical network to which the virtual servers
of the UDS platform are going to be connected
You must have at least one setup Logical network to which the different virtual
desktops managed by UDS are going to be connected
servers that make up UDS
There must be at least 3 GB of free RAM to host the virtual servers that make
up UDS.
Page 26 of 253

UDS Server RHEV-Manager 443
Page 27 of 253
2.4 Installing UDS Enterprise on Microsoft Hyper-V
UDS can be deployed on Microsoft Hyper-V platforms version 3
The Microsoft Hyper-V platform on which UDS is going to be deployed must meet the
following requirements.
At least one Microsoft Hyper-V server with a valid license to host the UDS
servers and create the virtual desktops
It is necessary that Microsoft Hyper-V servers are not part of a Microsoft cluster
For UDS to work properly against a Microsoft Hyper-V server, it is necessary

that this server is not part of a Microsoft cluster. Clustered Microsoft Hyper-V
will be supported in next UDS versions
You must have at least one Virtual Switch to connect the virtual servers of
UDS platform
You must have at least one Virtual Switch to connect the different virtual
desktops managed by UDS
You must have the credentials of one user with administration rights on the
Microsoft Hyper-V platform where the virtual desktops are going to be deployed
up UDS
You must enable WSMan on every Hyper-V host used with UDS so that
Microsoft Hyper-V with UDS will perform properly
Page 28 of 253
To enable it through HTTPS, you must have a valid certificate.
To enable it through HTTP, run:
winrm quickconfig
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
Page 29 of 253

UDS Server Hyper-V 443/80
Usuarios UDS Server 80/443
Page 30 of 253
2.5 Installing UDS Enterprise on XenServer Virtual

Platform
UDS can be deployed on Citrix XenServer 6.5 platforms.
The XenServer platform on which UDS is going to be deployed must meet the following
requirements:
At least one XenServer server to host the UDS servers and create the virtual
desktops
For UDS to work properly against a XenServer server, it is necessary to have a

user with credentials with administration rights on the XenServer platform where
the virtual desktops are going to be deployed
You must have at least one network to connect the virtual servers of UDS
platform
You must have at least one network to connect the different virtual desktops
managed by UDS
up UDS
Page 31 of 253
The following connections among the different elements which make up the
UDS platform must be enabled:

UDS Server XenServer 443/80
Page 32 of 253
2.6 Installing UDS Enterprise on Nutanix Acropolis

Virtual Platform
UDS can be deployed on Nutanix Acropolis platforms.
The Nutanix Acropolis platform on which UDS is going to be deployed must meet the
In order to setup UDS and Acropolis can receive and run UDS requests, you
must have credentials for a user with administration permissions on the
Acropolis platform where the virtual desktops are going to be deployed
You must have at least one network to connect the virtual servers of
UDS platform
managed by UDS
up UDS
Page 33 of 253

UDS Server Acropolis 443/80
Page 34 of 253
2.7 Installing UDS Enterprise on OpenStack Platform
UDS can be deployed on Openstack platforms through the version Liberty.
The OpenStack platform on which UDS is going to be deployed must meet the
In order to setup UDS, and OpenStack can receive and run UDS requests, you
must have credentials for a user with administration permissions on the
OpenStack platform where the virtual desktops are going to be deployed
UDS platform
managed by UDS
up UDS.
Page 35 of 253

UDS Server OpenStack 5000
Page 36 of 253
2.8 Installing UDS Enterprise on OpenNebula Platform
UDS can be deployed on OpenNebula platforms through the versions 5.0, 5.1 and 5.2.
The OpenNebula platform on which UDS is going to be deployed must meet the
In order to setup UDS, and OpenNebula can receive and run UDS requests,
you must have credentials for a user with administration permissions on the
OpenStack platform where the virtual desktops are going to be deployed
UDS platform
managed by UDS
up UDS.
Page 37 of 253
Source Destino Puerto

UDS Server OpenNebula 2633
Page 38 of 253
3 INSTALLING UDS ENTERPRISE
At this point we will detail the installation of the components of UDS Enterprise. The
installation procedure is the same for different virtualization platforms (VMware
vSphere, Microsoft Hyper-V, Citrix XenServer, etc...) supported by UDS.
Page 39 of 253
3.1 Requirements of UDS Enterprise Environment
3.1.1 Infrastructure Requirements
The infrastructure requirements needed to deploy UDS are:
Virtualization platform. It will be responsible for hosting the UDS servers,

generated virtual desktops and application servers.
o Username and Password of the manager of the virtualization platform with

administrator permissions
DNS server. This service is necessary for both the proper running of the virtual
platform as well as for the UDS virtual platform environment to be deployed
DHCP server. A DHCP server that enables to assign IP addresses to the virtual
desktop groups created by UDS
3.1.2 Network Requirements
In order to configure the UDS network, you must have at least 3 IP addresses (Server,
tunneler and MySQL Database). To setup UDS Enterprise Free Edition or UDS
Enterprise Evaluation Edition you only need 2 IP addresses (Server and tunneler).
It is also necessary to have the following components available:
Network mask
IP address of the DNS server
Gateway IP address
Domain name (if there is one)
IP address of the virtualization platform manager.
Page 40 of 253
3.2 Installing UDS Enterprise Environment
3.2.1 Install and configure the Database
Please, remember that UDS Enterprise Free Edition & UDS Enterprise Evaluation
Edition feature an internal database, so UDS Database setup is not required.
If VirtualCable provides the UDS DB virtual appliance, the following steps should be
followed:
Access MySQL server with the following credentials:
User: root
Password: uds
Page 41 of 253
We configure the virtual machines network parameters. The file interfaces should be
modified and a static IP address should be assigned (the virtual appliance is configured
with dhcp by default).
It is also necessary to modify the resolv.conf file in order to configure the dns server:
Page 42 of 253
Once the IP data of the VM are configured, it is ready to be used with UDS. The
MySQL server has configured the following DB by default to use it with UDS server:
Instance: uds
User: uds
Password: uds
If you need to create a new DB instance for UDS, you should perform the following
process:
Access MySQL with these credentials:
User: root
Password: uds
The DB is created using the following command:
create database database_name character set utf8 collate

utf8_general_ci;
Page 43 of 253
A user with administration rights is created on the new DB using the command:
grant all on database_name.* to 'usuario'@'%' identified by 'password';
The DB will be available to be used with UDS server.
Page 44 of 253
3.2.2 Installing UDS Server
Once the virtual machine that makes up the UDS Broker server is turned on, a client
console will be displayed to access the virtual machine.
NOTE:
In order to successfully configure a UDS Broker server, a MySQL database server with
a completely empty database must be configured. If you use a database which has
already been used and it contains data from another UDS version, all data will be
migrated in order to be used in UDS Server version 2.0 (database migrations are only
allowed from previous versions onwards).
UDS Enterprise Free Edition & UDS Enterprise Evaluation Edition dont require MySQL
DB, since the system automatically enables a local DB.
In this moment, the UDS Broker server configuration process starts:
Step 1.- Select keyboard input layout language.
Page 45 of 253
Step 2. - You must enter the subscription activation code.
Step 3. - You should configure the following parameters:
Host Name. This name has to be created in the appropiate name server
Domain. Domain where the Broker server UDS is going to be hosted
Broker Server UDS network data (IP Address, Network Mask, Gateway and
DNS)
Page 46 of 253
Step 4. - Enter the database server connection data:
Server: IP address or database server DNS name
Port: Connection port to the MySQL server. By default: 3306
Username: Database administrator user
Password: User password previously defined
Database: Database where the table structure will be created to host the data
needed for the UDS platform
Page 47 of 253
Step 5. - Configuration of UDS administration user.
In this step, a username will be created in order to access UDS Administration for the
first time. The access of such user can be disabled in UDS advanced configuration
options. The following information must be filled in:
Username: User with administrator permission for managing the UDS platform
Password: Password for the administrator user created in the previous step
NOTE:
The assigned password to the UDS system administrator user will be also valid for the
Linux SO root user that hosts UDS software. It may be changed via console inside the
virtual appliance using the command passwd
Page 48 of 253
Step 6.- Configuration summary.
If all the data entered in the configuration wizard are right, click on Continue to start
the UDS Server virtual appliance configuration.
Page 49 of 253
Once all the steps are completed, the Broker server UDS has to be rebooted.
If you need to run the configuration wizard again to modify any data, youll have to
validate yourself on the server (using the root user and the password for UDS system
administration user fixed in Step 4) and execute SetupUDS.sh.
Once the new configuration has been setup, it is necessary to reboot the server
manually.
Page 50 of 253
3.2.3 Installing UDS Tunneler
Once the virtual machine that makes up the UDS tunneler is turned on, a client console
will be displayed to access and start configuring the virtual machine.
NOTE:
To configure a UDS server tunneler successfully you must configure a UDS server
Broker and know its IP address or name.
At this moment, the UDS tunneler configuration process starts:
Step 1.- Select keyboard input layout language.
Page 51 of 253
Step 2. - The following parameters will be configured:
Host Name. This name must be defined in the corresponding DNS server
Domain. Domain where the UDS Server Tunneler will be hosted
UDS server Tunneler Network data (IP Address, Network Mask, Gateway and
DNS)
Page 52 of 253
Step 3. - Fill in connection data to UDS Broker server (broker):
Broker Address: UDS server Broker IP address or DSN name
Broker Port: Communication Port with UDS server Broker. By default 443
Use SSL: Use SSL secure connection
Page 53 of 253
Step 4. - Configuration of the Linux OS root user password
Step 5. - Start the UDS server tunneler configuration:
Page 54 of 253
Once all the steps have been completed, the UDS server tunneler has to be rebooted.
If a rerun of the configuration wizard is needed to modify any data, we will have to
validate us in the server using the credentials we obtained in the Step 3 and run
SetupTunneler.sh
Once the configuration is finished, we will have to manually reboot the server for the
changes to be made.
Page 55 of 253
3.2.4 Install and configure UDS Actor
The UDS actor is installed in the S.O. Windows or Linux (gold image) to be used for
the deployment of virtual desktops. It is also necessary that the RDS application
servers have the UDS actor installed in order to be able to present virtual application
sessions to the users.
In order to install UDS Actor, you must previously download in the UDS Broker the
suitable Actor for each platform (Windows, Linux and vApps).
In order to do that, connect to the UDS Broker via web browser and using credentials
for a user with administration permission to access the downloads.
Select Downloads in the user menu:
Page 56 of 253
The UDS Actors available for download will be displayed in the browser. Select the
Actor corresponding to the operating system or the service installed on the base
template, from which virtual machines and services will be deployed:
UDSActorSetup-2.0.0.exe: UDS Actor for Windows machines (32 and 64 bits)
UdsActor-opensuse-2.0.0-1.noarch.rpm: UDS Actor for Linux OpenSuse

machines
UdsActor-2.0.0-1.noarch.rpm: UDS Actor for Linux CenOS, Fedora, RHEL,

etc
UdsActor-2.0.0_all.deb : UDS Actor for Linux, Debian, Ubuntu,

Xubuntumachines
RDSActorSetup-2.0.0.exe: UDS Actor for Windows 2012 R2 servers with RDS

which will provide virtualized applications
Page 57 of 253
3.2.4.1 Install UDS Actor. Windows Virtual Desktops
Once the UDS Actor for Windows OS has been downloaded and transferred to the
template, its time to strat the configuration:
NOTE:
Before UDS Actor has been setup, you need the IP address of the UDS server Broker.
Accept the license agreement:
Page 58 of 253
Select the install location for UDS Actor:
Click on Install and the UDS Actor will begin its installation process:
Page 59 of 253
Once the installation has been completed, the UDS Actor is configured:
Enter the IP address of the UDS server Broker and indicate if you will use a secure
connection and the level of generated logs.
We need to indicate the UDS Master Key that the UDS server Broker has created
(this code provides more security to the system). In order to obtain this code, you have
to access UDS administration (with a user with administration rights), go to Tools
section and there select Security tab and copy the code from the Master Key
parameter.
Page 60 of 253
Once these parameters have been configured, run the connection test to check the
connectivity to the UDS Broker.
Once the UDS Actor has been configured and installed, you can switch off the virtual
machine. It is now ready to be used as an UDS system virtual desktop template.
Page 61 of 253
3.2.4.2 Install UDS Actor. Linux Virtual Desktops
Once we have downloaded the appropiate UDS Actor for the chosen Linux distro and it
has been transferred to the base template, we run the Actor in order to start the setup.
NOTE:
Before installing the UDS Actor we need the UDS server Broker IP address and name.
Enter the folder where we have downloaded the UDS Actor
The setup may happen to fail because of some dependencies resolution problems, or
conflicts.
Once the dependencies have been installed we indicate the necessary data in the
configuration wizard of the UDS Actor
Type the IP address or name of the UDS server
Page 62 of 253
We select how the communication between the Actor and the UDS server will be.
Finally, enter the UDS Master Key generated by the UDS server Broker (this code
provides the system with more security). To obtain this code, access UDS
administration (with a user with administration rights), go to Tools section and click
on Security tab and copy the code from Master Key parameter.
Paste the master key in the configuration wizard of the actor and finish.
Page 63 of 253
Open the configuration of the actor and test the connection with the data above.
If you need to modify some data, such as the IP address / name of the UDS server or
the UDS Master Key, we can do this in this window.
We can also do this directly in the Actor configuration file located in

/etc/udsactor/udsactor.cfg
Page 64 of 253
The virtual machine can now be turned off and will be available for use as a virtual
desktop template of the UDS system.
NOTE:
In addition to the installation of the UDS actor will be necessary to have a connection
protocol to be used to connect to the generated desktops (For example, have installed
XRDP, x2go, etc ...)
If the installation of a previous version of the UDS Actor already exists in the base
template of the desktop, it will be necessary to completely uninstall and install the new
Actor. You can follow the instructions in this article.
Page 65 of 253
3.2.4.3 Install UDS Actor. Microsoft RDS Virtual Applications
Upon UDS Actor download and transfer we can execute the install wizard and proceed
with setup:
NOTE:
Before installing the UDS Actor we need the UDS server Broker IP address.
Page 66 of 253
Accept license agreement:
Select the installation path of the UDS Actor:
Select the install location for UDS Actor
Page 67 of 253
Once the installation has been completed, the UDS Actor is configured:
Enter the IP address of the UDS server Broker and indicate if you will use a secure
connection and the level of logs generated.
Once these parameters have been configured, run the connection test to check the
connectivity to the server Broker.
Page 68 of 253
Once the UDS Actor for RDS has been configured and installed, you can proceed with
installing the features of RDS and integrate them with UDS Actor; hence you can
deploy and virtualize applications using RDS.
To proceed with UDS integration with Remote Desktop Services RDS you can check
our guide Install and Configure Microsoft RDS with UDS Enterprise available in the
documentation section under this link.
Page 69 of 253
3.2.5 Installing UDS Plugin for Windows
To connect to a virtual desktop through any transport other than HTML5, it will be
necessary for the connecting client computer to have the UDS Plugin installed.
In the first access to a desktop or virtual application, UDS will automatically recognize
the Operating System from which the user is connecting and will offer the appropriate
plugin download for it.
At any time, we can access the plugin downloads window by displaying the user
options and selecting: "UDS Plugin".
Page 70 of 253
If once installed the system continues showing the installation screen of the plugin,
preventing access to virtual desktops, it is recommended to restart the browser and re-
login to UDS. If you continue despite the reboot, we will disable automatic detection of
the plugin by selecting the option: "WARNING: Automatic plugin detection is disabled".
Page 71 of 253
3.2.5.1 Instalacin Plugin UDS Windows
Once downloaded the UDS Plugin in its S.O. Windows (connection client), we will
execute it to proceed with its installation:
Accept License agreement:
Page 72 of 253
Select the installation path of the UDS Plugin:
Clik on Install to start the installation:
Page 73 of 253
After installation to the Windows connection client, the UDS plug-in will execute the
selected connection protocol (Transport) and connect to the desktop or virtual
application.
Page 74 of 253
3.2.5.2 Installing UDS Plugin for Linux
Once the UDS Plugin is downloaded to the Linux connection client, we proceed to
install it.
We are located in the path where we have saved the UDS Actor and we execute it.
It is possible that the installation fails because some dependency is missing, in which
case we install them:
Once the dependencies are installed, the installation will be completed.
Once installed on the linux client, the UDS plugin will execute the selected connection
protocol (transport) and connect to the desktop or virtual application.
If we need to uninstall the UDS plugin we will execute: dpkg -P udsclient
Page 75 of 253
We can also install the UDS plugin (client) from the software installation tool of our
distribution.
Page 76 of 253
Page 77 of 253
4 ADMINISTRATION OF UDS
Once the UDS platform has been setup, the system will be ready for its initial
administering and configuration. To do this, input the IP address or UDS Broker server
name through http or https access.
The first time you enter UDS administration dashboard, you must enter using the
administrator user and the password indicated in the UDS Broker virtual appliance
configuration script (step 3.2.2.)
Once you access the administration dashboard, you will be able to change the
password and create or select new users to enter to the administration dashboard.
If you already have a user with administration permission for UDS platform, enter that
user, the password and select the authenticator that will be used to validate the user.
(Only in case you have more than one authenticator).
Page 78 of 253
If more than one authenticator is connected to UDS platform and you would like to
access the administration dashboard with the administrator user and password
indicated in the configuration script of the UDS Broker virtual appliance (see 3.2.1
section), the selected authenticator wont be used, because this user wont be
validated against any authenticator.
In the user menu, select "Dashboard" to enter UDS administration:
Once inside UDS administration, the initial configuration of the services, that will make
a Service Pool in which deployment of virtual desktops and services is executed, will
start.
The configuration of each "Services Pool" must be approached like the building of a
puzzle, it is made up of different elements:
Page 79 of 253
Each "Services Pool" is made up of different elements or pieces (Base

Services, OS Managers, Transports and Authenticators)
Once the elements of the first "Services Pool" have been configured, the
creation thereof will begin, repeating the process with the next "Service Pool", if
there is one
All configured "Services Pools" together will form the type of virtual desktop
deployment managed by the UDS platform.
Page 80 of 253
4.1 Configure Service Providers
A Service Provider is responsible for offering IP services. The services offered by UDS
will be on-demand virtual desktops or applications provided by a virtualization platform
or persistent physical/virtual desktops assigned to specific users via IPs assignment.
In order to build a Service Pool, at least one Service Provider must be created.
Currently, UDS supports the following Service Providers:
Page 81 of 253
5 Deployment of VDI platform via VMware vSphere

virtual infrastructure.
5.1.1 VDI Platform with VMware vSphere
5.1.1.1 Register Service Provider VMWare vCenter Platform Provider
Enter "Services", click "New" and select VMware Vcenter Platform Provider.
In a VMware Vcenter Platform Provider, the minimum parameters to configure are:
o Main:
Service provider name, vCenter server IP (field Host), Connection port with vCenter,
a username and password with administration rights on the vCenter.
Page 82 of 253
o Advanced:
Number of simultaneous tasks of desktop creation (field Creation concurrency),

number of simultaneous tasks of desktop deletion (field Removal concurrency), time
of Timeout in the connection establishment with the vCenter and specify the range for
MAC addresses for virtual dektop creations.
Through the button Test we can test and make sure the connection is successful.
Upon saving, our "Service Providers" is now valid and ready to use for base service
creations in VMware vSphere.
We can register as many "Service Providers" of type VMware vCenter Platform

Provider as we need in the platform UDS.
Page 83 of 253
In order to modify any parameter in an already existing Service Providers all you
neew is select it and click on Edit.
Through the button Enter Maintenance Mode you can suspend all the operations
issued by UDS Broker for a given service provider. Its recommended to put your
service provider in maintenance mode in case the connection to this latter has been
lost or a stop for maintenance.
Page 84 of 253
5.1.1.2 Configure a service based on VMware Linked Clones Base
Once the platform vSphere, where Virtual Desktops is created, a base services of type
"VMware Vcenter Platform Linked Clones" should be created.
Select the "Service Providers" in which you like to create your " VMware Vcenter
Platform Linked Clones" and click "New":
Page 85 of 253
In a VMware Linked Clones Base minimal parameters to be configured are:
o Main:
Name: Service name.
Datacenter: Datacenter where the service will be hosted.
Pub. Resource Pool: vCenter resources pool where the Linked Clones virtual
desktops will be hosted (if there are no Pools in the VMware infrastructure, they will be
created in the root).
Pub. Datastores: Location where the publication of the service will be stored. We can
select one, several or all the datastores. If you select more than one, the system will
always locate the new publications in the datastore with more free space (By default,
the system wont generate new publications in datastores with less than 30GB of free
space. This parameter can be modified entering the UDS system advanced options).
Remove found duplicates: If set to yes, UDS will remove any service with the same
name generated by UDS.
o Machine:
Resource Pool: vCenter resources pool where the template to be used by the service
is located.
Base Machine: Template for deploying the virtual desktops.
Memory: Amount of memory to be assigned to the Linked Clones virtual desktops.
Network: Network to which the desktops will be connected.
Clones Folder: Location of the Linked Clones virtual desktops in the VMs view and the
vCenter templates.
Page 86 of 253
Inc. Datastores: Location where the created Linked Clones will be stored. We can
select one, several or all the datastores. If you select more than one, the system will
always locate the new Linked Clone desktops in the datastore with more free space
(By default, the system wont generate new virtual desktops in datastores with less
than 30GB of free space. This parameter can be modified entering the UDS system
advanced options).
Machine Names: Root name of all of the Linked Clones virtual desktops to be
deployed on this service. (eg: Machine Names= UDSW8).
Name Length: Number of digits of the counter attached to the root name of the
desktops (ex: Name Length= 3, UDSW8-000... UDSW8-999).
When saving this configuration, we already have a valid "VMware Linked Clone
Base" in the VMware vCenter platform. We can register all VMware Linked
Clone Base" we need in the UDS platform.
Once the entire UDS environment has been configured and the first Service Pool has
been created, we will be able to observe how the virtual desktops based on VMware
Linked Clones are deployed on the vCenter server.
Page 87 of 253
The first task that the vCenter will perform will be to create a base machine (this
machine will be created each time we make a publication of a service) which will be a
clone of the template selected when registering the service, with a hard drive size and
features equal to those of said template.
Once the process of creating the base machine has been completed (the UDS system
calls it: UDS Publication name_service number_publication), the creation of virtual
desktops in the vCenter automatically begins (the UDS system calls it: UDS service
Machine_Name+Name_Length).
The hard drive space taken up by the virtual desktops (Linked Clones) will be
exclusively that which is taken up by the changes made by the users on the machines
after their initial connection.
Page 88 of 253
5.1.2 VDI Platform with oVirt or RHEV
Deploying the VDI platform via virtual oVirt infrastructure or RedHat Enterprise
Virtualization (RHEV).
5.1.2.1 Register a Service Provider of the Service oVirt Platform Provider
Enter "Services", click "New" and select oVirt/RHEV Platform Provider:
In an oVirt/RHEV Platform Provider minimal parameters to be configured are the

following:
o Main:
Service provider name, oVirt-engine or RHEV-Manager server IP (field Host), a

username (in the format user@doain) and password with administration rights on oVirt-
engine or RHEV-Manager.
Page 89 of 253
o Advanced:

of Timeout in the connection establishment with the oVirt-engine and specify the
range for MAC addresses for virtual dektop creations.
Page 90 of 253
creations in oVirt.
We can register as many "Service Providers" of type oVirt/RHEV Platform Provider as

we need in the platform UDS.
Page 91 of 253
5.1.2.2 Configure a service based on oVirt/RHEV Linked Clone
Once the oVirt platform where the desktops will be created has been setup, you must
create base services based on oVirt/RHEV Linked Clones.
Select the Service Providers where an oVirt/RHEV Linked Clone is going to be created
and click on "New".
In an oVirt/RHEV Linked Clone minimal parameters to be configured are:
o Main:
Name: Service name.
Base Machine: Template for deploying the virtual desktops (Golden Image).
Cluster: oVirt node cluster that will host the deployed Linked Clones.
Datastore Domain: Storage established for deploying the Linked Clones. We can
select one, many or all the available datastores; in case of multiple datastore selection,
the system will always publish into the datastore with more free space.
Reserved Space: Minimum free space a datastore may have to be used by UDS
system.
Page 92 of 253
o Machine:
Memory: Amount of memory that will be assigned to the Linked Clones in MB.
Memory Guaranteed: Amount of memory that will be guaranteed to the Linked

Clones.
Machine Names: Root name of all of the Linked Clones to be deployed in this service
(eg. Machine Names= Win7lab2).
Name Length: Number of counter digits attached to the root name of the desktops (ex:
Name Length= 3, Win7lab2000... Win7lab2999).
USB: If selected, virtual desktops will support USB device redirection.
Display: Connection protocol of the virtual desktops deployed via Linked

Clones.
Machine Names: Root of the name of all Linked Clones to be deployed in this service
(ex: Machine Names = Win7lab2-).
Name Length: Number of digits of the counter attached to the root of the name of the
desktops (ex: Name Length = 3, Win7lab2-000 ... Win7lab2-999).
Page 93 of 253
Page 94 of 253
After saving this configuration, we already have a valid "oVirt Linked Clone" in the oVirt
platform. We can register all "oVirt Linked Clone" we need in the UDS platform.
After the entire UDS environment has been configured (Services, Authenticators, Os
Managers and Transports) and created the Service Pool, we will be able to observe
how the virtual desktops based on oVirt Linked Clones are deployed on the oVirt-
engine server.
Page 95 of 253
5.1.3 VDI Platform with Microsoft Hyper-V
Deploying the VDI platform via Microsoft Hyper-V virtual infrastructure.
5.1.3.1 Register a Service Provider of the Service Hyper-V Platform Provider
Enter "Services", click "New" and select Hyper-V Platform Provider.
In a Hyper-V Platform Provider you must configure at least the following parameters:
o Main:
Service Name, Microsoft Hyper-V IP server (Host field), connection port, user name
and password with administration rights on the Microsoft Hyper-V.
Page 96 of 253
o Advanced:

of Timeout in the connection establishment with the Hyper-V and specify the range
for MAC addresses for virtual dektop creations.
Page 97 of 253
creations in Hyper-V.
We can register as many "Service Providers" of type Hyper-V Platform Provider as

we need in the platform UDS
Page 98 of 253
5.1.3.2 Configure a service based on Hyper-V Linked Clone
Once the Microsoft Hyper-V platform where the desktops will be created has been
configured, you must create base services based on "Hyper-V Linked Clone".
Select the Service Providers where a "Hyper-V Linked Clone" is going to be created
and click on "New".
In a Hyper-V Linked Clone minimal parameters to be configured are:
o Main:
Name: Nombre del servicio.
Datastores Drives: Location where the publication of the service and the Linked
Clones created will be stored. We can select one, several or all of the datastores
clicking the Ctrl button. If you select more than one, the system will always locate the
new publications and desktops in the datastore with more free space.
Reserved Space: Minimal free space that should be available in a storage space for it
to be eligible to be used by UDS.
Page 99 of 253
o Machine:
Network: Network to connect virtual desktops.
deployed on this service. (eg: Machine Names= W1).
desktops (eg: Name Length= 3, W7000...W7999).
Upon saving this configuration, we have a valid " Hyper-V Linked Clone " in the Hper-V
platform. We can register all " Hyper-V Linked Clone" we need in the UDS platform.
Page 100 of 253

Once the entire UDS environment has been setup and the first Service Pools have
been created, we will be able to observe how the virtual desktops based on Microsoft
Hyper-V are deployed on the Microsoft Hyper-V server.
The first task the Microsoft Hyper-V server will perform will be to create a base
machine (this machine will be created each time we make a publication of a service)
which will be a clone of the template selected when registering the service, with a hard
drive size and characteristics equal to those of said template.
Once the process of creating the base machine has been completed (the UDS system
calls it: UDS Publication name_service number_publication), the creation of virtual
desktops in the Microsoft Hyper-V automatically begins (the UDS system calls it: UDS
service Machine_Name+Name_Length.
The hard drive space taken up by the virtual desktops (Linked Clones) will be
exclusively that which is taken up by the changes made by the users on the machines
after their initial connection.
Page 101 of 253

5.1.4 VDI Platform with Citrix XenServer
Deploying VDI platform via Citrix XenServer virtual infrastructure.
5.1.4.1 Register a Service Provider of the Service XenServer Platform

Provider
Enter "Services", click "New" and select XenServer Platform Provider.
In a Xenserver Platform Provider minimal parameters to be configured are:
o Main:
Service Name, connection port with XenServer, XenServer IP server (Host field), user
name and password with administration rights on XenServer.
Page 102 of 253

o Advanced:

number of simultaneous tasks of desktop deletion (field Removal concurrency), and
specify the range for MAC addresses for virtual dektop creations
We will check that the connection has been correctly made clicking on the Test
button.
Upon saving this configuration, we have a valid "Service Providers" to start creating
base services in the XenServer platform.
We will be able to register all XenServer Platform Provider "Service Providers" we need
on the UDS platform.
Page 103 of 253

In order to modify any parameter in a current Service Providers, we select it and click
on Edit.
Clicking the Maintenance button we can stop all operations running in UDS Broker on
a service provider. It is recommended to enter a maintenance service provider when
the communication with those service provider is lost or youre planning a maintenance
stoppage.
Page 104 of 253

5.1.4.2 Configure a service based on Xen Linked Clone
Once the Microsoft Citrix XenServer platform where the desktops will be created has
been setup, base services based on "Xen Clone" must be created.
Select the Service Providers where a "Xen Linked Clone" is going to be created and
click on "New".
In a Xen Linked Clone minimal parameters to be configured are:
o Main:
Name: Service name.
Storage SR: Location where the publication of the service and the Linked
Only shared storage is supported.
Reserved Space: Minimal free space that should be available in a storage space for it
to be eligible to be used by UDS.
Page 105 of 253

o Machine:
Base Machine: Template for deploying the virtual desktops (Gold image).
Shadow: memory multiplicator.
deployed on this service. (eg: Machine Names= W1).
Once the entire UDS environment has been setup and the first Service Pools have
been created, we will be able to observe how the virtual desktops based on Citrix
XenServer are deployed on Xen Linked Clones.
Page 106 of 253

5.1.5 VDI Platform with Nutanix Acropolis
Deploying VDI platform via Nutanix Acropolis virtual infrastructure.
5.1.5.1 Register a Service Provider of the Service Nutanix Acropolis Platform

Provider
Enter "Services", click "New" and select Nutanix Acropolis Platform Provider.
In a Nutanix Acropolis Provider minimal parameters to be configured are:
o Main:
Service Name, connection port with Nutanix Acropolis, Nutanix Acropolis IP server
(Host field), user name and password with administration rights on Nutanix Acropolis.
Page 107 of 253

o Advanced:

Timeout for the connection with with the platform Acropolis and specify the range for
MAC addresses for virtual dektop creations
Page 108 of 253

We can check that the connection has been correctly made clicking on the Test
button.
Upon saving this configuration, we have a valid "Service Provider" to start creating
base services in Nutanix Acropolis platform.
We can register all Nutanix Acropolis Provider Service Providers we need in the UDS
platform.
on Edit.
stoppage.
Page 109 of 253

5.1.5.2 Configure a service based on Nutanix KVM
Once the Nutanix Acropolis platform where the desktops will be created has been
setup, base services based on "Nutanix KVM" must be created.
Select the Service Providers where a "Nutanix KVM Linked Clone" is going to be
created and click on "New".
In a Nutanix Acropolis Service minimal parameters to be configured are:
Name: Service name.
Base VM: Template for deploying the virtual desktops.
Machine Names: Root name of all the Linked Clones virtual desktops to be deployed
on this service. (eg: Machine Names= W1).
Page 110 of 253

Upon saving we have a valid Nutanix KVM on Nutanix Acropolis platform. We can
register all Nutanix Acropolis Provider Service Providers we need in the UDS
platform.
Once the entire UDS environment has been configured and the first Service Pools
have been created, we will be able to see how the virtual desktops based on Nutanix
KVM are deployed on the Nutanix Acropolis server.
Page 111 of 253

5.1.6 VDI Platform with OpenStack
Deployment of the VDI platform through OpenStack.
5.1.6.1 Register a Service Provider of the Service OpenStack Platform

Provider
In "Services", click the button "New" and select OpenStack Platform Provider:
In an OpenStack Platform Provider minimal parameters to be configured are:
o Menu Main:
Service name, OpenStack Server IP (field Host), a username and password with
administration rights on OpenStack.
We can also indicate the connection port with OpenStack, specify access interface and
used domain name.
Page 112 of 253

o Menu Advanced:
Number of simultaneous tasks of desktop creation in the platform OpenStack (field

Creation concurrency), Number of simultaneous tasks of desktop deletion in the
platform OpenStack (field Removal concurrency) and the time Timeout in the
connection with the platform OpenStack.
Page 113 of 253

Using the button Test we test the successful connection establishement.
Upon saving our config, we have a valid "OpenStack Platform Provider " ready to start
creating base services in the plataform OpenStack.
We can register as many "Service Providers" of type OpenStack Platform Provider as

need is select it and click on Edit.
Page 114 of 253

5.1.6.2 Configure a service based on OpenStack Live Volume
Once the platform OpenStack, where Virtual Desktops will be created, base services of
type " OpenStack Live Volume " should be created.
Select the "Service Providers" in which you like to create your " OpenStack Live
Volume " and click "New":
In a Nutanix Acropolis Service the minimal parameters to configure are:
o Menu Main:
Name: service name.
Region: Each region has its proper complete deployment in OpenStack, including its
own assessment criteria of the API, network and computing resources.
Page 115 of 253

Project: Organization units, to which we can assign a user, in the cloud.
Availability zones: within a region, compute nodes can be grouped logically in

availability zones.
o Machine:
Volume: Base Volume of the service (restricted by availability zone).
Network: Network that desktops will be connected to.
Flavor: H/W configurations available for servers.
Security Groups: Service security groups.
Machine Names: Root name of all linked clone virtual desktops to be deployed in this
service (eg: Machine Names = UDSW8-).
Name Length: Number of digits of the counter attached to the root name of the virtual
desktops (eg: Name Length= 3, UDSW8-000... UDSW8-999).
Page 116 of 253

Upon saving the configuration we have a valid "OpenStack Live Volume" in the
plataform OpenStack. We can register as many "OpenStack Live Volume" as we need
in the platform UDS.
Once we have all the UDS environment properly configured, and and we have created
the first Service Pools, we can observe how deployments of virtual desktops, based
on OpenStack Live Volume, are made in the server OpenStack.
Page 117 of 253

5.1.7 VDI Platform with OpenNebula
Deployment of the VDI platform through OpenNebula.
5.1.7.1 Register a Service Provider of the Service OpenNebula Platform

Provider
In "Services", click the button "New" and select OpenNebula Platform Provider:
In an OpenNebula Platform Provider minimal parameter to be configured are:
o Main:
Name of the Service, IP of the OpenNebula server ("Host" field), a user name and
password with administrative rights to OpenNebula.
We can also indicate the port of the connection with OpenNebula.
Page 118 of 253

o Advanced:

Timeout for the connection with with the platform Acropolis.
By clicking the Test button, we check if the connection has been correctly made.
By saving this configuration, we have a valid "Service Providers" to start creating base
services in the OpenNebula host. We can register all OpenNebula Platform Provider
Service Providers we need in the UDS platform.
We can register as many "Service Providers" of type OpenNebula Platform Provider

as we need in the platform UDS.
Page 119 of 253

Page 120 of 253

5.1.7.2 Configure a service based on OpenNebula Live Volume
Once the platform OpenNebula, where Virtual Desktops will be created, base services
of type " OpenNebula Live Volume " should be created.
Select the "Service Providers" in which you like to create your " OpenNebula Live
Volume " and click "New":
In an OpenNebula Live Volume minimal parameters to be configured are:
o Main:
Name: Service name.
Datastores Drives: Location where the publication of the service and the Linked
Machine Names: Root name of all the Linked Clones virtual desktops to be deployed
on this service. (eg: Machine Names= W1).
Page 121 of 253

o Machine:
Base Template: Virtual Machine template (Gold Image) used by the UDS system for
the deployment of virtual desktops.
Machine Names: Root of the name of all virtual desktops Linked Clones to be
deployed in this service. (Ex: Machine Names = UDSW8-).
Name Length: Number of digits of the counter attached to the root of the name of the
desktops (ex: Name Length = 3, UDSW8-000 ... UDSW8-999).
Upon saving we have a valid OpenNebula Live Volume on OpenNebula platform. We

can register all OpenNebula Live Volume Service Providers we need in the UDS
platform.
Once the entire UDS environment has been configured and the first Service Pools
have been created, we will be able to see how the virtual desktops based on
OpenNebula Live Volume are deployed on the OpenNebula server.
Page 122 of 253

5.1.8 Direct Connection to Persistent Devices
Access to persistent hardware by assigning fixed-user IP addresses.
Assigning IP addresses and usernames will be done by order of access, that is, the
first user that accesses this service will be assigned the first IP address on the list.
If multiple users need access to same device, its necessary subscribe the IP of the
device as many times as many users we have.
In order to connect to the machine with the IP address assigned to a user, the machine
must have previously been switched on, the Terminal Services for Windows machines
must be enabled and the NX software for Linux machines must be installed.
5.1.8.1 Register a Service Provider of the Service Static IP Machines Provider
Enter "Services", click "New" and select Static IP Machines Provider.
Page 123 of 253

In the creation of a "Static IP Machines Provider" we must indicate the name of the
service provider.
By saving this configuration, we have a valid "Static IP Machines Provider to start

creating base services of type "Static IP Machines Provider".
We can register as many "Service Providers" of type "Static IP Machines Provider" as

Page 124 of 253

5.1.8.2 Configure a service based on Static Multiple IP
Once the "Service Provider" has been created for access to computers with a fixed IP
address, we create "Static Multiple IP" services.
This type of service will connect a user to a computer.
Select the "Service Providers" on which we will create a "Static Multiple IP" and click on
"New":
We will enter a name for the service and enter one or more machine IP addresses
(they must be turned on and connected) to which access will be provided.
Click on "List of IPS" to add IP addresses:
Enter one or more IP addresses of the machines that will be accessed and save the
changes:
Page 125 of 253

We save and have a valid "Static Multiple IP" service.
The assignment of users and machines will be done in order of access, ie the first user
to connect to the service will be assigned the machine that responds to the first IP in
the list.
We will be able to register all the "Static Multiple IP" we need on the UDS platform.
Page 126 of 253

5.1.8.3 Configure a service based on Static Single IP
Once the "Service Provider" has been created for access to computers with a fixed IP
address, we create "Static Single IP" services.
This type of service will connect users to the same computer.
Select the "Service Providers" on which we will create a "Static Single IP" and click on
"New":
We will indicate a name for the service and enter the IP address of the machine (it
needs to be turned on and with connectivity) that will be provided access to the users.
We save and have a valid "Static Single IP" service.
Page 127 of 253

5.1.9 RDS Platform Provider
Deployment of virtual applications through Microsoft Remote Desktop Services (RDS).
5.1.9.1 Register a Service Provider of the Service RDS Platform Provider
In "Services", we click on "New" and select RDS Provider:
In an "RDS Platform Provider" the minimum parameters to be configured are:
Name: Service name.
List of servers: Listing of Microsoft RDS servers available for publishing applications.
In case of indicating more than one server the connections of the users will be
distributed between the servers.
User mapping: "Yes" indicates that specific users will be used to access applications,
"No" will use the UDS login user to access the applications.
User list for mapping: Mapping users belonging to an Active Directory who can log in
to the RDS application servers and will be used by UDS only to run a session of an
application.
User`s password: Password for all users in the "User list for mapping" section. It is
necessary that all "mapping" users have the same password.
Using the Test button we will verify that the connection is successful.
Page 128 of 253

When saving this configuration, we already have a valid "Service Provider" to start
creating base applications in RDS. We can register all RDS Platform Provider Service
Providers we need in the UDS platform.
on Edit.
stoppage.
Page 129 of 253

5.1.9.2 Configure a service based on RDS Platform RemoteAPP
Once the RDS application provider where the desktops will be created has been
configured, base services based on "RDS RemoteAPP" must be created.
Select the Service Providers where a "RDS RemoteAPP" is going to be created and
click on "New".
In an "RDS Platform RemoteAPP" the minimum parameters to be configured are:
Name: Service name.
Application path: Application route, hosted in RDS servers, which is going to be

published.
Max. Allowd services: Maximum number of services to be published (0 = unlimited)
Page 130 of 253

Upon saving this configuration, we have a valid RDS RemoteAPP". We can register all
RDS RemoteAP we need in the UDS platform.
NOTE:
UDS needs one or several RDS Windows 2012 external servers to connect and
provide applications. The server must be configured and properly integrated with UDS
Actor in order to work properly.
To configure and integrate RDS with UDS you can consult this document: Installation
and configuration of Microsoft RDS with UDS Enterprise available in the documentation
section of the web: www.udsenterprise.com
Page 131 of 253

Page 132 of 253

5.2 Configure Authenticators
An Authenticator is a basic component within a desktop services platform since it

allows the users and user groups to which you have granted sign in credentials to
connect to the different desktop services.
An Authenticator is not needed to create a Service Pool. But if the Service Pool hasnt
at least one authenticator assigned, there will be no users able to connect to UDS
platform desktop services.
You can choose between many types Authenticators either external (Active Directory,
eDirectory, OpenLDAP, etc) or internal (Internal Database y Autenticacin por IP).
You can choose between different types of authenticators as needed by your business
and platform.
Page 133 of 253

5.2.1 Active Directory Authenticator
This external authenticator allows access to users and groups of users, belonging to an
Active Directory, virtual desktops or applications.
In an Active Directory Authenticator minimal parameters to be configured are:
o Main:
Name: Authenticator name.
Priority: the priority of this authenticator, the lower that priority is, the higher it will
appear on the list of authenticators available in the user access window (this field
admits negative values).
Label: Enables direct validation in the authenticator, it allows to validate this latter in
the login page URL without going through the whole dashboard interface using this
format: UDSServer/login/label (e.g: https://UDSServer/login/AD)
Host: IP address or AD server name.
Use SSL: If set to Yes then use SSL connection.
Compatibility: Select the compatibility level of your AD authenticator.
Timeout: Time of Timeout of the connection with the autenticator
Page 134 of 253

o Credentials:
User: User with read rights on the authenticator in the format: user@domain
Password: user password
Page 135 of 253

Clicking on the Test button, we can check if the connection has been established
correctly.
5.2.2 eDirectory Authenticator
This authenticator is available to provide Novell network users and user groups access
to UDS desktop services.
In an eDirectory Authenticator minimal parameters to be configured are:
o Main:
format: UDSServer/login/label (e.g: https://UDSServer/login/eAD)
Host: IP address or AD server name.
Use SSL: If set to Yes then use SSL connection.
Timeout: Time of Timeout of the connection with the autenticator
Page 136 of 253

o Credentials:
User: User with read rights on the authenticator in the format: CN=user, O=domain
Password: user password
Page 137 of 253

Clicking on the Test button, we can check whether the connection has been made
correctly.
Page 138 of 253

5.2.3 Internal Database
In environments where no external authenticator is available, it is possible to use the

internal authenticator. This authenticator is included in the UDS Broker and enables to
manually create users and user groups so that they can subsequently access the
different Service Pools provided by UDS.
All user and group data are stored in UDS Database.
In Internal Database minimal parameters to be configured are:
o Main:
format: UDSServer/login/label (e.g: https://UDSServer/login/int1)
Page 139 of 253

o Advanced:
Different user for each host: This option allows connections to virtual desktops using
a single connection user ID. These types of connections are made creating multiple
users in the internal database by adding a root to existing user already existing at the
time of establishing a connection with the virtual desktop. This suffix is the IP of
connection client or its DNS name.
The new created username has the following structure:
IP of the client-generic connection user
Page 140 of 253

Reverse DNS: The behavior is exactly the same as in the previous option, but the
username structure would be different in this way:
The added suffix is the DNS name instead of IP. Good DNS resolution is mandatory for
this authenticator.
The new username would look like:
DNS name of the client-Generic connection user
Accept proxy: This feature must be enabled when you have a component prior to the
access of UDS like for example a load balancer.
UDS automatically detects the IP address of the client connection in environments

where there are configured load balancers this detection is not successful since the IP
address corresponds to the detected balancers, enabling this option will get correct IP
detection.
This feature must be enabled in environments where "Different user for each host"
option is used as well as load balancers.
Page 141 of 253

5.2.4 IP Authenticator
This Internal Authenticator allows access to clients connecting, through their IP

address, to virtual desktops and applications.
The IP addresses function as the users of other authenticators allowing the direct
validation of the connection clients in the UDS login portal. User groups on an "IP
Authenticator" can range from specific network ranges to full subnets or specific IPs.
In an IP Authenticator minimal parameters to be configured are:
o Main:
format: UDSServer/login/label (e.g: https://UDSServer/login/IP)
Page 142 of 253

o Advanced:
Accept proxy: This feature must be enabled when you have a component prior to the
access of UDS like for example a load balancer.
UDS automatically detects the IP address of the client connection in environments

where there are configured load balancers this detection is not successful since the IP
address corresponds to the detected balancers, enabling this option will get correct IP
detection.
Page 143 of 253

5.2.5 SAML Authenticator
SAML is used to exchange authentication and authorization data among security

domains, that means, among an identity provider (an assertion producer) and a service
provider (an assertion consumer).
In a "SAML Authenticator" we configure the authenticator name and data: Private Key,
Certificate, IDP Metedata, Entity ID, User name attrs, Group name attrs and Real name
attrs.
We can also indicate the priority that this authenticator will have. The lower that priority,
the higher it will appear in the list of available authenticators in the user access window
(this field supports negative values).
The "Label" field Enables direct validation in this authenticator, allows the user login
screen to validate with that authenticator even though the UDS environment has more
authenticators. To do this we will have to access the UDS login screen with the
following format: UDSServer/login/label (For example: https://UDSServer/login/saml)
Page 144 of 253

Page 145 of 253

5.2.6 LDAP Authenticator
This is a generic authenticator available within the UDS platform. By configuring the
correct parameters according to each case, we can define practically any
authentication service based on LDAP.
In an "LDAP Authenticator" (Simple or Regex) we configure the name of the

authenticator, the IP of the LDAP server (Host field), the connection port, a user (Ldap
User field) and a password with read rights over LDAP, The name of the user and
groups search base ("base" field in format: dc = domain_name, dc =
domain_extension).
The user (Ldap User field) must be entered with the format: cn = user, dc =
domain_name, dc = domain_extension
We can also indicate the priority that this authenticator will have. The lower the priority,
the higher the number of authenticators available in the user access window (this field
will allow negative values), if we want to use an SSL connection and the "Timeout" time
in the connection with the LDAP server.
The "Label" field Enables direct validation in this authenticator, allows the user login
screen to validate with that authenticator even though the UDS environment has more
authenticators. To do this we will have to access the UDS login screen with the
following format: UDSServer/login/label (eg https://UDSServer/login/oldap)
Page 146 of 253

Page 147 of 253

Page 148 of 253

5.3 Configure users, groups and user metagroups
Once the authenticator or authenticators have been configured, you must configure the
user groups that contain the users to which access to the desktop services is to be
granted. It is also possible to create metagroups, which will be used to combine several
groups.
To create a group, select the authenticator where we want to create or add the group.
In the new window displayed at the bottom of the window, select Groups tab and click
"new".
The search for user groups is done automatically in all authenticators defined in UDS,
except in the authenticators of type "Internal Database" and "IP Authenticator" (also it
is possible that in authenticators of type OpenLdap or eDirectory the option "search
"Does not work, having to indicate the group name manually). In this case, the groups
are discharged without possibility of searching.
To search for a group, click on the "Search" button. We can write a root of name to
narrow the search. If we leave it empty, we will see all the groups available in the
authenticator. If we need to add several groups, we will have to add them one at a
time.
Page 149 of 253

Once the group is selected, click Accept. If you know the name, you can write it down
directly, but it is recommended to check that it appears in the right way in the search
option.
The groups, metagroups and users can be temporarily activated or deactivated.
To create a metagroup, select the groups that will form part of the metagroup, choose
a name for the new group and click Accept.
A user will belong to this metagroup if he belongs to all the groups included in the
metagroup.
Page 150 of 253

The users of the configured groups are automatically added to the system when they
connect to the UDS platform for the first time, except in Internal or by IP
authenticators, in which the users will have to be manually registered.
If we need to register new users manually, to assign special permissions before they
connect for the first time and they add themselves automatically, well have to select
the authenticator. Then, in Users tab click on "New".
Page 151 of 253

The additional Staff parameter allows access to downloads (UDS Actor) and to UDS
administration.
The additional Admin parameter allows access to downloads (UDS Actor), to the
administration and also allows for the modification of advanced UDS configurations
(Tab Tools - Configuration). An Admin user has to simultaneously be a Staff
member.
By clicking "Search" button we can search users created in the authenticator and add
them.
Once the user has been created, click "Edit" to check that the user has been
automatically assigned to the group it belongs.
Page 152 of 253

Page 153 of 253

If we register a user that belongs to a group which is not registered in the authenticator,
it will appear without group and we wont be able to use that user.
The "Staff member" and "Admin" user options can be modified anytime.
To delete a user, a group or a metagroup, select it and click "Delete" button. If we have
registered users in the system that belong to a group and this group is deleted, the
users wont have an assigned group and they wont be able to be validated in the
system.
Page 154 of 253

5.3.1 Creation of groups and users "Internal Database"
In an Internal Database authenticator, the first thing we have to do is create a group or

groups of users that we will be later assigned to a service pool.
Select the Internal Database authenticator and in Groups tab click "New".
Give a name to the new group and save.
Once we have created the group or groups of users, we register users and assign
them to a group or several.
We select the authenticator of type "Internal Database" previously created and in the
tab "Users" click on "New".
Page 155 of 253

5.3.2 Creation of groups and users "IP Authenticator"
The creation of a group in the by IP authenticator is different from the other ones,
because in this case it will be a range of IPs addresses which will be registered to allow
access to all the hardware within this range. This range of addresses is defined as
follows:
- Unique IP: xxx.xxx.xxx.xxx (e.g: 192.168.11.33)
- Complete subnet: xxx.xxx.xxx.xxx\x (e.g: 192.168.11.0\24)
- IP addresses range: xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx (e.g: 192.168.11.1

192.168.11.155)
IP address start range IP address end range
Select IP Authenticator" authenticator and in "Groups" tab click "New".
When the access client connection to the UDS portal login and IP address belong to a
given group, they will be automatically registered to the "Users" tab.
Page 156 of 253

In this type of authenticator an IP address is considered as a normal user with all

available options.
Page 157 of 253

5.4 Configure OS Managers
An OS Manager runs a previously configured service.
The UDS Actor, hosted on the virtual desktop or application server, is responsible for
the interaction among the OS and the Broker based on the configurations or type of OS
Manager chosen.
In order to perform VDI deployments via Linked Clones, you will have to select the
disconnection behavior of the Linked Clones, within the configuration of each OS
Manager. If a non-persistent desktop policy is configured, you can indicate user
downtime before the system will automatically log out.
You can choose different types of OS Managers.
Page 158 of 253

5.4.1 Linux OS Manager
A Linux OS Manager is used for virtual desktops based on Linux systems. It renames
the machines.
In a Linux OS Manager minimal parameters to be configured are:
Name: OS Manager name.
On Logout: What is the action that UDS is supposed to do on the VM when a user
closes a session:
Keep service assigned: (Persistent VM) when a user logs out the desktop
wont undergo any change. If this same user requests a virtual machine to the
system again, the system will provide the same virtual desktop
Remove service: (non-persistent VM) when a user logs out, the system will
destroy the desktop. If this same user requests a virtual machine to the system
again, the system will provide a new virtual desktop
Max. Idle time: When we configure non persistent desktops (Remove service)
we can specify a maximum idle time (in seconds) in the virtual desktop. When it
finishes, the UDS Actor will automatically log out from the virtual desktop. The
Max. Idle time field doesnt apply to persistent desktops (keep service
assigned).
Note: negative values or values less than 300 disable this option.
Page 159 of 253

Page 160 of 253

5.4.2 Linux Random Password OS Manager
A Linux Random Password OS Manager is used for virtual desktops based on Linux
systems which require a higher level of security in user access.
It performs tasks of renaming and password change of existing users.
A random password is assigned to an existing local user, which has been previously
defined during the configuration process, in each new deployed virtual desktop, thus
providing a higher level of security in the access.
In a Linux Random Password OS Manager minimmal parameters to be configured

are:
Account: Name of local user to which we need to change password.
closes a session:
Max. Idle time: When we configure non persistent desktops (Remove service) we can
specify a maximum idle time (in seconds) in the virtual desktop. When it finishes, the
UDS Actor will automatically log out from the virtual desktop. The Max. Idle time field
doesnt apply to persistent desktops (keep service assigned).
Page 161 of 253

Page 162 of 253

5.4.3 Windows Basic OS Manager
A Windows Basic OS Manager is used for virtual desktops based on Windows systems
which arent part of a domain.
In a Windows Basic OS Manager minimal parameters to be configured are:
closes a session:
Max. Idle time: When we configure non-persistent desktops (Remove service) we can
Page 163 of 253

Page 164 of 253

5.4.4 Windows Domain OS Manager
A Windows Domain OS Manager is used for virtual desktops based on

Windows systems which are part of a domain.
In a Windows Domain OS Manager minimal parameters to be configured are:
Domain: Name of the domain, to which virtual desktops will be joined to.
Account: Username with rights to add machines to the domain.
Password: Password of the user of the field Account.
OU: Information of the Organizing Unit (OU) where the virtual desktops deployed with
this OS Manager are going to be registered (if we dont write anything, the desktops
will be located in the branch by default)
The OU admitted format is the following:
OU=name_OU_last_level,OU=name_OU_first_level,DC=name_domain,DC=extenstion_dom
ain
To avoid errors in the introduction of the format it is recommended to consult the

distinguishedName on the properties of the OU attribute
Page 165 of 253

closes a session:
Max. Idle time: When we configure non persistent desktops (Remove service) we can
Page 166 of 253

5.4.5 Windows Random Password OS Manager
A Windows Random Password OS Manager is used for virtual desktops based on

Windows systems that are not part of a domain and require a higher level of security in
user access.
A random password is assigned to an existing user, previously defined during the

setup process, in each new deployed virtual desktop; thus providing a higher level of
access security.
In a Windows Random Password OS Manager minimal parameters to be configured

are:
Page 167 of 253

Account: Username with rights to add machines to the domain.
Password: Password of the user of the field Account.
closes a session:
Max. Idle time: When we configure non-persistent desktops (Remove service) we can
Page 168 of 253

5.4.6 RDS OS Manager
"RDS OS Manager" is required for RDS Windows servers (allows application

virtualization).
In a RDS OS Manager minimal parameters to be configured are:
Max. Session time: The maximum time that a session will can stay open in hours (0 =
illimited)
Page 169 of 253

5.5 Configure Networks
UDS allows registering several networks to allow or deny access to virtual desktops or
applications. These networks, together with Transports will define what kind of access
the users will have to their virtual desktops or applications generated by UDS.
To add a network, go to "Connectivity" section and click "New" in "Current Networks".
Minimal parameters to provide are:
We provide a descriptive name and a network range (supported in many of existing

formats).
IP range, a complete subnet or a unique IP, in each case we use the following format:
- Unique IP: xxx.xxx.xxx.xxx (e.g: 192.168.11.33)
- Complete subnet: xxx.xxx.xxx.xxx\x (e.g: 192.168.11.0\24)
IP range: xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx (e.g: 192.168.11.1 192.168.11.155)
If no network is registered, access to the virtual desktops or applications will be allowed

from any network.
Page 170 of 253

5.6 Configure Transports
In order to connect to the virtual desktops and applications, Transports must be

created. Transports are small applications that will be run on the client and which will
be responsible for providing access to the implemented service.
Depending on the type of virtual desktop configured, the location and way of
connection to our virtual desktops, different types of transports must be created.
Both, the client and the virtual machine should have the connection protocol installed,
this latter will be used in the transport section.
The following Transports are currently available:
Tunneled:
Directs:
Page 171 of 253

"Transports" that are indicated as "direct" will be used for user access to virtual
desktops and applications from an internal LAN, VPN, LAN Extension, etc ...
"Transports" that are indicated as "Tunneled" will be used for user access to virtual
desktops and applications from a WAN. These "Transports" will rely on the Tunneler
UDS server to make the connection.
The "Transport" HTML5 can be used for user access to virtual desktops from all types
of access (LAN, WAN, etc ...). This "Transport" uses the Tunneler UDS server to make
the connection against the virtual desktops.
To create a "Transport", in the section "Connectivity" click on "New" in the "Current

Transports" section.
Page 172 of 253

5.6.1 HTML5 RDP Transport
An "HTML5 RDP Transport" allows access to Windows and Linux virtual desktops
using the RDP protocol through a browser that supports HTML5 (for Linux desktops it
is necessary for machines to have the XRDP package installed and for Windows
desktops, RDP access has to Be enabled).
This transport uses the Tunneler UDS server to make the connection against the virtual
desktops, having to be previously configured for its correct operation.
In a HTML5 RDP Transport minimal parameters to be configured are:
o Main:
Name: transport name.
Priority: The lower that priority is, the higher it will appear on the list of transports
available in virtual desktop window of each user (this field admits negative values).
Networks Access: we indicate if in the selected network in "Networks" access to users

through this Transport will be allowed (the available networks will be the configured
ones in the "Networks" section).
Networks: Network ranges, subnets or IP addresses listed in the "Current Networks" in

"Connectivity" section. It is used in conjunction with the "Network Access" field to
enable or disable user access to a service based on your network location.
Page 173 of 253

o Tunnel:
Tunnel Server: IP address with the connection port Tunnel UDS server. If desktop
access is via a WAN, you must enter public IP address of the Tunnel UDS server.
Format: https: // IP_Tunneler: 10443 (default port).
o Credentials:
Empty creds: If this option is enabled, when we make the connection to the service
we will ask the access credentials to the virtual desktop, in case it is "No" the
credentials entered in the login portal are redirected.
Page 174 of 253

Username: Username to use to log on to the virtual desktop, if it is empty, UDS will try
to user user's login; if the "Empty creds" field is "No", it will ask for credentials to
indicate them manually.
Password: password of the user in the field Username.
Without Domain: states whether the user of the field Username belongs to a domain
or not.
Domain: Domain name.
o Parameters:
Enable Audio: Enables audio redirection on the virtual desktop
Enable Printing: Enables printing on the virtual desktop
Layout: Keyboard language to be enabled on the virtual desktop
Show wallpaper: Show background of screens
Allow Desk.Comp: Enable "Desktop Composition
Font Smoothing: Enable font smoothing
Page 175 of 253

Page 176 of 253

5.6.2 NX Transport (direct)
A "NX Transport (direct)" enables access to Linux virtual desktops through NX software
(the virtual machines and the connection clients must have NX installed).
Currently, NX supported version is 3.5.
In a NX Transport (direct) minimal parameters to be configured are:
o Main:
Listening port: Listening port of NX software.


Page 177 of 253

o Credentials:
Page 178 of 253

o Parameters:
Connection: Connection quality
Session: Desktop default session
Disk Cache: Size of cache hosted in the disk
Memory Cache: Size of cache hosted in the memory
Page 179 of 253

5.6.3 NX Transport (tunneled)
A "NX Transport (tunneled)" enables access to Linux virtual desktops through NX

software (the virtual machines and the connection clients must have NX installed).
Currently, NX supported version is 3.5
This transport uses UDS tunneler server to make the connection against the virtual
desktops, and it must be configured beforehand in order to work properly.
In a "NX Transport (tunneled) minimal parameters to be configured are:
o Main:
Listening port: Listening port of NX software.


Page 180 of 253

o Tunnel:
o Credentials:
Page 181 of 253

o Parameters:
Connection: Connection quality
Session: Desktop default session
Disk Cache: Size of cache hosted in the disk
Memory Cache: Size of cache hosted in the memory
Page 182 of 253

5.6.4 PCoIP Transport
A "PCoIP Transport" allows access to Windows / Linux virtual desktops by users

located on a WAN using Teradici's PCoIP protocol, it is necessary that both the
connection clients and the virtual desktops have the PCoIP server and client installed
and enabled respectively.
In addition, the other elements that make up the PCoIP suite (license server,
connection manager and Security Gateway) must be previously configured.
Name: Transport name.
Priority: Priority will be the transport, the lower that priority, the higher will appear in
the list of available transport of a service. The transport with the lowest priority will be
the one used by default when clicking on the image of a service.
Networks Access: It allows or disables the access of users to a service based on the
network from where it is accessing and the network indicated in the "Networks" field.
Networks: Network ranges, subnets or IP addresses indicated in the "Current

Networks" section of the "Connectivity" section. It is used in conjunction with the
"Network Access" field to allow or disable user access to a service based on its
network location.
Allowed Devices: Enables access to the service only with the selected devices, if
there is no one marked, no filtering is performed.
Page 183 of 253

o Credentials:
Empty creds: If this option is enabled, when we make the connection with the service
will ask for the credentials of access to the virtual desktop, in case of being "No" will be
redirected the credentials entered in the UDS login portal.
Username: The user name that will be used to log in to the virtual desktop, if this field
is empty, it will attempt to use the protal UDS login user if the "Empty creds" field is
"No" or will ask for credentials to indicate them Manual form.
Password: Contrasea del usuario del campo Username.
Without Domain: Indicates whether the username in the "Username" field belongs to
a domain.
Page 184 of 253

5.6.5 RDP Transport (direct)
A "RDP Transport (direct)" enables access to Windows virtual desktops through RDP
protocol (the virtual machines must have RDP service enabled).
In case of Linux VMs, XRDP should be installed instead of normal RDP.
In a RDP Transport (direct) minimal parameters to be configured are:
o Main:


Page 185 of 253

o Credentials:
or not.
Page 186 of 253

o Parameters:
Allow Smartcards: Enable SmartCard redirection
Allow Printers: Enables printing redirection
Allow Drives: enables disk redirection
Allow Serials: enables serial port redirection
Show wallpaper: displays desktop wallpaper
Multiple monitors: enables using multiple monitors
Allow Desk.Comp.: Habilita Desktop Composition
Font Smoothing: Activar suavizado de fuentes
Credssp Support: Si est activado usar Credential Security Support Provider
Page 187 of 253

o Linux Client:
Multimedia sync: Enables the multimedia parameter in freerdp (Linux connection

clients only).
Use Alsa: Enables the use of audio through Alsa (Linux connection clients only).
Printer string: Example: "Zebra", "ZDesigner TM400 200 dpi (ZPL)"

("Zebra" is the name of the local printer, "ZDesigner TM400 200 dpi (ZPL)" is the exact
name of the printer driver in Windows)
Smartcard string: Example: "Gemalto PC Twin Reader 00 00"

("Gemalto PC Twin Reader 00 00" is the name of the smartcard)
Page 188 of 253

5.6.6 RDP Transport (tunneled)
An "RDP Transport (tunneled)" allows access to Windows / Linux virtual desktops by

users located on a WAN using the Remote Desktop Protocol (RDP) protocol, it is
necessary that both connection clients and virtual desktops have RDP installed and
enabled (In the case of Linux virtual desktops, XRDP should be used).
In a RDP Transport (tunneled) minimal parameters to be configured are:
o Main:


Page 189 of 253

o Tunnel:
o Credentials:
Page 190 of 253

or not.
o Parameters:
Show wallpaper: displays desktop wallpaper
Multiple monitors: enables using multiple monitors
Allow Desk.Comp.: Habilita Desktop Composition
Page 191 of 253

o Linux Client:

clients only).


Page 192 of 253

Page 193 of 253

5.6.7 RDS Transport (direct)
A "RDS Transport (direct)" allows access to virtual Windows applications by users

through RemoteApp. Client connection can be under Windows or Linux systems.
A Windows client must have RemoteApp connection to open virtual applications. A

Linux client must have the freerdp2 connection to open virtual application package.
In a RDS Transport (direct) minimal parameters to be configured are:
o Main:


Page 194 of 253

o Credentials:
or not.
Page 195 of 253

o Parameters:
o Linux Client:

Page 196 of 253

Custom Parameters: Add new parameters (separated by commas).

clients only).
Page 197 of 253

5.6.8 RDS Transport (tunneled)
A "RDS Transport (tunneled)" allows access to virtual Windows applications by users

located in a WAN using RemoteApp. Client connection can be under Windows or Linux
systems.
A Windows client must have RemoteApp connection to open virtual applications. A

Linux client must have the freerdp2 connection to open virtual application package.
This transport uses the UDS Tunneler server to connect to virtual applications, it has to
be pre-configured for proper operations.
In a RDS Transport (tunneled) minimal parameters to be configured are:
o Main:


Page 198 of 253

o Tunnel:
o Credentials:
Page 199 of 253

or not.
o Parameters:
o Linux Client:
Page 200 of 253



Custom Parameters: Add new parameters (separated by commas).
Page 201 of 253

5.6.9 RGS Transport (direct)
A "RGS Transport (direct)" allows access to virtual desktops Windows / Linux users by
the protocol Remote Graphics Software (RGS), it is necessary that both connection
clients and virtual desktops have RGS software installed and enabled.
The RGS transport is used for connections that need high graphics performance.
In a "RGS Transport (direct) minimal parameters to be configured are:
o Main:


Page 202 of 253

o Credentials:
Page 203 of 253

o Parameters:
Image quality: image quality between values 0-100.
Adjustable Quality: if enabled, it will adjust image quality to the bandwidth.
Min. Adjustable Quality: minimal image quality.
Adjustable Frame Rate: Adjust frame rate.
Match Local Resolution: Adjust screen resolution of the client and server.
Redirect USB: If enabled, it redirects USB to the VM.
Redirect Audio: If enabled, it redirects Audio to the VM
Redirect Mic: If enabled, it redirects Mic and voice input to the VM.
Page 204 of 253

5.6.10 SPICE Transport (direct)
A "SPICE Transport (direct)" allows access to virtual desktops Windows / Linux users
through the SPICE protocol, clients need the SPICE connection (Virt-Manager) to be
installed.
SPICE transport is only possible to use with a service provider oVirt or Red Hat
Enterprise Virtualization (RHEV) and OpenNebula.
In a " SPICE Transport (direct) minimal parameters to be configured are:
o Main:


Certificate: Certificate generated in oVirt-engine / RHEV-manager needed to connect

with virtual desktops (usually hosted in /etc/pki/ovirt-engine/certs/ca.der).
Page 205 of 253

o Advanced:
Show fullscreen: Enables fullscreen remote display.
Page 206 of 253

5.6.11 SPICE Transport (tunneled)
A "SPICE Transport (tunneled)" allows access to virtual desktops Windows / Linux

users through the SPICE protocol, clients need the SPICE connection (Virt-Manager)
to be installed.
SPICE transport is only possible to use with a service provider oVirt or Red Hat
Enterprise Virtualization (RHEV) and OpenNebula.
This transport uses the UDS Tunneler server to connect to virtual applications and it
has to be pre-configured for proper operations.
In a " SPICE Transport (direct) minimal parameters to be configured are:
o Main:


Certificate: Certificate generated in oVirt-engine / RHEV-manager needed to connect

with virtual desktops (usually hosted in /etc/pki/ovirt-engine/certs/ca.der).
Page 207 of 253

o Tunnel:
o Advanced:
Show fullscreen: Enables fullscreen remote display.
Page 208 of 253

Page 209 of 253

5.6.12 X2Go Transport (direct)
An "X2Go Transport (direct)" allows access to Linux virtual desktops by users using
X2Go software (software based on the NX protocol).
Both the client (client) and the virtual desktops (server) need to have X2Go installed
and enabled.
In a X2Go Transport (direct) minimal parameters to be configured are:
o Main:


Page 210 of 253

o Credentials:
Username: username
o Parameters:
Desktop: Desktop Manager Selection
Enable sound: Enable audio
Page 211 of 253

Redirect root folder: Redirect user's home
Speed: Optimize connection
o Advanced:
Sound: Select server type
Keyboard: Keyboard layout
Page 212 of 253

Page 213 of 253

5.6.13 X2Go Transport (tunneled)
An "X2Go Transport (tunneled)" allows access to Linux virtual desktops by users using
X2Go software (software based on the NX protocol).
Both the client (client) and the virtual desktops (server) need to have X2Go installed
and enabled.
In a X2Go Transport (tunneled) minimal parameters to be configured are:
o Main:


Page 214 of 253

o Tunnel:
o Credentials:
Username: username
Page 215 of 253

o Parameters:
Desktop: Desktop Manager Selection
Enable sound: Enable audio
Redirect root folder: Redirect user's home
Speed: Optimize connection
o Advanced:
Sound: Select server type
Keyboard: Keyboard layout
Page 216 of 253

5.7 Access Calendars and Scheduled Tasks

UDS Enterprise incorporates a system access through calendars, they enable or
restrict user access to services, virtual desktops and applications by dates and slots.
With the use of calendars is also possible to schedule and automate certain tasks on a
"service Pool", such as making new publications, adjust the system cache or change
the maximum number of services.
Calendars defined in this section will be used in the "services Pool" to enable / deny
access to virtual desktops or applications or to configure scheduled tasks so you can
automate certain actions.
5.7.1 Configure Calendars
To create a "Calendars" in the Calendars men click on "New".
Give a descriptive name to your calendar.
Page 217 of 253

Upon saving we have a valid calendar and we can start creating rules that will apply to
services through the "Services Pool" calendar.
In a calendar, we can enlist various types of rules in which we could schedule the
availability of services at certain times.
To create a rule, select a calendar and choose New.
The minimum parameters to be configured in a Rule are:
Name: Name of the rule
Event: sets periods of execution, for this we specify the start time and duration of this
rule (in minutes, hours, days and months)
Repeat: In this section, you can configure the rule to repeat in days, weeks, months,
years and even specify working days, and also repeat intervals per day.
Summary: Displays a summary of all settings made previously.
Page 218 of 253

Upon saving we have a valid rule to be assigned to a service pool for scheduling
creation and managment of virtual services.
Page 219 of 253

5.7.1.1 Grant or Deny Accesses to Users
Once rules are configured in the calendars we can use them to enable or deny user
access to services, virtual desktops and applications.
To apply these calendar rules, you select a "Service Pool", and go in the menu "Access
Calendars" tab and click on "New"
We indicate the priority access, select an existing calendar and mark the actions that
apply in accessing the service.
Upon saving you a configured access calendar.
Page 220 of 253

5.7.1.2 Configure Scheduled Actions:
Once rules are configured in the calendars we can use them to schedule Certain tasks
on a "Service Pool".
To apply these rules to a service pool, we select a service pool and go to the tab
"Scheduled actions" and click on "New"
Select an existing calendar, the time during which the action will be executed and
select the action to perform:
Set initial services: Re-adjustment of virtual desktops initially created by the system.
These desktops are configured and ready to be assigned to a user.
Adjust the size of the cache: Re-adjustment of virtual desktops always available in
the system cache. These desktops are configured and ready to be assigned to a user.
Change the maximum number of services: Modify the maximum number of virtual
desktops in the service pool, created by the system.
Adjust the L2 cache size: Re-adjustment of virtual desktops always available in the
L2 cache system. These desktops are configured and put in suspension mode.
Publish: Creating a new service publication.
Page 221 of 253

Upon saving, we have a scheduled task that can perform real actions on a service
pool.
Page 222 of 253

5.8 Configure Services Pools
Once the different pieces of UDS platform are configured, Service Pools can be
created. Services Pools are made up of a Base Service created from a Service
Provider and an OS Manager. You must indicate one or several Transports, one or
several accesses Network (if no access network is specified, all networks will be
allowed) and a group or groups of users to access this service.
To create a "Service Pool" click on "New".
To create a Service Pool you should provide:
o Main:
Name: Service name which will be shown to the user to access the virtual desktop.
Base Services: Base service configured beforehand in a "Service Provider", where it

will be used to make the virtual desktops based in Linked Clones deployment.
OS Manager: We must indicate an OS Manager" created beforehand which

configuration will be applied to each virtual desktop generated in this "Services Pool".
Show Transports: If it is enabled, the users can select and access a desktop through
different transports. In case more than one is available, if it is not enabled, users only
will be able to access the desktop through the transport by default (the one with less
priority).
Publish on creation: If this option is setup, the system will publish the new
Service Pool when the user saves the creation of the new "Service Pool". If is is not
enabled, the desktops will have to be manually published (from Publications tab).
Page 223 of 253

o Display:
Associated image: Image associated to the service. It must first be added to the
image repository accessible from "Tools" - "Gallery" section.
Pool group: Enables grouping different services. In order to assign a "pool group" this
has to be previously created in the "Tools" section - "Services Pool Groups".
o Availability:
Initial available services: Virtual desktops that will be created, configured and will be
initially available in the system.
Page 224 of 253

Services to keep in cache: Virtual desktops available in the system cache. These
desktops will be configured and ready to be assigned (this number of desktops will be
automatically generated until the maximum number of machines indicated in the field
"Maximum number of services to provide" will be reached).
Services to keep in L2 cache: Virtual desktops in sleeping mode. These desktops will
be configured and ready to be assigned when the system demands new desktops.
Virtual desktops generated in the cache level 2 skip to cache level 1 at the time that the
system is requested.
Maximum number of services to provide: Maximum number of virtual desktops

created by UDS system in this "Service Pool".
We save the new Service Pool and the system will start generating virtual desktops
based on the configured cache (Availabiliy tab).
By means of the "Delete" button we can completely eliminate a "Service Pool" and with
"Edit" we can modify it.
Page 225 of 253

In "publications" and if you have set the "Publish on creation" option, the system will
start with the publication of the machine generating the service base on which will be
deploying virtual desktops.
Once a "Service Pool" is created, we select it and well have the following control and
configuration menus available:
Assigned Services: Virtual desktops assigned to users. It shows information

about the desktop creation date, revision number (or publication) on which the
desktop is generated, the MAC address of the VM network card, the virtual
desktop DNS and IP name, the current desktop state (if it is being used) the IP
name of the connection client, the machine owner and the UDS agent version
installed on the base machine.
Selecting the virtual desktop and clicking on "Delete" we can delete it manually.
Cache: Virtual desktops available in the system cache (including level 2 cache
machines). These desktops will go through different states:
o In Preparation: The virtual desktops are being created in the virtualization

platform
Page 226 of 253

o Waiting OS: The virtual desktops are being configured with the parameters
indicated in the OS Manager
o Valid: Virtual desktop available to be used
Groups: To allow the users connection, it is necessary to assign access groups or

metagroups. These groups or metagroups must be created in the Authenticators
section and we will be able to assign one or several access groups or metagroups to
each Service Pool
We select the Authenticator and based on this choice we select the Group Name.
Transports: The Transport to make the connection with the virtual desktop
(beforehand added in the Transports section) will be indicated. The "Transport" with
less priority will be configured by the system by default. For the other ones, the user
will have to open the pull-down menu in the virtual desktops access window and select
the one that corresponds
Page 227 of 253

Select the Transport" we want to use in this "Service Pool" and save.
Publications: From this menu, we will be able to perform a new publication of the
service (for example if we have updated our base machine with new applications or
patches of S.O. and we want all our virtual desks to take these changes). Once the
publishing process is finished, the entire system cache will be regenerated with the
new Linked Clones based on this latest publication
If we perform a new publication, a new base machine will be generated and, once
available, the system will remove the virtual desktops from the previous version and
generate new ones based on the new publication.
Page 228 of 253

5.9 Configure Permissions
In UDS Enterprise administration dashboard you can assign access permissions for
the different elements, users and groups of users. The permissions will be directly
assigned on each element and will also apply to sub-elements.
In order to enable user access to the administration dashboard to get these

permissions, Staff member option must be enabled for that user.
In order to enable permissions in the different elements of the administration

dashboard, select the element and click on Permissions:
Page 229 of 253

Click on Add group permission in the permissions window to add permissions to a

group. Click on Add user permission to add permisions to a user. Then, select the
authenticator and the group/user that is going to get those permissions. We must
specify wether this user or group of users will have read only access or full access.
Once applied, the users with Staff member option enabled will be able to access this
administration element with the given permissions.
In order to revoke user or group permissions, select it and click on Revoke user
permission / Revoke group permission.
Page 230 of 253

Permissions "Full Access" may only be applied to elements of the second level of the
sections "Services", Calendars and "Service Pools". In the items "Authenticators" "OS
mnagers" and Connectivity "will only be possible to apply read permissions.
Page 231 of 253

6 ACCESS VIRTUAL DESKTOPS WITH UDS

ENTERPRISE
Once one or several Service Pools are available, we can run a connection to a virtual
desktop. Access UDS Enterprise via web browser (Internet Explorer, Chrome and
Firefox browsers are supported), enter a valid username and password and select the
authenticator if more than one is available.
In Services dashboard, the available services for that user will be displayed. Click on
the one you want to run.
By default, if we click directly on the service image, the connection with the Transport
which has the lower priority will be performed. If several Transports are setup, a pull-
down menu will be displayed and you will be able to select the Transport you are going
to use to connect to the virtual desktop.
If needed, we can group services by type for an easy access:
Page 232 of 253

In order to start the connection with the virtual machine, it is necessary to have the
UDS Plugin installed on the client machine (in case it is not installed the system will
provide the appropriate version for each OS) in order to start the connection for all
transports except for HTML5 transport.
In order to be able to connect to the desktop or virtual application it is necessary to

have the clients of each protocol used (RDP client, NX, RGS, SPICE, etc ...)
Page 233 of 253

Example of an RDP connection:
Example of an HTML5 connection:
Page 234 of 253

Example of NX Connection:
Once the connection is made, the virtual desktop will be available for use.
Page 235 of 253

7 ADVANCED CONFIGURATION OF UDS ENTERPRISE
UDS provides advanced parameters which will define the running of the system. These
parameters will be responsible for defining security, connectivity, operating mode
both of UDS system and its communication with the virtual platforms (vSphere,
oVirt/RHEV, Hyper-V, XenServer, Acropolis) registered on UDS.
This manual shows only some of the system variables, which are considered the most
useful ones to the management of virtual desktops.
Here you can find the system variables that are considered to be the more useful ones
to manage the virtual desktops. When using the variables which arent mentioned here,
it is recommended not to modify the default values, as some of them indicate how the
system has to work (number of simultaneous tasks, time for tasks execution,
programmed checks, etc) and a wrong parameter modification may completely stop
the system or make it work in a wrong way.
Once the values of one of the UDS advanced configuration variables have been
modified, it will be necessary to reboot the UDS Server so that the changes will be
applied.
If you want to modify any value which isnt included in this section, we recommend you
to contact the UDS Enterprise support team in order to verify that change and confirm
that it doesnt affect in a negative way to the running of UDS system.
Page 236 of 253

7.1 Image Gallery
UDS has a repository of images that may be associated to a Service Pool" to facilitate
the identification of the virtual desktop. The supported formats are: PNG, JPEG and
GIF. The maximum image size is 256 Kb.
To access UDS image Gallery, enter "Tools" section and select "Gallery":
Click on New to add the image to the repository and write a name. Click on Select
image to search the image you want to save.
Page 237 of 253

Once the image is stored, it will be available in order to be assigned to a Service Pool
(see more details in 4.7).
Page 238 of 253

7.2 Service Pool Group
UDS services group allows for easy access and location; nonetheless, to each service
group there can be assigned a name and image. If a "Pool Group Services" is not
defined all services will be located in the default group created by the system.
To access and create new "Pool Services Group", we access the "Tools" section and
select "Services Pool Group":
Page 239 of 253

Select "New" and indicate a descriptive name, assign priority pool group (groups with
small priority numbers will appear first in the list) and associate an image.
Once created, the "Pool Service Group" will be available for allocation to a "Service
Pool" (for details go to 4.7).
Page 240 of 253

Page 241 of 253

7.3 Reports
UDS generates automatically reports about different platform elements.
In order to access the reports, go to Tools section and click on Reports:
You can generate the following reports:
List os users: It creates a report featuring all users belonging to an

authenticator. To create the report, click on List, then click on Generate
report and select an authenticator:
Once the report is created, well obtain a list of users belonging to that authenticator:
Page 242 of 253

User access: It creates a report with all user accesses to the system in a specific date
range. To create the report, select the Statistics / Users access report by date group
and click on Generate report and select the date range and the number of intervals
Page 243 of 253

Once the report is generated, youll get a graphic and a list with all users accesses:
Service Pool performance: It creates a report about the use of a services pool in a
specific date range. In order to create the report, select the Statistics / Pools
performance by date group, click on Generate report and select the pool, date range
and number of intervals:
Page 244 of 253

Once the report is created, youll get a graphic and a performance list of the selected
Service Pool:
Page 245 of 253

7.4 ADvanced Parameters of UDS Enterprise
In order to access the UDS advanced configuration parameters, access Tools section
and click Configuration:
Page 246 of 253

7.4.1 UDS
The most important parameters regarding UDS internal procedures, appearance and
communication with the hypervisor platforms.
AutorunService = It performs direct access to the virtual desktop when a user only
has one service assigned (0 = off 1 = on).
If this parameter is turned on, the users who only have one virtual desktop assigned
will connect to it straightaway, the window where you select the service wont appear
and the first configured transport will be used.
Default value 0.
CustomHtmlLogin= HTML code for partial customization of UDS login page. The
code you enter will appear under the user login box in the UDS Access dashboard.
Empty by default.
DisallowGlobalLogin = If it is turned on, the entire authenticators list wont appear (0

= off 1 = on).
If this variable is turned on, you must use a short name to see an authenticator and
allow user access to the system.
Default value 0
RedirectToHttps = It automatically redirects UDS Enterprise access from http to https

(0 = off 1 = on).
Default value 0
SessionExpireTime = It indicates the maximum time a user session will be opened

after publishing something new. After, the user session will be closed and the system
will delete the service.
Default value 24 Hours.
StatsDuration = It indicates how long the system will keep the statistics.
Default value 365 days.
UDSTheme = Name of the folder which contains the HTML templates for the login
Windows, user, preferences, downloads, etc
Default name html5.
Page 247 of 253

7.4.2 RGS
Find below the description of the parameters related to the RGS Transport:
DownloadUrl = Web address to download RGS software.
TunnelOpenedTime = Maximum time the tunnel will wait for the RGS connection to be
opened.
If the connection isnt carried out in the time indicated in this variable, it will be
canceled and you will have to make the connection again (if you make the connection
using slow clients, it is recommended to increase this value)
Default value 30 seconds.
7.4.3 SAML
Find below the description of the parameters related to the SAML authenticator:
Global logout on exit = It indicates the logout mode (0 = off 1 = on).
If it is enabled, when you logout from UDS you also logout from SAML.
Default value 0.
IDP Metadata Cache = Time the IDP.m searched metadata are kept.
Default value 86400 seconds (24 hours).
Organization Display Name = Organization name displayed.
Organization Name = Organization name.
Organization URL = Organization web address.
User cleanup = It indicates how often the system cleans up the users without activity.
If a user remains inactive for the time indicated in this variable, the system will delete it.
Default value 2592000 seconds (30 days).
7.4.4 IPAUTH
These variables are inactive in this UDS Enterprise version.
Page 248 of 253

7.4.5 NX
Find below the description of the parameters related to the NX Transport:
DownloadUrl = Web address to download NX software.
DownloadUrlMACOS = Web address to download NX software for MAC.
7.4.6 CLUSTER
These variables are inactive in this UDS Enterprise version.
7.4.7 WYSE
Find below the description of the parameters related to the connection with
Wyse clients:
Autoconnect = It allows the automatic connection of the device.
Default value no.
Colors = It defines the quality of the colours displayed during the connection.
Default value High.
DefaultUser = Default user redirected to the device.
Default value UDS.
Language = Device language.
Default value us.
Privilege = User privilege level.
Default value NONE.
For more details about these parameters see Wyse official documentation or the
following reference guide:
http://www.freewysemonkeys.com/downloads/wtos/Wyse%20Thin%20OS%2064%20P
arameters.pdf
7.4.8 ENTERPRISE
Find below the description of the parameters related to UDS Enterprise subscription:
Page 249 of 253

Serial Number = Subscription activation code.
During the UDS Server configuration you must indicate a valid serial number. Using
this variable you can update or change it.
7.4.9 SECURITY
Find below the description of the parameters related to UDS system security:
AdminIdleTime = It indicates how long an administrator session will be opened. After

this period, you must authenticate yourself again in the system.
Default value 14400 seconds (4 hours).
AllowRootWebAccess = It allows the root user login via web (0 = off 1 = on).
The modification of this variable doesnt affect the root user access through the
administration client.
Default value 1.
RootPass = Root user password, previously indicated in the UDS Server configuration
script.
SuperUser = User with UDS system administration rights.
By default: root.
Trusted Hosts = Hosts considered to be secure by UDS. These host can make
sensitive requests to UDS, for example tunnelers (it is recommended to modify this
variable so that the only displayed option is the list of tunnelers).
By default * (all allowed), it admits addresses range values.
UserSessionLength = It indicates how long the user session will be opened. After this
period, it will be necessary for the user to authenticate himself again in the system.
Default value 14400 seconds (4 hours)
Page 250 of 253

7.4.10 VMWARE
Find below the description of the parameters related to VMware vSphere virtual
platform:
MaxRetriesOnError = Number of times and operation is retried in case VMware

reports an error to UDS system.
Default value 63 retries.
MinUsableDatastoreGB = Minimum free space in a datastore to create the virtual

desktops.
If the VMware platform datastores selected to create services in UDS have less free
space than the value of this variable, the virtual desktops wont be created. Once this
value is modified or the needed space is available, the system will work properly.
Default value 30.
Page 251 of 253

7.5 Flush System Cache
In order to flush the UDS systems cache, enter the Tools section and click on Flush
cache.
The most common reasons to flush the system cache are:
Blocking of a user: when a user enters an invalid password up to 4

consecutive times, UDS blocks that user. To unlock it it will be necessary to
flush the cache system
Inventory update: it is possible that when you edit a "Service", some elements
as datastores, networks, base machines, etc. recently added, are not available.
To view them, we will have to flush the system cache. In this way, the Broker
will again make the request to the hypervisor and data will be updated
Page 252 of 253

8 ABOUT VIRTUALCABLE
VirtualCable commercializes UDS Enterprise via a subscription model, including NBD

product support via email and segment updates by number of users.
VirtualCable also offers a broad portfolio of professional services in order to help its
clients in both installation processes and UDS Enterprise configuration and in
virtualization projects with other platforms.
For more information, visit www.udsenterprise.com or email us at

info@udsenterprise.com
u
All the proper names of programs, operating systems, hardware, etc. that appear in
this document are registered trademarks of their respective companies or
organizations.
All rights reserved. The content of this work is protected by law, which establishes
prison sentences and /or fines in addition to appropriate compensation for damages for
the ones that copy, plagiarise, distribute or communicate publically, whole or in part, a
literary, artistic or scientific work or its transformation, interpretation or artistic execution
fixed in any type or format or communicated through any means without the required
authorization.
-END OF DOCUMENT-
Page 253 of 253

Uds 21 User Administration Guide Rev1

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Uds 21 User Administration Guide Rev1

Hochgeladen von

Copyright:

Verfügbare Formate

Installation Manual,

Administration and User

Version 2.1 Rev. 1

1.1 Free & Evaluation versions vs. Enterprise version ........................................ 8

1.2 Caracteristics ................................................................................................ 9

1.3 Architecture of the Platform with UDS Enterprise ....................................... 10

1.3.1 Architecture of the Network ...................................................................... 12

1.4 Components of UDS Enterprise .................................................................. 15

1.4.1 UDS Server............................................................................................... 16

1.4.2 UDS Tunneler ........................................................................................... 17

1.4.3 UDS Database .......................................................................................... 18

1.4.4 UDS Actor ................................................................................................. 19

1.4.5 UDS Plugin ............................................................................................... 20

2 BEFORE INSTALLING UDS ......................................................................... 21

2.1 Installing Enterprise on VMware vSphere Virtual Platform ......................... 22

2.1.1 Requirements of the Virtual Platform........................................................ 22

2.1.2 Network Connectivity ................................................................................ 23

2.2 Installing UDS Enterprise on oVirt Virtual Platform ..................................... 24

2.2.1 Virtual Platform Requirements.................................................................. 24

2.2.2 Network Connectivity ................................................................................ 25

2.3 Installing UDS Enterprise on RHEV Virtual Platform .................................. 26

2.3.1 Virtual Platform Requirements.................................................................. 26

2.3.2 Network Connectivity ................................................................................ 27

2.4 Installing UDS Enterprise on Microsoft Hyper-V ......................................... 28

2.4.1 Virtual Platform Requirements.................................................................. 28

2.4.2 Network Connectivity ................................................................................ 30

2.5 Installing UDS Enterprise on XenServer Virtual Platform ........................... 31

2.5.1 Virtual Platform Requirements.................................................................. 31

2.5.2 Network Connectivity ................................................................................ 32

2.6 Installing UDS Enterprise on Nutanix Acropolis Virtual Platform ................ 33

2.6.1 Virtual Platform Requirements.................................................................. 33

2.6.2 Network Connectivity ................................................................................ 34

2.7 Installing UDS Enterprise on OpenStack Platform ...................................... 35

2.7.1 Virtual Platform Requirements.................................................................. 35

2.7.2 Network Connectivity ................................................................................ 36

2.8 Installing UDS Enterprise on OpenNebula Platform ................................... 37

2.8.1 Virtual Platform Requirements.................................................................. 37

2.8.2 Network Connectivity ................................................................................ 38

3 INSTALLING UDS ENTERPRISE ................................................................. 39

3.1 Requirements of UDS Enterprise Environment ........................................... 40

3.1.1 Infrastructure Requirements ..................................................................... 40

3.1.2 Network Requirements ............................................................................. 40

3.2 Installing UDS Enterprise Environment ....................................................... 41

3.2.1 Install and configure the Database ........................................................... 41

3.2.2 Installing UDS Server ............................................................................... 45

3.2.3 Installing UDS Tunneler ............................................................................ 51

3.2.4 Install and configure UDS Actor ............................................................... 56

3.2.4.1 Install UDS Actor. Windows Virtual Desktops ....................................... 58

3.2.4.2 Install UDS Actor. Linux Virtual Desktops ............................................. 62

3.2.4.3 Install UDS Actor. Microsoft RDS Virtual Applications .......................... 66

3.2.5 Installing UDS Plugin for Windows ........................................................... 70

3.2.5.1 Instalacin Plugin UDS Windows .......................................................... 72

3.2.5.2 Installing UDS Plugin for Linux ............................................................. 75

4 ADMINISTRATION OF UDS ......................................................................... 78

4.1 Configure Service Providers ..................................................................... 81

5 DEPLOYMENT OF VDI PLATFORM VIA VMWARE VSPHERE VIRTUAL

5.1.1 VDI Platform with VMware vSphere ......................................................... 82

5.1.1.1 Register Service Provider VMWare vCenter Platform Provider .......... 82

5.1.1.2 Configure a service based on VMware Linked Clones Base .............. 85

5.1.2 VDI Platform with oVirt or RHEV .............................................................. 89

5.1.2.2 Configure a service based on oVirt/RHEV Linked Clone .................... 92

5.1.3 VDI Platform with Microsoft Hyper-V ........................................................ 96

5.1.3.1 Register a Service Provider of the Service Hyper-V Platform Provider

5.1.3.2 Configure a service based on Hyper-V Linked Clone ......................... 99