Already seen in other forums, but did not find any solution.
We are using VMware UEM 9.3 with Windows 10 (in this case build 1609), but the icon locations are not maintained.
The first time a user logs into a dekstop, and arranges his icons and logoff, then the locations are being save (somewhere), after loggin on again, these locations are maintained. After changing the locations again, log off an log on again, the first time arranged icons are where they where the first time. So after the first time logging on with a user it works, after that not anymore...
Already tried different logs...
https://communities.vmware.com/thread/554311
https://communities.vmware.com/thread/563975
https://communities.vmware.com/thread/522005
https://kb.vmware.com/s/article/2128007
But no solution unfortunately,
Any tips/suggestions about this topic?
Are you using Blast to connect to the VDI machines?
Because Blast will reset/change the resolution after the connection is setup, and this causes the desktop icons layout to be reset.
Not a lot UEM can do about that, since it's how Blast and Windows work. If you change the resolution of your session you will see the same behavior, and it makes sense, because when switching to a lower resolution, sometimes the icons layout no longer fits on the screen and needs to be reordered.
Well
In my lab : No, in my lab just Windows 10 RDS and UEM 9.3, and strangly enough, same behaviour...
hi
I ran a PoC for a customer last year, using UEM 9.2 and Windows 10 (1609 and 1703). One of the key test points for this PoC was to retain icon locations on the desktop. In this case we had no issues regarding this. I ran a few test this morning using different screen sizes, even changed between one and two monitor setup, icons moved saved and retained locations to "last saved".
I read a bit about this issue, but only settings I enabled to retain icons was to "expand" the "Windows Explorer" config.
I'll try to upgrade to UEM 9.3 later today and see if I get the same behavior.
We have it as an extra Ini File for this - do have these in your enviroment?
[IncludeRegistryTrees]
HKCU\Software\Microsoft\Windows\Shell\BagMRU
HKCU\Software\Microsoft\Windows\Shell\Bags\1\Desktop
BR
Thanks for youre info, I have the same config tried...
The behaviour is after the second / third time logging on and then change the location..
It seems that this issue kicks in after the first time UEM writes the user settings away. From that moment, this issue starts.
I also have tried in a clean Windows 10 / UEM 9.3 setup, same story....
Yes I have these...
hi
Upgraded my UEM agent to 9.3 this morning, still not able to reproduce your problems.
Starting up a new environment next week, will exciting to see if I get any issues
Interesting please let me know....
I have same issue on 1709. No fix.
I will investigate further! Also interesting for 18031
If I come up with something I will let you know asap
We have similar behavior in Windows 7, but only in multi-monitor situations. Single-monitor users always persist their icon locations. Following...
Actually we have same story long back but I did not keep eye on it these day's, I will updated on it if we are having this issue are not with multiple scenarios [like, single monitor and double monitor]
Regards,
Vkmr.
We had this same issue in our environment.
I noticed a crucial registry key for preserving icon locations was missing from the the default Windows Common Settings in UEM which we added (sounds like you found this too)
Once we applied that, it fixed 80% of our users, however, we still had a handful continuing to experience issues. What the heck Microsoft!?
After doing some registry comparisons, the key mentioned above was not behaving correctly on the problem profiles
The Fix
Deleting the entire 'HKCU\Software\Microsoft\Windows\Shell\BagMRU' key completely fixed the issue. Once it was deleted, I logged out the user, logged them back in, and any desktop changes from that moment forward was retained every log in. Seems like an easy thing to automate for someone much more skilled than me .
What a pain!
This is very interesting! Thanks, I will dig into this...