Management

The primary objective of HyWorks deployment is to provide desktop/application sessions to its intended client. The client could be a device, a user, a group of users, etc. and it is important to associate target desktops with appropriate clients.

The Desktop Pools tab provides an interface for creating and managing desktop pools and associating desktops with intended clients.

Desktop Pool Categorization

Desktop pools can be categorized based on the following factors:

Desktop Virtualization Type
Desktop Provisioning
Entitlement Type
Assignment Lifespan

As shown in the above diagram, as per the end-user's needs, multiple options are available in HyWorks to deliver desktops.

Desktop Virtualization Type

The Administrator must choose the kind of virtualization type that must be done out of the following options:

Persistent Virtual Desktops: Dedicated desktops that will not be reverted to a fresh state and will retain all the changes done by the user. Applicable for existing desktops and provisioned desktop pools.
Non-persistent Virtual desktops: Applicable for provisioned desktops only, where changes done to the desktop VMs by the users will be reverted after the users have logged out.
Shared Hosted Desktop: For delivering Shared Hosted Desktops to the end-users.
Provisioned Shared Hosted Desktop: For delivering provisioned (dynamically created) Shared Hosted Desktops to the end-users.
Physical Desktop: For delivering a desktop which does not belong to the hypervisor.

Desktop Provisioning

HyWorks can deploy a new virtual machine on the respective Session Provider from a pre-configured gold image or source VM. This process is termed desktop provisioning. If an environment has existing VMs, then they can be re-used instead of deploying new ones. HyWorks can be used to deliver dedicated desktops to the end-user. This choice is given during Desktop Pool creation as the Provisioning, which can be set as:

None: To use the existing desktop VMs on the Session Provider.
Dynamic: To provision new VMs in the Desktop Pool, new VMs will be cloned from the master image.

Once the Provisioning is set, it can not be changed.

Entitlement Type or Client Type

HyWorks can assign desktops either to registered endpoints or to users. In an office, the desktops could be assigned to the registered endpoints, where the user will get assigned a desktop only when logging in from a device. If desktops are directly assigned to the users, then the user will get a desktop irrespective of the endpoints they are logging in from.

The choice is shown under Entitlement Type in the Desktop Pool wizard, which can be set as:

Device based: for entitling the desktops to registered endpoints.
User-based: for assigning the desktops to users from a configured authentication server. In the user-based assignment, the Administrator can select the the following type of entities from a particular authentication server:
- User
- Group
- OU (Organizational Units)

The Entitlement type can be configured during pool creation and cannot be changed afterwards.

Assignment Lifespan

The Assignment lifespan defines the lifespan of the desktop assignment to the client. The available options are:

Personal: Personal assignment will keep the assignment for the client unless it is manually revoked by the Administrator.
Floating: The floating assignment will be removed when the user logs out. The floating assignment can be further sub-divided into the following two use cases:
- On Connect: The desktop will be assigned whenever the user requests access, un-assigned when the user is disconnected (after a specified time), or when the user logs out.
- On Login: The desktop will be assigned when the user logs in and unassigned when the user logs out.

Configuration Options for Dedicated Desktop Pools

Desktop pool configurations consists of two parts:

Common Configurations: Configurations, which will be common across the desktop pools of different types.
Critical Configurations affecting deployment type: Configurations, which will affect the whole deployment of desktops in HyWorks

Common Configurations

Common Configurations of General Screen

Name: Name of the desktop pool that is shown to end-users when they logon, if configured under in Advance Configuration > Display Preferences.
Display Name: Name of the desktop, which can be the same or different than the name. This can also be used to be shown to end-users, as per configurations in Advance Configuration > Display Preferences.
Description: For providing logical details of the desktop pools.
Connection Profiles: To assign a specific connection profile for the desktop pool. Connection attributes will be decided as per the provided connection profile.
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.
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 from accessing the desktop pool during deployment, redeployment, or maintenance activities.
Remote Desktop Connection Port: Port number of virtual desktops, on which client will initiate 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 desktop pool wizard.

Clients (Users/Devices) Screen

Devices/Users: Based on the Entitlement Type selected, screen for Devices or Users will be shown. The screen can be used to add/remove devices, users/groups or OUs.

Important Points for Adding Groups or OUs as a Client:

If groups or OUs are being added as clients for permanent dedicated Desktop Pools, then assignments should be kept Automatic, as one virtual machine can be assigned to only one user (client) at a time.
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 assign desktops to different clients manually.

In an automatic assignment, HyWorks assigns the desktop, using it's mechanism to identify the best desktop pool.
1. Default mechanism for provisioned desktop.
2. Should be used when trying to entitle desktops to groups/ organizational units.
Whereas in manual assignment, the administrator will be required to assign desktops to the clients.
1. Can be used for the desktop pool with existing VMs.

Important

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

Classification Rules

Configure the Classification Rules to restrict desktop access only to users who are connecting from specific classified devices.

Refer to the Classification Rules section to enable restricted client group access.

Select the access policy as From specific classification rules only.
It will list the added classification rules.
Select the classification rules and move them to the allowed list.
Now end-points satisfying the classification rules settings will be able to access the desktops from this pool.

Advanced Configurations

The following advanced configurations are commonly configured for users:

Keep desktops in power on state: Configurations to set if the associated desktops should also be kept 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 to be kept powered on.
3. Specified Desktops: Minimum number of desktops which should be kept powered-on perpetually.
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 to be kept powered all the time. Even if administrator or user turns it off, outside of HyWorks, controller will power it on, whenever it fetches the state as powered-off.
2. Before Specified Timing: To be entered in HH:MM TT format, specifies when the desktops will be powered on, if they are found powered off. The HyWorks Controller starts the process to turn the desktops' power on prior to the specified time to have them ready before the specified time. HyWorks performs this task only at specified time, which means HyWorks will not maintain the number of desktops in powered-on state all the time.
Power action when user logs off: The setting Power action when user logs off 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 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: Shutdown desktop when the user logs off.
Important

The setting Power action when 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 setting related to Power actions when the user logs off.
User Permission (Add user to the local Administrator group): Selecting this option will make the logged in user a member of local Administrator group on the target Desktop. Unchecking this option will not modify user privileges on the desktops.
Dedicated Linux VM Pool: A special configuration to be used, when Linux-based dedicated desktops are to be delivered to end users.
Use last known good IP address: A specific advanced settings which enables HyWorks to use the last cached good IP address of the desktop if it does not receive the IP address from the Session Provider.
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.
Assign Desktop: If the assignment type is Floating Desktop then this option get enabled. There are 2 Types:
1. On Login: Desktop will be assigned when the user logs on.
2. On Connect: Desktop will be assigned when the user clicks on desktop (shows at the HyWorks client's end). The following settings will enabled for the On Connect option:
3. Unassign disconnected desktop after(Min.): Remove assignment after this timeout on RDP disconnect: Post remote session disconnection to the assigned desktop, the assignment will be removed after a specified time limit. Value can not be empty. If specified as zero, assignments will be removed when the user logs out.
  1. Unassign on VDI Logoff: This feature is only supported with HyWorks configurations in Hybrid mode. Enable this option to release user assignment from the desktop VM when the remote session logs off. Note: If the desktop agent is unreachable, then assignment will be released as per the 'Un-assign disconnected desktop after' timer.
Auto upgrade desktop agent: To 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 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.
  1. Reboot if required: Select this option if the desktop VMs can be rebooted post upgrade of the DVM tools.
A specific component or all components can be selected to be upgraded. Usually this option is enabled after desktop pool creation, 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 for verifying the configured options.
Display Preferences for Desktop Pool Name to End-users If the end-users should be provided with a different display name for the desktop pool than the one being displayed to the Administrator, there is a configuration 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.
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. Common username, password and domain name for all the users connecting to desktop pool. Personal desktop delivery supports specifying username, password or domain; for shared hosted desktop pools only domain name can be specified.
2. Hypervisor Console The Hypervisor Console Connection Method specifies the login credentials of the user for the Console connection to the Virtual Desktop. These can be the logged-in-user credentials or 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 network is unavailable on the VMs.
  
  This feature is available for Hyper-V, ESXi, and Virtual Center session providers, where the VM 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. User credentials must have the authority to connect to the console of the VM.
  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, and HyLite do not support the Console Connect feature.
  ESXi and Virtual Center
  1. The Provider must be a ESXi or Virtual Center.
  2. User credentials must have the authority to connect to the Console of the VM.
  3. Required user credentials - Username and Password of ESXi or vCenter Server.
  4. Default Port supported 433 and 902 must be accessible from the endpoints to ESXi or Virtual Center server.
  5. Feature is supported on the Windows Clients only.
  6. HyLite does not support the Console Connect feature.

Refer to this section for detailed information on console connection.

Site Association

Now every pool is associated with either local or remote site. Site association option is available for all types of pool like Shared and dedicate(Existing or deployed). For reference Site Management :
1. Local site:
  1. By default, every pool is associated with a local site. Access to the local site will not blocked, because the DR-enabled/Disabled option is not available (The local site is a DC site).
2. Remote Site:
  1. If admin wants to create pool for remote site then select option as Remote Site.
  2. Then admin must select at-least on remote site.
  3. Once pool is created for remote site and particular sites selected, then pool is not allow to access to user's until atleast one sites DR is enabled.
IP Address Filtering in the Desktop Pool: If desktop VMs configured in HyWorks are having multiple network adapters or multiple IPs allocated, 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 providing IP address in the connection settings to initiate connection.

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

Summary Screen

The Summary screen provides the information of the configurations done to re-validate the settings before committing the changes.

The Administrator can go back using the Back on each screen to modify the configurations if required or Click the Finish to commit the pool changes. The HyWorks Controller will start the operations required after pool creation, for example, Desktop Provisioning or getting Desktop details etc.

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: Desktop virtualization type decides the type of desktops which will be given to the end-users. Each of the available options further enables or disables other controls.
1. Shared hosted desktop: To 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: Listing all the configured session providers that support the deployment of non-persistent desktops.
    1. It will list the SCVMM server, VMware vCenter Server, 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, which have 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: Listing all configured session providers with the type Physical PC.
Provisioning Type: The type of dedicated desktops to be used in this pool:
1. None: For using existing desktops Provisioning Type to be selected as None. 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 the desktops to clients.
  3. The Session Providers dropdown control will list all configured Session Providers.
2. Dynamic: For provisioning new desktops by cloning gold images, the Provisioning Type should be selected as Dynamic. Selecting Provisioning Type as Dynamic enables the following:
  1. The Session Providers dropdown control will list all configured Session Providers which 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 are to be used for provisioning and preparing customized new desktops.
  3. Will remove the Desktop Assignment screen, as dynamically provisioned desktops are assigned automatically.
    1. Logically all the desktops are going to have the same configuration so it is not required to assign them manually.
    2. Desktops are going to be created on demand, as such prior assignment will not be possible.
Assignment Lifespan: This option defines if the client assignment to the Desktop will persist after the session or not. 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 the clients (Devices or Users) which 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 that at every successful logon event, the session can be assigned to a different Desktop. 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 to assign the desktop upon user logon.
  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 desktop session is disconnected.

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 option available in the Deployment screen and its meaning.

Source VM

Source VM also termed as gold image, will be copied multiple times to provision multiple Desktops. 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 source VM.
- HyWorks Desktop Agent Installation: Source VM should have HyWorks Desktop Agent installed as HyWorks Desktop Agent is required for post-installation customization of the virtual machine and ensures remote access for new valid users.
- Source VM Power State: Should be in running state which helps HyWorks Controller to determine the HyWorks Desktop Agent ailability in the Source VM. However, if administrator knows that all prerequisites are correctly installed and configured in gold image then gold image machine can be kept in powered-off state as well.
- Source VM should be a Fresh Installed Image: Source VM should preferably be a fresh installed virtual machine. Using a virtual machine as source VM which was created using provisioning may result in customization failure since customization can be done only once on virtual machines.

Following links Windows Gold Image or Linux Gold Image for detailed information on gold master or source image preparation.

Note

While selecting a source VM, if it is in powered off state or HyWorks is unable to connect to desktop agent, it will show warning message. However, if Administrator is sure about the selected Desktop (any displayed configuration error can be ignored) click Continue Anyway to proceed or click Cancel to cancel the Source VM selection dialog and correcting the issues on virtual machine.

Source VM OS: To be set as Linux or Windows as per the operating system of source VM. Selecting source VM as Linux will hide option Dedicated Linux VM Pool from Advanced configuration tab of pool wizard and also will hide option Sysprep from customization wizard.
Clone from Snapshot

Select this option, if clones should be created from specific snapshot/checkpoint on virtual machine. Please note, not all providers support this operation and thus if selected provider does not support this, the option will be disabled. Selecting Clone from snapshot, enables option to select snapshot, which provide list of all available snapshots.
Desktop Name Prefix

HyWorks uses the desktop name prefix with appending unique number to create desktops on respective Hypervisor.
HyWorks append a hyphen(-) and number in XXXX format e.g. a prefix as AccVDI, controller will create VMs with name as AccVDI-0001, AccVDI-0002, AccVDI-0003 and so on.
Including the hyphen and number as XXXX, 5 more characters are added to the desktop name and thus administrator must consider that the name of the VM should not exceed the allowed number of characters in the respective dedicated session provider.
Note
- Providing a prefix with text which will make a duplicate name after appending the number is not validated in Desktop Pool wizard and thus results in Desktop creation failure.
- It's a mandatory field in Deployment screen, keeping it blank will display relevant error.
Clone Type

Clone type field in Desktop deployment defines the type of clones to be created of 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 operation. The ongoing operation of a full clone is an entirely separate entity from the parent virtual machine.
2. Linked Clone: A linked clone is a copy of a virtual machine that shares virtual disks with the parent virtual machine in an ongoing manner. This helps in conserving disk space and allows multiple virtual machines to use the same software installation.
  - Linked Clones in HyWorks: Linked cloning in HyWorks uses the following mechanism:
    1. When Linked Clones are initiated, HyWorks creates an exact replica or full clone of the Gold Image (Source VM).
    2. Then linked clone of Replica VMs are created.
    3. Having a replica VM ensures that if the gold image is modified in any manner, linked clones won't get affected, and if it requires to re-create all the linked cloned desktops then a new replica VM can be deployed from gold image.
Refer 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 HyWorks Controller will start creating the virtual machine as per the provided number and in case a Dedicated Session The provider is not having enough resources, provisioning will fail.
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:
Provision all Desktops now: Proceeding in the Desktop Pool wizard with the schedule as Provision all Desktop now will create all desktops as per the specified Max Desktop Capacity.
On-Demand: Create desktops as per the demand arrives. While configuring Desktops on demand following two parameters are considered
- Count of Desktops to Create Now: Defines how many desktops should be created first. E.g. if the Create Now Desktops count is specified as 2, then at least 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 2 desktops will always be free and as soon as the count of free desktop count goes to 1 it will start creating a new desktop to maintain the spare Desktop count. In this manner, HyWorks Controller will create desktops up to reach Max Desktop Capacity**.
Administrator can choose any of desktop creation schedule as per requirement.
Power on Desktop Post Provisioning

Keeping the checkbox selected will power on the virtual machine after cloning is completed whereas un-checking 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 of desktop VMs fresh state and if needed, DVMs or whole pool can be revered to fresh state using Reset operation.
1. Not all providers support this option, please refer section Functioning Support Provider-wise for detailed information on provider support. Providers that 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

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

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

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

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

Working:
- During cloning pool, HyWorks Controller adds tags in VM, Network and IP Address object in Azure.
- In Recompose or recreate desktop operation, Controller sends flag to preserve Network Interface while deleting DVM.
  - Which means the deployed VM will be deleted, but associated network object will be preserved.
- When HyWorks controller, redeploys the VM, then it re-associates the preserved network object using the tag names.
Limitations:
- Azure Network will work with same gold VM only and thus:
  - If gold VM is changed then network preserve will not work and will be unchecked.
  - With Network preserve option enabled, change in gold VM will not be allowed.
- If clone VM fails (after delete VM with network preserve) , the azure network object will be deleted.
VM Disk Encryption(Azure)

This option is enabled for Azure desktop provider only and is used to encrypt VM disk, post syprep (If enabled).

Following types of disk encryption mechanisms are supported in HyWorks:
- Platform Managed Key (Azure's Default) - Azure uses Server Side Encryption (SSE) with Platform Managed Key (PMK), as default.
- Customer Managed Key - For customer managed key, Disk Encryption Set is needed. Following types of encryption can be used, while creating 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, select Disk Encryption Set created earlier -> Properties-> Resource Id.
- Azure Disk Encryption - On selecting this option, Server Side Encryption (SSE) with Platform Managed Key (PMK), and Azure disk encryption (ADE) both are used to encrypt VM disks. For ADE , on Windows platform Bitlocker is used and on Linux platform Crypto used. Check Azure for Linux platform support.
  
  For this option, need to configure 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 key (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 for encryption using Customer Managed Key or using Azure Disk Encryption.

Refer section for Azure Disk Encryption Details
Target Locations of Clones VMs

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

Deployment settings gets dynamically updated as per selected Clone Type option in following manner:
1. For Linked Clone: Option to choose Replica VM Deployment Settings, gets enabled along with Cloned VMs Deployment Settings.
2. For Full Clone: Option for Cloned VMs Deployment Settings gets 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, following configurations will be available:
- Replica VM Deployment Settings: The section can be used to change the location of the replica VM on the dedicated session provider. To change configurations of the replica VM, Click Change Location.
  - Change Location
    
    Clicking on Change Location will open the Available Datastores dialog, which can be used to specify a new location 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 the Change Location to invoke the Available Datastores dialog, and follow the steps mentioned in the 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 the error no data centers found.
  - Hyper-V Servers: With Hyper-V Servers administrator will be able to change the Datastores up to the available drive level and pool selection will not be available.
    
    Changing the Datastore in the case of Hyper-V servers will create a folder with the name Accops-Cloned-VMs in the selected drive and will keep Desktops files in a 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: The current version uses the same configurations as gold master, though options can be shown to change the 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

The deployment screen ensures the deployment options that affects the new DVM configurations on the 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, a customization screen can be used. On Customization screen administrator can opt to enable or disable customization.

Before moving to the Customization process or available options, we must learn that a 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 customization will create identical desktops in terms of computer name, network settings, locale, and product key. This can be a handy option if an administrator is willing to customize new Desktops manually from a Dedicated Session Provider or using an independent tool. To disable customization,

Select the option No customization and proceed to the next screen.

Enabling Customization

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

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

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:

Owner Name: Owner name of the Desktop (Optional).
Organization Name: Organization name of the Desktop (Optional).
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. The 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.
Local Username: The new local user is to be created on the 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.
Local Password and Confirm Local Password: Password to be set for new local user (* Mandatory field if local username is provided)
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).
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).
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).
AD Group: Specify comma separated active directory groups. Provisioned VMs will be made member of these groups.
Select Locale: For configuring the local language of the new Desktop.
OS Product Key: Provide the Volume product key to be applied to the new Desktop. However, if creating multiple VMs, this should be a mass activation key or left blank for activating the OS later manually.

Click here to learn more about the user permissions required to join a desktop to an AD Domain.

Desktop Pool Management

Administrator can use VDI > Pools section to:

Add Desktop Pool.
Edit Desktop Pool.
Delete Desktop Pool.
Move desktops to maintenance mode.
Reset desktop pool (Non-persistent desktop pools or desktop pools deployed with Enabled DVM Reset option checked).
Export Desktop Pools.

Desktop Pool wizard presents several configurable properties in different screens of Desktop Pool wizard; we will try to understand different Desktop Pool concepts and associated fields in this section of the document from Add Desktop Pool wizard.

Add Desktop Pool

In the previous section, different screens of the desktop pool wizard, and different types of configurations (Common/ important) are already shared, in this section details will be provided as to how different types of desktop pools can be added in HyWorks.

Following the classifications of desktop pools in section Desktop Pool Categorization, administrator can opt for the following two types of desktop deliveries to end users:

This section will include details for creating several types of desktop pools under these categories:

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.

Prerequisites

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.
Devices are registered with HyWorks Controller.
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:

Prerequisites

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.
Devices are registered with HyWorks Controller.
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

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.
A valid authentication server (Microsoft AD, Built-in, or Novell eDirectory) is configured—this is Required to validate the user credentials used for login.
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

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.
A valid authentication server (Microsoft AD, Built-in, or Novell eDirectory) is configured—this is Required to validate the user credentials used for login.
All required users exist on the authentication server.
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

An appropriate physical PC dedicated desktop provider is added to HyWorks.
Physical desktops are added in physical desktops.
All added desktops are powered on and reachable from HyWorks/ client on the given host address and port.
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

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.

Save the desktop pool.
All added desktops will now be visible on the Desktop VMs page.
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

An appropriate Dedicated Session Provider, i.e., vCenter Server/ SCVMM, is configured (Only vCenter Server or SCVMM supports Linked Clones).
vCenter Server has a source VM that is ready to create multiple linked clones of it.
Devices are registered with HyWorks Controller.
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.

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.
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).
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

We have provisioned a total of 3 Desktops, and all Desktops will be free initially.
Once User-1 logs in from device-1, it will be assigned to either of 3 available Desktops, say Desktop-1.
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.
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.
All assignments will be removed once users log out of the session on their respective desktops.
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:

HyWorks first deploys and customizes VMs as per deployment settings.
Once the VM is in a ready (Fresh) state, HyWorks creates a restore point representing the fresh state.
When the user logs in, the desktop will get assigned to the user.
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.

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.

Edit Desktop Pool

Edit Desktop Pool wizard presents different editable options to administrators according to the type of pool being modified.

In this section, details of pool editing process, modifiable options of several types of Desktop Pools will be provided.

How to Edit a Desktop Pool

To edit a pool, following steps should be followed:

Go to VDI > Pools page.
Select the desktop pool needs modifications.
Click Edit -- It will open Edit Desktop Pool wizard.
Update the configurations as per requirement in General, Desktops (for pools using existing desktops), Deployment/Customization (for pool using dynamic provisioning), Users/ Devices, Desktop Assignments (for pools using existing desktops), Client Groups or Advance screens.
On Summary screen, verify if updated information is displayed.
Click Finish to complete pool edit process.

Editing Desktop Pools of Distinct Types

The section will describe modifying process of desktop pools of several types and the options which can be edited in Edit Desktop Pool wizard.

Editing Desktop Pool Having Existing Dedicated Desktops

Following configurations can be modified for desktop pools with existing desktops:

General Configuration:
- Name/ Description.
- Assignment Life Span.
- Connection Profiles.
Desktops:
- Add More Desktops.
- Remove added Desktops.
Clients:
- Add/ Remove Clients (Users/Devices).
Change Assignments
- Change Assignment Type from Manual to Auto-assignment or vice versa.
- Change mapping of desktops to clients.
Client Group
- Change access policy from Unrestricted access to From specific client groups only or vice versa.
- If client group is already selected then move client groups from restricted to allowed and vice versa.
Update Advance Options

Editing Desktop Pool having Provisioned Dedicated Desktops

In Edit Desktop Pool wizard, which uses Dynamic Desktop Provisioning to provision new desktops, presents the following options to administrator:

Stop Provisioning.
Modifying other pool configurations: Following editable options are available for desktop pool with dynamic desktop provisioning:
- General Information
  - Name.
  - Description.
  - Assignment Life Span.
  - Stop Provisioning (* Only when provisioning is in progress).
- Deployment Tab
  - Recompose
    - Source VM.
    - Desktop Name Prefix.
    - Clone Type.
    - Max Desktop Capacity.
    - Power on Configuration.
    - Advance Options.
  - Without Recompose
    - Change Max Desktop Capacity.
    - Power on Option.
- Customization
- Desktops
  - Remove Provisioned Desktop from Pool.
- Devices/ Users
  - Add/ Remove new clients (Devices/ Users).
- Client Group
  - Change access policy from Unrestricted access to From specific client groups only or vice versa.
  - If client group is already selected then move client groups from restricted to allowed and vice versa.
- Advance Options.

Stop Provisioning

Launching Edit Desktop Pool wizard, when desktop provisioning in progress; presents option to Stop Provisioning.

To stop provisioning following steps can be followed:

Go to VDI > Pools page.
Select the Desktop Pool on which Desktop Provisioning is in progress (Can be identified by its Status in Desktop Pool-- Status should be Cloning Desktops).
Click Edit: It will open Edit Desktop Pool wizard.
Click Stop Provisioning.
Confirm the action by clicking on Stop on Confirm Action dialog.
Desktop provisioning will be stopped:

a. Any task of cloning (currently in progress) will be completed and will not be canceled.

b. HyWorks Controller will not provision any new Desktops.

c. Desktop Pools status will be changed to Cloning Desktops Cancelled.
Appropriate Log entries will be created for the action.

Warning

Sometimes 'Stop Provisioning' may leave some residual Desktops in respective Dedicated Session Provider and administrator will be required to cleanup such Desktops from Dedicated Session Providers manually.

Recompose

As the term suggests, if administrator needs to re-provision all deployed desktop, recompose of provisioned desktop can be initiated by selecting Recompose checkbox and modifying all deployment options as allowed.

Recompose in HyWorks, allows administrator to re-provision all the desktops and at the same time keeps the assignment and other options intact for the desktop pool.

Recompose Candidates

Recompose should be done on the desktop pools where provisioning is completed. Recomposing desktop pools with provisioning in progress is not possible, as no actions are allowed with provisioning in progress.

Recompose Mechanism for Distinct Types of Clones

Linked Clone Provisioned Desktop Pool

On initiating Linked Cloned Provisioned Desktop Pool, following changes will be done:
1. All linked cloned desktops will be deleted
2. Replica Image will be deleted
3. New replica image will be created from the specified gold image
4. New desktops (linked cloned) will be provisioned
  1. The configurations of old desktops will be retained, and new desktops will have same configurations i.e. VM Name, Computer Name, client assignments etc.
Full Clone Provisioned Desktop Pool

With desktop pool having full cloned provisioned desktops, following changes will be done:
1. All provisioned desktops (full cloned) will be deleted
2. New desktops (Full Cloned) will be provisioned
  1. The configurations of old desktops will be retained, and new desktops will have same configurations i.e. VM Name, Computer Name, client assignments etc.

Recompose -- How To

Follow the below steps to recompose a provisioned desktop pool:

Select a desktop pool having provisioned desktops with all provisioning tasks are done
Modify general configurations (If needed)
On Deployment screen, select checkbox Recompose
1. Select Recompose Type as All VMs Now (Forceful) or Only Free VMs (Graceful)
Modify all the available options with recompose enabled. With Recompose enabled, only following configurations can be modified:
1. Deployment Configurations:
  1. Source VM: Administrator can select any other gold image for provisioning
  2. Clone from Snapshot: If snapshot pointer to be changed, new snapshot or current state can be selected
  3. Desktop Name Prefix: Administrator can choose to change the Desktop Name Prefix
  4. Clone Type: If selected dedicated session provider is a vCenter Server/SCVMM then administrator will also have option to change the Clone Type
  5. Power on Desktop Post Provisioning Configuration: If needed, power on configuration can be changed
  6. Deployment Settings: Administrator will also be able to modify the deployment settings for cloned desktops and replica image (only applicable if Clone Type is Linked Clone)
2. Customization Configurations:
  1. All configurations can be modified as needed
3. Other configurations:
  1. Modify as needed
Finish the Edit Desktop Pool wizard
All provisioned desktops will be deleted
HyWorks Controller will start provisioning new Desktops as per new deployment options

Recompose Example

Let us try to understand recompose process using an example.

Configuration: Desktop Pool-1 has been created using Dynamic Desktop Provisioning where 5 desktops were created (say Win7-Org-1 to Win7-Org-5)

a. The provisioned desktops are in use and assigned to devices
Recompose is needed and in recompose the desktop pool has been modified to change desktop name as Recompose. Now the desktops will be recomposed with new name, but the assignments will be retained
Desktops VMs tab will display information on provisioning of new Desktops

a. Observe that assignments are retained.
Note
1. Initially Desktops VMs tab may display Desktops names with old names but eventually old Desktops will be deleted and new Desktops as per new deployment options will be created
2. Recompose, keeps the configurations of desktop pool same as before but the count cannot be modified, while recomposing the pool.
3. Recompose, in current version does not create desktops in sequential order
Appropriate Log entries will be displayed in Logs tab for all recompose tasks.

Recompose v2: Graceful Recompose in HyWorks v3.4-SP1 or Later

Accops HyWorks provides a recompose option for deployed desktop pools, allowing administrators to re-provision all desktops while preserving the assignment and other configurations.

In earlier versions, recomposing a desktop pool involved deleting all VMs and creating new ones, leading to downtime for users as they had to wait for desktops to become available or force the recomposition. The latest version of HyWorks Controller supports VM recreation for free VMs while preserving configurations. Occupied VMs are recreated once they become available, allowing administrators to initiate a recompose operation on a pool even when some VMs are connected without disrupting running sessions.

Supported in version: HyWorks Controller v3.4-SP1 or later

Connector Support: Graceful recompose and Revert to version are supported with below session providers:

vCenter (Full Clone only)
Azure
Nutanix

Challenges in Previous Recompose:

The recomposition requires 100 % downtime.
The IT Admin needs to monitor the recompose process actively.
There was no option to revert to previous images and pool settings.
There was no selective rollout of VMs.

Advanced Features in Latest HyWorks Recompose:

Options to recompose a specific number of desktop VMs.
Version management: All VMs can be associated with a specific image version.
Reverting to a specific version: Option to revert to any previous VM versions.

Benefits for Administrators:

Selective rollouts for improved flexibility.
Reduced monitoring requirements.
Easy rollback to previous versions.
Version management for better identification.

New Recompose Options

The new recompose offers the following options for administrators:

All VMs Now (Forceful): This option functions similarly to earlier versions, where all VMs are deleted upon initiating the recompose, and new VMs are created. To initiate forceful recompose:
- Edit a desktop pool
- Go to the Deployment tab.
- Enable checkbox for Recompose checkbox.
- Select Recompose type as All VMs Now (Forceful)
- Save the pool.

This option is supported by all session providers that support dynamically provisioned desktop pools.

Only Free VMs (Graceful): This feature is integrated into the latest HyWorks Controller and offers two recompose rollout options:
1. All Free VMs: All VMs that are not in use are instantly deleted and recreated, while occupied VMs are redeployed once they become available.
  - Edit a desktop pool.
  - Go to the Deployment tab.
  - Enable the Recompose checkbox, select the Recompose type as Only Free VMs (Graceful), and select the Recompose rollout type as All Free VMs.
  - Save the pool.
2. Limited (Specified no of VMs): It provides an option to redeploy only a specific number of VMs, and for redeploying the VMs, first, it checks for the free VMs and then redeploys VMs as per the number configured. For initiating graceful recompose with recompose rollout type as Limited (Specified no of VMs):
  - Edit a desktop pool.
  - Go to the Deployment tab and enable the checkbox for Recompose.
  - Select the Recompose type as Only Free VMs (Graceful), select the Recompose rollout type as Limited, and provide the number per the requirement.
  - Save the pool.

Note

For graceful recompose, it is mandatory to select "Clone from checkpoint."
The checkpoint feature is available in Azure providers, while administrators of other providers must create snapshots/checkpoints from their hypervisor management portals.

Version

In desktop pools, the "Version" now represents a specific set of configurations associated with the deployment. This version is linked directly to the following pool configurations:

Desktop customization
Gold Master
Gold Master (Snapshot/Checkpoint)
VM Name Prefix

Move to Version

The latest HyWorks Controller introduces the Move to Version functionality to maintain recompose history and enable future VM redeployment based on previous configurations. Administrators can revert VMs or the entire pool to any earlier version.

Move to Version from Pool Page: For redeploying the whole pool:
- Select the desktop pool and click on the Move to Version button.
- Current and previous version details will be displayed in a pop-up window.
- Select the version details to which all VMs from the pool should be moved.
- Click the Move button, and all VMs from the pool will be moved to selected versions.
Move to version from VMs Page:
- On the VMs page, select one or more VMs to be moved to a specific version and click the button.
- Choose Recompose Type as Only Free VMs (Graceful) or All VMs Now (Forceful)
- Select the version and click the Move button to redeploy a particular VM(s).

Process to Recompose Selective VMs

If it is needed to apply the recompose to only selective VMs, the following process can be followed:

Edit the desktop pool.
In Deployment tab > Enable checkbox for Recompose checkbox.
Select the Recompose type as Only Free VMs (Graceful), select the Recompose rollout type as Limited to, and provide the number as "0" per the requirement.
1. Select the appropriate snapshot/image to be associated with the version. (if needed)
Save the pool. This will help create a version without pushing upgrades to any VMs.
Now go to the Desktops page and filter out desktops from the pool updated in the above step.
Select one or more desktops and click on Move to version.
In the Move to Version window, a list of versions will be displayed with details like (Version Number, Gold Master Name, Snapshot Name, Date, and Time).
1. Select the version.
2. Click on Move.
The selected VM(s) will now be recomposed and moved to the selected version.
Desktop pages and logs can be checked to check the progress and status of the tasks.

Other modifications in Provisioned Desktop Pool without Recompose

In Edit Desktop Pool wizard for desktop pool with provisioned desktops, administrator can also modify other deployment options without recomposing the desktop pool. Following options are editable in such desktop pools:

Deployment Screen: Only following configurations are editable in Deployment screen:
- Max Desktop Capacity
- Desktop Creation Schedule (If it was enabled while creating desktop pool)
- Deployment Settings
All other screens provide editable options as specified in above sections.

The edit process remains same as specified in above section.

Delete Desktop Pool

The administrator can delete a Desktop Pool from HyWorks deployment using following steps:

Select Desktop Pool from Desktop Pools tab.
Click Delete.
Deleting options for provisioned desktop pools or desktop pools with existing desktops.
1. If it's a provisioned desktop pool Confirm Action dialog will be displayed, showing the checkbox as Delete the desktops (if any) that have been deployed by this pool.
  1. Keeping the option checked will delete all provisioned desktops from the dedicated session provider as well.
  2. Unchecking the checkbox will delete the desktop pool and all configurations from HyWorks but will leave the desktops on dedicated session provider.
2. For Desktop Pools (Using existing Desktops), the Confirm Action dialog, will not have any checkbox for deleting the desktops and thus confirming the pool deletion only deletes the desktop pool configuration from HyWorks Management Console.
Enter minimum first 5 correct characters from pool name to confirm delete action.
Click Delete on Confirm Action dialog.
Desktop Pool will be deleted, and all associated Desktops will also be removed from Desktops VMs tab.

Add to Maintenance

A desktop pool can be moved to maintenance mode to perform maintenance activities on it. In maintenance mode, the desktop pool will be processed by HyWorks Controller, but users will not be able to access desktops from the pool.

To enable maintenance mode in desktop pool:

Select desktop pool from list.
Click Add to maintenance.
On Confirm Action dialog box, Click OK
Desktop pool will move to maintenance mode. HyWorks will continue to process in backend but end-users will not be allowed to access virtual desktops from the pool.

Reset Desktop Pool

For non-persistent desktop pools or deployed desktop pools that are enabled with the DVM Reset option, the administrator can reset all desktops in a desktop pool using Reset.

To reset a desktop pool, follow below steps:

Select desktop pool from list.
Click Reset.
On Confirm Action dialog box, Click Reset.
All desktops in the desktop pool will be reverted to their respective restore point.

Desktop Pools Page and Available Information

Once Desktop Pools are created by providing appropriate details in Add Desktop Pool wizard, Desktop Pools page is refreshed and displays following information of configured Desktop Pools using different columns.

Pool Name and Display Name:
- Desktop Pool Name and Display Name as provided in General screen
Pool Type and Entitlement Type
- Pool Type (persistence or non-persistent) and Entitlement Type (user based or device based) as provided in General screen
Provider/Team Name and Type
- Name of session provider or session host team
- Type of session provider
Desktop Provisioning and Connection Profile
- Desktop Provisioning configuration as Deployed for dynamic and None
- Connection Profile if configured else None
Assignment Life Span/ DVM Persistence:
- Lifespan as Personal or On demand
- DVM Persistence as Persistent or Non-persistent
Desktops Ready
- Total number of ready Desktops
- Not applicable (NA) for Microsoft RDS Server Desktop Pools
Desktops in Use
- Desktops already assigned or being used in session
- Not applicable (NA) for Microsoft RDS Server Desktop Pools
Free Desktops
- Unassigned Desktops in Pool, available for assignments and connection
Status
- Ready (Default fonts)
- Ready in maintenance (Orange Font)
- Cloning Desktops (If provisioning is in progress)
- Cloning failed
- Recomposing
Status - Information(i)
- Maintenance symbol.
- Pool cloning, recomposing , cloning failed information displayed on mouse over on symbol.
Active
- If Desktop Pool is active or not

Important Aspects of Desktop Delivery in HyWorks

In this section, we will try to learn some important aspects that can be used while deploying desktops:

Provisioning and Customization Process in HyWorks

Details about prerequisites for desktop customization and flow will be provided in this section:

Desktop Customization Pre-requisites and Limitations

The source VM must have Hypervisor tools installed (For VMware ESXi/vCenter server VMware tools, for Microsoft Hyper-V/SCVMM integration services setup and for Nutanix, Nutanix Guest tools should be installed)
The source VM must have HyWorks Desktop Agent installed to initiate the customization
The source VM must be a fresh installed virtual machine in which customization is not run earlier. A single Desktop cannot be customized twice.
- Applicable for Sysprep only, for Hyprep, it is expected to work fine as there is no restriction). and thus if source VM is already customized once the clones i.e. new Desktops will not be able to run customization.
The source VM should not be having expired product key as customization may get interrupted due to the activation notification thrown in between.
The source VM should be configured with DHCP network settings as all clones will be created with the same network settings thus causing IP conflict and affecting HyWorks Controller to Desktop Agent communication. VM Auto sleep and power options must be disabled.
When joining cloned VMs to domain:
- Specified credentials should have adequate rights on the target OU (if specified) or else on the domain controller to create objects.
- Cloned VMs must be able to communicate with a domain controller to move it to a specified domain (specify DNS servers or DNS servers are provided by DHCP).

Flow of events for desktop customization

The Desktop Customization in HyWorks deployment is done using the following flow sequence:

Once all the customization attributes are properly configured and the administrator committed to the pool changes by completing the Desktop Pool Wizard, and HyWorks Controller will mark that the new Desktops will require customization. (This can be observed in Desktop Details dialog -> SYSPREP Info).
Source VM will be powered off and will be cloned multiple times as specified - New Desktops will be created as per the provided deployment options.
Desktops will be powered on automatically if configured or will require manual power on from administrator if Power on Desktop Post Provisioning is not enabled.
After Desktops are powered on, HyWorks Controller will try to communicate with HyWorks Desktop Agent on each Desktop.

Note

This step requires that the source VM must have hypervisor tools and HyWorks Desktop Agent installed.
Till step# 4, new Desktops are replicas of the source VM, Desktop details will display attribute SYSPREP Info as Required, which specifies that the new Desktop will require customization.
Once the HyWorks Controller can communicate with the HyWorks Desktop Agent on new Desktops, it will share the customization details with each Desktop.
Desktops will be rebooted and will run setup to customize the Desktop as per provided parameters (This step may take several minutes depending on the hardware, software resources, and network settings).
Once the setup is completed, as inputs provided in the pool customization tab, all new Desktops will have a unique name, a local user with a provided password, joined with a specified domain or workgroup, set with specified locale, and activated with the provided OS Product key.

The Desktop status will start displaying as Responding in Desktops VMs tab with the Sysprep Info attribute showing as completed

HyPrep and Sysprep for Desktop Customization

The latest HyWorks DVM Tools support the following two methods of preparing cloned systems for usage in deployment:

Sysprep: Sysprep (System Preparation) prepares a Windows installation (Windows client and Windows Server) for imaging, allowing you to capture a customized installation. Sysprep removes PC-specific information from a Windows installation, "generalizing" the installation so it can be installed on different PCs.
- Applicable for Windows systems only
Hyprep: Accops own system preparation tool with faster processing. Hyprep can be used for fast deployment.
- Default for Linux systems.
- Can be used for Windows systems.
- Does not change Security Identifier (SID).
- Requires object(Computer) creation and deletion privileges for user being used to join the domain.

How to use Hyprep

In latest HyWorks Controller, desktop customization can be controlled from HyWorks Controller Management Console > Add Desktop Pool > Dynamic > Customization screen.

To use Hyprep, set Customization as Hyprep.
To use Sysprep, set Customization as Sysprep.
To use identical machines as source VM, keep Customization as No customization.

Older HyWorks Controller v3.2 does not provide option to use Hyprep from management console. Hyprep can be enabled on gold image using registry settings. To enable Hyprep:

Connect to gold image with the user having administrator privileges.
Open registry editor.
Go to HKLM\SOFTWARE\Accops\DVMAgent..
Change registry value of USEHYPREPTool to true.
Now clones machine will be customized using Hyprep.
Keeping it as false will continue to use Sysprep as default system preparation tool.

HyWorks Fallback Model for Delivering Best Available VM to user

The logical fallback model best fits for desktop pools with floating assignment, where desktop assignments are removed on user logout and a new user is assigned with desktop as per the availability. Within the desktop pool, a desktop may have the following status:

[Priority# 1] Powered on, IP (Network) available, DVM Agent installed and responding.
[Priority# 2] Powered on, IP (Network) available, DVM Agent not installed or not reachable.
[Priority# 3] Powered on, IP (network) not available.
[Priority# 4] Powered off or suspended.

Considering the above priority model, HyWorks behavior in different use cases can be defined as below:

HyWorks checks desktop availability on the above order only and provides the desktop that is best fit for the user. E.g. if a pool has 4 VMs with only one VM in the powered-on state with IP and agent in the reachable state, HyWorks will provide that desktop to the user.
Another logic added to the above fallback model, where HyWorks will try to provide a fresh or not accessed VM to the user unless all priority VMs are exhausted and every priority level works as a bucket for end-users. Consider the following examples:
1. A desktop pool with 3 VMs having agent responding, powered on state with IP, then if user-1 connects, VM-1 will be assigned to the user, if user-1 logs out and VM-1 is released (All VM-1,2 and 3 are available). If a new user, user-2 requests desktops, then HyWorks will try to provide VM-2 or VM-3.
2. If all VMs (VM-1,2 and 3) are currently in use and user-1 (accessing VM-1) logs out and releases VM-1. A new user, user-4 requests desktop access, then HyWorks will try to provide access of VM-1 only. Though it is most recently released but belong to the highest priority bucket.

Network Ready Desktops

In some cases, where users may use softwares affecting local networks (e.g. full tunnel VPN clients), then the respective machines may not remain usable after usage. Ideally in such situations, on user logout machine power policies should be set to reboot but still in some cases, HyWorks did not get notified and DVMs may remain unusable.

In such cases, the number of VMs available to end-user may keep on decreasing and thus it is important to assign only those VMs to users which are ready for connection.

To overcome such situations, HyWorks can be enabled to check reachability of all DVMs in a desktop pool explicitly on specific network (RDP) port and only those VMs will be provided with access, which are found available on network.

Now in previous section, priority order is already defined which now will get changed as below:

[Priority# 1] Powered on, IP (Network) available, DVM Agent installed and responding.
[Priority# 2] Powered on, IP (Network) available, DVM Agent not installed or not reachable.

Which means HyWorks will not provide access of any desktops which are not reachable and thus, avoiding any circumstances where user will be provided access of desktops which cannot be accessed.

Provider Failsafe Policies

As HyWorks has support to connect to hypervisor management layers (e.g. VMware vCenter servers, managing multiple ESXi servers, Microsoft SCVMM managing Hyper-V servers), management servers may be down through backend hypervisors and virtual machines hosted on those hypervisors are running fine on them.

In such cases, HyWorks is configured to use cached values of DVMs power status, network status, and provide access to clients (wherever applicable).

The feature does not guarantee that all users will be provided error free access to assigned VMs, but it serves many users for whom assigned VMs are in deliverable mode.

Failsafe policies can be controlled from Settings > General > Advance Config; following configurations are available:

Session provider failsafe policy: Suggesting if failsafe policy to be enabled or not. The default is true, suggesting by default failsafe policies are by default enabled.
Failsafe Policy Timeout (Min): Suggesting, for how long controller should continue to server sessions though provider is not reachable. Default is zero (0) means infinite.

What works and what fails with provider failure:

HyWorks will not be able to update the desktop power status or IP address.
Any desktops which is in running state and in connection ready state, will be given access.
Any desktop that is in not running state or in not ready state will be given access as per the fallback model but the connection may fail.
Provisioning will not work.
Any power operation initiated by HyWorks will not work.
Non-persistent desktops will not be able to revert to fresh state on user logout.
Adding new desktop pools or new desktops to existing desktop pools will be affected and not recommended.

One Desktop can used in only one desktop pool throughout HyWorks

A Desktop can be configured only in a single desktop pool in HyWorks deployment and thus Available Desktops dialog lists only virtual machines that are not yet configured in any of the Desktop Pools in the HyWorks Controller.

Therefore, if administrator is not able to see any specific virtual machine in Available Desktops dialog then either of the following conclusions can be made:

It has been already configured in any existing Desktop Pool
The Dedicated Session Provider cache does not have details of this Desktop (Can be resolved by refreshing the Available Desktops list as explained below).

ERR: DVM Details Duplication when Hypervisor and It's Management Server, both configured in HyWorks

As HyWorks supports desktop delivery from Microsoft Hyper-V as well as Microsoft SCVMM Server, in a similar manner it supports desktop delivery from ESXi servers as well as VMware vCenter Server as well. But if you configure a hypervisor and its management server both as a desktop provider, desktop VM details are duplicated and thus configuration may show some problems.

Reason: Every hypervisor keeps a unique ID for each VM and when a management server connects to the hypervisor the same unique Id is used. This unique ID helps in maintaining the identity of VMs even when their name or other attributes are the same.

HyWorks also uses this unique ID to identify VMs uniquely on the desktop provider and at the same time it maintains its unique IDs for each VM.

Consider a scenario:

VM on ESXi (Unique Id: EVM1) is added to HyWorks, HyWorks Id (HVM1).
vCenter Managing ESXi is also added (Which has a VM ID the same as ESXi).
vCenter is also added to HyWorks. So now if HyWorks will try to add one more VM as HVM2 pointing to the same EVM1(duplicate ID).
Now for every VM operation, HyWorks will have duplicate IDs and may show failures.

Conclusion:

It is not recommended to add a Hypervisor and its managing server as a dedicated session provider both in the same deployment of HyWorks. It may cause failures. Some examples could be:
1. ESXi server and vCenter Server
2. Hyper-V and SCVMM Server

Extended Functional Support in Physical PC

Some new features are added in the Physical desktop pool which are not provided in other type of desktop pool.

IP address or Host name support: While importing CSV desktops can be added using both IP address and host name, provided host names are resolvable from both HyWorks Controller and clients.
Microsoft RDS Delivery without HyWorks Session Host Agent: In physical desktop, same host can be added with different Desktop IDs and can be assigned to users to enable direct access of Microsoft RDS servers. An example CSV to publish Microsoft RDS Server in Physical PC is given below:

Add/Update,Desktop ID,Host Address
1, RDS41,192.168.1.4
1, RDS42,192.168.1.4
1, RDS43,192.168.1.4
1, RDS44,192.168.1.4

Assumptions and Limitations in Physical PC

Assumptions:

Some assumptions are there in case of Physical Desktop:

Installing Desktop agents should be done to facilitate remote access and other features like session management, time-outs etc.
Not having desktop agent will not block access to physical desktops but administrator must configure remote access for users and other supported functions will not work.

Limitations:

Limitations of physical desktop are as follows:

Power operations from management console are not supported. (For e.g., Powered off physical desktop cannot be powered on from controller automatically).
Power operations can not be performed from clients as well.
Dynamic provisioning cannot be performed on Physical desktops.

Exporting Desktop Pools Details

HyWorks Controller is having option to export CSV of all published desktop pools in the current organization from the management console. To export CSV of desktop pools:

Go to HyWorks Controller Management Console > VDI > Pools.
Click Export.
Select Encoding type and columns.
Click on Export.
CSV with details of all desktop pools will be downloaded.

Note

Use encoding type UTF_8 or Unicode while exporting pool data with Japanese characters. Using encoding type as Shift_JIS or ANSI will result in garbage characters for the entries having Japanese characters.

Advance Configuration

Refer section for Advance Configuration for pool

Management

Desktop Pool Categorization

Desktop Virtualization Type

Desktop Provisioning

Entitlement Type or Client Type

Assignment Lifespan

Configuration Options for Dedicated Desktop Pools

Common Configurations

Common Configurations of General Screen

Clients (Users/Devices) Screen

Desktop Assignment

Classification Rules

Advanced Configurations

Summary Screen

Important Configurations Affecting Deployment

General Screen

Deployment Screen

Customization Screen

Desktop Pool Management

Add Desktop Pool

Creating Desktop Pools of Several Types

Using Existing Desktops or Session Providers

Device Based - Personal Assignment Lifespan

Device-Based - Floating Assignment Lifespan

User Based - Personal Assignment Lifespan

User Based - Floating Assignment Lifespan

Using Dynamic Desktop Provisioning

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

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

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

Login and Connect to Assigned Desktop

Edit Desktop Pool

How to Edit a Desktop Pool

Editing Desktop Pools of Distinct Types

Editing Desktop Pool Having Existing Dedicated Desktops

Editing Desktop Pool having Provisioned Dedicated Desktops

Stop Provisioning

Recompose

Recompose Mechanism for Distinct Types of Clones

Recompose -- How To

Recompose Example

Recompose v2: Graceful Recompose in HyWorks v3.4-SP1 or Later

New Recompose Options

Version

Move to Version

Process to Recompose Selective VMs

Other modifications in Provisioned Desktop Pool without Recompose

Delete Desktop Pool

Add to Maintenance

Reset Desktop Pool

Desktop Pools Page and Available Information

Important Aspects of Desktop Delivery in HyWorks

Provisioning and Customization Process in HyWorks

HyPrep and Sysprep for Desktop Customization

HyWorks Fallback Model for Delivering Best Available VM to user

Network Ready Desktops

Provider Failsafe Policies

One Desktop can used in only one desktop pool throughout HyWorks

ERR: DVM Details Duplication when Hypervisor and It's Management Server, both configured in HyWorks

Extended Functional Support in Physical PC

Assumptions and Limitations in Physical PC

Exporting Desktop Pools Details

Advance Configuration