The-Virtual-Desktop-Team / Virtual-Desktop-Optimization-Tool

The script and configuration files in this repository provide an easy method to customize and apply performance related settings to virtual desktop environments.
687 stars 174 forks source link

/Microsoft/Windows/International/Synchronize Language Settings Task Hangs after Optimization #46

Closed brepmasterdav closed 3 years ago

brepmasterdav commented 3 years ago

Hi,

We've used the optimization script on a 20H2 image and are having some strange issues. Logging in with a fresh user profile on the optimized 20H2 image and then logging out fairly quickly after is causing the Windows logout to hang due to the above mentioned task. If you force the logout and log back in again, open Task Scheduler, we can see this task initiates at login and runs for 10 minutes until it hits the defined 10 minute timeout. A logout after the task has timed out, or if the task is stopped manually is successful.

What's interesting is that the same does not occur on the same image before the optimization script has been run against it. The task will fire at login and complete with the same second.

Do you have any thoughts around this?

Thanks in advance.

tmmuessig commented 3 years ago

Hi @brepmasterdav - That is an interesting one that we have not seen before. Can you grab the code from from the tmm-dev branch and run the following so everything else is run except the ScheduledTasks to see if you still have the issue?

.\Win10_VirtualDesktop_Optimize.ps1 -WindowsVersion 2009 -Optimizations AppxPackages,Autologgers,DefaultUserSettings,DiskCleanup,LGPO,NetworkOptimizations,Services,WindowsMediaPlayer

brepmasterdav commented 3 years ago

@tmmuessig Thanks for the swift reply Tim!

After posting this, I noticed it was a duplicate of Issue #29 . I see @sandude-ms replied about re-enabling the "\Microsoft\Windows\Speech\SpeechModelDownloadTask" Task. I've just checked out our optimized image and this task is indeed disabled, so I'm just in the process of rolling out this change to retest with the task enabled.

I will report my findings.

brepmasterdav commented 3 years ago

@tmmuessig Hi Tim,

Just to add, we're using VMware Horizon 8 2012 for the deployment of our VMs.

So here's what I've found:

1) On the 20H2 image that I'd already run the optimisation script I simply re-enabled the "\Microsoft\Windows\Speech\SpeechModelDownloadTask" task as per @sandude-ms on the other issue. Result: No change. The Synchronize Language Settings task runs for 10 minutes and then times out. Meaning if you login to the VM and then out again within 10 minutes the logout fails.

2) Revert image back to a non-optimised state via snapshot. Re-run using the master optimisation script without touching the Scheduled Tasks. Result: The same behaviour. Logout within 10 minutes fails due to the Sync Language Settings task hanging.

3) Revert image back to non-optimised state via snapshot. Re-run using the tmm-dev branch and using your command above. I removed the "WindowsMediaPlayer" option as we need this in our image. Result: The same behaviour. Logout within 10 minutes fails due to the Sync Language Settings task hanging.

4) Deploy non-optimised image. Result: The Synchronize Language Settings task runs at logon and completes within the same second. A logout is honoured correctly and logs the user off as expected.

It seems the optimisation script does something to cause this task to hang given the above.

If you need me to test anything else, please let me know.

LBXComputers commented 3 years ago

Hi, I'm also seeing the same. Any ideas on a fix please?

dancing-groot commented 3 years ago

Same here, testing 20H2 for WVD. The scheduled task in question is already enabled for me. If it makes a difference, I installed en-gb language, ran VDOT, then sysprepped the VM to create an image.

JMann1987 commented 3 years ago

Experiencing this issue across multiple WVD Deployments, utilising either 2004 or 20H2 (2009). The Scheduled Task "SpeechModelDownloadTask" remained enabled on some environments but was disabled on others. I've since been through ensuring the task is enabled for all WVD Session Hosts but the issue remains. Would appreciate any further feedback on this issue please. Edit - Updated following comment from LBXComputers, thanks.

LBXComputers commented 3 years ago

Experiencing this issue across multiple WVD Deployments, utilising either 2004 or 20H2 (2009). The Scheduled Task "SpeechModelDownloadTask" remained enabled on some environments but was disabled on others. I've since been through ensuring the task is enabled for all WVD Session Hosts but the issue remains. Might require further troubleshooting to verify, but it only appears to occur for FSLogix User Profiles and not Local User Profiles. Would appreciate any further feedback on this issue please.

We're seeing it when logging in as a domain administrator which has been excluded from FSL - so is using a local user profile.

davetustin commented 3 years ago

Hey everyone, just a quick message to let you know we are also experiencing it, but we have yet to investigate it.

I was hoping someone might have found a fix for it already. I will keep an eye on this issue and if we find anything will let you know.

sandude-ms commented 3 years ago

If anyone could try for a test...rename the file "ScheduledTasks.json" to "ScheduledTasks.json.old". Then run the optimizations as normal. If we narrow it down to just those subset of optimizations it would be a great help.

Also, I have edited a ScheduledTasks.json file, by removing several entries including SpeechModelDownloadTask. If someone could try this and let us know if it helps.

ScheduledTasks.json.txt

Thanks,

Robert Smith

sandude-ms commented 3 years ago

Just a quick update @davetustin, @JMann1987, @LBXComputers, @dancing-groot, and @brepmasterdav. I was able to get a reproduction of the issue in a lab environment. I have it narrowed down to one of the services causing this issue (not ScheduledTasks). The workaround for now would be to delete "Services.json", or just run all the optimizations except Services. If someone else could test this that would be great. Once we determine which one or ones, we will post that information and also probably make a new Pull Request to get that checked into "main".

sandude-ms commented 3 years ago

@davetustin, @JMann1987, @LBXComputers, @dancing-groot, @brepmasterdav (et al). I believe I have found the problem. I was able to stop the delayed logoff in my test environment by editing the file 'Services.json', and changing the 'VDIState' to anything but 'Enabled' ('Unchanged' is what I used) for the following 2 services:

Ex. "VDIState": "Unchanged",

If someone could test and confirm, we would be most appreciative. I would be glad to PR that change into the "main" branch as soon as someone can confirm positive results.

Thanks,

Robert Smith

Iamshehansilva commented 3 years ago

@sandude-ms As you mentioned above, I have tried both scenarios with scheduled tasks. Please see the results below:

Our environment is running on Win10 2004. I haven't tried this out with the services you mentioned yet.

Apart from that, I would like to share something that we found on VM, where this issue is prevailing. We have disabled the “Synchronize Language Settings” (Microsoft\Windows\International\Synchronize Language Settings) task. After this, I didn't experience any sign-out delay.

Thanks, Romero Silva

Iamshehansilva commented 3 years ago

@sandude-ms I just tried after editing the 'Services.json' file as you recommended and I have done multiple testing by adding different language packs and I didn't experience any signout delay afterwards but I will do a couple more tests and let you know the result if anything changes.

Changes:

Thanks, Romero Silva

davetustin commented 3 years ago

@sandude-ms I made the changes to the services.json as recommended and it appears this has resolved the issue with logging out. I have only tested it a hand full of times, but so far so good!

Its the end of the working day here, so I can test it more on Monday if needed.

Thanks for looking into it so quickly! Dave

LBXComputers commented 3 years ago

Are you amending services.json and reapplying over the top of an already optimized machine or are you running on a clean unoptimized image?

davetustin commented 3 years ago

Are you amending services.json and reapplying over the top of an already optimized machine or are you running on a clean unoptimized image?

I was deploying a new image at the time so I haven't tried applying it over the top of an existing one.

Remember to check the Windows version and change the the relevant services.json you are using. As in my case it was 2009.

sandude-ms commented 3 years ago

We just made a change so that those 2 services are left unchanged (CDPSvc, CDPUserSvc), in all folders. Their uses are unclear in many virtual desktop cases, and CDPUserSvc will spin up a "per-user" instance of Svchost.exe. That could lead to a number of services that may not be potentially needed, but better to have that than a problem at logoff.

If you have existing machines, and you don't want to reimage them, if you have some kind of central management like AD GPO, or maybe Intune, you can change the service start values with GPO. That one isn't difficult, especially if your VDI devices are in a common OU.

reg add HKLM\SYSTEM\CurrentControlSet\Services\CDPSvc /t REG_DWORD /v Start /d 2 reg add HKLM\SYSTEM\CurrentControlSet\Services\CDPUserSvc /t REG_DWORD /v Start /d 2

Note that in my test lab, I was able to stop the hanging task at logoff by changing ONLY 'CDPUserSvc' back to default start value (2). But I believe those are related services, so best to put them both back to default.

sandude-ms commented 3 years ago

We believe this issue is resolved by editing the CDPSvc and CDBUserSvc start values back to default, and by changing the Services category to leave these unchanged. If this is not the case please open a new issue and refer to this one. Thank you for utilizing the VDOT project.