Logs are important of course no argument there but in my very humble opinion is the wrong way to start, always start by chatting, asking questions, observing, and analyzing then turn to logs and events. Solution:Īs simple as it may be always work your way through the basics when troubleshooting any issue with the prize question in mind, what changed or is changing from the as-built tested standardized environment with asking questions and observing being the ultimate way to do so. Fast forward couple of days in the future, users are not signing off which means virtual desktops are not being restarted (Delivery Group Power Management does not apply to Disconnected sessions) thus the overflow cache disk will fill up again with no space to do any IO writes and crash the VM. The restart of the VM would cause the overflow cache disk to clear which returned the VM into a working state.

That’s it, the overflow disk cache was being filled up by the user eventually causing the VM to crash and consequently get unregistered. Checking the catalog configuration showed that Citrix MCS was being utilized with RAM cache 512MB and Overflow Disk Cache 10GB configured. The statement meant that users where not signing off and always disconnecting their sessions to come and continue work the second day which in turn meant that no disconnect idle timer was configured which ultimately meant that those virtual desktops where not being restart for some time. An observation stated by IT was that this was happening to users that often leave their desks and come next day to commence their work where they left off. Key aspect of troubleshooting intermittent issues is keep on asking questions about behavior, I cannot stress how important that is, make it clear that these questions are not user related and thus have no consequences on the user but backend related to understand the flow of a certain event. Given the above, it was determined that this was a storage related issue of some sorts. Checking with effected users showed that standard applications are being used amongst all users and issue happening intermittently for some users, all of which use the same set of data and instructions so seemed that a process/applications causing this was unlikely. vCenter console did not show any CPU/Memory spikes for any Virtual Desktop VM nor did vRealize Operations report on any spikes for the same. That was key to understanding that this was not a security, networking, nor misconfiguration issue but rather OS was clearly crashing with some type of BSOD which was not visible from the now stuck console. Studio showing Virtual Desktops as Unregistered is a familiar sight and could be caused by a number of events such as networking, security, and/or misconfiguration but for this case specifically, it seemed that unregistered Virtual Desktops were showing as frozen/stuck VMs in vCenter/vSphere console with just a black unresponsive screen and upon restart became operational as a VM and registered with DDCs.

Citrix Virtual Apps and Desktops “XenDesktop” 1811 was being used with VMware vSphere 6.7 U1. XenDesktop 7.In a recent engagement with one of our customers, I received a call that many Virtual Desktop VMs are going to an unregistered state which obviously caused employees to panic given the state of resistance they are already in which required immediate intervention.

Workspace Environment Management WEM (1).$a = $a + “TABLE | select HostedMachineName, RegistrationState | ConvertTo-Html -Head $a -PreContent $pre -PostContent $post $messageSubject = (“Unregistered VMs on XenApp 7.6 Farm ” + (Get-Date -format R)) I thought of a script which would do the same and wrote this small script: I got the infomation and send email manually. I recently came across a task to check all the unregistered vms in xenapp 7.6.

Server vdi unregistered