In the effort to make logons faster and the Win10 Start menu quicker to launch, I implemented a mandatory profile on Win10 1803. After implementation, logons were a little faster and the start menu went from taking 30 seconds to launch to launching instantaneously. Although I like the result of the instantaneous start menu, the user's changes to the start menu is no longer being saved. If I disable the mandatory profile within AD for a user, the UEM brings back the user start menu changes. My question is: Is there a way I can use both the mandatory profile and the UEM and allow user changes to be saved in the start menu?
Thanks
Rob
Creating a new-fully patched 1709 master image resolved the issue. I made absolutely NO changes to my mandatory profile config.
Thanks to all who participated in the solution. Very nice to have this solved the day before I leave for vacation!
Cheers!
Rob
Hi robsisk1972,
That use case is definitely supported – mandatory profiles were the main reason to create UEM ten years ago, and although the Windows 10 start menu has proven to be a bit tricky to persist and restore, our latest templates should do the trick.
Which version of UEM are you using, and how are you persisting the start menu? Also, how did you create the mandatory profile?
n Response to: Which version of UEM are you using, and how are you persisting the start menu? Also, how did you create the mandatory profile?
UEM Version = 9.4.0.820
Mandatory Profile creation method = Creating a mandatory profile on Windows 10 1803 – JAMES-RANKIN.COM
Persisting Start Menu Config =
Hi robsisk1972,
Thank you for the additional info. Could you try recreating your "Start Menu" Flex config file based on the UEM 9.4 Windows Common Setting?
That will capture a few more registry and file system locations than your current config file.
Unfortunately, the template didn't work either.
I removed my custom config and used the default as shown below:
Hi robsisk1972,
Thanks for trying that. Just in case: did you remove the corresponding profile archive from the previous export before testing this?
Paging Pim_van_de_Vis and ijdemes to see if they have any insights.
Those [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Microsoft\Windows\CloudStore\cloudstore.dat' log messages are not boding well...
I hope Pim, Ivan, or someone else can shed some light on this...
I hope so too! Any help I could get from Pim_van_de_Vis or ijdemes would be greatly appreciated. This is one of my last issues before I take this POC in to production. I have my new VXRails racked and stacked and I am ready to move on.
The warning message in the logs is definitely related to the mandatory profile. If the mandatory profile is not set in AD, these files don't exist nor does the warn message appear in the log.
The only thing I can think of that may impact this is the way I created the Mandatory Profile. I have to confess that I cheated a bit: One of the steps before you copy out the profile to a network share is that one must completely patch the OS. By nature, I'm lazy and this takes about 5 hours to accomplish so I did NOT patch the OS before exporting the profile. I don't know if this factors in or not but I am currently in the process of creating a new ManProfil with a fully patched OS. Is should be done in about 3 hours of pain staking waiting and will post the results back. IF this works, I will have more questions regarding will my mandatory profile need to be rebuilt every time I patch my OS. IF so, I will not be a fan of Mandatory Profiles. I have even heard that MS may not even support them much longer. Is there any truth to this?
Well...That proved to be a waste of time. I completely patched the OS and ran through all parts of the mandatory profile build and I have the exact same problem. When I shutdown the machine after making changes to the start menu, I see this in the log file and all of my start menu changes have vanished.
2018-07-25 12:17:50.386 [INFO ] Exporting file information
2018-07-25 12:17:50.386 [DEBUG] ExportFiles: Recursively processing folder '<LocalAppData>\Microsoft\Windows\Caches'
2018-07-25 12:17:50.407 [DEBUG] ExportFiles: Recursively processing folder '<LocalAppData>\Microsoft\Windows\CloudStore'
2018-07-25 12:17:50.407 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Microsoft\Windows\CloudStore\cloudstore.dat'
2018-07-25 12:17:50.409 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Microsoft\Windows\CloudStore\cloudstore.dat.LOG1'
2018-07-25 12:17:50.409 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Microsoft\Windows\CloudStore\cloudstore.dat.LOG2'
2018-07-25 12:17:50.411 [DEBUG] ExportFiles: Recursively processing folder '<LocalAppData>\Microsoft\Windows\Explorer'
2018-07-25 12:17:50.907 [INFO ] Exported file information successfully
I'm at a loss!
I suspect the mandatory profile is the issue here.
Could you give this guide a try?
Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware
Just been published and I've heard good results with creating a mandatory profile when following these steps.
Please let me know the results.
So it's not really the mandatory profile as much as it is 1803 and UEM. After getting my VMWare ticket escalated, I was finally able to work with a tech and we figured out that it's a bug right now and is documented in the UEM 9.4 release notes. So now I am building a new Master image and moving down to 1709 until it's fixed. The major issues is that some files in %Localappdata% are in use and locked therefore can not be copied back to the network share.
Hi robsisk1972,
That known issue is just about a few aspects of the start menu (like the ones mentioned there); the start menu tiles themselves roam correctly.
Note also that that issue is not specific for a particular Windows 10 version.
I don't have anything constructive to add, I'm afraid, but just wanted to warn that moving down to Version 1709 isn't necessarily going to make this work, until we figure out what exactly is happening in your setup.
How can you say that it is not specific to a version of windows 10 when it clearly states 1803 and was just added to the release notes 2 days ago? Unless you have a better idea, I am proceeding.
These are two separate issues (maybe more clearly visible on the original release notes page.)
The update from a few days ago only applies to the folder redirection item. That is indeed specifically an issue on Version 1803, but Microsoft fixed that in a later build, hence the update.
Creating a new-fully patched 1709 master image resolved the issue. I made absolutely NO changes to my mandatory profile config.
Thanks to all who participated in the solution. Very nice to have this solved the day before I leave for vacation!
Cheers!
Rob
wow @Pim_van_de_Vis ==> This links is realy great, thanks a lot !
Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware
I'm also experiencing this exact same issue on 1803
2018-09-24 17:27:32.337 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Microsoft\Windows\CloudStore\cloudstore.dat'
2018-09-24 17:27:32.337 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Microsoft\Windows\CloudStore\cloudstore.dat.LOG1'
2018-09-24 17:27:32.337 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Microsoft\Windows\CloudStore\cloudstore.dat.LOG2'
I also notice this isn't the only UEM setting with this issue.
It also appears to be the case for Edge:
2018-09-24 17:27:32.056 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\Settings\settings.dat'
2018-09-24 17:27:32.056 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\Settings\settings.dat.LOG1'
2018-09-24 17:27:32.056 [WARN ] ExportFiles::ExportFile: Sharing violation for file '<LocalAppData>\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\Settings\settings.dat.LOG2'
I'd rather not have to go back to 1709. I have opened a support case so I'll let you know if anything comes of it.
For reference I followed not only this guide:
Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware
But also this series:
Creating a mandatory profile on Windows 10 1803 – JAMES-RANKIN.COM
None of which have helped with the UEM issue.
I am curious if there has been any progress or suggestions for this with 1803?
I have UEM working well for persisting the start menu without mandatory profile. (and even using UEM built in "default settings" for a standardized start menu on first logon!)
Mandatory profiles are a requirement due to the fact that logon of Win 10 is simply too slow without them. The UEM Start menu config does not work and I am getting the same results as the original poster (only edge icon)
Hi All
I am also getting the issue with 1803, did anyone resolve the issue?
Thanks
Matt