Windows 10 1803
Issue: The users profile does not always load when logging on. The Group Policy for always waiting until DEM loads is set to on but a user can sometimes still find themselves logging on without their profile applied. You can tell instantly as we have Verbose messages at startup on via Group Policy and it doesn't "Apply DEM Settings" when the user logs on. Has anybody experienced this issue and resolved it?
Is there maybe an (intermittent) issue with Group Policy applying correctly? For a session where DEM didn't run at logon, what do you see in RegEdit in key HKCU\Software\Policies\Immidio?
The registry key isn't there for a profile that hasn't loaded properly but it is there for a profile that has loaded.
If that key is missing, that means that the GPO with DEM agent configuration wasn't applied, which explains why the DEM agent did not run at logon.
I'm afraid I'm not much help in trying to troubleshoot Group Policy issues; hopefully someone else on the forum has some ideas.
While not a common bug, it could be the UNC hardening issue "bug" found in the 18xx Windows 10 builds.
If you see some 1058 errors in your event logs, give this a shot.
UNC path hardening MS15-011 and MS15-014. It looks like Windows 10 has hardening enabled by default which is not the case with previous OS versions. As a test if you change the Local Computer Policy>Computer Configuration>Administrative Templates>Network>Network Provider>Hardened UNC Paths to Enabled and click into the Show button enter the following Values
See if this clears up your group policy errors.I added this into my Master Image and it resolved by random DEM not working issue.
See the article from Microsoft about MS15-011 for more information. It contains a good description of the security implications of changing this setting, as well as detailed steps of how to change the policy.
Warning: Note that the settings above disable some or all of the protections against the security issue MS15-011 was created for! Do not just blindly copy/paste them, but take an informed decision based on the risks involved. Also, this issue is likely to be solved sometime in the future. When that happens, don't forget to set this policy to the recommended values as described in MS15-011.
If that doesn't solve the problem then it is most likely a network stack timing issue, where GP processing for the computer is kicking off before the network stack is fully initialized. This has been around since Windows 7, Microsoft added a policy under Computer Configuration\Policies\Administrative Templates\System\Group Policy\Startup Policy Processing Wait Time where you can increase the time that GP waits before initiating. Try setting it to 60 seconds and see if that helps. (default is 30)