Una vez solicitado los servicios de SRD debido a la utilización o necesidad de la virtualización de aplicaciones bajo nuestra tecnología y utilizando SoaX como motor de virtualización, se proporcionará al Usuario vía correo electrónico las credenciales de acceso del usuario admin sobre la compañía o compañías necesitadas por el usuario.
La estructura de SRD permite una gestión multi-cliente permitiendo segmentar nuestros entornos por compañías y poder aplicar distintas políticas de acceso, licencias y nombres entre sí. El cliente podrá solicitar tantas compañías como necesite gestionar bajo su entorno de administrador.
Las licencias concurrentes de SRD se aplican a nivel de compañía y no se pueden mezclar entre sí. Podremos escalar tanto hacia arriba como decrecer en el número de licencias concurrentes por compañía. OasiX facturará la suma o total de licencias concurrentes asignadas a cada una de las compañías.
Para acceder a la plataforma de gestión deberá de hacerlo a través de la siguiente URL: https://workspace-os.oasixcloud.es/ovd/admin/ donde le aparecerá un login como el siguiente:
Para acceder como administrador deberá proporcionar las claves que se le suministraron en el momento del alta vía correo electrónico.
Al acceder a la plataforma veremos las distintas compañías que tengamos dadas de alta. En caso de tener una única nos aparecerá directamente la capa de gestión de la compañía.
Como vemos en la imagen cada compañía se identifica con 4 campos:
En el momento de solicitar la puesta en marcha del servicio, para que el equipo técnico de OasiX pueda dar de alta una nueva compañía, se solicitará al cliente los datos mencionados anteriormente. Una vez recibido estos datos, se procederá a crear un nuevo tenant y se asignará un usuario administrador para que pueda gestionarlo bajo su panel de cliente.
Para poder gestionar cada una de las compañías pulsaremos sobre el botón “Select” lo que entraremos en modo gestión y visualizaremos el entorno únicamente de este cliente. Si queremos volver hacia el modo vista Global pulsaremos sobre el botón “Back to global view”.
Sobre el apartado Servers aparecerán todos los servidores que disponemos bajo nuestras empresas. Si accedemos a servers desde la vista de compañía veríamos únicamente el entorno de virtualización dedicado para esa compañía. Si pulsamos sobre ese servidor podremos definir los parámetros como nombre, IP o RDP port. Una vez tengamos ese APP Server bajo una de nuestras compañías podremos extenderlo a otras desde este menú como se ve en la imagen siguiente:
En el apartado usuarios (“Users”) vamos a poder tener la capacidad de poder crear, editar agrupar y borrar los usuarios que posteriormente tendrán acceso a la OVD de Inuvika. A continuación, procederemos a explicar cómo crear un usuario, posteriormente los grupos de usuario y por último, los grupos de aplicaciones.
La cantidad de usuarios que se permite crear en una compañía es ilimitada pero únicamente van a poder iniciar sesión en la plataforma de manera simultánea el número de usuarios equivalente a las licencias concurrentes aplicadas en la misma.
Una vez tenemos generados nuestros distintos grupos de usuarios podremos aplicar configuraciones avanzadas pulsando sobre el nombre del mismo. Podremos definir un grupo como default, añadir usuarios a este grupo o incluso aplicar políticas de permisos o aplicaciones sobre el grupo de usuarios en concreto.
Para poder ver cada uno de los servidores que tenemos disponibles pulsaremos sobre el botón Servers. En el aparecerá una tabla resumen con las características de cada uno de los servidores donde encontraremos:
Como vemos los Roles de los servidores se pueden agrupar en tres.
Podremos acceder a cada uno de estos servidores y gestionar o cambiar el DisplayName para cambiarlo por un nombre identificativo del servicio al igual que podríamos llegar a cambiar el RDP Port de nuestro equipo.
En este apartado también podremos extender un servidor en concreto que tenemos en una compañía a otras compañías bajo nuestro panel. Simplemente pulsaremos sobre la opción: “Shared with following tenants” y añadiremos a las compañías que deseemos.
SRD ofrece la posibilidad de agrupación lógica por servicios de los servidores de aplicaciones. Si pulsamos sobre Servers-> Server Groups podremos crear un grupo de Servidores como aparece en la imagen siguiente. Sobre este grupo asignaremos los servidores que queremos que pertenezcan y por último el grupo de usuarios que queremos publicar estos servidores.
Mediante el panel de aplicaciones (“Applications”), vamos a poder administrar los programas que tenemos instalados en los File Servers de nuestro dominio.
En la primera pestaña “Applications”, tendremos un listado con las aplicaciones que están disponibles en las máquinas App Servers de nuestro dominio. A parte se nos indica para que sistema operativo están destinadas.
En caso de que necesitemos instalar aplicaciones adicionales una vez desplegados nuestros App Servers, deberemos reiniciar las máquinas accediendo a ellas mediante la consola remota de SoaX. De esta forma, al reiniciarse los servicios de Inuvika en nuestro App Server, Inuvika escaneará de nuevo las aplicaciones instaladas en la máquina y por tanto se mostrarán en el panel de gestión de aplicaciones.
En ocasiones, existen programas o archivos ejecutables que, por la ruta o extensión del archivo, Inuvika no va a ser capaz de poder detectarlos de manera automática. En otros casos, es posible que determinadas aplicaciones por su forma de trabajar, requieran de una parametrización específica. Este apartado resuelve todos estos problemas ya que vamos a poder crear accesos directos a aplicaciones para que puedan ser ejecutadas.
Para ello tendremos que indicar primeramente en que sistema operativo se ubica nuestra aplicación (Windows o Linux). Acto seguido indicaremos un nombre para la aplicación estática, una descripción y la ruta exacta del directorio donde se encuentra la aplicación. En el momento que presionemos en “Add”, se agregará automáticamente al panel de gestión de aplicaciones.
Una vez creada la aplicación estática, tendremos la posibilidad de poder modificar sus parámetros (Nombre, Descripción y Ruta) como también la posibilidad de agregar un incono de aplicación.
Por último, tendremos que dirigirnos al apartado de “Servers with this Application” y en el menú desplegable tendremos que seleccionar el App Server donde se encuentra la aplicación.
A continuación, veremos como distribuir las aplicaciones a nuestros usuarios. Para ello vamos a hacer uso del Asistente de Publicación de Aplicaciones. Mediante este asistente vamos a poder conceder a nuestros usuarios el acceso a las aplicaciones que se encuentran dentro de los App Servers.
Lo primero que nos pedirá el asistente es que creemos un grupo de usuarios o que seleccionemos uno ya existente al que daremos acceso a las aplicaciones. Para este ejemplo, hemos procedido a crear un grupo de usuarios para los comerciales de una empresa. Lo hemos llamado “Comercial”.
Para este ejemplo, hemos procedido a crear un grupo de usuarios para los comerciales de una empresa. Hemos procedido a llamarlo “Comercial”.
El siguiente paso es seleccionar las aplicaciones a las que tendrán acceso los usuarios de dentro del grupo que hemos creado o seleccionado y presionaremos “Next”.
Estas aplicaciones que hemos seleccionado en el paso anterior, se incrustarán dentro de un grupo de aplicaciones. A continuación, procederemos a proporcionar un nombre y una descripción para este grupo. Para este ejemplo, hemos creado un grupo llamado “App-Comerciales” con una serie de aplicaciones que solamente estarán disponibles para el grupo de “Comerciales”
En el último apartado del asistente de publicación de aplicaciones veremos un resumen de lo que hemos configurado. Para finalizar pulsaremos en “Confirm”.
Por último, en la pestaña de publicaciones (“Publications”) podremos asociar los grupos de usuario con los grupos de aplicaciones. A parte, podremos visualizar todas las publicaciones que tenemos activas. Para asociar una publicación nueva, seleccionaremos tanto el grupo de usuarios como el grupo de aplicaciones mediante las listas desplegables. Para guardar los cambios presionaremos en “Add”. También tenemos la posibilidad de asociar las aplicaciones de un grupo de usuarios a un grupo de servidores.
En este apartado el cliente podrá observar los perfiles que existen en su dominio. Si hacemos click sobre el nombre de usuario, nos redirigirá al apartado de usuarios, en concreto, a la modificación del usuario que en este caso sería “David Navarro”.
Tenemos la posibilidad de poder crear directorios compartidos de tal forma que los grupos de usuarios puedan alojar archivos a modo de repositorio. Una vez accedamos al escritorio remoto de Inuvika, estas unidades compartidas se mostrarán en el apartado de unidades de red en Windows.
En este panel podremos gestionar las unidades compartidas que tengamos creadas, o en su defecto, crear una nueva. Para crearla, introduciremos un nombre para la nueva unidad compartida en el cuadro de texto y posteriormente presionaremos en “Create this shared folder”. Si hacemos click sobre una de las unidades compartidas, accederemos a la configuración de sus propiedades.
En el apartado de “Servers” podremos visualizar los servidores que tienen acceso a esta unidad de red compartida. Si proseguimos, en el apartado de configuración podremos modificar el nombre de la unidad y la capacidad de almacenamiento de la unidad. Por último, tendremos que seleccionar que grupo de usuario, tendrán acceso a esta unidad, para ello, no dirigiremos al apartado de publicaciones “Publications”. En la primera lista desplegable seleccionaremos el grupo de usuarios que podrá tener acceso y en la segunda lista desplegable seleccionaremos los permisos que tendrán sobre la unidad (Sólo lectura / Lectura y escritura)
Al igual que hemos visto que podemos crear unidades de almacenamiento compartido para nuestros usuarios dentro de los File Servers, tenemos la posibilidad de conectar una unidad de almacenamiento en red externa. Esta unidad puede ser montada en un servidor externo y permite que los usuarios tengan acceso a ella una vez dentro del OVD de Inuvika.
Para ello nos dirigiremos al apartado de “External Data Storage” y se nos abrirá un panel de configuración donde veremos las unidades disponibles y más abajo un formulario para agregar una nueva unidad. A continuación, veremos como rellenar estos campos:
OVD Session Folder: Indicaremos un nombre para la unidad.
Type: Seleccionaremos el tipo de unidad de almacenamiento externa. Las opciones son NFS, CIFS, WebDAV, WebDAVS, y Weka (disponible para las versiones OVD 2.8.0 y posteriores). A excepción del NFS, el resto de protocolos exigirán autenticación. En ese caso necesitaremos completar los siguientes campos:
URI: Indicaremos la dirección IP de la unidad de almacenamiento seguido de la ruta del directorio principal (raíz) donde se podrán almacenar los archivos.
Parameters (Linux Application Server Only): Se pueden especificar parámetros adicionales que se transferirán a los App Servers de Linux. Estos parámetros se utilizarán en la sesión de usuario y se agregarán al comando de montaje emitido por el servidor de aplicaciones. Esta configuración se aplica solo a los App Servers de Linux.
Por último, vamos a ver el panel de gestión de sesiones. Este apartado nos permite configurar ciertos parámetros para los usuarios que accedan al cliente OVD de Inuvika. También tenemos la posibilidad de poder integrar un script para que este se ejecute cuando el cliente inicie la sesión, con el fin de poder automatizar ciertos procesos.
En este panel, podremos configurar los parámetros de la sesión, a continuación, vamos a ir revisando cada uno de los apartados:
Users can still launch a sesión when some of their published applications are not available: Los usuarios podrán iniciar sesión incluso si una de las aplicaciones publicadas no está disponible.
Users can still launch a sesión when some of their login scripts are not available: Los usuarios podrán iniciar sesión incluso si los scripts de inicio de sesión no están disponibles.
Use known drives: Permite abrir los archivos en el propio servidor en vez de retransmitirlo por el RDP
Bypass server restrictions: Si todos los huecos de sesiones disponibles están ocupados, con esta opción evadimos las restricciones de conexión.
Remote audio playback: Permite reproducir en el dispositivo local el audio del escritorio remoto.
Remote audio recording: Permite grabar audio del equipo local para que sea recogido por el equipo remoto.
Redirect client drives: Para el EDC, la sesión de usuario se puede configurar para que no tenga acceso a ninguna unidad cliente, acceso parcial o acceso total. El acceso parcial permite el acceso a las carpetas específicas del usuario en el dispositivo cliente, como Escritorio, Documentos, Imágenes, etc. en la sesión de OVD, pero el acceso a unidades USB, unidades de red y unidades locales no está disponible. El acceso completo permite el acceso a las carpetas específicas del usuario en el dispositivo cliente, así como el acceso a unidades USB, unidades de red y unidades locales. En el caso del cliente HTML5, la configuración puede ser no tener acceso a ninguna unidad del cliente, lo que deshabilita la capacidad de cargar y descargar archivos desde/hacia una unidad local; o acceso total o parcial, en cuyo caso se habilita la capacidad de cargar archivos desde cualquier unidad y descargar archivos. Para el cliente iOS, la configuración no se aplica. Para el cliente de Android, el acceso a una unidad SD se puede controlar a través de esta configuración. La configuración predeterminada es “full”.
Clipboard redirection: Permite la copia y pega entre equipo local y remoto.
Synchronize IE cookies: Permite la sincronización de las cookies de Internet Explorer.
RDP bpp: Ajuste de la profundidad de color del escritorio remoto.
Enhance user experience: Permite activar la mejora de la calidad de los efectos de vídeo.
Remote FX capabilities: Permite activar las animaciones de Windows
Multi-monitor support: Permite activar la función de monitor extendido
Use local IME integration: Permite la integración de teclados con caracteres asiáticos.
Client will download all application icons in an archive: Los iconos de las aplicaciones asociadas con el OVD de Inuvika se descargarán en un solo archivo, activando esta opción podría reducir el tiempo de inicio de una aplicación.
Delay before displaying desktop in application mode: En el modo aplicación, esta propiedad permite especificar un tiempo de espera a la hora de mostrar el escritorio remoto por si las aplicaciones aún no están listas para ser iniciadas en la sesión.
Faster applications installation on desktop in external apps: Si configuramos este valor en “yes”, permitirá que el icono de la publicación de la aplicación remota se muestre inmediatamente para que el usuario no tenga que esperar a que el servidor OAS proporcione el estado. Si el usuario ejecuta una aplicación que no está lista para usar, se mostrará una barra de progreso hasta que la aplicación esté lista.
Sessions are persistent: Si activamos esta función, la sesión persistirá cuando un cliente se desconecte, incluso si es provocado por un fallo de conexión.
Follow me: Permite restablecer la sesión desconectada en un dispositivo diferente. Para que esto funcione, las sesiones persistentes deben estar habilitadas.
Persistent user profiles: Esta configuración permitirá que el perfil de usuario se guarde en el File Server después de que finalice la sesión. Se puede integrar un sistema de almacenamiento externo en el servidor de archivos OVD para almacenar datos de perfil de usuario.
User profiles data storage limitation (quota): La configuración predeterminada de cero significa que no hay límite en el tamaño del almacenamiento del perfil. Si establecemos un valor, definiremos la cantidad máxima de almacenamiento de datos que se asignará a un perfil de usuario. La cuota se puede definir como un valor entero con o sin una unidad de almacenamiento. Si no se especifica la unidad, se asumen bytes. La unidad de almacenamiento se puede especificar como Kilobyte, Megabyte y Gigabyte.
SMB version used to mount external resources: SMB es un protocolo para compartir archivos. La configuración predeterminada, 2.1, ofrece la posibilidad de acceder a todos los sistemas recientes. Los valores posibles son:
Auto-create user profiles when non-existent: Si configuramos este valor en “yes”, creará un perfil de usuario predeterminado en el primer inicio de sesión.
Launch a session without a valid profile: Si configuramos este valor en “no”, no se permitirá que se inicie una sesión de usuario si un perfil de usuario está dañado.
Enable shared folders: permite asignar carpetas compartidas a una sesión de usuario del OVD. Esto requiere el uso de un servidor de archivos OVD (OFS) para proporcionar almacenamiento para las carpetas compartidas o para que una carpeta se asigne como una unidad de red compartida.
Launch a session even when a shared folder's fileserver is missing: Permite que se inicie la sesión de usuario si la carpeta compartida no está disponible. Si el valor se establece en no, la sesión no se iniciará si la carpeta no se puede asignar.
Launch a session even when an External Data Storage mapping is not available: Permite que se inicie la sesión del usuario si la carpeta Almacenamiento de datos externos no está disponible. Si el valor se establece en no, la sesión no se iniciará si la carpeta no se puede asignar. En ambos casos, se registrará un mensaje de error.
Publish AD Roaming Profile as Shared Folder: Cuando se utilizan perfiles OVD con usuarios de dominio, es posible tener acceso al perfil móvil si existe. Esta opción también está disponible en servidores de aplicaciones Linux.
Version of the Roaming Profile to publish: De forma predeterminada, los perfiles móviles se gestionan por versión. Se agrega un sufijo a las rutas del perfil de usuario para distinguir la versión de Windows. Las versiones compatibles con Windows son:
Roaming Profile Shared Folder name: Cuando se activa la opción anterior, es posible especificar el nombre asignado al directorio utilizado para el perfil de “roaming”.
Minimum number of FS Cluster servers required for a session: Cuando esta función está activa, define cuantos nodos de un clúster de File Servers han de estar operativos para que el usuario pueda iniciar sesión
Redirect Smart card readers: OVD brinda soporte para lectores de tarjetas inteligentes dentro de una aplicación de Windows para Enterprise Desktop Client en Windows y Linux. La compatibilidad con Linux puede variar según el hardware específico que se utilice. El cliente HTML5 y otros clientes no admiten la redirección de tarjetas inteligentes.
Enable Remote Desktop: Permite el acceso mediante escritorio remoto.
Show icons on user desktop: Permite mostrar los iconos de las aplicaciones remotas en el escritorio del equipo local.
Allow external applications in Desktop: Al iniciar una sesión de escritorio, si existen aplicaciones publicadas que no se puedan ejecutar en el mismo servidor (por ejemplo: Linux + Windows), esta configuración define si la sesión incluirá aplicaciones externas en el escritorio o no.
Desktop type: Selección de tipo de escritorio Windows / Linux
Servers which are allowed to start desktop: Especifica el conjunto de servidores que se pueden proporcionar escritorios a los usuarios. Si no se especifica ningún servidor, se utilizará el primer servidor disponible para proporcionar un escritorio. Tendremos que ingresar el nombre del servidor o el nombre interno (FQDN) de los servidores que están asignados para proporcionar sesiones de escritorio. Esta información se encuentra en la sección Configuración del servidor y se puede mostrar haciendo clic en la pestaña principal Servidores y luego seleccionando el servidor individual.
Enable Remote Applications: Permite iniciar la sesión en el modo aplicación.
Provision applications with a native Windows experience: Las aplicaciones remotas que ejecutemos en el modo Aplicación, se mostrarán con el mismo aspecto que las aplicaciones que tengamos instaladas en nuestro equipo local.
Enable access to File Server data folders from the Web Access component: Habilita el acceso a las carpetas de datos del File Server desde el componente “Web Access”.
CPU Priority: Establece una prioridad relativa del tiempo de CPU disponible para una sesión. Por ejemplo, dos sesiones que tengan la prioridad establecida en normal recibirán el mismo tiempo de CPU, pero una sesión que tenga la prioridad establecida en alta recibirá 2 veces más tiempo de CPU. En la API, estos valores están representados por valores numéricos:
CPU Allocation: Establece Límite un límite de tiempo de CPU que una sesión no puede exceder.
Memory Allocation (RAM): Establece la cantidad máxima de memoria de usuario (incluida la caché de archivos). Si no se especifican unidades, el valor se interpreta como bytes. Sin embargo, es posible usar sufijos para representar unidades más grandes: k o K para kilobytes, m o M para megabytes y g o G para gigabytes.
Memory Allocation (RAM and Swap): Asignación de memoria (RAM e intercambio): establece la cantidad máxima para la suma del uso de memoria e intercambio. Si no se especifican unidades, el valor se interpreta como bytes. Sin embargo, es posible usar sufijos para representar unidades más grandes: k o K para kilobytes, m o M para megabytes y g o G para gigabytes.
Ej: configurar memory = 2G y memory+swap = 4G permitirá que una sesión asigne 2 GB de memoria y, una vez agotada, asigne otros 2 GB de intercambio solamente.
Per Session Process Isolation: Asegura que un usuario no pueda enumerar los procesos de otras sesiones. Esta opción debe configurarse para hacer visibles las restricciones de memoria definidas para una sesión. Este aislamiento solo es compatible con servidores Ubuntu.
Advanced System configuration: Las restricciones de Linux se basan en el control de recursos systemd. Debido a que la consola de administración no ofrece todas las restricciones disponibles con systemd, este campo hace posible declarar reglas systemd adicionales utilizadas en el archivo de segmento de usuario (consulte la página de manual de systemd.resource-control). Por ejemplo, podemos especificar la siguiente regla:
MemoryMax=300M
MemorySwapMax=300M
CPUQuota=20%
Otra de las características que se nos ofrece, es la posibilidad de introducir scripts que se ejecutarán cuando el usuario inicie sesión, de este modo, podremos automatizar procesos como ejecutar de manera automática aplicaciones que se encuentren dentro de nuestro App Server. Para añadir un nuevo script tendremos que rellenar los siguientes campos.
En “Name” introduciremos el nombre del nuevo script que vamos a implementar. En “OS” tendremos que indicar el sistema operativo de la máquina donde se va a ejecutar el script. Por último, indicaremos el lenguaje del script y en el cuadro de texto procederemos a escribir o pegar el script deseado.
También tenemos la posibilidad de importarlo, para ello presionaremos el botón de “Seleccionar archivo” y seleccionaremos el script que queramos importar de nuestro equipo local.
Para guardar el script y aplicar los cambios, presionaremos el botón “Add Script”.
Al iniciar sesión en el escritorio remoto de Inuvika, veremos que este cuenta con un fondo por defecto con la marca de Inuvika. Este fondo podemos modificarlo con el branding de nuestra empresa para dar un aspecto más profesional a nuestro entorno virtual de trabajo.
A continuación, veremos como hacerlo tanto en Windows como en Ubuntu:
El formato de la imagen debe ser “.jpg” con una resolución de 1024 píxeles de ancho por 768 píxeles de alto.
El formato de la imagen debe ser “.png” con una resolución de 1024 píxeles de ancho por 768 píxeles de alto.
Puede seguir viendo más información, acceda a la página de guías de SoaX Remote Desktop