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

[Theo Portaal]

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]

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]

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.

[Theo Portaal]

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]

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]

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]

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

[Rasmus Kindberg]

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]

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]

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]

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]

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]

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 Boniface1709152749]

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.

[Jason Lloyd1709152312]

 

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.

 

 

This is exactly what I'm looking for but the parameter you speak of is not available in 7.6. Please can you confirm what version it was released in?

[Stuart Millar]

On 19/05/2017 at 4:53 PM, Nathan Boniface1709152749 said:

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.

 

I've tried using this setting but it doesnt seem to work on 7.15.  VDAs still change from "Initalizing" to "Registered" within seconds of Windows booting.

 

set-brokerdesktopgroup -name "MyDeliveryGroupName" -SettlementPeriodBeforeUse 00:03:00

 

Using get-brokerdesktopgroup -name "MyDeliveryGroupName" shows it has changed to 00:03:00.  All the VDA VMs have been rebooted and all delivery controllers have rebooted too (in case thats relevant).

 

I'd rather use this instead of delaying startup the Citrix Desktop Service.  Has anyone seen it work?

 

[Stuart Millar]

I couldn't get the SettlementPeriodBeforeUse setting to work so gave up and used a scheduled task to control the Citrix Desktop Service and create a 5 minute delay.   As per instructions here:  https://smulpuru.wordpress.com/2017/04/30/delay-vda-registration-for-xendestopxenapp/

[Global Systems]

When you say you couildnt get it to work. Was it being set correctly after you ran the powershell. When you went back and dig Get-BrokerDesktop group was it listing the time change you made?

[Jeremy Saunders]

I've been dealing with this issue for a few years now and have provided the solution here: https://www.jhouseconsulting.com/2019/03/04/controlling-the-starting-of-the-citrix-desktop-service-brokeragent-1894