This post is designed to explain the different types of settings and scenarios surrounding power managing Virtual Apps and Desktops (formerly XenDesktop and XenApp) machines using Citrix Virtual Apps and Desktops 7.
Static XenDesktop Desktops
Take a look at the Power Management settings on a Static Desktop Delivery Group.
What have we got to play with?
Firstly, you need to assign your peak hours. Peak hours generally will match core business hours. Static desktops will be powered on as soon as we enter peak hours, ready for users.
It is important to note that if static desktops are shut down during peak hours, they won’t (by default) be automatically powered back on. Only when an assigned user again attempts to connect to the desktop will it be powered on. Peak hours can be set for weekends and weekdays.
Next, we have a couple of configurable settings under During peak hours:
- When disconnected – What to do when a session has been disconnected for a period of time defined by you. Options are:
- No action, Suspend or Shut Down.
- When logged off – What to do when a session has been logged off for a period of time defined by you. Options are:
- No action, Suspend or Shut Down.
During off-peak hours:
- When disconnected – What to do when a session has been disconnected for a period of time defined by you. Options are:
- No action, Suspend, or Shut Down.
- When logged off – What to do when a session has been logged off for a period of time defined by you. Options are:
- No action, Suspend or Shut Down.
As mentioned above, desktops do not power on automatically after they have been shut down until the peak period starts again or a user attempts to connect to their machine. A user if the ability is granted could shut down a desktop mistakenly or other factors outside of XenDesktop could cause machines to power down. If you would like machines to power on automatically during peak hours run the following command against the Static/Persistent Desktop Delivery Group.
Set-BrokerDesktopGroup -Name “DGName” -AutomaticPowerOnForAssignedDuringPeak $true
Non-persistent XenDesktop Desktops
Pooled Desktops that do not persist any change come with different power management settings as shown in the preceding screenshot.
Firstly, set how many machines should be powered on and when. The peak hours directly beneath should also be set. If you click the Edit button you can also specify how many machines are powered on or specify a percentage of the pool.
During peak hours:
- When disconnected – What to do when a session has been disconnected for a period of time defined by you. Options are:
- No action, Suspend or Shut Down.
During off-peak hours:
- When disconnected – What to do when a session has been disconnected for a period of time defined by you. Options are:
- No action, Suspend or Shut Down.
By default, when a user logs off a random/non-persistent machine, the machine restarts in order to flush the changes made to the machine in preparation for a new user session. 
If you want to disable machine restarts after log off, run command:
Set-BrokerDesktopGroup -Name “DGName” -ShutdownDesktopsAfterUse $false
VDI desktops that have no user assignment for example pooled or static, or XenApp machines all come with a 10% peak and off-peak buffer. This means that if you specify 100 machines out of 200 in a Delivery Group to be powered on and available at 10pm, the buffer by default is 10% of the Delivery Group. This means an extra 20 machines would always be kept available for connecting users. Once the 101st concurrent user logs on, another machine is powered on to keep the buffer at 10%.
To control the values for peak and off-peak and specify that 100% of the machines be powered on, use command:
Set-BrokerDesktopGroup “Deliverygroupname” -PeakBufferSizePercent 100 or -OffPeakBufferSizePercent 100
XenApp Shared Desktops/Apps
Firstly make sure you have host connections defined in Citrix Studio or else your Delivery Controllers won’t be able to instruct the Hypervisor to power manage machines. Navigate to Citrix Studio -> Configuration -> Hosting -> Add Connection and Resources.
Hosts you can make a connection to as of Virtual Apps and Desktops 7 1811:
- Citrix Hypervisor (formerly XenServer)
- Microsoft System Center Virtual Machine Manager (SCVMM)
- VMware vSphere
- Google CloudPlatform
- Microsoft Azure
- Microsoft Azure Classic (deprecated)
- Amazon EC2
- Microsoft SCCM WOL (Wake on LAN)
To set a restart schedule against a Server OS Delivery Group, right-click the Delivery Group and select Edit Delivery Group.
Click Restart Schedule and then specify parameters to suit your needs, based on the Virtual Apps and Desktops version you are running:
Virtual Apps and Desktops up to version 7 1808:
Note: In XenApp and XenDesktop 7.12 up to Virtual Apps and Desktops 1808, you can create multiple restart schedules for a single Delivery Group by using PowerShell commands. To read more on that method, see here. Otherwise, you can only create a single restart schedule for a Delivery Group via the Studio GUI.
You have a number of configurable options under the Restart Schedule pane:
- Restart frequency – Every day, or every certain day of the week.
- Begin restart at – Specify time to begin restarts.
- Restart duration – Restart all machines at once or within a certain amount of time e.g. 4 hours. If you set a reboot duration of 4 hours and have 20 machines, machines are split into two reboot groups. Each reboot group will contain 10 VDAs. The reboot cycle is calculated by the amount of time set for the reboot duration and the number of machines that must be restarted. In this case, 240 minutes divided by 20 machines. This equals to 12 minutes. This means, a VDA will be restarted every 12 minutes. Most preferred VDAs are chosen first, preferred VDAs are those that are currently registered against a Delivery Controller, not in maintenance mode and have the fewest user sessions running on them.
- Send notification to users – Yes or No. If Yes, send a notification to users 1, 5 or 15 minutes before restart. If you select 15 minutes, you have the option to resend the notifications every 5 minutes.
- Notification message – Your defined text explaining that machines will be restarted.
One thing to note is that if a machine is in maintenance mode, it won’t be restarted by the schedule.
Virtual Apps and Desktops up to version 7 1811:
Starting 1811, you can now create multiple reboot schedules via the GUI. Previously, XenApp and XenDesktop 7.12 released the capability to create multiple reboot schedules, but only via PowerShell, and this ability lasted right up to Virtual Apps and Desktops 7 1808. To read more on that method, see here.
Once you have the Edit Delivery Group box open, click on Restart Schedule -> Add.
Many of the fields are self-explanatory, but some are new to the GUI such as:
- Restrict to tag – Tags were introduced in XenApp and XenDesktop 7.12. If you select this box, you can restrict the restart schedule you are creating to VDAs that have been assigned a specific tag. This is useful when you only want to reboot a subset of VDAs in a Delivery Group on a particular day or time.
Upon clicking save, you can return to the Add button to create more schedules as you wish. 
Girdhar
September 16, 2016Excellent article i always have a confusion in power management. Thanks for clearing it. Is power management same in xendekstop 5.x also.
George Spiers
September 16, 2016Thanks Girdhar.
XenDesktop 5.x has the majority of power management options that XenDesktop 7.x has. Powering on desktops during peak hours, defining peak hours, setting power actions based on disconnected/logged off time etc.
Lalit Gopal Bansal
September 23, 2016Really Helpful .. Got to know new things 🙂
carsten
December 22, 2016Hi,
great writeup.
Is it a new configuration regarding host connection ?? Just upgraded xenapp 7.11 to 7.12, and now restart schedule does NOT Work. But I have never had a connection to VMM before because the VM’s were not managed from studio. cant find any doc about that ?
/anker
George Spiers
December 22, 2016Hi
You need a Host Connection to power manage machines, this applies to XenApp 7.12, XenApp 7.11 and below versions also. If there is no host connection you have to manually add the VMs to a Machine Catalog by host name, and they will be unmanaged when it comes to power.
ORYXWAY
July 10, 2019Hi George,
What happened to Power Management in 7.15 LTSR? It was such a nice feature when I worked on XD 5.X and now in this version I do not see at all? We are currently in 7.15 LTSR and I want to turn off the desktops after business hours and bring it up before business hours and I am not able to do it.
George Spiers
July 14, 2019Power Management is still there. Have you created a Hosting connection? When you created your Machine Catalog did you specify the VMs were power managed?
Harie Vallabhaneni
December 19, 2017Helped me a lot , nice article.
Morne
January 12, 2018Any way to get the Reboot to work in AZURE
George Spiers
January 12, 2018Have you looked at Smart Scale? https://jgspiers.com/citrix-smart-tools/#Smart-Scale
A-Man
June 7, 2018Has anyone ever set a schedule for random XenDesktop Desktops, only to find that the environment doesn’t seem to obey the new settings? I had initially configured a schedule for 5 machines to be powered on at all times, and recently changed the schedule such that 7 machines should be powered on for a few hours in the afternoon. However, I still only see 5 VMs powered on in XenCenter during the time window when 7 should be on.
Furthermore, when I manually power on an additional VM in XenCenter, another VM suddenly is shut down. It’s as if Citrix Studio hasn’t accepted the new settings, even though it continues to display them.
marco
June 12, 2018I have a machine that i cant add to the machine Catalog. Powerstate is on and registrated.
George Spiers
June 12, 2018Why can it not be?
Girdhar
October 1, 2019Hi George,
I have a query regarding non persistent MCS pool if i use below command. Flush to changes made by user in session will not happen correct. If yes will that machine not available to new user. what is the exact pros and cons using below command.
Set-BrokerDesktopGroup -Name “DGName” -ShutdownDesktopsAfterUse $false
George Spiers
October 3, 2019It means if a user logs off the desktop, it will not automatically restart. When you restart the desktop manually or via a different automated method, the changes will be flushed as normal.
Anonymous
October 9, 2019Will it still available for new user to take it. are there any issue in this setting. Any performance issue though i made it restart every VDI once in a week through power management policy
Set-BrokerDesktopGroup -Name “DGName” -ShutdownDesktopsAfterUse $false
Girdahr
October 9, 2019Will it still available for new user to take it. are there any issue in this setting. Any performance issue though i made it restart every VDI once in a week through power management policy
Set-BrokerDesktopGroup -Name “DGName” -ShutdownDesktopsAfterUse $false
George Spiers
October 15, 2019When a user logs off or is logged off then yes the desktop becomes available for others. You should run a POC initially. Size your Write Cache appropriately also in case that becomes an issue.
Pingback: Citrix MCS dedicated machines reboots » Citrixirc.com
sasi
March 21, 2021Can I change the days of weekdays and weekends to set sunday as weekdays?
Scott
February 3, 2022Can the flushing of temporary files, cause delayed boot times on non-persistent VDAs deployed via PVS? I am having a intermittent issue where certain VDAs do not boot quickly and can take anywhere between 7-30 minutes to finally come online in VMware vCenter. They typically hang @ %19 but will eventually boot. Any ideas as my XIO storage array is barely being taxed. Is there some logs/configuration I can check that you may know of? TIA