Windows 10 LTSC - Slow Logon with UserLayer enabled

[Dominic Herrmann1709161393]

Hello,

 

we have trouble with our userlayer enabled Win 10 LTSC workers. The logon performance is very slow although the layers are empty.

 

Our environment:

XenDesktop 1909

ELM Appliance and machine tools: 19.10.0.26

Worker: Windows 10 x64 LTSC hosted on Xenserver Pool 7.6

Fileserver: Windows 2K16 with SMB 1.0 enabled

Default Userlayer size: 100 GB

 

Problem description:

 

If we logon with a fresh Userprofile without an existing userlayer in the smb store, we have logontimes round about 50 seconds.

If I deploy the same template without elastic layering, the logontimes is about 16 seconds.

All systems (worker, fileserver) have no antivir installed. Proof-of-concept phase.

 

I've placed the windows fileserver with the userlayer smb shares on the same hypervisor and in the same subnet, where the worker resides. Without luck. The logonperformance is still way too slow.

A newly created userlayer .vhd after the first logon is only 312MB big. That's not much.

 

Do you have any idea, what could slow down the logonprocess or where to obtain debug logs?

 

Thanks in advance

 

 

[David Thacker]

I'm sure one of the employees will correct me if I'm wrong, but from my understanding of App Layering, User Layer disks are attached to the VM via filter driver during the logon process. There is a folder in (I think) ProgramData\Unidesk, or %appdata%\Unidesk that has a session log that is created when the VM is powered up and it covers the logon phase (all the Elastic Layering attaches, User Layer attach) with the load times and any errors it encountered. It's a good place to start when debugging login issues, since it logs the file/location/success/failure/time to load/etc.

 

312MB for a Win10 profile seems low, even Win7 profiles tended to be larger than that on initial creation. I would definitely check the logs

[Billy Xiong]

We ran into slow login times and noticed it was something with GPOs and printers. In the end, we Cleaned up the GPOs and moved the printers to the platform layer then set them by default via GPO instead of adding them. Not sure if this pertains to your situation, but it doesn't hurt to look?