Jump to content


Photo

Is it possible to delay VDA registration to Xendesktop 7.6 Controller after VM startup?

Started by portaal1 , 25 November 2015 - 03:29 PM
13 replies to this topic

portaal1 Members

Theo Portaal
  • 15 posts

Posted 25 November 2015 - 03:29 PM

Hello everybody,

 

First off, i have to say we are not really experiencing any problems with our Xendestop 7.6 configuration and systems. VDA's are registering without problems to the controllers and pretty quick as well.

 

However, it now seems that these speedy registrations are causing some side effects that result long logon times for users.

During the day users log on and off and desktops are restarted as a rsult so they are available again. Now we noticed that VM's that have just been restarted are also the first VM's to be assigned to a new user session again even tho there are 50 more VM's ready that have been ready for hours.

 

We suspect that these VM's, that have just been started, are still processing some configurations when a user session gets assigned to it.

 

So in order to prevent that we would like to know:

- is this working as intended? user sessions being assigned to the last VM that registered itself?

- is there any way to manupulate this? by example to delay the VDA registration or maybe a setting in the Desktop group?

 

It would be great if anybody could answer these question and even better if there is a solution!

If more info is needed please let me know.

 

We run a Xendesktop 7.6 configuration on a vSphere 5.1 hypervisor. And have a Windows 8.1 catalog with MCS random pooled vm's (about 550 desktops).

User personalisation is done with Appsense personalisation.

 

Thanks in advance!

 

Hans

 



Ryan Goldstein Members

Ryan Goldstein
  • 310 posts

Posted 25 November 2015 - 03:50 PM

hahaha that's a good problem to have i guess.

 

Set the Citrix Desktop service to delayed start on your Master Image.

 

Set the Desktop service to manual and start the service with a script after a set amount of time.

 

 

 

With 550 desktops you would have about 55 desktops in your ready pool by default, as far as i know its a random what desktop a user gets put on.  That should be big enough where a user should not regularly get a newly registered desktop, so i'm skeptical that is your issue, but GL to you.



Blair Williams Members

Blair Williams
  • 126 posts

Posted 25 November 2015 - 04:00 PM

I have observed the behavior you are talking about - machines being available but a user getting assigned to a machine which is still booting. The user sees "Please wait while your workstation is being started..." and then the session launches after it's registered. I would be curious for someone from Citrix to explain how exactly it does choose randomly from the pool. I've seen a user log off a machine, wait 15 seconds and log back on, and get the same machine they were just using, which was still booting up, despite there being about a thousand free machines in the random pool.



portaal1 Members

Theo Portaal
  • 15 posts

Posted 26 November 2015 - 06:35 AM

Thanks for your reply guys!

 

We'll try adjusting the desktop service.

 

I agree desktop assignment should be random, i guess it is random because a user is not bound to a certain VM. It is just when you ask someone to log off and back on, 9 out of 10 times they will get redirected to the same desktop again, unless another user happens to log on in between.

We have tested this in a small desktop group with 10 desktops where a user would constantly be logged on to the same 2 desktops.

So we have made the same observations Blair Williams has (also the "please wait while your workstation is being started") and we are also very curious how the desktop assignment works.

It does not feel to be random like picking blindly from a pool of VM's, but more like picking the top VM from a stack. And newly registered vm's get added to the top of the stack.



Michael Tudor Members

Michael Tudor
  • 177 posts

Posted 10 December 2015 - 11:16 PM

I'm having a similar problem, when someone logs off their desktop restarts. The next person to log in seems to get the desktop that restarted the most recently, its like available desktops have a weighting and the most recently rebooted ones always get picked first.

 

The problem is other software that updates at startup, we use Microsoft Configuration Manager and Endpoint Protection for our antivirus. The desktop takes a good half hour to settle down after a reboot, it creates a rubbish user experience when they first log on.

 

How did you deal with this? Ideally XenDesktop would be able to delay assigning recently booted devices, but I suspect I might have to set the service to manual start and then use a scheduled task to start the service 30 minutes after boot, but that sounds extreme to me.



Ryan Goldstein Members

Ryan Goldstein
  • 310 posts

Posted 10 December 2015 - 11:30 PM

Also if you schedule for 30 min after boot, citrix is going to think there is an issue and put the desktop into maintenence mode.

Michael Tudor Members

Michael Tudor
  • 177 posts

Posted 11 December 2015 - 12:45 AM

good point, I didn't think of that. I might have to raise a call with Citrix over this.



Rasmus Kindberg Members

Rasmus Kindberg
  • 1,013 posts

Posted 11 December 2015 - 09:24 AM

Also if you schedule for 30 min after boot, citrix is going to think there is an issue and put the desktop into maintenence mode.

 

This behaviour can be disabled/modified through registry keys on the DDC.



PETE MICKELONIS Members

PETE MICKELONIS
  • 26 posts

Posted 11 December 2015 - 07:11 PM

I have observed the behavior you are talking about - machines being available but a user getting assigned to a machine which is still booting. The user sees "Please wait while your workstation is being started..." and then the session launches after it's registered. I would be curious for someone from Citrix to explain how exactly it does choose randomly from the pool. I've seen a user log off a machine, wait 15 seconds and log back on, and get the same machine they were just using, which was still booting up, despite there being about a thousand free machines in the random pool.

 

I've observed this exact issue in my environment.



Michael Tudor Members
  • #10

Michael Tudor
  • 177 posts

Posted 13 December 2015 - 08:47 PM

This behaviour can be disabled/modified through registry keys on the DDC.

Do you have any idea what keys I should be looking at?



Ryan Goldstein Members
  • #11

Ryan Goldstein
  • 310 posts

Posted 13 December 2015 - 08:57 PM

HKLM\Software\Citrix\DesktopServer\MaxFailedRegistrationsAllowed
Value = -1 (REG_DWORD)
If -1 is set, DDC will not put the VD in maintenance mode, regardless if it has registered successfully or not
Default is 2 if not set

HKLM\Software\Citrix\DesktopServer\MaxRegistrationDelayMin
Value = 20 (REG_DWORD)
Default is 20 if key not present

http://discussions.citrix.com/topic/296460-maintenance-mode-being-automatically-enabled/

Erno Alanen Members
  • #12

Erno Alanen
  • 40 posts

Posted 08 April 2016 - 11:04 AM

Any more info to this? I have been wondering years why DDC assigns user the desktop which has just started, or even worse starting, even when there are plenty of unused ready desktops in the pool..



Michael Tudor Members
  • #13

Michael Tudor
  • 177 posts

Posted 10 April 2016 - 08:39 PM

I logged a case with Citrix regarding this and got it escalated to the Devs, there is currently no ability to do this (other than the hack above).

 

In the end I logged a "Citrix Enhancement Request" but I haven't heard back yet.

 

It's a shame really because this is the main reason people complain "Citrix is slow" from my experience. For us most of the delays are caused by the Configuration Manager Client and Microsoft Endpoint Protection. I really don't think these products are suitable for a virtual desktop environment.



Nathan Boniface Citrix Employees
  • #14

Nathan Boniface
  • 93 posts

Posted 19 May 2017 - 03:53 PM

FYI to address this problem look at setting the following Parameter of Set-BrokerDesktopGroup

 

        -- SettlementPeriodBeforeUse (System.TimeSpan)
           Idle period before a machine can be selected to host a new session after registration or the end of a
    previous session. This is typically used to allow a machine to become idle following processing associated with
    start-up or logoff actions. A machine may still be selected during the idle period if no other machine is
    available for immediate use.