When creating, editing, or restarting a Unidesk desktop from the Management Console, you may see this status in the task detail:

The desktop is in the process of restarting; the Unidesk system is waiting for an indication that the desktop is ready before it proceeds

This message always comes after any desktop rebuild has completed, and Unidesk is starting the desktop VM.  It means that Unidesk has sent the Power On request to vSphere, and now we are waiting for a network message from Uniservice.exe on the desktop to tell us that the desktop has completed starting up.  At this point, the Unidesk appliances are no longer involved, and it's all up to Windows to complete the boot process.  Uniservice.exe will send the Ready message only when it has started properly and the network is up, which usually happens only moments before the Windows logon prompt.

If you see this task status in Unidesk, and you believe it's a problem (for instance, it's been at that status for several hours) it means that you need to go to vSphere and open the console window of your desktop and see what is happening in Windows.

For instance, if Windows is blue-screening, Support would need to know the STOP code.  If the screen is simply black, check the Performance tab in vSphere, Advanced, CPU, and see if you're getting a spike of CPU usage every few minutes, followed by a flat-line.  That also indicated a blue-screen loop.  Check the timing, and capture the STOP code.

If Windows is rebooting without a blue-screen, it could be a startup script, or a serious configuration error.  If Windows is completely up, login and verify that the network is working, Uniservice is running, and the CachePoint can be pinged.  There are also some considerations for nonpersistent machines where the Ready message will be blocked until some additional tasks, like activation and View integration, have completed.

But neither the Unidesk Management Console, the CachePoint logs, nor your connection broker will have any additional information about this.  You need to ask Windows what's going on.

Depending on what operation you were doing, there are some simple recovery techniques.

If you are creating a new desktop and it never finishes, try with fewer layers.  This could be a layer conflict, and building desktops with no app layers, and then different combinations of app layers, would tell you if this is a problem inherent to the OS layer, or if it's a problem with a specific app layer of combination of app layers.

If you are editing an existing desktop, try reverting the layer change.  You can see the exact changes you made by clicking the (i) for the desktop and scrolling down to the Audit Logs to see what changes were most recently made.  Undo those changes.

If you moved the desktop to a new CachePoint using Backup/Repair, the network may have gotten broken along the way.  In fact, if you login to Windows and find the network broken even without moving it to a new CP, see this KB article: https://support.citrix.com/article/CTX221733

And contact Technical Support for guidance once you've gotten a sense of what Windows is unhappy about.