UDS Enterprise Installation, Administration & User Guide

Transcription

1 UDS Enterprise Installation, Administration & User Guide Version 2.0 Rev. 1 26th of September 2016

2 Index 1. INTRODUCTION Enterprise, Free & Evaluation versions Features Platform architecture with UDS Enterprise Network Architecture UDS Enterprise Components UDS Server UDS Tunneler UDS DataBase UDS Actor UDS Plugin BEFORE INSTALLING UDS Installation of UDS Enterprise on VMware vsphere virtual platform Virtual Platform Requirements Network Connections Storing UDS elements on VMware vsphere UDS Enterprise installation on ovirt virtual platform Virtual platform requirements Network Connections UDS Enterprise installation on RHEV virtual platform Virtual Platform Requirements Network Connections UDS Enterprise installation on Microsoft Hyper-V Virtual Platform Requirements Network Connections UDS Enterprise installation on Citrix XenServer Page 1 of 243

3 2.5.1 Virtual Platform Requirements Network Connections UDS Enterprise installation on Nutanix Acropolis Virtual platform requirements Network Connections UDS Enterprise Installation on OpenStack platform Virtual Platform Requirements Network Connections UDS Enterprise Installation on OpenNebula Platform Virtual Platform Requirements Network Connections INSTALLING UDS ENTERPRISE UDS Enterprise Platform Requirements Infrastructure requirements Network requirements UDS Enterprise Platform installation UDS Database Setup UDS Server setup UDS Tunneler setup UDS Actor Setup Windows UDS Actor Installation Linux UDS Actor Installation UDS Actor Setup for Microsoft RDS UDS Plugin Setup Windows UDS Plugin Setup Linux UDS Plugin Setup ADMINISTRING UDS Configuring Service Providers Page 2 of 243

4 4.1.1 VDI Platform with VMware vsphere Registering VMWare vcenter Platform Provider Service Provider Configuring a service based on VMware Linked Clones Base VDI Platform with ovirt Registration of service provider ovirt Platform Provider Setup Service based on ovirt/rhev Linked Clone VDI Platform with Microsoft Hyper-V Registration of Service Provider Hyper-V Platform Provider Setup Service based on Hyper-V Linked Clone VDI Platform with Citrix XenServer Registration of Service Provider XenServer Platform Provider Setup of a Service based on Xen Linked Clone VDI Platform with Nutanix Acropolis Registration of Service Provider Nutanix Acropolis Platform Provider Setup a Service based on Nutanix KVM VDI Platform with OpenStack Register Service Provider OpenStack Platform Provider Configure a service based on OpenStack Live Volume VDI platform with OpenNebula Registration of a Service Provider for OpenNebula Platform Provider Configuring a service based on OpenNebula Live Volume Conexión directa a equipos persistentes Registration of Service Provider Static IP Machines Provider Configuring service based on Physical machines Provider RDS Application Provider Registering Service Provider RDS Platform Provider Setup of service based on RDS Platform RemoteAPP Configuring Authenticators Page 3 of 243

5 4.2.1 Active Directory Authenticator edirectory Authenticator Internal Database IP Authenticator SAML Authenticator LDAP Authenticator Configuring users, user groups and user metagroups Creating "Internal Database" groups and users Creating IP Authenticator groups and users Configure OS Managers Linux OS Manager Linux Random Password OS Manager Windows Basic OS Manager Windows Domain OS Manager Windows Random Password OS Manager RDS OS Manager Configuring Networks Configuring Transports HTML5 RDP Transport NX Transport (direct) NX Transport (tunneled) RDP Transport (direct) RDP Transport (tunneled) RDS Transport (direct) RDS Transport (tunneled) RGS Transport (direct) RGS Transport (tunneled) RHEV/oVirt SPICE Transport (direct) Page 4 of 243

6 RHEV/oVirt SPICE Transport (tunneled) Access Calendars and Scheduled Tasks Configuring Calendars Habilitar o denegar accesos de usuarios Configurar acciones Programadas: Configuring Services Pools Configuring Permisions ACCESSING VIRTUAL DESKTOPS AND SERVICES WITH UDS ENTERPRISE UDS ENTERPRISE ADVANCED CONFIGURATION Image Gallery Services Pool Group Reports UDS Advanced Parameters UDS RGS SAML IPAUTH NX CLUSTER WYSE ENTERPRISE SECURITY VMWARE Flush System Cache ABOUT VIRTUALCABLE Page 5 of 243

7 1. INTRODUCTION UDS Enterprise is a multiplatform connection Broker for Windows and Linux. It manages user access to virtual and remote desktops, applications and any service validated in the system. UDS Enterprise provides a set of software elements for services lifecycle management, administration and deployment. This document contains basic instructions to setup UDS software on a virtual infrastructure and procedure for a proper administration of the different services. Page 6 of 243

8 1.1 Enterprise, Free & Evaluation versions UDS software requires a Data Base (DB) to storage system configuration parameters. To perform this function, UDS is compatible with MySQL different versions. UDS Enterprise paid version requires an external Data Base. In case you don t 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 you re about to setup UDS Enterprise Free Edition or UDS Enterprise Evaluation Edition, the sections included in this guide regarding UDS Data Base don t apply, since as we explained before the DB is embedded in the system. Principales diferencias entre UDS Enterprise, Free Edition & Edición de Evaluación: Enterprise Edition Free Edition Evaluation Edition Nº of users Unlimited 10 Unlimited Duration Unlimited Unlimited 60 days New hypervisors? Yes No No Data Basee? External required Internal Internal Tunneled WAN Mail to Yes No connections? UDS Team Security updates? Yes No No Updates between versions? Yes No Yes New Modules? Yes No No Support? Yes Per incident No Premium Support? Yes No No Page 7 of 243

9 1.2 Features The main features of UDS Enterprise include: Very easy installation and administration Virtual and remote desktops deployment Application virtualization for users in Windows environment through RDS Multi-hypervisor, with the ability to migrate the platform to more efficient future solutions (currently it is compatible with VMware vsphere, KVM, Microsoft Hyper-V, OpenNebula, OpenStack, Citrix XenServer and Nutanix Acropolis) Multi-authenticator, which permits users and user groups from different sources to be set up with a practically unlimited number of configurations Authentication system via multiple connectors, for example: Active Directory, LDAP, OpenLDAP, edirectory, SAML, CAS, Internal authentication system, authentication system by device, IP, MAC, Hostname Reports featuring users lists/accesses and services pools use Secure WAN access for publishing PCs on the Internet, using an SSL tunneler included in the subscription Tool personalization using customized development Product roadmap based on client and community requests Ready for heterogeneous environments where other solutions do not have access because of functionalities or cost scaling, for example: AAPP or academic environment Subscription model based on support and updates of UDS Enterprise. Non-redistributable subscription model up to an unlimited number of users Task scheduling system (Service deployment, user access control, etc ) through the Calendar feature. Secure WAN access for the publications of virtual desktops in internet by SSL Tunneler that is included in the subscription. Page 8 of 243

10 1.3 Platform architecture 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 an unlimited number of authenticators Service Providers o 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 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 9 of 243

11 In the following image you can see an example of an architecture with UDS Enterprise: Page 10 of 243

12 1.3.1 Network Architecture 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 11 of 243

13 Example of deployment of services and virtual desktop applications for user access across a WAN (internet). In order for UDS to be publish 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 12 of 243

14 1.4 UDS Enterprise Components 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 doesn t 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 13 of 243

15 1.4.1 UDS Server This is the software that mediates among 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 features: 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 14 of 243

16 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. Virtual Appliance with the following features: 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 15 of 243

17 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.0 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. Virtual Appliance with the following features: 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 16 of 243

18 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 are: Windows 10 Windows 8.1 Windows 8 Windows 7 Windows 2008 Windows 2012 Linux (Debian, Ubuntu, CentOS, Fedora, OpenSuse, etc ) Requirements:.Net Framework 3.5 SP1 (Windows machines) Python 2.7 (Linux machines) UDS Server IP 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 Page 17 of 243

19 Windows 7 Windows 2012 Windows 2008 Linux (Debian, Ubuntu, CentOS, Fedora, OpenSuse, etc ) MAC OSX (10.5 onwards) Page 18 of 243

20 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 19 of 243

21 2.1 Installation of UDS Enterprise on VMware vsphere virtual platform Virtual Platform Requirements UDS Enterprise will be able to be deployed on VMware vsphere platforms starting with version 5. 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 installed 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 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 E1000E virtual network adapter of the template machine (gold image) is not supported UDS Enterprise podrá ser desplegado sobre plataformas VMware vsphere 5 o superior. Page 20 of 243

22 2.1.2 Network Connections The following connections between the different elements which make up the UDS Enterprise platform must be enabled: Origin Destination Port UDS Server DB MySQl 3306 UDS Server vcenter 443 UDS Server Authenticator 389, 636 (SSL) UDS Tunneler UDS Broker 80, 443 UDS Broker Virtual Desktops (UDS Actor) UDS Tunneler Virtual Desktops 3389 (RDP), 22 (NX), (RGS) 5XXX (SPICE) UDS Tunneler UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunneler 443 Users UDS Tunneler (HTML5) Page 21 of 243

23 2.1.3 Storing UDS elements on VMware vsphere The main component of UDS is provided as virtual appliance to upload the VM to vsphere platform, using the vsphere client. Steps: 1.- Once established connection on the target platform though VMware vsphere client, please choose the menu option File \ deploy OVF Template... Page 22 of 243

24 2.- Select the source location of the virtual machine.ova file Page 23 of 243

25 3.- On next step the wizard displays virtual machine features to be hosted in the target virtual platform: 4.- Next step, select inventory name and location of the virtual machine on the target platform. Page 24 of 243

26 5.- Then, select the destination datastore where the virtual machine is going to be stored. 6.- The wizard displays the name and size of the selected datastore; you can choose the machine virtual hard drive format. It is recommended to select Thick Provision Lazy Zeroed format, as this provides better performance. Page 25 of 243

27 7.- Select the virtual network to which the virtual machine will be connected to. 8.- In the last step, wizard displays the virtual machine conversion details. Clicking "Finish" button starts the conversion process. Page 26 of 243

28 Once the conversion process has been completed, you now have the UDS Broker server in its Enterprise version stored on the vsphere virtual platform. NOTE: Steps 1 to 8 (if necessary) must be repeated for the tunneler s virtual appliance and the MySQL DB server (only in the event that VirtualCable provides the DB s virtual appliance). Page 27 of 243

29 2.2 UDS Enterprise installation on ovirt virtual platform Virtual platform requirements UDS can be deployed on ovirt platforms version 3.2, 3.3, 3.4 & The ovirt platform on which UDS is going to be deployed must meet the following requirements: At least one ovirt server node is needed to host the UDS servers and create the virtual desktops The ovirt platform must be administered by an ovirt-engine For UDS to be installed and capable of sending requests to an ovirt-engine, and for these requests to be carried out, the user must have credentials with administration rights on the ovirt 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 There must be at least 18 GB of free space on the hard drive to host the virtual 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 28 of 243

30 2.2.2 Network Connections Es necesario tener habilitados los siguientes puertos de comunicación entre los diferentes elementos que conforman la plataforma UDS: Origen Destino Puerto UDS Server UDS MySQL 3306 UDS Server ovirt-engine 443 UDS Server Autenticator 389, 636 (SSL) UDS Server Virtual Desktops 3389 (RDP), 22 (NX), (RGS) UDS Server Virtual Desktops (UDS Actor) UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), (RGS), XXX (SPICE) UDS Tunnel UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunnel 443 Users UDS Tunnel (HTML5) Page 29 of 243

31 2.3 UDS Enterprise installation on RHEV virtual platform Virtual Platform Requirements UDS Enterprise can be deployed on Red Hat Enterprise Virtualization platforms version 3. 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 There must be at least 18 GB of free space on the hard drive to host the virtual 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 30 of 243

32 2.3.2 Network Connections The following ports among the different elements that make up the UDS platform must be enabled: Origen Destino Puerto UDS Server UDS MySQL 3306 UDS Server RHEV-Manager 443 UDS Server Autenticator 389, 636 (SSL) UDS Server Virtual Desktops 3389 (RDP), 22 (NX), (RGS) UDS Server Virtual Desktops (UDS Actor) UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), (RGS), XXX (SPICE) UDS Tunnel UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunnel 443 Users UDS Tunnel (HTML5) Page 31 of 243

33 2.4 UDS Enterprise installation on Microsoft Hyper-V Virtual Platform Requirements 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 There must be at least 18 GB of free space on the hard drive to host the virtual servers that make up UDS There must be at least 3 GB of free RAM to host the virtual servers that make up UDS You must enable WSMan on every Hyper-V host used with UDS so that Microsoft Hyper-V with UDS will perform properly To enable it through HTTPS, you must have a valid certificate. Page 32 of 243

34 To enable it through HTTP, run: winrm quickconfig winrm set winrm/config/service winrm set winrm/config/service/auth Page 33 of 243

35 2.4.2 Network Connections The following connections among the different elements which make up the UDS platform must be enabled: Origen Destino Puerto UDS Server UDS MySQL 3306 UDS Server Hyper-V 80, 443 UDS Server Autenticator 389, 636 (SSL) UDS Server Virtual Desktops 3389 (RDP), 22 (NX), (RGS) UDS Server Virtual Desktops (UDS Actor) UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), (RGS), XXX (SPICE) UDS Tunnel UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunnel 443 Users UDS Tunnel (HTML5) Page 34 of 243

36 2.5 UDS Enterprise installation on Citrix XenServer Virtual Platform Requirements 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 There must be at least 18 GB of free space on the hard drive to host the virtual 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 35 of 243

37 2.5.2 Network Connections The following connections among the different elements which make up the UDS platform must be enabled: Origen Destino Puerto UDS Server UDS MySQL 3306 UDS Server XenServer 80, 443 UDS Server Autenticator 389, 636 (SSL) UDS Server Virtual Desktops 3389 (RDP), 22 (NX), (RGS) UDS Server Virtual Desktops (UDS Actor) UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), (RGS), XXX (SPICE) UDS Tunnel UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunnel 443 Users UDS Tunnel (HTML5) Page 36 of 243

38 2.6 UDS Enterprise installation on Nutanix Acropolis Virtual platform requirements UDS can be deployed on Nutanix Acropolis platforms. The Nutanix Acropolis platform on which UDS is going to be deployed must meet the following requirements. 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 You must have at least one network to connect the different virtual desktops managed by UDS There must be at least 18 GB of free space on the hard drive to host the virtual 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 37 of 243

39 2.6.2 Network Connections The following connections among the different elements which make up the UDS platform must be enabled: Origen Destino Puerto UDS Server UDS MySQl 3306 UDS Server Acropolis 80, 443 UDS Server Autenticator 389, 636 (SSL) UDS Server Virtual Desktops 3389 (RDP), 22 (NX), (RGS) UDS Server Virtual Desktops (UDS Actor) UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), (RGS), XXX (SPICE) UDS Tunnel UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunnel 443 Users UDS Tunnel (HTML5) Page 38 of 243

40 2.7 UDS Enterprise Installation on OpenStack platform Virtual Platform Requirements 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 following requirements. 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 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 There must be at least 18 GB of free space on the hard drive to host the virtual 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 39 of 243

41 2.7.2 Network Connections The following connections among the different elements which make up the UDS platform must be enabled: Origen Destino Puerto UDS Server UDS MySQl 3306 UDS Server OpenStack 5000 UDS Server Autenticator 389, 636 (SSL) UDS Server Virtual Desktops 3389 (RDP), 22 (NX), (RGS) UDS Server Virtual Desktops (UDS Actor) UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), (RGS), XXX (SPICE) UDS Tunnel UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunnel 443 Users UDS Tunnel (HTML5) Page 40 of 243

42 2.8 UDS Enterprise Installation on OpenNebula Platform Virtual Platform Requirements UDS can be deployed on OpenNebula platforms through the versions 4.0 and 5.0. The OpenNebula platform on which UDS is going to be deployed must meet the following requirements. 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 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 There must be at least 18 GB of free space on the hard drive to host the virtual 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 41 of 243

43 2.8.2 Network Connections The following connections among the different elements which make up the UDS platform must be enabled: Origen Destino Puerto UDS Server UDS MySQl 3306 UDS Server OpenNebula 2633 UDS Server Autenticator 389, 636 (SSL) UDS Server Virtual Desktops 3389 (RDP), 22 (NX), (RGS) UDS Server Virtual Desktops (UDS Actor) UDS Tunnel Virtual Desktops 3389 (RDP), 22 (NX), (RGS), XXX (SPICE) UDS Tunnel UDS Server 80, 443 Users UDS Server 80, 443 Users UDS Tunnel 443 Users UDS Tunnel (HTML5) Page 42 of 243

44 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 43 of 243

45 3.1 UDS Enterprise Platform Requirements Infrastructure requirements The infrastructure requirements needed to deploy UDS are: Virtualization platform. This will be responsible for hosting the virtual desktops generated by UDS and running the servers that make up UDS 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 platform to be deployed DHCP server. A DHCP server that enables to assign IP addresses to the virtual desktop groups created by Linked Clones is needed Network requirements In order to configure the UDS network, you must have at least 3 IP addresses to configure UDS (Broker, tunneler and MySQL Database). To setup UDS Enterprise Free Edition or UDS Enterprise Evaluation Edition you only must have 2 IP addresses (Broker 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 44 of 243

46 3.2 UDS Enterprise Platform installation UDS Database Setup 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 45 of 243

47 We configure the virtual machine s 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 46 of 243

48 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 47 of 243

49 A user with administration rights is created on the new DB using the command: grant all on database_name.* to identified by 'password'; The DB will be available to be used with UDS system. Page 48 of 243

50 3.2.2 UDS Server setup 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 don t 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 49 of 243

51 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 50 of 243

52 Step 4.- Enter the database server connection data: MySQL Server: IP address or database server DNS name MySQL Port: Connection port to the MySQL server. By default: 3306 MySQL Username: Database administrator user MySQL Password: User password previously defined MySQL Database: Database where the table structure will be created to host the data needed for the UDS platform Page 51 of 243

53 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 Page 52 of 243

54 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 53 of 243

55 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, you ll 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 54 of 243

56 3.2.3 UDS Tunneler setup Once the virtual machine that makes up the UDS tunneler is turned on, a client console will be displayed to access the virtual machine. NOTE: To configure a UDS server tunneler successfully you must configure a UDS server Broker and know its IP address. At this moment the UDS tunneler configuration process starts: Step 1.- Select keyboard input layout language. Page 55 of 243

57 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 56 of 243

58 Step 3.- Fill in connection data to UDS Broker server: Broker Address: UDS server Broker IP address or DSN name Broker Port: Communication Port with UDS server Broker. By default 443 Use SSL secure connection Page 57 of 243

59 Step 4.- Configuration of the Linux OS root user that hosts the UDS software tunneler. Fill in the following data: Password: root user`s password Step 5.- Start the UDS server tunneler configuration: Page 58 of 243

60 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 59 of 243

61 3.2.4 UDS Actor Setup In order to install UDS Actor, you must previously download in the UDS Broker the suitable Actor for each platform (Windows and Linux). 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: 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 exe: UDS Actor for Windows machines (32 and 64 bits) UdsActor-opensuse noarch.rpm: UDS Actor for Linux OpenSuse machines UdsActor noarch.rpm: UDS Actor for Linux CenOS, Fedora, RHEL, etc Page 60 of 243

62 UdsActor-2.0.0_all.deb : UDS Actor for Linux, Debian, Ubuntu, Xubuntu machines RDSActorSetup exe: UDS Actor for Windows 2012 R2 servers with RDS which will provide virtualized applications Page 61 of 243

63 Windows UDS Actor Installation Once the UDS Actor has been downloaded and it has been transferred to the template, it s time to setup it: NOTE: Before UDS Actor has been setup, you need the IP address of the UDS server Broker. In the first window, accept the license agreement: Page 62 of 243

64 In the next window, select the install location for UDS Actor: Click on Install and the UDS Actor will begin its installation process: Page 63 of 243

65 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 an user with administration rights), go to Tools section and there select Security tab and copy the code from the Master Key parameter. Page 64 of 243

66 Once these parameters have been configured, run the connection test to check the connectivity to the server 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 65 of 243

67 Linux UDS Actor Installation 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. The setup may happen to fail because of some dependencies resolution problems or conflicts. We enter the UDS server Broker address in the configuration wizard: Page 66 of 243

68 Select how communication with the UDS server Broker will be carried out. 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. Page 67 of 243

69 Click on ok. UDS Actor installation and configuration process ends here. The virtual machine is now ready to be used as a UDS virtual desktop template and can be switched off. You can modify any configuration parameter of the UDS Actor for Linux desktops in the Actor configuration file localet in: /etc/udsactor/udsactor.cfg If the desktop s base template has already a previous version of the UDS Actor, it is necessary to completely uninstall it and install the new Actor. You may follow the steps explained in this article. Page 68 of 243

70 UDS Actor Setup for Microsoft RDS 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. In the first window, accept the license agreement: Page 69 of 243

71 In the next window, select the install location for UDS Actor: Click on Install and the UDS Actor will begin its installation process: Page 70 of 243

72 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 71 of 243

73 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 72 of 243

74 3.2.5 UDS Plugin Setup In order to connect to a virtual desktop through any transport except HTML5, the connection client device must have UDS Plugin installed. In your first access to a virtual desktop, UDS will automatically recognize the Operating System the user is using to connect, and the appropiate plugin download will be displayed. We can also access the plugin s downloads window clicking on the drop down menu and selecting UDS Plugin Page 73 of 243

75 It may be that the system does not automatically detect that the UDS Plugin is already installed on your device and thus, the Plugin UDS download window is displayed. In this case, it is recommended to reboot the browser and log in again in UDS. If this issue persists, select the option WARNING: Automatic plugin detection is disabled in order to avoid automatic access to this window and to connect directly to the virtual desktop. Page 74 of 243

76 Windows UDS Plugin Setup Once the appropriate UDS Plugin is downloaded, run it to start the setup process: In the first window, accept the license agreement: Page 75 of 243

77 In the next window, choose the UDS Plugin location: Click on Install to start UDS Plugin Installation: Page 76 of 243

78 Once the installation is completed, UDS plugin will execute the connection protocol selected in the transport section to connect desktops and virtual services. Page 77 of 243

79 Linux UDS Plugin Setup Once the appropriate UDS Plugin is downloaded, run it to start the setup process: Execute the package and start setup Page 78 of 243

80 Once the installation is completed, UDS plugin will execute the connection protocol selected in the transport section to connect desktops and virtual services. If you need to uninstall UDS Plugin, execute: dpkg --purge udsclient Page 79 of 243

81 4. ADMINISTRING 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 ) 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 80 of 243

82 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 section), the selected authenticator won t be used, because this user won t 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. Page 81 of 243

83 The configuration of each "Services Pool" must be approached like the building of a puzzle, it is made up of different elements: 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. 4.1 Configuring 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 82 of 243

84 Page 83 of 243

85 4.1.1 VDI Platform with VMware vsphere Deployment of VDI platform via VMware vsphere virtual infrastructure Registering VMWare vcenter Platform Provider Service Provider Enter "Services", click "New" and select VMware Virtual Center Provider. Service Name, vcenter server IP ( Host field), a username and password with administrator rights on vcenter. We can also select Timeout in the connection with vcenter and specify a range of MAC addresses to cretate the virtual desktops. By clicking the Test button, we check if the connection has been correctly made. In a VMware Virtual Center 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 84 of 243

86 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. Page 85 of 243

87 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. 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 Configuring a service based on VMware Linked Clones Base Once the platform vsphere, where Virtual Desktops is created, a base services of type " VMware Linked Clones Base" should be created. Select the "Service Providers" in which you like to create your " VMware Linked Clones Base" and click "New": Page 86 of 243

88 Page 87 of 243

89 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 won t 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. Page 88 of 243

90 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. 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 won t 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, UDSW UDSW8-999). When saving this configuration, we already have a valid "VMware Linked Clone Page 89 of 243

91 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. 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 90 of 243

92 Page 91 of 243

93 4.1.2 VDI Platform with ovirt Deploying the VDI platform via virtual ovirt infrastructure or RedHat Enterprise Virtualization (RHEV) Registration of service provider 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 ovirtengine or RHEV-Manager. Page 92 of 243

94 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 ovirt-engine 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 ovirt. We can register as many "Service Providers" of type ovirt/rhev Platform Provider as we need in the platform UDS. Page 93 of 243

95 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 Setup 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". Page 94 of 243

96 In an ovirt/rhev Linked Clone minimal parameters to be configured are: 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. 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, Win7lab Win7lab2999). USB: If selected, virtual desktops will support USB device redirection. Display: Connection protocol of the virtual desktops deployed via Linked Clones. Page 95 of 243

97 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. Page 96 of 243

98 After the entire UDS environment has been configured (Services, Authenticators, Os Managers y 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 97 of 243

99 4.1.3 VDI Platform with Microsoft Hyper-V Deploying the VDI platform via Microsoft Hyper-V virtual infrastructure Registration of Service Provider 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 98 of 243

100 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 Hyper-V 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 Hyper-V. We can register as many "Service Providers" of type Hyper-V Platform Provider as we need in the platform UDS Page 99 of 243

101 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 100 of 243

102 Setup 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: Name: Service name. Base Machine: Template for deploying the virtual desktops. Network: Red donde se conectarán los escritorios virtuales.. Memory: Amount of memory to be assigned to the Linked Clones virtual desktops. 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 101 of 243

103 Machine Names: Root name of all of the Linked Clones virtual desktops to be deployed on this service. (eg: Machine Names= W1). Name Length: Number of digits of the counter attached to the root name of the desktops (eg: Name Length= 3, W 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 102 of 243

104 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 103 of 243

105 4.1.4 VDI Platform with Citrix XenServer Deploying VDI platform via Citrix XenServer virtual infrastructure Registration of Service Provider 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 104 of 243

106 o Advanced: Number of simultaneous tasks of desktop creation (field Creation concurrency ), 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. Page 105 of 243

107 We will be able to register all XenServer Platform Provider "Service Providers" we need on the UDS platform. 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 you re planning a maintenance stoppage Setup of 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". Page 106 of 243

108 In a Xen Linked Clone minimal parameters to be configured are: Name: Service name. Base Machine: Template for deploying the virtual desktops (Gold image). Storage SR: 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. Only shared storage is supported. Network: Network to which the desktops will be connected. Reserved Space: Minimal free space that should be available in a storage space for it to be eligible to be used by UDS. Memory: Amount of memory to be assigned to the Linked Clones virtual desktops. Shadow: Machine Names: Root name of all of the Linked Clones virtual desktops to be deployed on this service. (eg: Machine Names= W1). Name Length: Number of digits of the counter attached to the root name of the desktops (eg: Name Length= 3, W W7999). Page 107 of 243

109 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 108 of 243

110 4.1.5 VDI Platform with Nutanix Acropolis Deploying VDI platform via Nutanix Acropolis virtual infrastructure Registration of Service Provider Nutanix Acropolis Platform Provider Enter "Services", click "New" and select Nutanix Acropolis 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 109 of 243

111 o Advanced: Number of simultaneous tasks of desktop creation (field Creation concurrency ), number of simultaneous tasks of desktop deletion (field Removal concurrency ), time Timeout for the connection with with the platform Acropolis and specify the range for MAC addresses for virtual dektop creations Page 110 of 243

112 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. 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 you re planning a maintenance stoppage Setup 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". Page 111 of 243

113 In a Nutanix Acropolis Service minimal parameters to be configured are: Name: Service name. Base Machine: Template for deploying the virtual desktops. Network: Network to which the desktops will be connected. Machine Names: Root name of all the Linked Clones virtual desktops to be deployed on this service. (eg: Machine Names= W1). Name Length: Number of digits of the counter attached to the root name of the desktops (eg: Name Length= 3, W W7999). Page 112 of 243

114 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 113 of 243

115 4.1.6 VDI Platform with OpenStack Deployment of the VDI platform through OpenStack Register Service Provider 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 114 of 243

116 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. 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 we need in the platform UDS. Page 115 of 243

117 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 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": Page 116 of 243

118 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. 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. Page 117 of 243

119 o Menu 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, UDSW UDSW8-999). Page 118 of 243

120 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 119 of 243

121 4.1.7 VDI platform with OpenNebula Registration of a Service Provider for 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: Service Name, Host IP ( Host field), a username and password for oneadmin account. We can also check Use SSL in the connection with the host if this latter supports SSL connections. Nonetheless, we can specify a port number for connections with OpenNebula. By clicking the Test button, we check if the connection has been correctly made. Page 120 of 243

122 o Advanced: Number of simultaneous tasks of desktop creation (field Creation concurrency ), number of simultaneous tasks of desktop deletion (field Removal concurrency ), time 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 121 of 243

123 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 Configuring 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. Base Machine: Template for deploying the virtual desktops. 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. Machine Names: Root name of all the Linked Clones virtual desktops to be deployed on this service. (eg: Machine Names= W1). Name Length: Number of digits of the counter attached to the root name of the desktops (eg: Name Length= 3, W W7999). Page 122 of 243

124 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 123 of 243

125 4.1.8 Conexión directa a equipos persistentes Access 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, it s 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 Registration of Service Provider Static IP Machines Provider Enter "Services", click "New" and select Static IP Machines Provider. Choose a name for the Physical Machine Provider. Page 124 of 243

126 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 we need in the platform UDS. 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 Configuring service based on Physical machines Provider Once the Service Provider for persistent hardware has been created, a Base Service based on Static IP Machines Service must be registered. Select the "Service Providers" where a Static IP Machines Service is going to be created and click on "New". Page 125 of 243

127 Choose a name for the service and enter the IP addresses to which they will provide access (Machines with selected IPs should be connected and on). Click List of IPS to add IPs addresses: Enter the IP addresses of the machines to which it will have access and save the changes: Page 126 of 243

128 Upon saving we ll have a valid Physical machines accessed by IP. We ll be able to create all Physical machines accessed by IP we need on UDS platform. NOTE: The user & IP address assignation will be made according to the order of access; the first user accessing the service will be assigned the first machine (IP assigned in the list) and so on with the rest of them. We can register as many "Service Providers" of type "Static IP Machines Provider" as we need in the platform UDS. Page 127 of 243

129 If you want to assign sessions to the same machine, all you need is register same IP as many times as users you have. Page 128 of 243

130 4.1.9 RDS Application Provider Applications deployment through Microsoft Remote Desktop Services Registering Service Provider RDS Platform Provider In "Services", we click on "New" and select RDS Provider : In a RDS Provider we should type a descriptive name for the template and configure the following parameters: Name: Service name. List of servers: List of RD servers available to publish applications. User list for mappling: Users belonging to an Active Directory who will be able to log in the RDS applications servers and will be used by UDS to run an application. User`s password: Passwords of all users in the User`s password section. All users must have the same pasword. We will check the connection has been correctly made clicking on the Test button. Page 129 of 243

131 When saving this configuration, we already have a valid "Service Providers" to start creating base applications in RDS. We can register all RDS Provider Service Providers we need in the UDS platform. 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 you re planning a maintenance stoppage Setup of 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". Page 130 of 243

132 Type a descriptive name and configure the service parameters: 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) Upon saving this configuration, we have a valid " RDS RemoteAPP". We can register all RDS RemoteAP we need in the UDS platform. Page 131 of 243

133 NOTA: 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 setup and integrate RDS with UDS you can read the following document: How to setup Microsoft RDS with UDS Enterprise Page 132 of 243

134 4.2 Configuring 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 hasn t 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 Autenticación por IP). You can choose between different types of authenticators as needed by your business and platform Active Directory Authenticator This external authenticator allows access to users and groups of users, belonging to an Active Directory, virtual desktops or applications. Page 133 of 243

135 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/label (e.g: 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 243

136 o Credentials: User: User with read rights on the authenticator in the format: Password: user password Page 135 of 243

137 Clicking on the Test button, we can check whether the connection has been made correctly. Page 136 of 243

138 4.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: 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/label (e.g: 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 137 of 243

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

140 Clicking on the Test button, we can check whether the connection has been made correctly. Page 139 of 243

141 4.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: 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/label (e.g: Page 140 of 243

142 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 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: Page 141 of 243

143 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 142 of 243

144 4.2.4 IP Authenticator It is possible to assign virtual desktops to connecting devices via the IP identifier. Ex: Thin Clients in kiosk mode, Call Center environments, proprietary applications, etc... IPs work as users of other authenticators allow direct validation of customer connections in the UDS portal login. User groups in a "IP Authenticator" can range from specific ranges or entire network specific IP subnets. In an IP 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/label (e.g: Page 143 of 243

145 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 144 of 243

146 4.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 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). If the Small Name field is chosen, it only allows this authenticator to appear on the user login screen. To do this, we have to access the login screen with the following format: address_server_broker/small_name For example: Page 145 of 243

147 Page 146 of 243

148 4.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 authenticator name, the LDAP server IP ( Host field), the connection port, a username ( Ldap User field) and password with reading rights on LDAP, the name of the user and groups search base ( base field) in the format: dc=name_domain,dc=extension_domain The username (Ldap User field) must be typed in with the format: cn=user,dc=name_domain,dc=extension_domain We can also indicate 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). If the Small Name field is chosen, it only allows this authenticator to appear on the user login screen. To do this, we have to access the login screen with the following format: address_server_broker/small_name For example: Page 147 of 243

149 Page 148 of 243

150 4.3 Configuring users, user 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". Searching for user groups is done automatically in all of the defined authenticators in UDS, with the exception of Internal and by IP authenticators (Sometimes the search option doesn t work in OpenLdap or edirectory authenticators. In that case, you may indicate manually the group name in which the groups are registered and you won t be able to perform a search. To look for a group, click "Search". We can write down a root name to enclose the search. If we leave this field empty, all the available groups on the authenticator will appear. If we need to add more than one group, we ll have to do it one by one. Page 149 of 243

151 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 243

152 Los usuarios de los grupos configurados se añaden automáticamente al sistema en el momento que éstos se conectan la primera vez a la plataforma UDS, salvo en los 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, we ll have to select the authenticator. Then, in Users tab click on "New". Page 151 of 243

153 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. If we register a user that belongs to a group which is not registered in the authenticator, it will appear without group and we won t be able to use that user. Page 152 of 243

154 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 won t have an assigned group and they won t be able to be validated in the system. Page 153 of 243

155 4.3.1 Creating "Internal Database" groups and users In an Internal Database authenticator the first thing we have to do is create a group or groups of users that we will later assign 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 the group or groups of users are created, register the users and assign them to one or several groups. Select the Internal Database authenticator and in Users tab click "New". Page 154 of 243

156 4.3.2 Creating IP Authenticator groups and users 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: ) - Complete subnet: xxx.xxx.xxx.xxx\x (e.g: \24) - IP addresses range: xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx (e.g: ) 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. The IP addresses for the new users, will be automatically added to the Users tab the first time they log in. Page 155 of 243

157 In this type of authenticator an IP address is considered as a normal user with all available options. Page 156 of 243

158 4.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 157 of 243

159 4.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 won t 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 doesn t apply to persistent desktops (keep service assigned). Note: negative values or values less than 300 disable this option. Page 158 of 243

160 Page 159 of 243

161 4.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. 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 won t 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 doesn t apply to persistent desktops (keep service assigned). Note: negative values or values less than 300 disable this option. Page 160 of 243

162 Page 161 of 243

163 4.4.3 Windows Basic OS Manager A Windows Basic OS Manager is used for virtual desktops based on Windows systems which aren t part of a domain. In a Windows Basic 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 won t 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 doesn t apply to persistent desktops (keep service assigned). Note: negative values or values less than 300 disable this option. Page 162 of 243

164 Page 163 of 243

165 4.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: Name: OS Manager name. 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 don t 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 164 of 243

166 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 won t 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 doesn t apply to persistent desktops (keep service assigned). Note: negative values or values less than 300 disable this option. Page 165 of 243

167 Page 166 of 243

168 4.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: Name: OS Manager name. Account: Username with rights to add machines to the domain. Password: Password of the user of the field Account. 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 won t 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 doesn t apply to persistent desktops (keep service assigned). Note: negative values or values less than 300 disable this option. Page 167 of 243

169 Page 168 of 243

170 4.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: Name: OS Manager name. Max. Sesión time: The maximum time that a sesión will can stay open in hours (0 = illimited) Page 169 of 243

171 4.5 Configuring 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" section. Minimal parameters to provide are: Name: OS Manager name. 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: ) - Complete subnet: xxx.xxx.xxx.xxx\x (e.g: \24) IP range: xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx (e.g: ) Page 170 of 243

172 If no network is registered, access to the virtual desktops or applications will be allowed from any network. Page 171 of 243

173 4.6 Configuring 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: We can configure the "Transport" indicated as "direct" for users accesses from an internal LAN, VPN, LAN Extension, etc... We can configure the "Transport" indicated as "Tunneled" to user access through WAN. These "Transports" will be supported in the UDS Tunneler server to make the connection against the virtual desktops. The HTML5 "Transport" can be used for any type of access. This "Transport" uses the UDS Tunneler server to make the connection against the virtual desktops. To create a "Transport", in the "Connectivity" section, click "New" in "Current Transports" section. Page 172 of 243

174 Page 173 of 243

175 4.6.1 HTML5 RDP Transport A "HTML5 RDP Transport" enables access to Windows and Linux virtual desktops through RDP protocol using a browser which supports HTML5 (for Linux desktops the machines must have XRDP package installed. For Windows desktops RDP access must be setup). This transport uses UDS Tunneler server to make the connection against the virtual desktops. It must be configured beforehand in order to work properly. 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 174 of 243

176 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: (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. 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. Page 175 of 243

177 Domain: Domain name. o Parameters: Enable Audio: Enables audio redirection in the virtual machine. Enable Printing: enables printing in the virtual machines. Layout: keyboard layout to use in the virtual machine. Page 176 of 243

178 4.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: 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). Listening port: Listening port of NX software. 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 177 of 243

179 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. 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. o Parameters: Page 178 of 243

180 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 243

181 4.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: 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). Listening port: Listening port of NX software. 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 180 of 243

182 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: 443 (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. 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. Page 181 of 243

183 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 243

184 4.6.4 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: 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). Listening port: Listening port of NX software. 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 183 of 243

185 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. 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. Page 184 of 243

186 o Parameters: Allow Smartcards: Enables smartcards 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 Aero: enables widows Aero Page 185 of 243

187 Page 186 of 243

188 4.6.5 RDP Transport (tunneled) A "RDP Transport (tunneled)" 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. This transport uses UDS Tunneler server to make the connection against the virtual desktops. It must be configured beforehand in order to work properly In a RDP Transport (tunneled) 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 187 of 243

189 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: 443 (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. 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. Page 188 of 243

190 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: Allow Smartcards: Enables smartcards 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 Aero: enables widows Aero Page 189 of 243

191 Page 190 of 243

192 4.6.6 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 RDS Transport (direct) 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 191 of 243

193 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. Without Domain: states whether the user of the field Username belongs to a domain or not. Domain: Domain name. o Parameters: Page 192 of 243

194 Allow Smartcards: Enables smartcards redirection Allow Printers: Enables printing redirection Allow Drives: enables disk redirection Allow Serials: enables serial port redirection o Linux Client: Multimedia sync: Enables multimedia parameter in freerdp (Linux connection client). Use Alsa: Enables using audio through Alsa ((Linux connection client). Page 193 of 243

195 4.6.7 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: 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 194 of 243

196 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: 443 (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. Without Domain: states whether the user of the field Username belongs to a domain or not. Domain: Domain name. Page 195 of 243

197 o Parameters: Allow Smartcards: Enables smartcards redirection Allow Printers: Enables printing redirection Allow Drives: enables disk redirection Allow Serials: enables serial port redirection o Linux Client: Multimedia sync: Enables multimedia parameter in freerdp (Linux connection client). Use Alsa: Enables using audio through Alsa ((Linux connection client). Page 196 of 243

198 Page 197 of 243

199 4.6.8 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: 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 198 of 243

200 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. 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. Domain: Domain name. o Parameters: Image quality: image quality between values Adjustable Quality: if enabled, it will adjust image quality to the bandwidth. Page 199 of 243

201 Min. Adjuntable 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 200 of 243

202 4.6.9 RGS Transport (tunneled) A "RGS Transport (tunneled)" 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. This transport uses the UDS Tunneler server to connect to virtual applications and it has to be pre-configured for proper operation. In a "RGS Transport (tunneled) 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 201 of 243

203 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: 443 (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. 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. Page 202 of 243

204 Domain: Domain name. o Parameters: Image quality: image quality between values Adjustable Quality: if enabled, it will adjust image quality to the bandwidth. Min. Adjuntable 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 203 of 243

205 Page 204 of 243

206 RHEV/oVirt SPICE Transport (direct) A "RHEV / ovirt 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). In a " RHEV/oVirt SPICE Transport (direct) 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. 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 243

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

208 RHEV/oVirt SPICE Transport (tunneled) A "RHEV / ovirt 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). This transport uses the UDS Tunneler server to connect to virtual applications and it has to be pre-configured for proper operations. En un " RHEV/oVirt SPICE Transport (direct) los parámetros mínimos a configurar son: 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. 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 243

209 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: 443 (default port). o Advanced: Show fullscreen: Enables fullscreen remote display. Page 208 of 243

210 4.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 Configuring Calendars To create a "Calendars" in the Calendars menú click on "New". Give a descriptive name to your calendar. Page 209 of 243

211 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 210 of 243

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

213 Habilitar o denegar accesos de usuarios 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 212 of 243

214 Configurar acciones Programadas: 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" Ajustar servicios iniciales: Re-ajuste de los escritorios virtuales creados inicialmente por el sistema. Estos escritorios estarán configurados y listos para su asignación a un usuario. Ajustar el tamaño de la caché: Re-ajuste de los escritorios virtuales disponibles siempre en la cache del sistema. Estos escritorios estarán configurados y listos para su asignación a un usuario. Cambiar el número máximo de servicios: Modifica el número máximo de escritorios virtuales, en el pool de servicios, creados por el sistema. Ajustar el tamaño de la caché L2: Re-ajuste de los escritorios virtuales disponibles siempre en la cache de nivel 2 del sistema. Estos escritorios estarán configurados y en modo de suspension. Publicar: Creación de una nueva publicación del servicio. 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 213 of 243

215 Upon saving, we have a schedules task that can perform real actions on a service pool. Page 214 of 243

216 4.8 Configuring 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 access 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". For creating 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 215 of 243

217 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 216 of 243

218 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". When we save the creation of a "Service Pool" and if we have selected the option "Publish on creation", the system will start the publication of the service generating the base machine on which the virtual desktops will be deployed. Clicking the "Delete" button, we will be able to completely delete a "Service Pool" and clicking Edit" we will be able to change the service pool name, the image associated to the service, the access to all transports and all system cache values (Initial available services, Services to keep in cache, Services to keep in L2 cache and Maximum number of services to provide). But the "Base Service" and "OS Manager" can t be modified once the Service Pool is created. Page 217 of 243

219 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 we ll 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 o o In Preparation: The virtual desktops are being created in the virtualization platform Waiting OS: The virtual desktops are being configured with the parameters indicated in the OS Manager Valid: Virtual desktop available to be used Page 218 of 243

220 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 219 of 243

221 Select the Transport" we want to use in this "Service Pool" and save. Publications: In this menu we will be able to make a new service publication. Once the publication process has finished, the whole system cache with the new Linked Clones based on this last publication will be regenerated If we make a new publication, a new base machine will be generated and once it is available, the system will delete the virtual desktops from the previous version and it will generate new ones based on the new publication. Page 220 of 243

222 4.9 Configuring Permisions 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 : 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. Page 221 of 243

223 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. 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 222 of 243

224 5. ACCESSING VIRTUAL DESKTOPS AND SERVICES 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. Page 223 of 243

225 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 pulldown 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: Page 224 of 243

226 To start the connection with the virtual machine, you need to have the UDS plugin installed on the client machine (if not installed the system will provide the suitable version for your OS) to start the connection to all transport except for HTML transport. In order to connect to the virtual desktop or application you need to have the client of each used protocol (client RDP, NX, RGS or SPICE) installed example of RDP connection: Example of HTML5 connection: Page 225 of 243

227 Example of NX connection: Once the connection is made, the virtual desktop will be available. Page 226 of 243

228 6. UDS ENTERPRISE ADVANCED CONFIGURATION 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 aren t 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 isn t included in this section, we recommend you to contact the UDS Enterprise support team in order to verify that change and confirm that it doesn t affect in a negative way to the running of UDS system. Page 227 of 243

229 6.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 228 of 243

230 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 229 of 243

231 Page 230 of 243

232 6.2 Services 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": 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. Page 231 of 243

233 Una vez creado el Service Pool Group estará disponible para su asignación a un Service Pool (para más detalles acceda al punto 4.7). Once created, the "Pool Service Group" will be available for allocation to a "Service Pool" (for details go to 4.7). Page 232 of 243

234 6.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, we ll obtain a list of users belonging to that authenticator: Page 233 of 243

235 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 Once the report is generated, you ll get a graphic and a list with all users accesses: Page 234 of 243

236 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: Once the report is created, you ll get a graphic and a performance list of the selected Service Pool : Page 235 of 243

237 Page 236 of 243

238 6.4 UDS Advanced Parameters In order to access the UDS advanced configuration parameters, access Tools section and click Configuration : 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 won t 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 won t appear (0 = off 1 = on). Page 237 of 243

239 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 html 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 isn t 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 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. Page 238 of 243

240 Default value 0. IDP Metadata Cache = Time the IDP.m searched metadata are kept. Default value 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 seconds (30 days) IPAUTH These variables are inactive in this UDS Enterprise version 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 CLUSTER These variables are inactive in this UDS Enterprise version 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. Page 239 of 243

241 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: arameters.pdf ENTERPRISE Find below the description of the parameters related to UDS Enterprise subscription: 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 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 seconds (4 hours). AllowRootWebAccess = It allows the root user login via web (0 = off 1 = on). The modification of this variable doesn t affect the root user access through the administration client. Default value 1. Page 240 of 243

242 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 seconds (4 hours) 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 won t be created. Once this value is modified or the needed space is available, the system will work properly. Default value 30. Page 241 of 243

243 6.5 Flush System Cache In order to flush the UDS system s 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 242 of 243