[1709, fcu] Mandatory vs Local Profiles on Windows 10

[karlr]

I'm currently researching and building a Windows 10 + Office 2016 deployment. Things are progressing but I've hit a snag when it comes to profiles. We're currently using a mandatory profile for our existing Windows 7 deployment and it provides us with a number of benefits:

 

* Cached profiles are wiped at logoff, so most user/profile related problems can be resolved with a simple logon cycle

* Logon times are reduced by skipping various "first sign in" actions

* Certain customisations are baked into the profile, which would otherwise be awkward to achieve via group policy (or are beneficial to have in place before GPO processes)

 

Mandatory profiles seem to have a questionable level of official support from Microsoft as of late, and we have had to implement a few hacks to get certain software to work. For example, certain cryptographic (PKI) functions in Windows will refuse to function if a mandatory profile is detected. However this can be bypassed by simply changing the registry value that describes the profile type (e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\\State).

 

Windows 10 (especially the Creators Update onwards?) seems to complicate matters even further. While it is now possible to create a mandatory profile on 1709 (as per https://www.htguk.com/how-to-create-mandatory-profiles-in-windows-10-creators-update-1703/) there are still some caveats. For example, Edge will not run on a profile that has been copied using the "Copy To" option in the User Profiles dialog box. I've traced this back to registry permissions that are present on profiles created by Windows, but are stripped by the "Copy To" process. Specifically the strange SID S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681 which is not necessarily a user account but appears to be related to some sort of new security model for UWP apps (or perhaps just specifically Edge).

 

While it is possible to restore those permission entries to a mandatory hive (programmatically, the GUI won't allow you to add unknown SIDs) I feel like this is potentially the tip of the iceberg of problems that could be encountered with mandatory profiles in Windows 10 (especially down the line in future updates). This raises the question of whether it's time to go back to local profiles to be more in line with something that Microsoft intends/supports (roaming profiles would probably introduce their own unique set of headaches). What route have you guys taken while rolling out Windows 10? I know a lot of people's advice is simply "don't use Edge", but I'd prefer to avoid any other hard-to-diagnose issues sneaking in in the future, too.

[Blue_Cookeh]

Microsoft are slowly abandoning mandatory profiles, they've said this specifically in the last year.

 

I setup a "Default User.v6" profile on our NETLOGON share which is used as the basis for any user logging into our network now, I then use the Group Policy setting 'Don't save settings at exit' and various others to lock kids' accounts down significantly. This has the added advantage that there is no "first sign in" actions, everyone gets the same profile, and they're kept local so none of the problems we had with "Waiting for the user profile service" when a user first logs in with a large profile exist anymore. My next step is to use UE-V to store stuff like Chrome data outside of the profile.

[karlr]

Did you copy the default profile directly from a Windows 10 system or did you use the "Copy To" button? If it was the latter I believe Edge would still fail, however "copy to" is most likely not needed since the default profile should already be ready to use as a "template" profile by design. Do you have any customisations to the default profile? Presumably when a user logs on to a computer they leave behind a local profile which is what they will log in to next time they use that particular machine. In an ideal world that local profile would be removed as soon as the user logged off ("Don't save settings at exit" is quite an old policy and I believe it may only affect things like desktop layout, rather than protecting the entire profile from modification).

[rjs_essex]

I'm also very interested in this. So far I have:

 

1. Removed all of the bloat from the Windows 10 image.

2. Set up and configured UE-V and have this working exactly as I need now (ven in its fairly limited capacity).

3. Set up and configured start menus using redirection and custom .xml layouts

4. Configured various other Group Policy / Preference and locked down features using various other methods.

 

The thing that I am a little stuck with, and stuggling to find a solution that will be furture proof, is profile creation. I dont want to use roaming profiles becuase Microsoft are turning their back on them. Mandatory profiles are also seeing limited support in the furture. So this leaves local profiles. But what do we do with thousands of roaming users that are only logged on for an hour at a time. My thoughts are:

 

Staff: Use UE-V with local profiles. They all have their own laptop so a local profile will grow with them and aside from the odd time they need a laptop fixed or they forget to bring one in, I belive UE-V should do enough to see settings populated between devices for each user logging on.

 

Pupils: Use UE-V with what????... Log on times aren't slow but they certainly aren't as quick as they could be with a mandatory profile... What do we use in its absence? I don't see how we can have each pupil log onto a computer and that machine create a new local profile each time. The defualt profiles that Windows 10 creates is like OP states, around 200Mb (mainly with a load of OneDrive tat). Or, do we do this and strip the local profile down as much as possible to make it as lightweight as possible? And then do we perform some sort of clean up routine at log off or when the profiles area exceeds a certain size? I currently script this to delete any roaming profiles that get left behind if a student just switches off a computer so could do something very similar.

[karlr]

What I'm looking at doing is copying the "default" profile to netlogon (e.g. C:\users\default -> \\domain\netlogon\Default User.v6). However to do this I am just doing a straight copy of the folder - using the "Copy To" option option in "User Profiles" WILL mess up the permissions and at best Edge won't work on that profile. The NTUSER.DAT for that default profile can be loaded in Regedit for simple changes (e.g. removing the OneDrive setup from the run key). Potentially Sysprep's CopyProfile could also be used for creating this default profile in the first place but I'm now seeing advice on avoiding CopyProfile as well. "Copy To" should be avoided at all costs, however - unless you're prepared to write a script to sanitise the permissions (some of the registry permissions are also impossible to add back using the GUI).

 

Having the default profile on netlogon also seems to speed up the first logon time (similar to a mandatory profile). Why this is the case is somewhat of a mystery as surely this is the very same default profile that any normal local login will be using. The policies "Show first sign-in animation" -> "Disable", "Allow Cortana" -> "Disable", "Turn off Microsoft consumer experience" -> "Enable" are also recommended.

 

As far as clearing up profiles when a user logs off... this is also something we're really keen to keep. We are currently using mandatory profiles + "Delete cached copies of roaming profiles" on Windows 7. This means that each login is a fresh one (apart from on laptops, which get taken home by staff, so a cached profile is needed along with offline files). I am looking at writing a service in C# that monitors for logoff events using SENS and then calling DeleteProfile(). There's an added caveat on Windows 10 though which will require some further fiddling with the registry after the profile has been deleted, at least until Microsoft fixes this in April.

[rjs_essex]

What I'm looking at doing is copying the "default" profile to netlogon (e.g. C:\users\default -> \\domain\netlogon\Default User.v6). However to do this I am just doing a straight copy of the folder - using the "Copy To" option option in "User Profiles" WILL mess up the permissions and at best Edge won't work on that profile. The NTUSER.DAT for that default profile can be loaded in Regedit for simple changes (e.g. removing the OneDrive setup from the run key). Potentially Sysprep's CopyProfile could also be used for creating this default profile in the first place but I'm now seeing advice on avoiding CopyProfile as well. "Copy To" should be avoided at all costs, however - unless you're prepared to write a script to sanitise the permissions (some of the registry permissions are also impossible to add back using the GUI).

 

What benefit would you see with this though? Aside from having a central profile that you could manipulate easily, would this not increase network latency? And is this not effectively creating a mandatory profile of sorts?

 

I assume you plan to point users AD accounts to this profile location?

 

As far as clearing up profiles when a user logs off... this is also something we're really keen to keep. We are currently using mandatory profiles + "Delete cached copies of roaming profiles" on Windows 7. This means that each login is a fresh one (apart from on laptops, which get taken home by staff, so a cached profile is needed along with offline files). I am looking at writing a service in C# that monitors for logoff events using SENS and then calling DeleteProfile(). There's an added caveat on Windows 10 though which will require some further fiddling with the registry after the profile has been deleted, at least until Microsoft fixes this in April.

 

I currently use roaming profiles and have a script that runs at shutdown/restart that looks in the users area and deletes any folder that exists with a numerical value in it (none of our staff accounts do)... This tidies up any that the system/GP settings miss if the students don't log off correctly.

 

I'm desperate to get away from roaming profiles because a large percentage of support tasks my team have to deal with are corrupt profile related!

Edited January 29, 2018 by rjs_essex

[karlr]

What benefit would you see with this though? Aside from having a central profile that you could manipulate easily, would this not increase network latency? And is this not effectively creating a mandatory profile of sorts?

 

I assume you plan to point users AD accounts to this profile location?

 

I currently use roaming profiles and have a script that runs at shutdown/restart that looks in the users area and deletes any folder that exists with a numerical value in it (none of our staff accounts do)... This tidies up any that the system/GP settings miss if the students don't log off correctly.

 

I'm desperate to get away from roaming profiles because a large percentage of support tasks my team have to deal with are corrupt profile related!

 

I'll have to run some tests/timing to determine the advantage of the centralised default profile. With a default profile you don't actually point users at it, you'd leave the profile field blank in AD. "Default User" (.vX) is actually treated as the "network default profile" by Windows. It will be used as a template for new local profiles, so clients will never try to write back to it. In terms of network throughput the profile comes in at under 500kb.

 

Using that script to clear up local profiles on a similar schedule may be a workable solution, and you'd no longer have any roaming profiles to maintain so profile problems should clean themselves up.

[rjs_essex]

Thaks for the extra info, much appreciated!

 

What I'm looking at doing is copying the "default" profile to netlogon (e.g. C:\users\default -> \\domain\netlogon\Default User.v6). However to do this I am just doing a straight copy of the folder.

 

Ok... I've done a little testing with this method and it seems to work well, except, the windows store apps fail to load with the usual 'You'll need a new app to open this' message. This is both good and bad... Good because it removes some of the things that there appears to be no supported way of removing - The 'Mixed Reality' app being one of them (I've tried various ways/hacks/etc but it always remains). The bad, because 'Calculator' is one app that I think people will miss!

 

Ironically, Edge works using this method!

 

Have you had any success yourself with this i.e. not breaking the built in apps?

 

- using the "Copy To" option option in "User Profiles" WILL mess up the permissions and at best Edge won't work on that profile. Potentially Sysprep's CopyProfile could also be used for creating this default profile in the first place but I'm now seeing advice on avoiding CopyProfile as well. "Copy To" should be avoided at all costs, however - unless you're prepared to write a script to sanitise the permissions (some of the registry permissions are also impossible to add back using the GUI).

 

I tried the 'Copy To' method and have had issues with the profile loading at all. If/when it does the start menu layout breaks or the start menu doesn't load at all (which brings back memories of v1511 from days gone by)...

[karlr]

The apps all appear to work just fine while logged in using the network default profile. Is this a "clean" default profile or has it been created using CopyProfile? Also were any apps removed from the image during build/before copying the profile?

 

Also note that the apps will be broken if you subsequently delete a local profile from the system and then try to log in again. There are some additional registry keys to clean up to resolve that.