Skip to content

Examples of Desktop Pools

The earlier sections covered desktop pool configurations, types, creation, and management topics in detail. This section will specify some examples of desktop pool creations.

The HyWorks administrators can use these example configurations to create desktop pools to satisfy the deployment needs.

  1. Common Configurations: Configurations that will be common across the desktop pools of different types.

  2. Critical Configurations affecting deployment type: Configurations that will affect the whole deployment of desktops in HyWorks.

Common Configuration

Common Configurations of General Screen

  1. Name: The name of the desktop pool shown to end-users when they log in if configured under Advance Configuration > Display Preferences.

  2. Display Name: The name of the desktop, which can be the same or different from the name. As per configurations in Advance Configuration > Display Preferences, this can also be shown to end-users.

  3. Description: To provide logical details of the desktop pools.

  4. Connection Profiles: To assign a specific connection profile for the desktop pool. Connection attributes will be decided as per the provided connection profile.

  5. Active: To mark the desktop pool as active or inactive. For inactive desktop pools, HyWorks stops processing desktops and does not provide access to clients on logon from inactive desktop pools.

  6. Maintenance Mode: To enable maintenance mode in the desktop pool. In maintenance mode, HyWorks continues processing the desktops but does not provide access to the end users. The Purpose of maintenance mode is to restrict the user's access to the desktop pool during deployment, redeployment, or maintenance activities.

  7. Remote Desktop Connection Port: The port number of the virtual desktops on which the client will initiate a remote connection. The default value is 3389. The port change has to be done on virtual desktops first, and then the same should be configured in the desktop pool wizard.

Clients (Users/Devices) Screen

Devices/Users: A screen for devices or users will appear based on the Entitlement Type selected. The screen can add or remove devices, users/groups, or OUs.

Important Points for Adding Groups or OUs as a Client:

  1. If groups or OUs are being added as clients for permanent dedicated Desktop Pools, assignments should be kept Automatic, as one virtual machine can be assigned to only one user (client) at a time.

  2. If the assignment is kept manual, then none of the users (members of the added group/OU) will be given a session of the desktops as the assignment is manual.

Desktop Assignment

Assignment happens automatically, or the administrator should manually assign desktops to different clients.

  1. HyWorks assigns the desktop automatically, using its mechanism to identify the best desktop pool.

    • The default mechanism for provisioned desktop.

    • Should be used when trying to entitle desktops to groups/ organizational units.

  2. Meanwhile, in manual assignment, the administrator will be required to assign desktops to the clients.

    • It can be used for the desktop pool with existing VMs.

Important

The Desktop Assignment screen is not displayed while creating the desktop pool through Dynamic Desktop Provisioning. This is because all the cloned VMs will have the same configurations, and the assignment will be done automatically for the clients, i.e., users or endpoints (based on the configured Assignment Type).

Classification Rules

Configure the Classification Rules to restrict desktop access to users connecting from specific classified devices. Refer to the Classification Rules section to enable restricted client group access.

  1. Select the access policy from specific classification rules only.

  2. It will list the added classification rules.

  3. Select the classification rules and move them to the allowed list.

  4. End-points satisfying the classification rules settings can now access the desktops from this pool.

Advanced Configurations

The following advanced configurations are commonly configured for users:

  1. Keep desktops in power-on state: Configurations to set if the associated desktops should also be powered on. The Administrator can have the following options:

    1. Not configured: Desktops will remain powered on as managed by the Administrator or users.

    2. All Desktops: All desktops are to be kept powered on.

    3. Specified Desktops: Minimum number of desktops that should be kept powered on perpetually.

  2. Power on state timing: If the option Keep desktops in power on state is set as All Desktops or Specified Desktops, then this option will get enabled. This option can be used to specify the time when the desktops should be checked as being powered on and should be turned on if found powered off. The possible configurations can be:

    1. Always: This option helps keep the specified desktops or all of them powered on perpetually.

    2. Before Specified Timing: This field, to be entered in HH:MM:SS format, specifies when the desktops will be powered on if they are found powered off. The HyWorks Controller starts turning the desktops’ power on before the specified time so they are ready before the specified time.

  3. Power action when the user logs off: This setting specifies what action will be taken by the HyWorks Controller once the user logs off their session. Possible actions can be:

    • Not Configured: Do not take any action.

    • Power Off: Power off the desktop once the user has logged off the session.

    • Suspend: Suspend the desktop once the user has logged off the session.

    • Restart: Restart the desktop when the user logs off.

    • Shutdown: Shut down the desktop when the user logs off.

    Important

    The setting Power action when the user logs off will not be enabled when the Keep Desktops in Power On state is configured as All desktops because keeping all the desktops in the Powered on state will contradict the settings related to Power actions when the user logs off.

  4. User Permission (Add user to the local Administrator group): Selecting this option will make the logged-in user a member of the local Administrator group on the target Desktop. Unchecking this option will not modify user privileges on the desktops.

  5. Dedicated Linux VM Pool: This is a special configuration for Linux-based dedicated desktops delivered to end users.

  6. Use last known good IP address: This specific advanced setting enables HyWorks to use the desktop's last cached good IP address if it does not receive the IP address from the Session Provider.

  7. Assign Network Ready Desktops: A specific advanced setting that will enable the delivery of only those desktops that are found ready for a desktop connection based on the reachability of the configured RDP port. If enabled:

    1. The HyWorks Controller checks the reachability of desktops in virtual machines periodically.

    2. If any desktop virtual machine is found unreachable on the RDP port, it will not give sessions from that machine to the end-user.

  8. Assign Desktop: This option gets enabled if the assignment type is Floating Desktop. There are 2 Types:

    1. On Login: Desktop will be assigned when the user logs in.

    2. On Connect: Desktop will be assigned when the user clicks on desktop (shows at the HyWorks client's end). The following settings will be enabled for the On Connect option:

    3. Unassign disconnected desktop after(Min.): Remove assignment after the mentioned timeout on RDP disconnect.

      Remote session disconnections to the assigned desktop will result in the assignment being removed after a specified time limit. Value can not be empty. If specified as zero, assignments will be removed when the user logs out.

    4. Unassign on VDI Logoff: This feature is only supported with HyWorks configurations in Hybrid mode. Enable this option to release user assignments from the desktop VM when the remote session logs off.

    ​ Note: If the desktop agent is unreachable, the assignment will be released according to the Unassign Disconnected Desktop timer.

  9. Auto upgrade desktop agent: This will be used to upgrade HyWorks DVM tools. All desktops will be notified about desktop agent upgrades and will be upgraded as per the available version of DVM Tools. The following additional configurations can be done:

    1. HyWorks Desktop Agent: For upgrading the desktop agent.

    2. HyWorks Printing Module: To be enabled to upgrade the HyWorks printing module.

    3. HyWorks USB cleaner: To upgrade the HyWorks USB cleaner utility.

    4. HyWorks USB Redirection Driver: For upgrading the built-in USB redirection driver (server side) module.

    5. Reboot if required: Select this option if the desktop VMs can be rebooted after upgrading the DVM tools.

    The admin can choose to upgrade a specific component or all components. This option is usually enabled after the desktop pool is created when the HyWorks DVM Tools need to be upgraded.

    The Administrator should configure appropriate Advance settings based on the requirements on the Advance screen and can move to the Summary screen to verify the configured options.

  10. Display Preferences for Desktop Pool Name to End-users: Suppose the end-users should be given a different display name for the desktop pool than the one displayed to the Administrator. In that case, a configuration is provided in the desktop pool to allow for this. To achieve this, HyWorks v3.3 has two configurations for the desktop pool:
    1. Name
    2. Display Name, with the Advanced Configuration, to specify which field should be displayed to the end users.

  11. Virtual Desktop Connection Method There are two Virtual Desktop Connection Methods:

    1. Remote Desktop: Default connection method to provide remote access to end-user. More options are available to use:

      1. All users connecting to the desktop pool use a common username, password, and domain name. Personal desktop delivery supports specifying a username, password, or domain; only the domain name can be specified for shared hosted desktop pools.

    2. Hypervisor Console The Hypervisor Console Connection Method specifies the user's login credentials for the Console connection to the Virtual Desktop. These can be the logged-in user credentials specified in the domain or specified by the user on the login screen.

      The feature enables users to connect to the Console for VMs running on Hyper-V, ESXi, and Virtual Center Hypervisor, allowing users to connect to desktops even when the network is unavailable on the VMs.

      This feature is available for Hyper-V, ESXi, and Virtual Center session providers, where the VM’s console session can be connected. Enabling this feature will require the following conditions to be met:

      Hyper-V -

      1. The Provider must be a Hyper-V server.

      2. Valid user credentials to connect to the VM console.

      3. Required user credentials - Username, Password, Domain, Port

      4. Port 2179 must be accessible from the endpoints to the Hyper-V server.

      5. This feature must be supported on the HyDesk Hy3000/Hy4000, Windows Clients, Hy1000, Ubuntu Clients.

      6. Hy2000 HyLite does not support the Console Connect feature.

      ESXi and Virtual Center

      1. The Provider must be an ESXi or a Virtual Center.

      2. User credentials must be able to connect to the VM console.

      3. Required user credentials - Username and Password of ESXi or vCenter Server.

      4. The default port supported by 433 and 902 must be accessible from the endpoints to the ESXi or Virtual Center server.

      5. The feature is supported only on Windows Clients.

      6. HyLite does not support the Console Connect feature.

Refer to this section for detailed information on the Console Connection.

  1. Site Association

    Now, every pool is associated with either a local or remote site. The site association option is available for all types of pools, such as shared and dedicated (Existing or Deployed). For reference visit Site Management :

    1. Local site:

      1. By default, every pool is associated with a local site. Access to the local site will not be blocked because the DR-enabled/Disabled option is not available (The local site is a DC site).

    2. Remote Site:

      1. If the admin wants to create a pool for the remote site, select Remote Site.
      2. Then, the admin must select at least one remote site.
      3. Once a pool is created for a remote site and particular sites are selected, users cannot access the pool until at least one site's DR is enabled.

  2. IP Address Filtering in the Desktop Pool: If the desktop VMs configured in HyWorks have multiple network adapters or multiple IPs allocated, then the HyWorks Controller can use the provided IP range filter to get a specific IP. This should be used to communicate with the desktop agents and provide the IP address in the connection settings to initiate the connection.

Previous versions (3.2 or older) had this configuration as the registry entries and required restarting the Controller service, which was challenging to manage.

Summary Screen

The summary screen provides configuration information to re-validate the settings before committing the changes.

The Administrator can use the Back button on each screen to modify the configurations or click Finish to commit the pool changes. The HyWorks Controller will start the operations required after pool creation, such as Desktop Provisioning or getting Desktop details.

Important Configurations Affecting Deployment

Configurations that decide the deployment of the desktop virtual machines will be briefly discussed in this section.

General Screen

  • Entitlement Type: This affects the deployment as the client for desktops will be changed. Selections have the following impact:

    1. Device based will show the Devices screen to the configured registered devices as clients.

    2. User based will change the screen to Users, which can be used to add/remove users from the configured authorization server.

  • Desktop Virtualization Type: The desktop virtualization type decides the type of desktops that will be given to the end-users. Each of the available options further turns other controls on or off.

    1. Shared hosted desktop: This will be used for shared hosted desktop delivery and not for dedicated desktops. Refer to the Shared Hosted Desktop Delivery section for detailed information.

    2. Persistent Virtual Desktops: Selecting the Virtualization Type as Persistent Virtual Desktops will have the following impact:

      1. Select Session Provider: Listing all configured session providers.

      2. Provisioning: Enabling both options, None for existing VMs and Dynamic for provisioning desktops.

    3. Non-persistent Virtual Desktops/ Non-persistent Shared Hosted Desktops: Selecting the Virtualization Type as a Non-persistent Virtual Desktops or Non-persistent Shared Hosted Desktops will have the following impact:

      1. Select Session Provider: List all the configured session providers that support the deployment of non-persistent desktops.

        1. It will list the SCVMM server, VMware vCenter Server, and Nutanix server if configured.

        2. It will remove any configured ESXi servers, Azure, or Hyper-V Servers.

      2. Provisioning: Only the Dynamic option will be shown and will be selected by default.

    4. Physical Desktop: Physical desktops with no hypervisor are mapped to a manually created desktop provider. Selecting the Virtualization Type as Physical Desktop will have the following impact:

      1. Select Session Provider: List all configured session providers with the type of Physical PC.

  • Provisioning Type: The type of dedicated desktops to be used in this pool:

    1. None: Provisioning Type will be selected as None for using existing desktops. This enables:

      1. The Desktops tab is to be used to get the desired dedicated desktops from the selected dedicated Session Provider.

      2. The Desktop Assignment tab is for assigning desktops to clients.

      3. The Session Providers dropdown control will list all configured Session Providers.

    2. Dynamic: The Provisioning Type should be selected as - Dynamic for provisioning new desktops by cloning the Gold image. Selecting Provisioning Type as Dynamic enables the following:

      1. The Session Providers dropdown control will list all configured Session Providers that support provisioning.

        1. It will list Hyper-V, SCVMM server, VMware vCenter Server, Microsoft Azure, or Nutanix server if configured.

        2. It will remove any configured ESXi servers from the list.

      2. The Deployment and Customization tabs will be used to provision and prepare customized new desktops.

      3. The Desktop Assignment screen will be removed, as dynamically provisioned desktops are assigned automatically.

        1. Logically, all the desktops will have the same configuration, so it is not required to assign them manually.

        2. Desktops will be created on demand, so prior assignments will not be possible.

  • Assignment Lifespan: This option determines whether the client’s assignment to the Desktop will persist after the session. Based on the persistence of the assignment, Desktop Pools can be of the following two types:

    1. Personal: Desktop Pools in which Desktops are permanently assigned to clients (Devices or Users). This means that the same Desktop is provided to the same client (User or Device) at every successful login event. The client's Desktop assignment is always remembered.

    2. Floating: Desktop Pools in which assignments do not persist after the session is removed. This means the session can be assigned to a different Desktop at every successful logon event. The client Desktop assignment is removed and is not remembered. Floating assignments can be further subdivided into the following two types based on when assignments should be made:

      1. On Login: The configuration is shown on the Advanced screen and specifies assigning the desktop upon user login.

      2. On Connect: Selecting this option will not assign the desktop at the logon event but will happen when the user initiates the connection to the desktop.

        • When the On connect option is selected, the Administrator must choose another option to specify the time limit, after which the assignment should be removed after the disconnected desktop session.

Deployment Screen

When the Administrator configures a desktop pool to use the Provisioning as Dynamic, the deployment screen is enabled, and the desktop screen is removed. The deployment screen provides options for the deployment of virtual machines. Let us try to understand the options available in Deployment screen and its meaning.

  • Source VM

    Source VM, also termed as Gold image, will be copied multiple times to provision multiple Desktops. The following important configurations should be remembered while selecting the Source VM:

    • Source VM Format on Dedicated Session Provider: The source VM must be a virtual machine and cannot be a template.

    • VMware Tools (VMware), Integration Services (Microsoft), or Nutanix Guest Tools (Nutanix) must be installed on the source VM.

    • HyWorks Desktop Agent Installation: The Source VM should have HyWorks Desktop Agent installed. It is required for post-installation virtual machine customization and it ensures remote access for new valid users.

    • Source VM Power State: The Source VM should be running, which helps the HyWorks Controller determine the HyWorks Desktop Agent's availability in the Source VM. However, if the administrator knows that all prerequisites are correctly installed and configured in the Gold Image, then the Gold Image machine can be kept in a powered-off state as well.

  • Source VM should be a Fresh Installed Image: Use a fresh virtual machine as the Source VM to avoid customization failure.

The following are the links to Windows Gold Image or Linux Gold Image for detailed information on preparing a Gold Master or source image preparation.

Note

If there are issues while selecting a Source VM, if it is powered off, or if HyWorks cannot connect to the desktop agent, then a warning message will appear. If you're sure about the selected Desktop, click Continue Anyway to proceed or Cancel to fix the issues on a virtual machine.

  • Source VM OS: This should be set to Linux or Windows, according to the operating system of the source VM. Selecting the source VM as Linux will hide the option Dedicated Linux VM Pool from the Advanced configuration tab of the pool wizard and also hide the option Sysprep from the customization wizard.

  • Clone from Snapshot

    Select this option if clones should be created from specific snapshots/checkpoints on a virtual machine. Please note that not all providers support this operation; thus, if a selected provider does not support this, the option will be disabled. Selecting Clone from snapshot enables the option to choose a snapshot, which provides a list of all available snapshots.

  • Desktop Name Prefix

    HyWorks uses the desktop name prefix by appending a unique number to create desktops on the respective Hypervisor. 1. HyWorks append a hyphen(-) and number in XXXX format, e.g., a prefix as AccVDI; the controller will create VMs with names such as AccVDI-0001, AccVDI-0002, AccVDI-0003, and so on. 2. Including hyphens and numbers. XXXX adds five more characters to the desktop name. Thus, the administrator must consider that the name of the VM should not exceed the allowed number of characters in the respective dedicated session provider.

Note

- The ** Desktop Pool ** wizard does not validate a prefix with text that will insert create a duplicate name after appending the number, resulting in Desktop creation failure.
- It's a mandatory field in the Deployment screen; keeping it blank will display a relevant error.

  • Clone Type

    The clone type field in Desktop deployment defines the type of clones created for the source VM.

    Following two types of clone Desktops can be created:

    1. Full Clone: A full clone is an independent copy of a virtual machine that shares nothing with the parent virtual machine after the cloning. Its ongoing operation is entirely separate from that of the parent virtual machine.

    2. Linked Clone: A linked clone is a copy of a virtual machine that continuously shares virtual disks with the parent virtual machine. This helps conserve disk space and allows multiple virtual machines to use the same software.

      • Linked Clones in HyWorks: Linked cloning in HyWorks uses the following mechanism:

        1. When Linked Clones are initiated, HyWorks creates a replica or complete clone of the Gold Image (Source VM).

        2. Then, Linked Clones of Replica VMs are created.

        3. Having a replica VM ensures that linked clones won't be affected if the gold image is modified in any manner. If re-creating all the linked cloned desktops is required, a new replica VM can be deployed from the gold image.

    Refer to Functioning Support Provider-wise for linked and full clone support with different session providers.

  • Max Desktop Capacity:

    The count of the maximum number of Desktops to be created using Desktop Provisioning. The field accepts values from 1 to 1000, but this should be provided wisely as per requirement and available resources on the Dedicated Session Provider.

    Once changes are committed, the HyWorks Controller will create the virtual machine using the provided number. Provisioning will fail if the Dedicated Session Provider does not have enough resources.

  • Desktop Creation Schedule

    This parameter defines the schedule of new VM creation; the administrator can choose to provision new desktops in the following two schedules:

    1. Provision all Desktops now: Proceeding in the Desktop Pool wizard with the schedule as Provision all Desktop now will create all Desktops per the Max Desktop Capacity.

    2. On Demand: Create desktops as the demand arrives. While configuring Desktops on demand, the following two parameters are considered.

      • Count of Desktops to Create Now: This defines how many desktops should be created first. For example, if the Create Now Desktops count is specified as two (2), then at least two (2)desktops will be created first as part of Desktop Provisioning.

      • Count of spare Desktops to be provisioned: Defines how many spare or extra desktops are to be kept in the Desktop Pool. The count of spare Desktops to be provisioned is 2, which means in this desktop pool, at least two (2) desktops will always be free, and as soon as the count of free desktops goes to one (1), it will start creating a new desktop to maintain the spare Desktop count. In this manner, HyWorks Controller will create a desktop that reaches Max Desktop Capacity**. The administrator can choose any of the desktop creation schedules as per requirement.

  • Power on Desktop Post Provisioning

    Keeping the checkbox selected will power on the virtual machine after cloning is completed, whereas unchecking this option will keep the Desktop in a powered-off state after creation.

  • Enable DVM Reset

    Option to enable reset options for cloned VMs. If enabled, a restore point will be created for the desktop VMs' fresh state, and if needed, DVMs or the whole pool can be restored to their fresh state using the operation.

    1. Not all providers support this option. Refer to the section Functioning Support Provider-wise for detailed information on provider support. Providers which support Non-persistent VMs will also support the option to reset DVMs

    2. Enable DVM Reset will be enabled by default for non-persistent desktops and is not modifiable.

  • Preserve MAC Address

    This configuration should be enabled if deployment needs to preserve the last assigned MAC address. This setting can be very useful in cases where dynamic IP pools are limited, and the same IP range should be utilized.

    The feature or option currently works only for VMware vCenter and Nutanix Hypervisors.

    In case of recomposing or recreating operations, HyWorks will remember the last MAC address assigned to the deployed DVM and assign the same MAC address to the VM after re-deployment.

  • Preserve Network(Azure)

    This configuration should be enabled if deployment needs to preserve the last assigned network interface and IP address. This setting can be very useful in cases where dynamic IP pools are limited, and the same IP range should be utilized.

    Working:

    • During the cloning pool, HyWorks Controller adds tags in VM, Network, and IP Address objects in Azure.

    • In Recompose or recreate desktop operation, the Controller sends a flag to preserve the Network Interface while deleting the DVM.

      • The deployed VM will be deleted, but the associated network object will be preserved.

    • When the HyWorks controller redeploys the VM, it re-associates the preserved network object using the tag names.

    Limitations:

    • Azure Network will work with the same Gold VM only, and thus:

      • If Gold VM is changed, then network preserve will not work and will be unchecked.

      • With the Network preserve option enabled, change in gold VM will not be allowed.

    • If cloning a VM fails (after deleting a VM with network preserve), the Azure network object will be deleted.

  • VM Disk Encryption(Azure)

    This option is enabled for the Azure desktop provider only and encrypts the VM disk post-sysrep (if enabled).

    The following types of disk encryption mechanisms are supported in HyWorks:

    • Platform Managed Key (Azure's Default)—Azure uses Server-Side Encryption (SSE) with a Platform-Managed Key (PMK) by default.

    • Customer Managed Key - Disk Encryption Set is needed for the customer-managed key. The following types of encryption can be used while creating a Disk Encryption Set on Azure:

      • Customer Managed Key (CMK) only.
      • Customer Managed Key (CMK) and Platform Managed Key (PMK) both.

    To get Disk Encryption Set ID on Azure Portal, Go to Disk Encryption Set and select Disk Encryption Set created earlier > Properties > Resource ID.

    • Azure Disk Encryption—When selecting this option, Server-Side Encryption (SSE) with Platform-Managed Key (PMK) and Azure Disk Encryption (ADE) are both used to encrypt VM disks. For ADE, Bitlocker is used on the Windows platform, and Crypto is used on the Linux platform. Check Azure for Linux platform support.

      For this option, you need to configure the Encryption Key Identifier and Vault Resource ID.

      • Encryption Key Identifier: Azure Key Vault enables Microsoft Azure applications and users to store and use several types of keys (Vault >Keys >Current Version >Key Identifier).

      • Vault Resource Id: Azure Key Vault is a cloud service for securely storing and accessing keys. (Vault >Properties >Resource Id).

    Currently, HyWorks supports encryption of OS disks only using the Customer Managed Key or Azure Disk Encryption.

    Refer to the section for Azure Disk Encryption Details.

  • Target Locations of Clones VMs

    Deployment Settings enables the administrator to define target data stores and resource pools for the cloned desktops and replica VMs.

    Deployment settings get dynamically updated as per the selected Clone Type option in the following manner.

    1. For Linked Clones, the Option to choose Replica VM Deployment Settings is enabled along with Cloned VM Deployment Settings**.

    2. For Full Clone: The option for Cloned VMs Deployment Settings is enabled. Keeping the Deployment Settings option unchecked, will keep all configurations as default i.e. same configuration as gold image.

    Considering that Clone Type is selected as Linked Clone, the following configurations will be available:

    • Replica VM Deployment Settings: This section allows you to change the location of the replica VM on the dedicated session provider. To change the replica VM's configurations, Click Change Location.

      • Change Location

        Clicking on Change Location will open Available Datastores dialog, which can be used to specify new locations for the replica VM.

        The administrator can select the following two location attributes by expanding the resource tree:

      • Resource Pool

      • Datastore

    • Cloned VMs Deployment Settings: Like replica VM deployment configurations, datastore and resource pool configurations of cloned VMs can also be modified. To modify the configurations of cloned VMs, Click Cloned VM Deployment Settings.

      • This will start displaying the currently applied configurations for cloned VMs (set to Default, which means same as gold image)

      • Click Change Location to invoke Available Datastores dialog, follow steps mentioned in above section to change configurations of cloned VMs.

      Important

      • Please note, Available Datastores dialog, displays all the available datastores and resource pools but it does not evaluate the feasibility of cloned VMs deployment on the target datastores or resource pool and administrator must choose these configurations carefully to avoid provisioning failure.
      • As a thumb rule, the datastores and resource pools should be chosen in a manner they are able to read from replica image.

    • Deployment Settings Support for dedicated session providers

      • SCVMM Servers: These advanced deployment settings are not supported with SCVMM servers configured as Dedicated Session Providers though shown as enabled. Clicking on Change location with SCVMM server configured as Dedicated Session Provider will show the Available Data Stores dialog with error no data centers found.

      • Hyper-V Servers: With Hyper-V Servers administrator will be able to change the Datastores up to available drives level and pool selection will not be available.

        Changing the Datastore in case of Hyper-V servers will create a folder with name Accops-Cloned-VMs in the selected drive and will keep Desktops files in folder with the name of Desktop. As in the below screenshot where Datastore has been changed to D:\ drive, the newly created Desktops will be located at

        D:\Accops-Cloned-VMs\\<Desktop Name>.

      • VMware vCenter Server: As vCenter Servers presents two cases as per supported clone types and as per accessible ESXi servers.

        • Linked Clones: Option to move replica VM and cloned VMs are available.
          Please note the wizard will display the available Resource Pools and Datastores of all ESXi servers, but administrator should choose target locations carefully so that after completing the pool wizard provisioning does not fail.

        • Full Clone: In case of full clones with vCenter Server administrator will be able to change the Resource Pool or Datastore.

        • Nutanix: Current version uses same configurations as gold master, though options can be shown to change storage pool.

  • Nutanix Flow Categories

    Nutanix Flow allows organizations to deploy software-defined virtual network security without the complexity of installing and managing additional products that have separate management and independent software maintenance requirements.

    Category Management in HyWorks: This option is enabled for Nutanix (Prism Central) desktop provider and if Micro-segmentation is enabled on it. Categories will be applied after the customization ( Sysprep or Hyprep ) when the new VM is Created or on recompose pool/Recreate VM.

    Following are the options provided to configure flow categories:

    • Not Configured: Categories will not be configured on VMs from pool, If any category applied from previous setting will be removed.

    • Copy from Source VM (Gold Mater): Categories which are configured on the selected source VM will be displayed in the Selected Categories dropdown. These categories will be displayed in read only manner, no changes allowed. The displayed categories will be configured on VMs from pool.

    • Select Categories: All the categories which are available on Nutanix (Prism Central) will be populated in the Selected Categories dropdown. Multiple categories can be selected and configured on the Pool. Selected categories will be applied on pool VMs.

    Note: Any changes on pool Category settings will update Categories on VMs (those are using pool setting). VMs, which are using DVMs settings will be ignored. Refer section for Nutanix Flow DVMs Settings

Customization Screen

Deployment screen ensures the deployment options which affects the new DVM configurations on Dedicated Session Provider E.g. Name of Desktop, Location, Power State, Count Etc. but the newly created Desktops may require some internal system level customization which will be specific for specific Desktops e.g. computer name of all new Desktops must be different, locale etc.

For customizing such changes, customization screen can be used. On Customization screen administrator can opt to enable or disable customization.

Before moving to Customization process or available options, we must learn that few pre-requisites are met for customization to run successfully.

Customization of the VM can be done via two processes: Sysprep or Hyprep.

Disabling customization

Disabling the customization will create all Desktops as identical in terms of computer name, network settings, locale, product key. It can be a handy option if administrator is willing to customize new Desktops manually from Dedicated Session Provider or using any independent tool. To disable customization,

  1. Select option No customization and proceed to next screen

Enabling Customization

Administrator can opt to customize the new copies of the Desktops by selecting the customization type as Sysprep or Hyprep in Customization section of Desktop Pool (The screen will be enabled only when Desktop Provisioning is set to Dynamic).

Sysprep: Accops DVM agent on VDI will use Microsoft Sysprep process to customize the VDI. Sysprep will take 3-10 minutes or more, based on configuration needs

Hyprep: Accops DVM agent on VDI will use Accops customization process. Hyprep is a quick VM customization process build by Accops. Hyprep process can take 1-3 minutes.

The following customizations in new clones are possible:

  1. Owner Name: Owner name of the Desktop (Optional)

  2. Organization Name: Organization name of the Desktop (Optional)

  3. Computer Name (Prefix): Computer name of the Desktop. To keep each Desktop identical HyWorks Controller will append the provided computer name with hyphen and a unique number e.g. -XXXX new Desktops are provisioned and computer name is specified as 'ProVM' then computer name of 5 Desktops will be ProVM-0001, ProVM-0002 and so on.

    1. Computer name (prefix) in customization cannot be more than 10 characters long. (* Mandatory field if customization is enabled)

    2. HyWorks maintains same number for VM name and Computer name

  4. Local Username: The new local user to be created on new Desktop. (Optional)

    Warning

    If leaving Local Username field blank then, make sure that at least one local admin (other than Administrator) user is already available on gold image, because post Sysprep administrator user gets disabled and could lead to configuration with no local administrator.

  5. Local Password and Confirm Local Password: Password to be set for new local user (* Mandatory field if local username is provided)

  6. Workgroup/ Domain Configurations:

    1. Join workgroup is selected by default and requires entries in Workgroup textbox.

    2. Join Domain: If new Desktops need to be joined to existing domain, then this option can be selected, which enables following fields:

      1. Domain Name: e.g. accops.com (* Mandatory if Join a domain combo box is selected)

      2. Username: User with privileges to join a machine to domain e.g. domain admin user (* Mandatory if Join a domain combo box is selected)

      3. Password and Confirm Domain Password: Password for domain admin user (* Mandatory if Join a domain combo box is selected)

  7. DNS Configurations:

    1. Preferred DNS: Preferred DNS to be configured in network settings (Optional)

    2. Alternate DNS: Alternate DNS to be configured in network settings (Optional)

  8. AD Path: Full OU path to which this computer should be registered. The provided domain username should have adequate rights to create objects in specified OU. (Optional)

  9. AD Group: Specify comma separated active directory groups. Provisioned VMs will be made member of these groups.

  10. Select Locale: For configuring local language of new Desktop

  11. OS Product Key: Provide Volume product key, to be applied on new Desktop however if creating multiple VMs then this should be mass activation key or should be left blank for activating the OS later manually.

Examples of Different Types of Desktop Pools

Creating Desktop Pools of Several Types

The administrator can proceed with the Add Desktop Pool wizard to create the following types of Desktop Pools in HyWorks deployments:

  • Using Existing Desktops (Desktop Provisioning type as None)

    • Device Based

    • User Based

  • Using Dynamic Desktop Provisioning (Creating New Desktops with Desktop Pool)

    • Device Based

    • User Based

Each type of pool can be a possible deployment scenario in different environments of different organizations. The administrator can choose the best-fit case for the requirement and try creating a pool to fulfill it. In the section below, we will try to understand the process of creating several types of pools.

Using Existing Desktops or Session Providers

This section will cover creating Desktop Pools using Desktops already in the configured Dedicated Session Providers. HyWorks Controller 2.1 supports the Pooling of Dedicated Session Providers only; External Session Providers work without any pools. We will cover the use of External Session Provider Session Providers in a later section of the document.

Device Based - Personal Assignment Lifespan

In any deployment, employees or professionals come to the office premises, log in to their respective desktops in a specific area, and work from there.

Device-based personally assigned pools replicate a similar environment where employees log in from their respective devices and are provided with sessions on their dedicated desktops.

Pre-requisites

  1. Appropriate Dedicated Session Provider (i.e., VMware ESXi/ vCenter Server or Microsoft Hyper-V/ SCVMM, Nutanix Prism Element/ Prism Central, Microsoft Azure) is configured and reachable.

  2. Devices are registered with HyWorks Controller.

  3. A valid authentication server Microsoft AD, Built-in, or Novell eDirectory) is configured—this is Required to validate the user credentials used for login.

Desktop Pool Configurations on different screens

     Device-based Permanently Assigned Dedicated Virtual Desktop Pool

Screen Name Configuration Attribute --> Name / Description Entitlement Type Desktop Virtualization Type Select Session Provider Desktop Provisioning Assignment Life Span Connection Profile
General Screen Expected Configuration --> As Required Device Based Persistent Virtual Desktop As Required None Personal As needed
Screen Name Expected Configuration
Desktop Screen Search, select, and add desktops as selected dedicated session providers require.
Devices Screen Search, select, and add devices required per the available registered devices list.
Desktop Assignment Screen As per requirement:
1. Auto-assigned (if needed)
or
2. Manually assign desktops to devices from the desktop pool wizard or desktop screen.
Advanced Screen Configure as per requirement.

Pool creation is completed, and the user who logs in with specific endpoints will get the configured desktops.

Device-Based - Floating Assignment Lifespan

In the above section, we have created a Device-based, personally assigned desktop pool to keep the assignments forever.

However, there could be deployment requirements where the user’s location and, thus, the device is fixed. Still, it does not matter which desktop has been assigned to the device, considering all desktops have the same configurations and the same users log in from the devices. For example, a hospital where users (doctors) log in with a common username, 'doctor,' to access their desktop, which does not have any local data, instead working on a web-based application.

In such scenarios, a temporary Desktop Pool can be very handy. Follow the below steps to create a temporary Desktop Pool:

Pre-requisites

  1. Appropriate Dedicated Session Provider (i.e., VMware ESXi/ vCenter Server or Microsoft Hyper-V/ SCVMM, Nutanix Prism Element/ Prism Central, Microsoft Azure) is configured and reachable.

  2. Devices are registered with HyWorks Controller.

  3. A valid authentication server (Microsoft AD, Built-in, or Novell eDirectory) is configured—this is Required to validate the user credentials used for login.

Desktop Pool Configurations on different screens

     Device-based Temporarily Assigned Dedicated Virtual Desktop Pool

Screen Name Configuration Attribute --> Name / Description Entitlement Type Desktop Virtualization Type Select Session Provider Desktop Provisioning Assignment Life Span Connection Profile
General Screen Expected Configuration --> As Required Device Based Persistent Virtual Desktop As Required None Floating As needed
Screen Name Expected Configuration
Desktop Screen Search, select, and add desktops as selected dedicated session providers require.
Devices Screen Search, select, and add devices as per requirement from the list of available registered devices.
Desktop Assignment Screen Auto assigned (Must)

Note: Manual assignments in the temporary pool are retained only until the first login and are erased after logout.
Advanced Screen Configure as per requirement. Choose if the desktop should be assigned on logon or connection for the floating assignment.

The pool creation is completed, and the user logging in from the configured devices will be provided with the appropriate Desktop session as per the below examples:

User Based - Personal Assignment Lifespan

Consider a deployment scenario where a field employee used to visit different offices all the time and rather than carrying any hardware (Laptop, etc.) with them to different offices due to security reasons, but the employees need to connect to their desktops only.

In such a scenario, a user-based dedicated pool can be helpful. In this pool, desktops are assigned to users, and irrespective of device, the user is provided with a session of the same desktop.

The below section will guide you on creating a user-based personally assigned desktop pool.

Prerequisites

  1. The Appropriate Dedicated Session Provider (e.g., VMware ESXi/ vCenter Server, Microsoft Hyper-V/ SCVMM, Nutanix Prism Element/ Prism Central, Microsoft Azure) is configured and reachable.

  2. A valid authentication server (Microsoft AD, Built-in, or Novell eDirectory) is configured—this is Required to validate the user credentials used for login.

  3. All required users exist on the authentication server.

Desktop Pool Configurations on different screens

     User-based Permanently Assigned Dedicated Desktop Pool

Screen Name Configuration Attribute --> Name / Description Entitlement Type Desktop Virtualization Type Select Session Provider Desktop Provisioning Assignment Life Span Connection Profile
General Screen Expected Configuration --> As Required User Based Persistent Virtual Desktop As Required None Permanent As needed
Screen Name Expected Configuration
Desktop Screen Search, select, and add desktops as selected dedicated session providers require.
Users Screen Search, select, and add users as per requirement from the list of available users.
Desktop Assignment Screen As per requirement:
1. Auto-assigned (if needed)
or
2. Manually assign desktops to users from the desktop pool wizard or desktops screen.
Advanced Screen Configure as per requirement.

User Based - Floating Assignment Lifespan

Consider a deployment scenario where field employees used to visit different offices all the time and rather than carrying any hardware (Laptop, etc.) with them to different offices due to security reasons and The desktops need not be specific to employees.

In such a scenario, a user-based dedicated pool can be helpful. In this pool, Desktops are assigned to users, and irrespective of device, the user is provided with a session on a different Desktop.

The section below will guide you on creating a user-based temporary assigned Desktop Pool.

Prerequisites

  1. The Appropriate Dedicated Session Provider (e.g., VMware ESXi/ vCenter Server, Microsoft Hyper-V/ SCVMM, Nutanix Prism Element/ Prism Central, Microsoft Azure) is configured and reachable.

  2. A valid authentication server (Microsoft AD, Built-in, or Novell eDirectory) is configured—this is Required to validate the user credentials used for login.

  3. All required users exist on the authentication server.

  4. Endpoints are configured correctly to log in to the controller.

Desktop pool configurations on different screens

     User-based Floating Assigned Dedicated Desktop Pool

Screen Name Configuration Attribute --> Name / Description Entitlement Type Desktop Virtualization Type Select Session Provider Desktop Provisioning Assignment Life Span Connection Profile
General Screen Expected Configuration --> As Required User Based Persistent Virtual Desktop As Required None Floating As needed
Screen Name Expected Configuration
Desktop Screen Search, select, and add desktops as selected dedicated session providers require.
Users Screen Search, select, and add users as per requirement from the list of available users.
Desktop Assignment Screen Auto assigned (Must)

or
Note: Manual assignments in floating desktop pools are retained only for the next login and are cleared after logout.
Advanced Screen Configure as per requirement. Choose if the desktop should be assigned on logon or connection for the floating assignment.

The pool creation is completed, and the user logging in from the configured devices will receive the appropriate Desktop session.

Desktop Pool of Physical Desktops

Physical desktops configured in HyWorks can be served using the following configuration:

Prerequisites

  1. An appropriate physical PC dedicated desktop provider is added to HyWorks.

  2. Physical desktops are added in physical desktops.

  3. All added desktops are powered on and reachable from HyWorks/ client on the given host address and port.

  4. Desktops are pre-configured for remote access of user (Assumption: Physical desktops will not be having HyWorks Desktop agent installed)

Desktop pool configurations on different screens

  1. Add a desktop pool as per the below example configuration
Screen Name Configuration Attribute --> Name/ Display Name/ Description Entitlement Type Desktop Pool Type **Select Session provider assignment Assignment Life Span Connection Profile RDP Port Active/ Maintenance Mode
General Screen Expected Configuration --> As Required User/ Device based Physical Desktop Physical PC (Added in HyWorks) Floating/ Personal As needed Default 3389 (Configure) As needed
Screen Name Expected Configuration
Desktop Screen Search, select, and add desktops as selected dedicated session providers require.
Users/Devices Screen Search, select, and add users/devices as needed from the available registered users/devices list.
Desktop Assignment Screen Auto Assigned (Must)
Or
They manually assign desktops to users from the desktop pool wizard or desktop screen.
Extended Screen Configurations for filtering IPs of desktops. Configure as per requirement.
Advanced Screen Configure as per requirement.

  1. Save the desktop pool.

  2. All added desktops will now be visible on the Desktop VMs page.

  3. On login, users will be assigned to respective physical desktops.

Using Dynamic Desktop Provisioning

In the above section, we used existing desktops from selected dedicated session providers; now, there could be a scenario where all new desktops need to be created. For example, an institute that needs new Windows 7 Desktops with a Java development environment for a whole new classroom: in such a case, the administrator can prepare a Gold image with the Windows 7 operating system and then use dynamic Desktop provisioning to deploy new Desktops in HyWorks to fulfill requirements.

Now that we have understood the kind of deployments where dynamic Desktop provisioning might be required let us move to the section on creating several types of Desktop Pools, which will use Desktop Provisioning in the Desktop Pool wizard to deploy new Desktops.

As explained in the above sections, Desktop Provisioning will deploy all new Desktops with similar configurations by cloning (copying) the source VM, so Desktop assignment won't be required as all the Desktops are the same. Considering the above fact, the Desktop Assignment screen is not provided in Desktop Pools with dynamic Desktop Provisioning.

Below are a few examples of creating several types of Desktop Pools, having Desktop Provisioning enabled:

Persistent Virtual Desktop: Device-Based, Personal Assignment Lifespan, Dynamic Provisioning

Create a desktop pool in which desktops will be provided with clone-type Linked Clones, and desktops will be permanently assigned to devices.

Prerequisites

  1. An appropriate Dedicated Session Provider, i.e., vCenter Server/ SCVMM, is configured (Only vCenter Server or SCVMM supports Linked Clones).

  2. vCenter Server has a source VM that is ready to create multiple linked clones of it.

  3. Devices are registered with HyWorks Controller.

  4. A valid authentication server (Microsoft AD, Built-in, or Novell eDirectory) is configured—this is Required to validate the user credentials used for login.

Desktop Pool configurations:

     Device-based Personally Assigned Deployed Desktop Pool

Screen Name Configuration Attribute --> Name / Description Entitlement Type Desktop Virtualization Type Select Session Provider Desktop Provisioning Assignment Life Span Connection Profile
General Screen Expected Configuration --> As Required Device Based Persistent vCenter Server/ SCVMM Dynamic Personal As needed
Screen Name Configuration Attribute --> Select a source VM Desktop Name Prefix Clone Type Desktop Creation Schedule Power on Desktop Deployment Configurations Enable DVM Reset
Deployment Screen Expected Configuration --> Gold Image to be cloned As needed Linked Clone On Demand. Provision Now -# as needed
Spare Desktop Count - #, as needed		 As needed As needed As needed
Screen Name Expected Configuration
Customization Configure as per requirement.
Note: Customization requires some prerequisites in the Gold image machine; please check these configurations in the respective sections of this document.
Devices Screen Search, select, and add devices as per requirement.
Advanced Screen Configure as per.

Important

  • As linked clones are supported with vCenter Server and Microsoft SCVMM only, the selected dedicated session provider must be vCenter Server. If it is an ESXi or Hyper-V, then the Linked Clone option will not be enabled in the Deployment Screen.

  • the Desktop Assignment screen will not appear in the Dynamic Desktop Provisioning pool, as all the desktops are going to have the same configurations. Therefore, any desktop can be assigned to any client (device or user).

Details in Desktop Pools Tab of Deployed Dedicated Virtual Desktop Pool

The pool creation is completed, and now Desktop provisioning is started, which can be first observed in the Desktop Pools tab: initially, the Desktop Pool status will be Cloning Desktops when Desktop Cloning is in progress, and as soon as Desktop Cloning is completed, the status will be ready.

Another important thing to observe is that, according to the provided Desktop Creation Schedule, only 2 Desktops were created first.

Details in Desktops Tab and Flow of Client Assignments to Clients

Once the deployed dedicated desktop pool wizard is finished, the Desktops tab can be used to see the provisioning progress and understand the Desktop Creation schedule.

  1. Desktop Provisioning Start: New Desktops are cloned one by one, and once the provisioning starts, the Desktops to be created first will have the following status:

    1. The first Desktop for which cloning is started will be displayed as Creating Desktop.

    2. Other Desktops to be provisioned later will be displayed with the status Pending Desktop Creations.

  2. Desktop Provisioning: Create Now Completed: Initially, the controller will create desktops equal to the count provided in field No of Desktops to create now in the Desktop Creation schedule. All the Desktops will be displayed with the Status as Powered On (This does not mean that desktops are ready; there will be more processes in the backend to complete the desktop provisioning).

  3. Customization Process: Customization will happen in the following manner:

    1. Initially, desktops will be marked with the Customization Info flag as Required, which means customization will be required on this Desktop. To see the Desktop’s detailed status, click its name in the Desktops VMs tab; the Desktop Detail dialog will display all the information about the Desktop.

    2. HyWorks Controller will wait for the new Desktops IP to be detected, and once it can get the IP of the new Desktop, it will try communicating with it.

    3. Once Communication is established, Customization(Sysprep or HyPrep) will be started on the new Desktop, and flag SYSPREP Info will be marked as running, suggesting that customization is in progress. The new desktop will be rebooted and configured for customization as needed.

    4. The Sysprep Info flag will be marked as Completed, which means Desktop customization is completed.

    5. The Desktop Agent status should now be Responding with Desktops. The DNS Name should display information to help identify whether the Desktop has been customized correctly. For example, we configured the Computer Name as DesktopLCWIn7 and the domain as accops.com, so the DNS name of the new Desktop after provisioning should be 'DesktopLCWin7-0001.accops.local'.

    6. Now, provisioning is completed for the first set of desktops as per the specified Create Now Desktops count, but the desktops assignment remains.

      Case Study (User assignment):

      1. The assignment will happen when a valid user from one configured device logs in or the administrator manually assigns the device from the tab.

      2. Let us try to understand the Auto Assignment and Desktop Creation Schedule process with an example:

        • We have provisioned Desktops as per the below configurations: Maximum Desktop Capacity as 5, Desktop Creation Schedule as On Demand, where 2 Desktops have been created now and 2 Desktops are to be kept in spare. The configured devices in Desktop Pools are Device-1, Device2....Device5.

        • In the first step, as per the above details, the HyWorks Controller will create and customize 2 Desktops, say Desktop1 and Desktop2, and keep them unassigned.

        • When a valid user from the configured authentication server logs in from Device-1, the HyWorks Controller will look for the ready Desktop and assign it to Device-1. The assignment will also be remembered, so if the user from Device-1 logs in again, the same Desktop-1 will be presented.

        • As per configuration, HyWorks Controller must keep at least 2 Desktops in spare, and once Desktop-1 is assigned to Device-1, free Desktop count as 1. The HyWorks Controller will start provisioning one more Desktop to keep spare Desktops as 2.

    Now, if the admin assigns or the user logs in from Device-2, the second Desktop will be assigned to this device. HyWorks Controller will trigger the creation of another Desktop, which will then be provisioned and customized per the provided settings.

    The process of provisioning new desktops will continue until the maximum desktop capacity is reached, which means that the HyWorks Controller has provisioned all five desktops. Now, login from Device-4 and Device-5 will be assigned to Desktop-4 and Desktop-5, but the HyWorks Controller will not provision any new Desktop.

Persistent Virtual Desktop: User-Based, Floating Assignment, Dynamic Provisioning with Enabled DVM Reset

Create a desktop pool in which Desktops will be provisioned with clone type Full Clones, and desktops will be assigned to users.

Case Study Configure desktop creation schedule

Prerequisites

  • An Appropriate Dedicated Session Provider, e.g., VMware vCenter Server or Microsoft Hyper-V/ SCVMM, Nutanix Prism Element/ Prism Central, or Microsoft Azure, is configured (These Dedicated Session Providers support Full Clones).

    • The Dedicated Session Provider has a source VM ready for creating multiple linked clones of it.

  • A valid authentication server [(Microsoft AD, Built-in, or Novell eDirectory) is configured—it is required to validate the user credentials when the user logs in.

Desktop pool configurations:

 User-based Floating Assigned Deployed Desktop Pool

Screen Name Configuration Attribute --> Name / Description Entitlement Type Desktop Virtualization Type Select Session Provider Desktop Provisioning Assignment Life Span Connection Profile
General Screen Expected Configuration --> As Required User Based Persistent vCenter Server/ SCVMM/ Hyper-V/ Nutanix/ Azure Dynamic Floating As needed
Screen Name Configuration Attribute --> Select a source VM Desktop Name Prefix Clone Type Desktop Creation Schedule Power on Desktop Deployment Configurations Enable DVM Reset
Deployment Screen Expected Configuration --> Gold Image to be cloned As needed Full Clone Create All Desktops Now As needed As needed Checked
Screen Name Expected Configuration
Customization Configure as per requirement.
Note: Customization requires some prerequisites in the Gold image machine; please check these configurations in the respective sections of this document.
User Screen Search, select, and add users, groups, or OUs as per requirement.
Advanced Screen Configure as per requirement

Login and Assignment Flow

  1. We have provisioned a total of 3 Desktops, and all Desktops will be free initially.

  2. Once User-1 logs in from device-1, it will be assigned to either of 3 available Desktops, say Desktop-1.

  3. If User-2 logs in with Desktop-1 already in session, User-2 will be assigned Desktop-2 or Desktop-3, and if User-3 logs in with only Desktop-3 remaining, it will be provided with a session of Desktop-3.

  4. If any other user logs in while all Desktops are already in use, the user will be displayed an appropriate error message stating that no free Desktop is available.

  5. All assignments will be removed once users log out of the session on their respective desktops.

  6. On the next logon, the same process will be repeated, and users will be assigned automatically according to the availability and readiness of the desktops, but the old assignment will not be guaranteed.

User-based - Floating Assignment, Dynamic Provisioning Non-persistent

Create a non-persistent desktop pool with floating assignments for users.

Prerequisites

  • An Appropriate Dedicated Session Provider, e.g., VMware vCenter Server, Microsoft SCVMM, or Nutanix Prism Element/ Prism Central, is configured (These Dedicated Session Providers support non-persistent desktops).

    • The dedicated session provider has a source VM that is ready to create multiple linked clones of it.

  • A valid authentication server (Microsoft AD, Built-in, or Novell eDirectory) is configured, which is required to validate the user credentials used for login.

Desktop pool configurations:

User-based Floating Assignment Life-span Deployed Virtual Desktop Pool

Screen Name Configuration Attribute --> Name / Description Entitlement Type Desktop Virtualization Type Select Session Provider Desktop Provisioning Assignment Life Span Connection Profile
General Screen Expected Configuration --> As Required User Based Non-persistent Virtual Desktop vCenter Server/ SCVMM/ Nutanix Dynamic Floating As needed
Screen Name Configuration Attribute --> Select a source VM Desktop Name Prefix Clone Type Desktop Creation Schedule Power on Desktop Deployment Configurations Enable DVM Reset
Deployment Screen Expected Configuration --> Gold Image to be cloned As needed Linked Clone Create All Desktops Now As needed As needed Default Checked
Screen Name Expected Configuration
Customization Configure as per requirement.
Note: Customization requires some prerequisites in the Gold image machine. Please check these configurations in the respective sections of this document.
Users Screen Search, select, and add users, groups, or OUs as per requirement.
Screen Name Configuration Attribute --> Power action when user logs-off Other advanced configurations
Advance Screen Expected Configuration --> Shutdown/Power off/Restart (Choose as per need) As per need

Non-persistent Desktop Pool:

A non-persistent desktop pool erases all changes made by a user in the session; thus, a fresh VM is presented to the user on the next login.

How does it work:

  1. HyWorks first deploys and customizes VMs as per deployment settings.

  2. Once the VM is in a ready (Fresh) state, HyWorks creates a restore point representing the fresh state.

  3. When the user logs in, the desktop will get assigned to the user.

  4. On user logout, HyWorks reverts the desktop to its fresh state using the restore point created.

    • When the user logs off, the restored VM will be kept in the power state, as per the configuration done for Power Action.

Login and Connect to Assigned Desktop

The last step of Desktop deployment is user login from respective clients.

To verify if the pool is adequately configured, administrators can get users to log in from appropriate devices to confirm if only assigned Desktops are provided. Consider the examples below:

  • Device-based personally assigned pools with assignments are done manually as follows

    • Pool Configuration:

      • Desktop-1 (Responding state) assigned to Device-1.

      • Desktop-2 (Responding state) assigned to Device-1.

    • Login Process:

      • Login from Device-1 with user credentials on successful authentication will configure Desktop-1 for remote access and will provide a session on Device-1.

      • In the same manner, login from Device-2 will provide a session of Desktop-2.

  • User-based pool with floating auto-assignment

    • Pool Configuration

      • Users - User-1 and User-2 are configured as clients in the pool.

      • Desktops - Desktop-1 and Desktop-2 are configured in the pool. Now, if User-2 attempts to log in when a desktop session of Desktop-1 is running, the response state is as follows:

  • Login Process:

    • Login from any registered devices with user-1 credentials will provide a session of any of the Desktops, I.e., Desktop-1 and Desktop-2. Assume a session of Desktop-1 is provided to User-1.

      -   Now, if User-2 attempts to log in when a desktop session of Desktop-1 is running, then a session of Desktop-2 will be provided to User-2.

    • Once desktop sessions are ended, assignments will be removed, and the next login from User-1 or User-2 credentials will randomly provide a session of any of the Desktops. For example, User-1 can be provided with a session of Desktop-2 or Desktop-1.

Now that the administrator has verified that the Desktop Pool is successfully configured and users are able to connect to their respective Desktops, the administrator can happily work on other tasks. At the same time, the HyWorks Controller handles user access configuration and other relevant tasks.

Important

Desktop Pool creation is managed up to the Desktop to Client (Devices/Users) assignment level; the overall success of the session depends on various other factors that must be addressed for a successful HyWorks deployment.

A few such factors are:

  • {{ accops_products.HyWorks_DVMTools }} installation on target Desktops ensures RDP enabling for logged-in users and several other user configurations.

  • Appropriate authentication server configuration and user credentials

  • Appropriate RDP Security Protocol and Connection Profile configurations on devices/clients/desktop pools.