This is a known issue. I had the same issue and have a post on this site about it. Just search for my name. I ended up going back t0 1709 because of it.
I posted in the other thread as well, but I am seeing the same issue with 1803. Wondering if anyone has a fix? It works perfectly without the mandatory profile but as you all know you really need a mandatory profile for Windows 10 otherwise logon times are rough.
Same behavior in my case. If I used mandatory profiles, an adjustment of the start menu is not possible. Without mandatory profiles everything is fine. I hope the bug will be fixed next year when the next windows 10 ltsb version is released.
I want to add that this is a still issue on Windows 1809 LTSC. Works fine if you don't use mandatory profile.
Maybe Predefined settings are not capturing what is needed. I checked in all locations under Local App Data folders that are captured in UEM from the previous login and they were restored correctly. What I notice is that I started Pinning new Tiles to start menu and nothing changed in these folders or registry to indicated that something was added.
Does anyone know where exactly the Tiles are stored in the profile?
Has anyone looked in the .zip .reg file to see if the start layout is even being captured? Has anyone tried setting the following key to 1? What does the uem log report in debug mode?
Hive HKEY_LOCAL_MACHINE Key path Software\Microsoft\Windows\CurrentVersion\Explorer Value name SpecialRoamingOverrideAllowed Value type REG_DWORD Value data 1 (or 0 to disable) Base Decimal
And then there's always my favorite, exclude this key from all configs where it might exist:
I added SpecialRoamingOverrideAllowed setting to local machine registry, but it didn't make any difference. Here is what I see on debug log.
I still think that the problem is with these 3 files in the Cloudstore folder. They are still in use when UEM is attempting to capture them. I check what service potentially is holding that folder, but I'm not sure if that is the correct one.
C:\Windows\system32\svchost.exe -k UnistackSvcGroup -s WpnUserService
You can use sysinternals handle tool to find which process has the .dat file open: Handle - Windows Sysinternals | Microsoft Docs
Then you can edit the permissions on that service using sdset to allow authenticated users or everyone to stop the service: Sc sdset | Microsoft Docs
Then you can set a logoff Acton before export to stop that service. I did something similar in 1607: Windows10StartLayout.ini instructions
Here is a list of things that need to be killed (in order) to free up locks on cloudstore.dat:
WpnUserService_##### (sc stop WpnUserService_#####) I'm not sure what generates the random #### per each login.
OneSyncSvc_##### (required elevation) but the service can be disabled on the golden image (sc config OneSyncSvc start= disabled) or you could edit the sddl using sc sdset.
These might not all be running during logoff and there are likely others that will lock cloudstore.dat but it's something I guess. The real question is will killing this stuff with a pre export task allow UEM to get the cloudstore.dat ?
Using a powershell script something like this?:
stop-process -name "explorer.exe" -force
stop-process -name "searchui.exe" -force
stop-process -name "shellexperiencehost.exe" -force
get-service WpnUserService_* | stop-service -force
get-service OneSyncSvc_* | stop-service -force
For my environment (LTSC 1809) this was all that was needed as a pre export logoff task:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command get-service WpnUserService_* | Stop-Service -force