Virtual Apps and Desktops – VDAs will remain turned off after Restart Schedule

Reading Time: 3 minutes

Have you ever experienced that some of the Virtual Desktop Agents remain turned off after a scheduled reboot via the Delivery Group? This is something I could notice several times of the last years in various environments. Most of the time this only affects a few machines and it is not a big deal. During a current customer engagement I could see the same issues again but sometimes over 40% of the VDAs have been affected (not every day). This can happen if there is a boot storm occurring (PVS servers are exhausted) or the VDA registration process is not happening after 20 minutes (CTX223434).  That was not the case in this specific environment. The interesting thing is that we never saw a power on action for the problem VDAs in VMware vCenter. You will find a lot of people in Citrix Discussions or Reddit who are struggling with the same problem but seems like there is not a real solution for this behavior.

That is why I came up with the idea to write a PowerShell script which needs to be run after the restart schedule which is doing the following things:

  • Checking for all faulty VDAs for the given Machine Catalog (PowerState: Off, RegistrationState: Unregistered, MaintenanceMode: False)
  • Powering on each VDA with a delay of 15 seconds (New-BrokerHostingPowerAction)
  • Sends an email notification (if enabled)

The great thing is we do not need to work with VMware PowerCLI, because we can start the VDAs with the integrated Citrix PowerShell SDK. This makes it work for all the environments out there, doesn’t matter if you are running Citrix Hypervisor, VMware, AHV etc.

Hope this is helping some people and I appreciate some feedback 🙂

Citrix_VDA_BootFix_V1.2.ps1

 

 

 

 

 

13 comments

  1. The script is working fine when I starting it in Powershell. But when I set it up as an Task Schedule is not working. Hav you tried to run the script from Task Schedule?

  2. Thanks.
    I had to set the Action in Task Schedule to:
    Action: Start a Program
    Program/Script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    Add arguments: -Executionpolicy bypass -file C:\thescript.ps1

    That did the trick.

    But it seems to run the script only work with Domain Admins role.

  3. I have multiple Machine Catalogs so when I add them to the script $Catalog = “FARMP10″,”FARMP11” it errors out on the script with this error:
    Stop-Transcript : An error occurred stopping transcription: The host is not currently transcribing.
    At line:103 char:1
    + Stop-Transcript
    + ~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidOperation: (:) [Stop-Transcript], PSInvalidOperationException
    + FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.StopTranscriptCommand

    Any suggestions on how to add multiple Machine Catalogs to the script?

    1. Hello Mike. I would suggest you to use an input paramater. Then you can use the same script and create different schedulded tasks for specifing the needed catalogs.
      Param ([parameter(Mandatory)] [String]$Catalog)

  4. Im kind a new to PS. Where in your script would I enter the parameter so that I can enter multiple Machine Catalogs?

    Thank you.

    1. Paste the param to line 14 in the script.
      Run the script with the following command: Citrix_VDA_BootFix_V1.2.ps1 -Catalog ‘Name”

  5. Hello its me again. I did add the command on line 14 and it worked but the problem still exist which it only checks one Machine Catalog and not multiple. What I wanted to do with the Script is to check all the Machine catalogs that has unregistered machines and if unregistered to power them all up. Thank you for helping me out. I hate it when a scheduled reboot powers off a few servers from different Machine Catalogs and I have to power them on manually.

    1. Mike,
      One possible solution would be to create a function that perform those tasks. Then call the function passing, in my case, the Desktop Group name as parameter . I this way you can perform these operation against the Desktop Groups that you interested in monitoring. You should explore the various Get-BrokerDesktop options to see if you can gather a collection of VDAs that make sense to you, then put that collection on the foreach cycle.

      Here I created the function
      Function CheckingVDAPoweredOff ($DesktopGroupName)
      {Write-Host “Checking VDAs DesktopGroupName $DesktopGroupName”
      $VDAs = Get-BrokerDesktop -DesktopGroupName $DesktopGroupName -RegistrationState Unregistered -PowerState Off -InMaintenanceMode $false | Select HostedMachineName

      if($VDAs -ne $null)
      {
      foreach($VDA in $VDAs)
      {Write-Host “$($VDA.HostedMachineName) was powered off. Booting up the machine….”
      try
      {
      New-BrokerHostingPowerAction -MachineName $VDA.HostedMachineName -Action TurnOn | Out-Null
      $BrokenVDA++
      }
      catch
      {
      Write-Host “E” “Problem with turning on the VDA: $($VDA.HostedMachineName)”
      Write-Host “I” “Exiting Script…..”
      exit 1
      }

      Write-Host “Waiting for 15 seconds before starting the next VDA….”
      Sleep 15
      }
      }

      else {Write-Host “All VDAs are registered. Nothing to do…..”}
      }

      #here I am setting the desktop Group name that I want to check
      $DesktopGroupName = “APPS01”

      #Here I am calling the function passing the Desktop Group Name
      CheckingVDAPoweredOff $DesktopGroupName

      $DesktopGroupName = “APPS02”
      CheckingVDAPoweredOff $DesktopGroupName

  6. Has anyone had this same issue but it completely breaks the entire Delivery Group? We are seeing where a VDA stays in a powered off state and when this happens the DG no longer takes any sessions until the VDA is put in MM or powered on.

Leave a Reply

Your email address will not be published. Required fields are marked *