This message was deleted.

So basically because they are not registering with in the time that is the default ( I thought it was 20 minutes by default). I can’t recall if memory what that is. The broker is shutting them down right?

Check out the SettlementPeriodBeforeUse flag on the desktop group as an alternative approach

Well, this link is what I am reading now. https://support.citrix.com/article/CTX140522/how-to-support-virtual-machines-with-long-startup-times-in-xendesktop-environment

@James Kindon

SettlementPeriodBeforeUse

only seems to work, after the registration, if I read that correctly? My problem is, its getting turned off before the registration.

A machine may still be selected during the idle period if no other machine is available for immediate use.

But this might still not work. As this is a small environment with 4 prod and 1 test machine, I do understand that the test machine would still accept user sessions, even if I set that

SettlementPeriodBeforeUse

value, because it's the only machine, what do the others think?

lol. snap.

So I guess I just put the FSLogix registry values into the master, and delete the VDA registration delay.

I've never used Auto Scale. I'm surprised you can't change the timeouts for it for this use case.

But that only solves the problem partly. I still would like to use that BIS-F VDA Registration delay, so I could let WEM finish its work, before the first user session.

Towards the bottom it should say Citrix Cloud or I though it did.

Here is another CTX article, I'm not sure if that might be the solution: https://support.citrix.com/article/CTX237815/

Looks like someone else has a similar issue. Not resolved in this thread: https://www.reddit.com/r/Citrix/comments/zbcel0/autoscale_on_daas_not_working_due_to_spin_up_time/

I love WEM, but when I deployed FSLogix from it, I had similar issues with the settings not applying right away from the GPO side that pertained to FSLogix. WEM has a regkey (SyncForegroundPolicy) that I used that allowed it to wait some. But then I was slower logins. I moved it back to native GPO for the Profile side. Computer GPOs are just as quick in my experince than WEM Computer GPO settings. The area I was talking about is here. https://docs.citrix.com/en-us/workspace-environment-management/current-release/install-and-configure/agent-host.html#system-settings

Currently testing the Maxspinup metadata setting

I know this does not address the AutoScale situation, but figured I share it vs bakeing it in the image.

Mh, worked on the first try 🤔

What worked extacly?

hmm interesting

I set that to 600 seconds in the Azure hypervisor connection, then launched the VM, this time it registered after the BIS-F delay, and didn't turn off. But one test is null test, so I will do more tests tomorrow.

Nice @Marco Hofmann. I think there's a blog in that 🙂

@Ray Davis So the Shutdown problem seems to be solved, but the original issue isn't solved :-/ BTW this is an AzureAD only environment, so no classic GPO available. Only WEM und PowerShell/Packer. I did some troubleshooting this morning, but regardless of what I try, all WEM GPO settings, only get applied, through the very first Citrix login. I waited 30 minutes, nothing. I executed

.\AgentCacheUtility.exe -RefreshCache -Reinitialize

, nothing. So despite missing my FSLogix settings, that should come through WEM, I'm just found out I also miss all other values, until somebody logs in! So I could fix my FSLogix problem, by adding all the registry settings, into the PowerShell setup script. Annyoing, but solves the issue. But still, all my other WEM GPO objects would still be missing, until somebody logs in. Any ideas @James Kindon @Anthony Shi?

I observed that new WEM agents were not always correctly registered. On WEM console you get the error "Agent (Agent name) is not bound to any configuration set". Usually a restart of the VDA solve this issue but the first users got a very bad experience.

I haven't done anything with Azure AD stuff with WEM - are you deleting the cache on your master image prior to provisioning? That could be potentially problematic?

Hi! I wanted to give feedback on how I solved the issue: 1. The shutdown issue was solved, but didn't solve the initial issue. 2. I reverted those changes. So BIS-F doesn't delay the VDA registration anymore. 3. Therefore the fix to the hypervisor connection via CTX237815 wasn't necessary anymore. 4. As I said above, WEM agent did only push those HKLM settings during the first user logon, regardless of how long I waited. 5. Through some search here in Slack, I stumbled upon:

SyncForegroundPolicy

6. This led me to: https://docs.citrix.com/en-us/workspace-environment-management/current-release/install-and-configure/agent-host.html#good-to-know 7. Which made me change my install string to:

$UnattendedArgs = '/quiet Cloud=1 SyncForegroundPolicy=1'

8. I then created a new DaaS master image via Packer with VDA and WEM agent 2308. 9. I wasn't able to replicate the issue since then! 10. Every logon has my FSLogix settings available and lets me load my VHDX correctly.

Good to know the outcome. This is the 3rd time I have heard of using the SyncForegroundPolicy =1 now. When I used it, I did see the logins delay some. Curious if you spotted that?

I did no measurement, so I can't give you objective numbers, only subjective feelings, and I didn't feel a slow down.

Okay, cool. Thanks for the update here. Good to see this.

Now that is very strange as that key (to the best of my knowledge) was for user policy only. I wonder if they have changed it and not documented… @Anthony Shi might know

hmmm interesting. I am wondering myself as well.