Jump to content


Machines don't always start after scheduled Reboot

Started by Tarik Chougui , 20 April 2015 - 12:41 PM
29 replies to this topic

L. T. Zwanenburg Members
  • #21

L. T. Zwanenburg
  • 6 posts

Posted 17 January 2017 - 10:35 AM

I think there is a differens in the update order.

We Always first update The Delivery Controllers\Director and then the VDA's.

I think the official way is first VDA's and then the Controllers.


Remove the reboot schedule and then recreate it is only working when the controllers are 7.12

(Controllers take the action to reboot an server)


After updated the controllers the reboot schedules where not working. (all versions VDA's)

ater recreating them it works fine.


So i do not know what happens when you first update the VDA's to 7.12 and the controler is still an older version.

I Think recreating the scheduler is not working in that case because the controller take the action to reboot.

Martin Stratmann Members
  • #22

Martin Stratmann
  • 10 posts

Posted 17 January 2017 - 11:06 AM

We have the same problem since we´ve updated from 7.6 FP3 to 7.12. Schedule reboots don´t work no more for each existing desktop group. I´ve created a new one with 7.9 or new features, added a server to this group.and set up a schedule reboot... That works!


We updated controller first, then the VDA´s. I´m going to remove the schedule reboot, recreate it and let you know tomorrow if that was the solution-




pjoppen371 Members
  • #23

Patrick Joppen
  • 4 posts

Posted 20 January 2017 - 07:00 AM

We solved the Problem by Using VDA 7.11 

it seems to be a problem of the VDA 7.12 -> after downgrading the VDA to 7.11 in the Master Images the Reboot schedule is working fine.

Martin Stratmann Members
  • #24

Martin Stratmann
  • 10 posts

Posted 20 January 2017 - 07:52 AM

Sorry for late response. Deleting and recreating of schedule reboot task via Studio didn´t fix it. 


Creating schedule tasks via  New-BrokerRebootScheduleV2 (decribed here) has done the job! It´s circuitous, but it works!





Francois Callens Members
  • #25

Francois Callens
  • 3 posts

Posted 20 January 2017 - 05:30 PM

Hello All,


I am new on this forum, and I read carefully all your messages. We meet exactly the same problem with reboot not working.


We upgraded from 7.8 to 7.12 last december (DDC + VDA), and since that moment scheduled reboots are not working properly.


In fact it works if the VDA server has no opened session. In the other way the server is skipped.


I tried to delete all the existing reboot schedule with the powershell command, and then recreate them with the "V2" commands (New-BrokerRebootScheduleV2). No success. I tried to add tags also, no success -> reboots don't work, with abandonned status in event.


I didn't try to downgrade the VDA agent version, I hope there is another solution with the VDA 7.12.



Adam Wingler Members
  • #26

Adam Wingler
  • 12 posts

Posted 20 January 2017 - 07:35 PM

There is a private hotfix available to address VDA's not rebooting at their scheduled time after upgrading to 7.12.

Christian Hock Members
  • #27

Christian Hock
  • 95 posts

Posted 23 January 2017 - 07:06 AM

Where we can download this fix?

Francois Callens Members
  • #28

Francois Callens
  • 3 posts

Posted 23 January 2017 - 03:42 PM

You may ask it to Citrix support, because it is a private fix

Christian Hock Members
  • #29

Christian Hock
  • 95 posts

Posted 31 January 2017 - 09:36 AM




Chris James Members
  • #30

Chris James
  • 2 posts

Posted 20 March 2017 - 10:11 PM

Those of you having this problem, do your provisioned servers have a SCSI Adapter? Not sure if this fixed mine, but I've added the SCSI adapter, and my server now restart when scheduled with no issue.


Previously, one server would restart and then shutdown after 20 minutes, and the other would not reboot at all. Upgraded to 7.13 recently, but after reboot both servers shut down. So I'm going to (at the moment) assume the scsi adapter is the fix. I couldn't even live migrate in SCVMM, but now I can manage that task too.