Jump to content
Welcome to our new Citrix community!
  • 0

Desktop VDAs in one Delivery Group going Unregistered

Chris Benali1709159201




We have one delivery group containing 6 x desktop Windows 2016 VDAs that randomly go unregistered over night, its regularly 3 VDAs that seem to go unregistered but sometimes more or less.


The other delivery groups dont experience this issue.


The client VDA is 7.15 and PVS is 7.15


I have tried a new delivery group but the issue remains regardless of delivery group, I have logged it with Citrix Support but after providing bunches of CDF logs they are saying the DDC cant contact vSphere on a restart schedule from the Delivery Group but that doesn't explain why the machines go unregistered, you shouldn't need to have a restart schedule in place to keep machines registered for more than 24 hours


Restarting an affected VDA causes it register straight away.


I mentioned its often 3 VDAs that go unregistered, I should add that I built 3 additional VDAs and added them to the existing 3 to make 6 in total, I'm not sure if the cause of the issue lies there somewhere because everything works as expected apart from the random going unregistered and its not the same VDAs its different everytime, its not always three VDAs either it can be 2 or 4 or more


Has anyone experienced anything similar and have anything to try? I have also checked the Event Logs, the Citrix Desktop Service is running and there doesnt appear to be anything useful in the VDA or DDC Event Logs




Link to comment

9 answers to this question

Recommended Posts

  • 0

I believe we have the same issue.

In our case we have Server Operating systems running with PVS.

a mix of Server 2008R2, 2016 and 2019.

two weeks ago we upgraded to PVS agent 1912 CU1 and now random servers disconnects  about 1 or 2 times a day.

Event log shows: bnistack event id 85, [MIoWorkerThread] IOS Socket UNAVAILABLE - not counting retry.

the server drops all network traffic, wont even respond to ping, for a few minutes.

I believe there is a bug in PVS agent 1912 CU1

Link to comment
  • 0
On 8/10/2020 at 11:46 AM, Carl Stalhood1709151912 said:

What Cumulative Update for 7.15 is installed?


Hi @Carl Stalhood, sorry for the delay I must have missed the notification email. 


On the VDA the versions are -


VDA - 7.15 LTSR CU5 (7.15.5000.855)

PVS - 7.15 LTSR (


The PVS Server is running -


@Niklas Paringlerstam


I'm not sure if its the same, there is nothing in the event logs and the servers run fine all day without going Unregistered, its during the night when they go Unregistered for some reason but I cant find out why, nothing runs that would cause them to lose connection to the DDC


Link to comment
  • 0

We have had the same issue since upgrading to 7.6 to 7.15. Our Desktop and Published Application servers reboot nightly and randomly some will never re-register and become "zombified" for lack of a better word.


Currently running PVS 7.18 with no change. Was contemplating upgrading to the latest issue (2009) but ran into an issue with the Target Device upgrade (https://discussions.citrix.com/topic/411194-citrix-provisioning-target-device-x64-200900-does-not-support-personal-vdisk/)


Was then considering going to 1912 CU1 but it sounds like the person above is still having the same problem. I can't believe this hasn't been fixed over so many versions and CUs. This was never an issue in 7.6.


I also have another thread going but no responses: https://discussions.citrix.com/topic/410736-target-devices-becoming-unresponsive-vmware/

Link to comment
  • 0

This was resolved for us since upgrading our storage array to SSD, no issues with VDAs going unregistered overnight since. We didn't upgrade the array for this issue it was happening anyway, this was an unexpected benefit.


I suspect the backups and related snapshots were causing the VDAs to go unregistered perhaps when the DDC was being backed up and snap shot removed due to their not being enough performance available on the old disk array but I was never able to prove it.



Link to comment
  • 0

Symantec has identified the issue per article below.  The workaround is to disable error reporting from the site level in SEPM. 

Admin > Servers  > Local site > Edit Properties > Collection Tab > Troubleshooting > 

Uncheck "Let clients send troubleshooting information to Symantec to resolve product issues faster"




Hope this helps.


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...