First-Gen Tenants - Desktop Assignments Based on Horizon Cloud Pods in Microsoft Azure

Tip: If you do not see any pods to select, verify that the Location list is not displaying a location without pods.

The Location field works on the Pod list to filter out pods that are not associated with the selected location. If you previously had a pod at a location and then deleted that pod or moved it to a different location, so that the displayed location no longer has any pods, the Pod list will display no entries.

Because the locations are listed alphabetically, when the screen opens, it automatically selects the one that is first in the alphabet.

If that location no longer has any pods associated with it, you must switch the location to a different entry.

Only farms that are in the selected pod and which not already involved in existing session desktop assignments are available for selection.

The name must contain only letters, hyphens, and numbers. Spaces are not allowed. The name cannot start with a non-alphabetic character.

Tip: If you do not see any pods to select, verify that the Location list is not displaying a location without pods. The Location field works on the Pod list to filter out pods that are not associated with the selected location.

If you previously had a pod at a location and then deleted that pod or moved it to a different location, so that the displayed location no longer has any pods, the Pod list will display no entries.

Because the locations are listed alphabetically, when the screen opens, it automatically selects the one that is first in the alphabet. If that location no longer has any pods associated with it, you must switch the location to a different entry.

When this toggle is switched off, the assignment's desktop VMs will be connected to the pod's primary VM subnet by default.

You can filter models by type, series, number of CPUs, memory, and tags. For more information about selecting models, see Managing VM Types and Sizes for Farms and Assignments in the Horizon Universal Console, which describes the options on the VM Types & Sizes page (Settings > VM Types & Sizes).

To set a filter, you first select the criterion in the drop-down menu and then enter the desired values. By default, there is a single filter with the criterion 'Tag' the value 'Recommended'. You can edit this first filter and add more filters connected by And and Or operators.

The following are the criteria you can use for filters and descriptions of the values you can enter for each.

• Type

  When you select this option, the second drop-down menu defaults to GPU and High Performance - Models with GPU.

  Note: If you choose a GPU model, then the list of images shown will contain only images that were created with the Include GPU flag selected, so you need at least one such image in order to create a farm or pool using a GPU model. If you choose a non-GPU model, then the list of images shown will contain only images that were created without the Include GPU flag.

• Series

  When you select this option, you can then select a series of models from a second drop-down menu. You can also filter this list by entering text in the Filter text box at the top of the list.

• CPUs

  When you select this option, you can then enter a CPU range.

  Important: For production environments, to avoid unexpected end-user connection issues, use VM models that have a minimum of two (2) CPUs.

• Memory

  When you select this option, you can then enter a range of memory in GBs.

• Tag

  When you select this option, you can then select a tag from a second drop-down menu.

  You can also filter this list by entering text in the Filter text box at the top of the list. Tags available in the drop-down menu are both hard-coded system tags and custom tags that you created on the VM Types & Sizes page (Settings > VM Types & Sizes).

1. Click the Add link.
2. Select either And or Or as the operator between the previous filter and the new one you are creating.
3. Set the new filter by selecting a criterion and entering values.

Important: For production environments, select a VM model that has a minimum of two (2) CPUs. First-gen Horizon Cloud scale testing has shown that using 2 CPUs or more avoids unexpected end-user connection issues. Even though the system does not prevent you from choosing a VM model with a single CPU, you should use such models for tests or proof-of-concepts only.

• Standard HDD - Default disk type.
• Standard SSD
• Premium SSD - Option only appears if you selected a model that supports premium IO.

• The default value is the base image OS disk size (typically 128 GB).
• If you edit the size, the value you enter must be greater than the base image OS disk size, and cannot exceed the largest size (typically 1024 GB) supported by the selected model.
• You can also edit this value later if desired.

Important:

• If you want disk encryption, you must make this selection when creating the VDI desktop assignment. You cannot later add disk encryption after the assignment is created.
• To use both NSX Cloud features and disk encryption, the image's installed NSX agent must be the latest agent version. Using disk encryption with previous versions of the NSX agent is not supported.

Important:

• If you want to use NSX Cloud with the desktop instances, you must make this selection when creating the VDI desktop assignment. You cannot later enable NSX Cloud management after the assignment is created.
• For the NSX Cloud management features to work with the assignment's desktop instances, the image that you select for this assignment must have the NSX agent already installed on it. When you set this toggle to Yes, ensure that the image you select in Image has the NSX agent installed on it. The system does not verify if the selected image has the NSX agent when it creates the VDI desktop assignment.
• To use both NSX Cloud features and disk encryption, the image's installed NSX agent must be the latest agent version. Using disk encryption with previous versions of the NSX agent is not supported.

Only those published images in the selected pod that are appropriate for VDI desktops are listed here. A published image, sometimes called a sealed image or an assignable image, is one that was published to the system by converting a base or golden image into a desktop.

Important:

• If you set the Encrypt Disks to Yes, ensure that the image you select here does not have data disks attached to it. Use of disk encryption of VMs with data disks for floating VDI assignments is not supported in this release.
• If you set the NSX Cloud Managed toggle to Yes, ensure that the image you select here has the NSX agent installed on it. For the NSX Cloud management features to work with the assignment's desktop instances, the image that you select for this assignment must have the NSX agent already installed on it. The system does not verify if the selected image has the NSX agent when it creates the VDI desktop assignment.
• In a tenant is configured for single-pod broker, Image will not list multi-pod images, because such images are unsupported in this use case.

The name must contain only letters, hyphens, and numbers. Spaces are not allowed. The name cannot start with a non-alphabetic character.

Circumstances might occur that cause another protocol to be used instead of the default protocol. For example, the client device does not support the default protocol or the end user overrides the default protocol selection.

Note: For images with the Microsoft Windows 7 Enterprise operating system, RDP is the only supported choice.

Note: For images with the Microsoft Windows 7 Enterprise operating system, Horizon Client is the only supported choice.

Max Desktops

When the assignment is first created, the system deploys the number of desktops specified in the Max Desktops field, and then powers off the desktops except the number specified for Min Desktops.

Only the minimum number of desktop instances is initially powered on. As end-user demand increases, the system powers on additional desktops, up to the Max Desktops number. Then as end-user demand shrinks, the system powers off the desktops, until it reaches the Min Desktops number. A desktop must be free of a logged-in user session before the system will power it off.

When you specify zero (0) for Min Desktops, it indicates that you want the system to power off all the assignment's desktops until there is end-user demand for a desktop.

This protect time is used primarily for the situations where the system will automatically power off a desktop VM. You can use this Power Off Protect Time setting to tell the system to wait the specified time before starting to power off the VM to meet the threshold setting in the Power Management field. The system waits the time specified for the Power Off Protect Time before powering off the VM to match the configured schedule. The default wait time is 30 minutes.

For a client operating system, Horizon Cloud sets the VDI assignment's desktop VMs to use the Windows Client license type by default and you cannot change that setting.

If you need to use nested Organization Units, see Considerations For Using Nested Active Directory Domain Organizational Units.

Note: If the Computer OU is set to CN=Computers, the system uses the default Active Directory Computers container for VMs. Your Active Directory might have this default container redirected to an organizational unit class container.

Note: The script must end with a reboot step to reboot the VM. Otherwise, the end user will not be able to log in the desktop until doing a manual restart. A sample reboot line as a Windows command is:

shutdown /r /t 0

The reason why the script must end with a reboot step is due to the sequence when the script is run after the sysprep process. When the system creates a desktop VM for the assignment, the VM boots up and completes the sysprep process in the Windows operating system. When the sysprep process completes, the agent in the desktop VM reaches out to do the domain join. At the same time, the agent gets the script path you specify here. The agent sets the Windows RunOnce path (System run once) and then restarts the desktop VM. On the next restart, the system logs in to the Windows operating system using the local administrator account and runs the script. It is only after another subsequent restart, specified in the script, that the desktop VM is ready for a user to log in.

CAUTION: When the system forces the log off in the underlying Windows operating system session, any unsaved data is lost. To prevent an unintended loss of data, set this interval high enough to accommodate the business needs of your end users.

The default interval is one week (10080 minutes).

Note: If no user activity occurs before the timeout interval is reached, a message appears in the desktop that indicates that the user will be logged off if they do not click OK in the next 30 seconds. If the logout occurs, any unsaved user data, such as documents or files, is lost.

(Optional) Create custom tags to be applied to Azure resource groups. Azure resource tags are only applied to the resource groups, and are not inherited by the resources in the groups.

To create the first tag, enter information in the Name and Value fields. To create an additional tag, click Add and then enter information in the Name and Value fields that appear below the existing ones.

• You can create a maximum of 10 tags.
• The tag name is limited to 512 characters, and the tag value is limited to 256 characters. For storage accounts, the tag name is limited to 128 characters, and the tag value is limited to 256 characters.
• Tag names cannot contain the following characters: < > % & \ ? /
• Tag names cannot contain these case-insensitive strings: azure, windows, microsoft

After an assignment has been created, you can add more Azure resource tags and edit or delete tags for that assignment.

For example, when you later edit this floating VDI desktop assignment to use another image, the system will power off this number of powered-on desktops simultaneously for those VMs that do not have any sessions. (When a powered-on desktop has a session, the system holds off powering off that desktop until the session ends.)

To the set of powered-off desktop VMs, the system performs the required actions to provision the new image to that set. For typical use cases, this number would be set to a subset of the full maximum number of desktops defined for this assignment. However, if you want, you can specify a number here equal to the Max Desktops setting. In that scenario, you would be allowing the system to power off all of the assignment's powered-on desktops simultaneously when you edit the assignment to use a new image.

Note: This setting does not pertain to desktop VMs that are powered off. When an image is changed for a floating VDI desktop assignment, the system immediately deletes those powered-off desktop VMs and updates them to the new image.

The power management selections balance capacity cost with faster availability:

• Select Optimized Performance when you want the system to power on the next desktop instance sooner rather than later. Even though you are spending more by having the next desktop ready to go before the user demand requires it, this setting increases the chance that when users try to launch a desktop from the assignment, the desktop is already powered up to meet that demand.
• Select Optimized Power, when you want the system to wait as long as possible before powering on the next desktop instance. The occupancy of the assignment's set of desktops is higher before the system powers up the next desktop instance. Even though this selection minimizes capacity costs by having more utilization of the existing desktops, this setting increases the chance that there might be a delay when new users try to log in because they might have to wait during the time system has to power on desktops.
• Select Balanced to strike a balance between capacity costs and time-to-availability for users.

• Optimized Performance
  • Low threshold: 23%
  • High threshold: 50%
• Optimized Power
  • Low threshold: 38%
  • High threshold: 80%
• Balanced
  • Low threshold: 31%
  • High threshold: 66%

Note: The user sessions governed by these settings are the user logins to the desktops' Windows operating system. These sessions are not the user logins in Horizon Client, Horizon Web Client, Omnissa Access, or Intelligent Hub.

The user's session begins when the user authenticates to the desktop's Windows operating system.

• Log Off Disconnected Sessions - Select when the system will log the user off of a disconnected session.
• Max Session Lifetime - Specify the maximum number of minutes the system should allow for a single user session.

• For weekends or night hours when you know that your end users will not be using their desktops, you can have a schedule for zero or a low number of powered-on desktops.
• For specific days or specific hourly stretches that you can predict will have increased end user demand, you can have a schedule that increases the minimum number of powered-on desktops to be available to meet that demand.

1. Click the + icon to add the first row in the Schedule Power Management section.
2. Type an identifying name for the first schedule.
3. Select the days for the first schedule.

   Note: One day is automatically selected by default when the row is added. If you do not want to include the selected day in this schedule, click the drop-down and deselect that selected day.

4. Specify the applicable hours in the specified days. Either:
   • Select the All Day check box to have this schedule in effect for all hours of the specified days.
   • Specify start and end times for the time period in each day.

     Note: Encrypted VMs take longer to power on than non-encrypted VMs. If you have set Encrypt Disks to Yes, and you want 100% of the encrypted VMs to be ready for end-user connections at a particular time of day, you might have to set an earlier start time here. See the section 'When Scheduling Power Management for Farms and VDI Desktop Assignments That Have Large Numbers of Encrypted VMs' in page Using Microsoft Azure Disk Encryption with Your Farms and VDI Desktops.

5. Select the time zone. The time zone closest to your end users' location is recommended. As appropriate for the selected time zone, Daylight Savings Time is automatically applied.

   Note: If two schedules have the same time zone setting and have overlapping times, a warning is displayed. However, if two schedules have different time zone settings and overlap, the warning is not displayed. As an example, if you have two all-day Saturday schedules and one has Europe/London time zone selected and the other has America/Toronto selected, the overlap warning does not display.

6. In the Min Desktops field, type the minimum number of desktops you want powered on during the specified time period. During the specified time period, that number of desktops at a minimum will be powered on to be available to take end user requests during that time. The number can range from zero (0) up to the number specified for Max Desktops for the overall floating VDI desktop assignment. When this number is zero (0) and there are no active end user sessions at the schedule's starting time point, the assignment's desktops are powered off. In that scenario, if an end user subsequently attempts to connect to a desktop from this assignment during the scheduled time period, there will be a delay before the desktop is in a usable state because the underlying desktop VM has to power on.

Note: By default, when a user logs off of a desktop at a time that lies outside of a schedule's time period, the system protects the desktop VM from powering off for the time specified in the Power Off Protect Time field. The default is 30 minutes.

When this toggle is switched off, the assignment's desktop VMs will be connected to the pod's primary VM subnet by default.

To set a filter, you first select the criterion in the drop-down menu and then enter the desired values. By default, there is a single filter with the criterion Tag and the value Recommended. You can edit this first filter and add more filters connected by And and Or operators.

The following are the criteria you can use for filters and descriptions of the values you can enter for each.

• Type

  When you select this option, the second drop-down menu defaults to GPU and High Performance - Models with GPU.

  Note: If you choose a GPU model, then the list of images shown will contain only images that were created with the Include GPU flag selected, so you need at least one such image to create a farm or pool using a GPU model.

  If you choose a non-GPU model, then the list of images shown will contain only images that were created without the Include GPU flag.

• Series

  When you select this option, you can then select a series of models from a second drop-down menu.

  You can also filter this list by entering text in the Filter text box at the top of the list.

• CPUs

  When you select this option, you can then enter a CPU range.

  Important: For production environments, to avoid unexpected end-user connection issues, use VM models that have a minimum of two (2) CPUs.

• Memory

  When you select this option, you can then enter a range of memory in GBs.

• Tag When you select this option, you can then select a tag from a second drop-down menu.

  You can also filter this list by entering text in the Filter text box at the top of the list.

  Tags available in the drop-down menu are both hard-coded system tags and custom tags that you created on the VM Types & Sizes page (Settings > VM Types & Sizes).

1. Click the Add link.
2. Select either And or Or as the operator between the previous filter and the new one you are creating.
3. Set the new filter by selecting a criterion and entering values.

This selection defines the set of underlying resources that will be used when the desktop instances are created, in terms of capacity (compute, storage, and so on). The available choices map to standard VM sizes that are available in Microsoft Azure.

Important: For production environments, select a VM model that has a minimum of two (2) CPUs. First-gen Horizon Cloud scale testing has shown that using 2 CPUs or more avoids unexpected end-user connection issues.

Even though the system does not prevent you from choosing a VM model with a single CPU, you should use such models for tests or proof-of-concepts only.

• Standard HDD - Default disk type.
• Standard SSD
• Premium SSD - Option only appears if you selected a model that supports premium IO.

• The default value is the base image OS disk size (typically 128GB).
• If you edit the size, the value you enter must be greater than the base image OS disk size, and cannot exceed the largest size (typically 1024GB) supported by the selected model.
• You can also edit this value later if desired.

For more information, see the section 'Required Administrator Actions When the Disk Size for a Farm or VDI Desktop Assignment is Increased' in Troubleshooting .

Important:

• If you want to use NSX Cloud with the desktop instances, you must make this selection when creating the VDI desktop assignment. You cannot later enable NSX Cloud management after the assignment is created.
• For the NSX Cloud management features to work with the assignment's desktop instances, the image that you select for this assignment must have the NSX agent already installed on it.

  When you set this toggle to Yes, ensure that the image you select in Image has the NSX agent installed on it. The system does not verify if the selected image has the NSX agent when it creates the VDI desktop assignment.

Only those published images in the selected pod that are appropriate for VDI desktops are listed here. A published image, sometimes called a sealed image or an assignable image, is one that was published to the system by converting a base or golden image into a desktop.

Important: If you set the NSX Cloud Managed toggle to Yes, ensure that the image you select here has the NSX agent installed on it.

For the NSX Cloud management features to work with the assignment's desktop instances, the image that you select for this assignment must have the NSX agent already installed on it. The system does not verify if the selected image has the NSX agent when it creates the VDI desktop assignment.

Note: For images with the Microsoft Windows 7 Enterprise operating system, RDP is the only supported choice.

• Min Desktops — Sets the number of powered-on unassigned desktop VMs to have in the pool defined by this assignment. When the assignment is first created, zero desktop VMs are assigned out of the total of maximum possible for the assignment (set by the Max Desktops number). Therefore, at that time, the number you set here is the subset of the number of unassigned VMs that you want powered on initially out of that possible maximum. When you specify zero (0) for Min Desktops, it indicates that you want none of the unassigned desktop VMs to be powered-on when the assignment is initially created.

  The benefit of setting some unassigned VMs to be powered on is primarily to have some unassigned VMs ready for users to quickly log in to. Over time, as these powered-on unassigned desktops get assigned to users — either from users doing their initial logins which claim desktops for them or from an administrator using the Assign action to explicitly assign a desktop to a user — the system powers on additional unassigned desktops until it reaches the Max Desktops number.

  Finally, when all of the desktop VMs in the assignment are assigned to users, the Min Desktops value is not much use until a time when you explicitly start unassigning desktops from users.

• Max Desktops — Sets the total number of desktop VMs you want in the pool of VMs defined by this assignment.

For a client operating system, Horizon Cloud sets the VDI assignment's desktop VMs to use the Windows Client license type by default and you cannot change that setting.

If you need to use nested Organization Units, see Considerations For Using Nested Active Directory Domain Organizational Units

Note: If the Computer OU is set to CN=Computers, the system uses the default Active Directory Computers container for VMs. Your Active Directory might have this default container redirected to an organizational unit class container.

Note: The script must end with a reboot step to reboot the VM. Otherwise, the end user will not be able to log in the desktop until doing a manual restart. A sample reboot line as a Windows command is: shutdown /r /t 0

The reason why the script must end with a reboot step is due to the sequence when the script is run after the sysprep process. When the system creates a desktop VM for the assignment, the VM boots up and completes the sysprep process in the Windows operating system. When the sysprep process completes, the agent in the desktop VM reaches out to do the domain join. At the same time, the agent gets the script path you specify here. The agent sets the Windows RunOnce path (System run once) and then restarts the desktop VM. On the next restart, the system logs in to the Windows operating system using the local administrator account and runs the script. It is only after another subsequent restart, specified in the script, that the desktop VM is ready for a user to log in.

Select one of the following options from the drop-down menu.

• Unlimited - Unlimited desktop VMs can be deleted from the assignment. In this case, the Deletion Protection setting is no longer relevant.
• None - No additional desktop VMs can be deleted before counting them against the rate you set for Deletion Protection. In this case, the system uses only the Deletion Protection to authorize or block deletions. None is the default value for Deletion Protection.
• Custom - Number of additional desktop VMs that can be deleted before counting them against the rate you set for Deletion Protection. If you select Custom, you must also enter a numerical value to the right of this drop-down menu.

  For example, you might set Max Desktop Deletions to 10 and Deletion Protection to 1.

  In this case, after the first 10 VMs are deleted (no matter how long it takes for the count to reach 10), the system only allows 1 additional VM to be deleted per hour from that time forward.

Important: If you specify a new image for a dedicated desktop assignment, the system changes the Max Desktop Deletions setting if necessary so that all unassigned desktop VMs can be rebuilt with the new image.

Note: If you select Unlimited for Deletion Protection, there is no need to use the Max Desktop Deletions setting.For more information about the Deletion Protection setting, see section 'Customizable General Settings for Your Horizon Cloud Tenant Environment' in Tour of the First-Gen Horizon Universal Console.

To prevent all VM deletions in a dedicated desktop assignment, use the Prevent Deletions setting on the Assignments page. See Prevent Deletions or Allow Deletions for a Dedicated Desktop Assignment.

The time you specify here is different from the time out settings that govern the Horizon Client or Horizon Web Client logged-in sessions of end users.

CAUTION: When the system forces the log off in the underlying Windows operating system session, any unsaved data is lost. To prevent an unintended loss of data, set this interval high enough to accommodate the business needs of your users. The default interval is one week (10080 minutes).

Note: If no user activity occurs before the timeout interval is reached, a message indicates that the user will be logged off if they do not click OK in the next 30 seconds. If the logout occurs, any unsaved user data, such as documents or files, is lost.

To create the first tag, enter information in the Name and Value fields. To create an additional tag, click Add and then enter information in the Name and Value fields that appear below the existing ones.

• You can create a maximum of 10 tags.
• The tag name is limited to 512 characters, and the tag value is limited to 256 characters. For storage accounts, the tag name is limited to 128 characters, and the tag value is limited to 256 characters.
• Tag names cannot contain the following characters: < > % & \ ? /
• Tag names cannot contain these case-insensitive strings: azure, windows, microsoft

After an assignment has been created, you can add more Azure resource tags and edit or delete tags for that assignment

Note: Desktops in a dedicated VDI desktop assignment that are mapped to users are said to be assigned to those users. Unassigned desktops in a dedicated VDI desktop assignment are desktops which have not yet been mapped to specific users.

• Log Off Disconnected Sessions - Select when the system will log the user off of a disconnected session.
• Max Session Lifetime - Specify the maximum number of minutes the system should allow for a single user session.

• For weekends or night hours when you know that your end users will not be using their desktops, you can have a schedule for zero or a low number of powered-on unassigned desktops.
• For specific days or specific hourly stretches that you can predict will have increased end user demand, you can have a schedule that increases the minimum number of powered-on unassigned desktops to be available to meet that demand.

You can specify up to 10 schedules for the dedicated VDI desktop assignment. If any schedules have overlapping time periods but specify different minimum unassigned desktop numbers, the system uses the largest value minimum unassigned desktops for the overlapping time period.

CAUTION: By default, when you configure a schedule here for a dedicated VDI desktop assignment, the system keeps all of the already assigned desktop VMs powered on, regardless of the schedule. That is:

• If you set any schedule here, it results in the system leaving the currently assigned (mapped to a user) desktop VMs on. The schedule only controls the power state of unassigned desktops, if any.
• Having a schedule here changes the system's treatment of the power-on behavior of the assigned desktops from what it would be in the absence of a schedule. When there is no schedule configured here, the system powers off the assigned desktops that have no logged-in users.

For example, if all of the desktops in this dedicated VDI desktop assignment are mapped to users (assigned), and there is a schedule configured here, the system does not power off those assigned desktops by design. This design is for ensuring an assigned desktop is ready to meet its mapped-to user's request to log in, even when a schedule is in effect.

As a result, if all of the desktops are in assigned state, when a schedule is set here, those assigned desktops will remain powered on, even when their assigned users are not logged in. If you want all assigned desktop VMs to be powered off during a specific day, like a weekend day, do not configure any schedules here.

To configure a schedule:

1. Click the + icon to add the first row in the Schedule Power Management section.
2. Type an identifying name for the first schedule.
3. Select the days for the first schedule.

   Note: One day is automatically selected by default when the row is added. If you do not want to include the selected day in this schedule, click the drop-down and deselect that selected day.

4. Specify the applicable hours in the specified days. Either:
   • Select the All Day check box to have this schedule in effect for all hours of the specified days.
   • Specify start and end times for the time period in each day.

     Note: Encrypted VMs take longer to power on than non-encrypted VMs. If you have set Encrypt Disks to Yes, and you want 100% of the encrypted VMs to be ready for end-user connections at a particular time of day, you might have to set an earlier start time here.

     See section 'When Scheduling Power Management for Farms and VDI Desktop Assignments That Have Large Numbers of Encrypted VMs' in page Using Microsoft Azure Disk Encryption with Your Farms and VDI Desktops.

5. Select the time zone. The time zone closest to your end users' location is recommended. As appropriate for the selected time zone, Daylight Savings Time is automatically applied.

   Note: If two schedules have the same time zone setting and have overlapping times, a warning is displayed. However, if two schedules have different time zone settings and overlap, the warning is not displayed.

   As an example, if you have two all-day Saturday schedules and one has Europe/London time zone selected and the other has America/Toronto selected, the overlap warning does not display.

6. In the Min Desktops field, type the minimum number of unassigned desktops you want powered on during the specified time period. During the specified time period, that number of unassigned desktops at a minimum will be powered on to be available to take end user requests during that time. The number can range from zero (0) up to the number specified for Max Desktops for the overall dedicated VDI desktop assignment.

   Important: The Min Desktops field in the power management schedules controls only the unassigned desktops. Assigned desktops do not participate in the power management schedule. When all desktops in the dedicated VDI desktop assignment are in Assigned state, this Min Desktops value, which controls the unassigned desktops, defaults to zero (0).

   When this number is zero (0) and there are no active end user sessions at the schedule's starting time point, the assignment's desktops are powered off. In that scenario, if an end user subsequently attempts to connect to a desktop from this assignment during the scheduled time period, there will be a delay before the desktop is in a usable state because the underlying desktop VM has to power on.

Note: By default, when a user logs off of a desktop at a time that lies outside of a schedule's time period, the system protects the desktop VM from powering off for the time specified in the Power Off Protect Time field. The default is 30 minutes.