[Samba] wiki entry regarding updating self compiled samba addc (4.11.x -> 4.15.0 in my case)

[Patrick Goetz]

Thanks for the detailed response. It's my understanding that the MS 
recommendation is to implement Windows profiles as a virtual disk:
https://techcommunity.microsoft.com/t5/security-compliance-and-identity/easier-user-data-management-with-user-profile-disks-in-windows/ba-p/247555

Based on your description is sounds like you're not using the VHDX 
version of profiles.


On 9/28/21 17:24, rme at bluemail.ch wrote:
>> I thought everyone was trying to get away from roaming profiles 
>> because, for example the AppData folder starts to fill up with cruft 
>> like browser and email caches, making login/logout times unbearably 
>> long for users.
> 
> It's rather about Microsoft and others trying to push you using cloud 
> services. They don't want you to do this for free or even without 
> running into a vendor lock-in of course.
> Actually the concept of Windows using %AppData% for roaming data and 
> %LocalAppData% for local data (which is not roaming and therefore not 
> synchronized at logoff is quite good. Sure there are some applications 
> which totally fail to make use of this concept and store heaps of caches 
> and volatile data belonging to %LocalAppData% or even %TEMP% to roaming 
> %AppData% folder. But some of those applications can be pre-configured 
> to store data into the right location and others (like Firefox) can be 
> configured using policies to keep the profile folders relatively clean. 
> For Firefox there is also open bug reports to review the %AppData% 
> folder structure and contents to move volatile data away from it.
> 
> If all fails you can also exclude paths from roaming so you might 
> exclude AppData\Roaming\xyz from roaming and therefore prevent Windows 
> from synchronizing it at logon/logoff.
> 
> With current SMB3 capabilities a typical profile including a Firefox 
> profile is perhaps around 200MB and is delaying the logon on a modern 
> LAN for about 10-20 seconds only - except you are logging on to a 
> machine for the first time which requires to download the complete 
> profile or you use policies to always wipe the local profile on logoff.
> 
> 
>> Does this work better than in the PDC/NTLM days? I'm in the process of 
>> upgrading such a network (which has admittedly been in place far too 
>> long) and it literally takes 45 minutes for users to logon or logoff.
> 
> I am not really having problems with Windows 10 clients and roaming 
> profiles on medium sized installations. However there are occasional 
> users complaining about long logon times. Those users are usually the 
> ones keeping heaps of data (talking about Gigabytes) on Desktop or other 
> roaming folders. So you can also remind those users NOT to do this as 
> mostly policies in companies should disallow storing data locally but 
> rather using shares. You can also use folder-redirection along with 
> roaming profiles to lower the size of roaming profiles by directing 
> typically large folders like documents, videos or even desktop to 
> network shares directly so they don't need to get synced on logoff.
> 
> 
> 
>> Final question about this: The page referenced above shows a chart of 
>> Windows profile suffixes. Since part of this project includes setting 
>> up several new PCs which will presumably be upgraded to the most 
>> current version of Windows 10, I found the lack of a server reference 
>> in that chart for Profile version V6 to be a but unnerving. Does this 
>> mean Samba does not work with V6 profiles; or maybe I should be asking 
>> what is the difference between, say, V4, V5, and V6?
> 
> The version is directly appended to the path you configure in GPO or in 
> user profile configuration. The reason for the version is that the data 
> structure changed. In Windows up to XP the %LocalAppData% tree was 
> stored at "%UserProfile%\Local Settings" while this was changed to 
> %UserProfile%\AppData\Local (%LocalAppData%) and 
> %UserProfile%\AppData\Roaming (%AppData%) later.
> 
> Microsoft also recommends to set the prefix via policy. So When future 
> versions (actually I don't know if they opted for using V7 or other 
> prefix in Windows 11) are introduced the path does not change. However 
> at the risk of mixing profile structures. So for example you could use a 
> Windows 7 profile all the way up to Windows 10 without actually having 
> to re-create it as the base structure did not change. However some 
> additional folders were introduced along the way.
> 
> 
>> I'm guessing this fact alone should be a deterrent to using Windows 
>> Profiles? "Most notable about Windows 10, however, is that the 
>> 'profile version' increments can now happen with Windows 10’s feature 
>> upgrades."
> 
> So just "freeze" the suffix via GPO if you need to. However I personally 
> opted not to do this. If a future Windows is adding another suffix I 
> will just symlink the old to the new folder on Linux if the profiles are 
> compatible so users keep using the same profile in future versions.
>>> This message is from an external sender. Learn more about why this <<
>>> matters at https://links.utexas.edu/rtyclf.                        <<