Desktop Pools to Deliver Desktops to End-users

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 pools of Desktops as well as associating the Desktops to 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. Click

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 which 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 as 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 tothe 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 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 specified time) or when the user logs out.
- On Login: The desktop will be assigned when the user logs on and un-assigned 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
Critical Configurations affecting deployment type: Configurations which will affect the whole deployment of desktops in HyWorks

Common Configurations

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 same or different than the name.
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 to access the desktop pool during deployment,
redeployment or maintenance activities.

Clients (Users/Devices) Screen

Devices/Users: Based on the Entitlement Type selected, screens Devices/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 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 Note:

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

Client Groups

Configure the Client Groups to restrict Shared Hosted Desktop access only to users who are connecting from a specific LAN or WAN or MAC. Refer to the Client Groups section to enable restricted client group's access,

Select the access policy as From specific client groups only
It will list the added client groups
Select the client groups and move them to the allowed list

Advanced Configurations

The following advanced configurations are commonly configured for users:

Advanced Screen

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 since 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 on perpetually
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.
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 Note:

    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 which will enable the delivery of only those desktops which are found ready for a desktop connection based on 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.
Use Connect Console: This feature is only available for Hyper-V dedicated session providers, where the VMs console session can be connected. Enabling this feature will require the following conditions to be met:
1. Provider must be a Hyper-V server
2. User credentials must have the authority to connect to the console of the VM
3. Port 2179 must be accessible from endpoints to Hyper-V server
4. Feature must be supported on HyDesk Hy3000/Hy4000, Windows Clients, Hy1000, Ubuntu Clients
5. Hy2000, HyLite do not support the Console Connect feature
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:
  1. 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.
  2. 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.
Use Pool Credential: A deployment-specific setting, where every desktop connection will use a common pool credential. This can be useful in deployments where the user profiles can be highly reduced as all users will log in with the given credentials but upon connecting, these configured pool credentials will be used. The following details need to be enabled for using pool credentials:
1. Username: Username must be used for logging on
2. Password: Password of the user must be used
3. Domain: Domain name/NetBIOS name to be used to logon. For local users specify dot (.)
Auto upgrade desktop agent: To be used to upgrade the HyWorks DVM tools. All desktops will be notified about the desktop agent upgrade 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
  
  4.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
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 VMs 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, 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
  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

Extended Configurations

Preferred 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 had this configuration as the registry entries and required the Controller ervice 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 which 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: Selecting the Virtualization Type as a Non-persistent Virtual Desktops will have following impact:
  1. Select Session Provider: Listing all the configured session providers which 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: 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 image, 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 to Desktop assignment is removed and is not remembered. Floating assignment can be further sub-divided 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. Deployment screen provides options for deployment of virtual machines. Let us try to understand the option available in Deployment screen and its meaning.

Source VM

Source VM also termed as gold image, will be copied multiple times to provision multiple Desktops. 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 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 availability 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.

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

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.
1. 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.
2. Including hyphen and number as XXXX, 5 more characters are added in desktop name and thus administrator must consider that the name of VM should not exceed allowed number of characters in 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. Ongoing operation of a full clone is 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 replica VM ensures that if 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 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 maximum number of Desktops to be created using Desktop Provisioning.

The field accepts value 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 provided number and in case Dedicated Session Provider is not having enough resources, provisioning will fail.
Desktop Creation Schedule

This parameter defines the schedule of new VM creation; administrator can choose to provision new desktops in the following two schedules:
1. Provision all Desktops now: Proceeding in Desktop Pool wizard with schedule as Provision all Desktop now will create all desktops as per specified Max Desktop Capacity.
2. 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 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 to be kept in Desktop Pool. E.g. 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 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 desktop 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 Desktop in 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 which support Non-persistent VMs will also support option to reset DVMs
2. Enable DVM Reset will be default enabled 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 recompose or recreate operations, HyWorks will remember the last assigned MAC address to deployed DVM and will 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 dedicated session provider. To change configurations of replica VM, Click Change Location.
  - Change Location
    
    Clicking on Change Location will open Available Datastores dialog, which can be used to specify new location for the replica VM.
    
    Administrator can select the following two locations attributes by expanding the resource tree:
    - Resource Pool
    - Datastore
- Cloned VMs Deployment Settings: Like replica VM deployment configurations, datastore and resource pool configurations of cloned VMs can also be modified. To modify the configurations of cloned VMs, Click Cloned VM Deployment Settings.
  - This will start displaying the currently applied configurations for cloned VMs (set to Default, which means same as gold image)
  - Click Change Location to invoke Available Datastores dialog, follow steps mentioned in above section to change configurations of cloned VMs.
  Important
  - Please note, Available Datastores dialog, displays all the available datastores and resource pools but it does not evaluate the feasibility of cloned VMs deployment on the target datastores or resource pool and administrator must choose these configurations carefully to avoid provisioning failure.
  - As a thumb rule, the datastores and resource pools should be chosen in a manner they are able to read from replica image.
- Deployment Settings Support for dedicated session providers
  - SCVMM Servers: These advanced deployment settings are not supported with SCVMM servers configured as Dedicated Session Providers though shown as enabled. Clicking on Change location with SCVMM server configured as Dedicated Session Provider will show the Available Data Stores dialog with error no data centers found.
  - Hyper-V Servers: With Hyper-V Servers administrator will be able to change the Datastores up to available drives level and pool selection will not be available.
    
    Changing the Datastore in case of Hyper-V servers will create a folder with name Accops-Cloned-VMs in the selected drive and will keep Desktops files in folder with the name of Desktop. As in the below screenshot where Datastore has been changed to D:\ drive, the newly created Desktops will be located at
    
    D:\Accops-Cloned-VMs\\<Desktop Name>.
  - VMware vCenter Server: As vCenter Servers presents two cases as per supported clone types and as per accessible ESXi servers.
    - Linked Clones: Option to move replica VM and cloned VMs are available.
      Please note the wizard will display the available Resource Pools and Datastores of all ESXi servers, but administrator should choose target locations carefully so that after completing the pool wizard provisioning does not fail.
    - Full Clone: In case of full clones with vCenter Server administrator will be able to change the Resource Pool or Datastore.
  - Nutanix: Current version uses same configurations as gold master, though options can be shown to change storage pool.

Customization Screen

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

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

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

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

Disabling customization

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

Select option No customization and proceed to next screen

Enabling Customization

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

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

Hyprep: Accops DVM agent on VDI will use Accops customization process. Hyprep is a quick VM customization process built 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. 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 to be created on new Desktop. (Optional)

Warning

If leaving Local Username field blank then, it should be making 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: Password to be set for new local user (* Mandatory field if local username is provided)
Workgroup/ Domain Configurations:
1. Join a workgroup is selected by default and requires entries in Workgroup textbox
2. Join a 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)
Select Locale: For configuring local language of new Desktop
OS Product Key: Provide Volume product key, to be applied on new Desktop however if creating multiple VMs then this should be mass activation key or should be left blank for activating the OS later manually.

Desktop Pool Management

Administrator can use Desktop 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)

Desktop Pool wizard presents number of 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 document from Add Desktop Pool wizard.

Add Desktop Pool

In previous section, different screens of desktop pool wizard, different types of configurations (Common/ important) are already shared, in this section details will be provided as 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 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

Administrator can proceed with Add Desktop Pool wizard to create 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 environment of different organizations. Administrator can simply choose the best fit case for the requirement and try creating a pool to fulfill it. In the below section of the document we will try to understand the process of creating several types of pools.

Using Existing Desktops or Session Providers

This section will cover creation of Desktop Pools using Desktops which are already present in the configured Dedicated Session Providers. Please note HyWorks Controller 2.1 supports Pooling of Dedicated Session Providers only, External Session Providers work without any pools. We will be covering use of External Session Provider Session Providers in a later section of document.

Device Based - Personal Assignment Lifespan

In any deployment, employees or professionals come to office premises, login to their respective desktops located at specific area and work from there.

Device based personally assigned pools replicate a similar environment where employee login from their respective devices and are provided with session of their dedicated desktops.

Pre-requisites

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
Valid authentication server (Microsoft AD, Built-in or Novell eDirectory) is configured - Required for validating the user credentials used for logon

Desktop Pool Configurations in 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 per requirement from selected dedicated session provider
Devices Screen	Search, select and add devices as per requirement from the list of available registered devices
Desktop Assignment Screen	As per requirement: 1. Auto assigned (if needed) or 2. Manually assign desktops to devices from desktop pool wizard or desktops screen
Advanced Screen	Configure as per requirement

Pool creation is completed and user on logon with specific endpoints will get the configured desktops.

Device Based - Floating Assignment Lifespan

In 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 location of the user and thus device is fixed but it does not matter which desktop has been assigned to the device considering all desktops are having same configurations and same users log in from the devices. E.g. a hospital where user (doctors) logs-in with a common username 'doctor' to access their desktop which does not have any local data rather work on a web-based application.

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

Pre-requisites

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
Valid authentication server (Microsoft AD, Built-in or Novell eDirectory) is configured - Required for validating the user credentials used for logon

Desktop Pool Configurations in 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 per requirement from selected dedicated session provider
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 temporary pool are retained only until first login and are erased after logout
Advanced Screen	Configure as per requirement

The pool creation is completed and user logging-in from the configured devices will be provided with appropriate Desktop session as per 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 scenario, a user based dedicated pool can be useful; where desktops are assigned to the users and irrespective of device, the session of same Desktop is provided to the user.

Below section will guide, how to create a user based personally assigned 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
Valid authentication server (Microsoft AD, Built-in or Novell eDirectory) is configured - Required for validating the user credentials used for logon
All required users exist on authentication server

Desktop Pool Configurations in 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 per requirement from selected dedicated session provider
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 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 to be specific to employee.

In such scenario, a user based dedicated pool can be useful; where Desktops are assigned to the users and irrespective of device, the session of different Desktop is provided to the user.

Below section will guide how to create a user based temporary assigned 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
Valid authentication server (Microsoft AD, Built-in or Novell eDirectory) is configured - Required for validating the user credentials used for logon
All required users exist on authentication server
Endpoints are configured correctly to login in to controller

Desktop pool configurations in different screens

User-based Temporary 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 per requirement from selected dedicated session provider
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 next one login and are cleared after logout
Advanced Screen	Configure as per requirement

The pool creation is completed and user logging-in from the configured devices will be provided with appropriate Desktop session.

Desktop Pool of Physical Desktops

To serve physical desktops configured in HyWorks, can be served using following configuration:

Prerequisites

Appropriate Physical PC dedicated desktop provider is added into HyWorks
Physical desktops are added in physical desktops
All added desktops are powered-on and reachable from HyWorks/ client on 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 in different screens

Add a desktop pool as per below example configuration

Screen Name	Configuration Attribute -->	Name/ Display Name/ Description	Entitlement Type	Desktop Pool Type	Select Session provider	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 per requirement from selected dedicated session provider
Users / Devices Screen	Search, select and add users/devices as per requirement from the list of available registered users/devices
Desktop Assignment Screen	Auto Assigned (Must) Or Manually assign desktops to users from desktop pool wizard or desktops 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 in Desktop VMs page
On logon, users will be assigned to respective desktops

Using Dynamic Desktop Provisioning

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

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

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

Below are 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 provisioned with clone type a Linked Clones and desktops will be permanently assigned to devices.

Prerequisites

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 Ready for creating multiple linked clones of it
Devices are registered with HyWorks Controller
Valid authentication server (Microsoft AD, Built-in or Novell eDirectory) is configured - Required for validating the user credentials used for logon

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 gold image machine, please check these configurations in respective section of this document.
Devices Screen	Search, select and add devices as per requirement.
Advanced Screen	Configure as per requirement

Important

As linked clones are supported with vCenter Server and Microsoft SCVMM only, hence selected dedicated session provider must be vCenter Server. If it is an ESXi, a Hyper-V, then Linked Clone option will not get enabled in Deployment Screen.
Desktop Assignment screen will not appear in Dynamic Desktop Provisioning pool, as all the desktops are going to have same configurations and thus any desktop can be assigned to any client (device/ 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 Desktop Pools tab: initially Desktop Pool status will be Cloning Desktops when Desktop Cloning is in progress and as soon as Desktop Cloning gets completed the status will be ready.

Another important thing to observe is that as per provided Desktop Creation Schedule only 2 Desktops have been created first.

Details in Desktops Tab and Flow of Client Assignments to Clients

Once the deployed dedicated desktop pool wizard is finished, Desktops tab can be used to see the provisioning progress as well understanding 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 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 status 'Pending Desktop Creations'
Desktop Provisioning - Create Now Completed: Initially controller will create desktops equal to the count provided in field No of Desktops to create now in Desktop Creation schedule all the Desktops will be displayed with Status as Powered On (This does not mean that desktops are ready, there will be more processes in backend to complete the desktop provisioning)
Customization Process: Customization will happen in the following manner:
1. Initially desktops will be marked with Sysprep Info flag as Required which means customization will be required on this Desktop. To see Desktops detailed status, Click it's name in Desktops VMs tab; Desktop Detail dialog will be displayed with all the information about the Desktop
2. HyWorks Controller will wait for new Desktops IP to be detected and once it's able to get the IP of new Desktop; it will try communicating with it.
3. Once Communication establishes, 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. New Desktop will get rebooted and will configure the customization as needed.
4. Sysprep Info flag will be marked as Completed, which means Desktop customization is completed
5. Desktop Agent status should now be Responding with Desktops DNS Name should display information which can help in identifying if Desktop has been customized correctly or not e.g. we configured Computer Name as DesktopLCWIn7 and configured it domain accops.com so the DNS name of new Desktop after provisioning should be 'DesktopLCWin7-0001.accops.local'.
6. Now provisioning is completed for first set of desktops as per specified Create Now Desktops count, but the desktops assignment is remaining.
  
  Case Study (User assignment):
  1. Assignment will happen when a valid user from one of the configured device logs-in or when administrator manually assigns the device from Desktops tab.
  2. Let us try to understand Auto Assignment and Desktop Creation Schedule process with an example:
    - We have provisioned Desktops as per below configurations: Maximum Desktop Capacity as 5, Desktop Creation Schedule as On Demand, where 2 Desktops create now and 2 Desktops to be kept in spare. The configured devices in Desktop Pools are Device-1, Device2....Device5.
    - In first step, as per above details also HyWorks Controller will create and customize 2 Desktops and will keep them unassigned say Desktop1 and Desktop2
    - Now as soon as a valid user from configured authentication server logs in from Device-1, HyWorks Controller will look for the ready Desktop and will assign the Desktop to Device-1. The assignment will also be remembered so if user from Device-1 logs in again same Desktop-1 will be presented.
    - Now as per configuration, HyWorks Controller must keep at least 2 Desktops in spare and once Desktop-1 is assigned to Device-1 which makes free Desktop count as 1 and now HyWorks Controller will start provisioning one more Desktop to keep spare Desktops as 2
Now if admin assigns or user logs in from Device-2, 2nd Desktop will be assigned to this device and HyWorks Controller will trigger creation of another Desktop which will be then provisioned and customized as per provided settings

The process of provisioning new Desktops will be continued until maximum Desktops capacity is reached which means HyWorks Controller has provisioned all 5 Desktops. Now login from Device-4 and Device-5 will be assigned with Desktop-4 and Desktop-5 but 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 a Full Clones and desktops will be assigned to users.

Case Study Configure desktop creation schedule

Prerequisites

Appropriate Dedicated Session Provider i.e. VMware vCenter Server or Microsoft Hyper-V/ SCVMM, Nutanix Prism Element/ Prism Central, Microsoft Azure is configured (These Dedicated Session Providers support Full Clones)
- Dedicated Session Provider has a source VM Ready for creating multiple linked clones of it
Valid authentication server (Microsoft AD, Built-in or Novell eDirectory) is configured - Required for validating the user credentials used for logon

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 gold image machine, please check these configurations in respective section 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 total of 3 Desktops and all Desktops will be free initially.
Once User-1 logs in from device-1, it will be assigned with either of 3 available Desktops say Desktop-1
If User-2 logs in with Desktop-1 already in session, User-2 will be assigned with Desktop-2 or Desktop-3 and if User-3 logs in with only Desktop-3 is remaining it will be provided with session of Desktop-3
If any other user logs in with all Desktops are already in use, user will be displayed appropriate error that no free Desktop is available.
Once users log out the session of respective Desktops, all the assignments will be removed
On next logon, again same process will be repeated where users will be assigned automatically as per availability and readiness of the desktops, but the old assignment will not be guaranteed.

User Based - Floating Assignment, Dynamic Provisioning Non-persistent

Create non-persistent desktop pool with floating assignments for users

Prerequisites

Appropriate Dedicated Session Provider e.g. VMware vCenter Server or Microsoft SCVMM or Nutanix Prism Element/ Prism Central is configured (These Dedicated Session Providers support non-persistent desktops)
- Dedicated Session Provider has a source VM Ready for creating multiple linked clones of it
Valid authentication server (Microsoft AD, Built-in or Novell eDirectory) is configured - Required for validating the user credentials used for logon

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 gold image machine, please check these configurations in respective section 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 done by a user in the session and thus a fresh VM is presented to user on next logon. How does it work:

HyWorks first deploys and customizes VMs as per deployment settings
Once VM is in ready (Fresh) state, HyWorks creates a restore point, which represents the fresh state
When user logs-in, desktop will get assigned to the user
On user logout, HyWorks revert the desktop to its fresh state using the restore point created.
1. Restored VM will be kept in power state as per configuration done for Power Action when user log-off

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

To verify if the pool is configured properly administrator can get users to login from appropriate devices to verify if only assigned Desktops is provided. Consider the examples below:

Device based personally assigned pool 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 session on device-1
  - In a same manner login from Device-2 will provide session of Desktop-2
User based pool with floating auto assignment
- Pool Configuration
  - Users - User-1 and User-2 are configured as clients in pool
  - Desktops - Desktop-1 and Desktop-2 are configured in pool and in responding state
- Login Process:
  - Login from any of registered device with user-1 credentials will provide session of any of Desktops I.e. Desktop-1 and Desktop-2. Assume session of Desktop-1 is provided to User-1
    - Now if User-2 attempts to login when desktop session of Desktop-1 is running then session of Desktop-2 will be provided to User-2.
  - Once desktop sessions are ended assignments will be removed and next logon from User-1 or User-2 credentials will randomly provide session of any of Desktops I.e. User-1 can be provided with session of Desktop-2 or Desktop-1.

Now administrator has successfully verified that the Desktop Pool is successfully configured, and users are able to connect to respective Desktops, administrator can happily work on other tasks when HyWorks Controller takes care of user access configuration and relevant tasks.

Important

Desktop Pool creation manages up to Desktop to Client (Devices/ Users) assignment level; the overall success of getting session depends on various other factors which must be addressed for successful HyWorks deployment. Few such factors are:

HyWorks DVM Tools installation on target Desktops, it ensures RDP enabling for logged-in user 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 administrator 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 Desktop 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 are using Dynamic Desktop Provisioning to provision new desktops, presents 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 Desktop 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 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
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.

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

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 checkbox as 'Delete the desktops (if any) which have been deployed by this pool?'
  1. Keeping the option checked will delete all provisioned desktops from 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, desktop pool will be processed by HyWorks Controller, but users will not be able to access desktops from 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.

Reset Desktop Pool

For non-persistent desktop pools or deployed desktop pools which are enabled with DVM Reset option, 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 desktop pool will be reverted to 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 which 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 VMware tools installed if selected Dedicated Session Provider is of type VMware/ vCenter Server (For Microsoft Hyper-V, 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 thrice only for Sysprep(for Hyprep, it 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 same network settings and thus causing IP conflict and affecting HyWorks Controller to Desktop Agent communication. VM Auto sleep and power option must be disabled.
When joining cloned VMs to domain:
- Specified credentials should have enough rights on the target OU (if specified) else on domain controller to create objects
- Cloned VMs must be able to communicate with domain controller to move it to specified domain (specify DNS servers or DNS servers are provided from 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 administrator committed the pool changes by completing the Desktop Pool wizard, 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 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 VMware tools and HyWorks Desktop Agent is installed
Till step# 4, new Desktops are exact replica of the source VM, Desktop details will display attribute SYSPREP Info as Required, which specifies that the new Desktop will require customization
Once HyWorks Controller can communicate with 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 while pool customization tab, all new Desktops will be having a unique name, a local user with provided password, joined with specified domain or workgroup, set with specified locale and activated with provided OS Product key.

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

HyPrep and Sysprep for Desktop Customization

Latest HyWorks DVM Tools support 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 domain

How to use Hyprep

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

In HyWorks Controller v3.3, 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

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 availability. Within desktop pool, a desktop may have 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 above order only and provides desktop which is best fit for the user. E.g. if a pool is having 4 VMs with only one VM in powered-on state with IP and agent in reachable state, HyWorks will provide that desktop to user.
Another logic added to the above fallback model, where HyWorks will try to provide a fresh or not accessed VM to user unless all priority VMs are exhausted and every priority level works as a bucket for end-users. Consider 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 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 readily available.

To overcome such situations, HyWorks can be enabled to check reachability of all DVMs in a desktop pool to be reachable 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), it is possible that management servers are down though 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 System -> Advanced Settings, following configurations are available:

Session provider failsafe policy: Suggesting if failsafe policy to be enabled or not. 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 desktop power status, IP address
Any desktops which is in running state and in connection ready state, will be given access
Any desktop which is in not running state or in not ready state, will be given access as per fallback model but 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 which 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).

DVM Details Duplication when Hypervisor and 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 hypervisor the same unique Id is used. This unique Id helps in maintaining identity of VMs even when their name or other attributes are same.

HyWorks also uses this unique Id to identify VM uniquely on desktop provider and at the same time it maintains its own 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 VM Id same as ESXi)
vCenter is also added to HyWorks. So now if HyWorks will try to add one more VM as HVM2 pointing to 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 dedicated session provider both in 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 v3.3 is having option to export CSV of all published desktop pools in current organization from management console. To export CSV of desktop pools:

1.Go to HyWorks Controller Management Console -> Workspace -> Desktop Pools

2.Click Export

3.Select Encoding type and columns

Export

5.CSV with details of all desktop pools will be downloaded.

Advance Configuration

Refer section for Advance Configuration for pool

Desktop Pools to Deliver Desktops to End-users

Desktop Pool Categorization

Desktop Virtualization Type

Desktop Provisioning

Entitlement Type or Client Type

Assignment Lifespan

Configuration Options for Dedicated Desktop Pools

Common Configurations

General Screen

Clients (Users/Devices) Screen

Desktop Assignment

Client Groups

Advanced Configurations

Advanced Screen

Extended 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

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

DVM Details Duplication when Hypervisor and Management Server, both configured in HyWorks

Extended Functional Support in Physical PC

Assumptions and Limitations in Physical PC

Exporting Desktop Pools Details

Advance Configuration