samba - Sep 2021 - wiki entry regarding updating self compiled samba addc (4.11.x -> 4.15.0 in my case)

On 9/28/21 13:46, Rowland Penny via samba wrote:
> On Tue, 2021-09-28 at 20:04 +0200, J?rgen Echter wrote:
>>
>>>
>>>
>> yeah i did that and thats also mentionend on the wiki, thats why
i'm
>> asking as it wasn't that clear to me.
> 
> I will try to make it clearer.
> 
>>>
>>>
>>> Depends, if you just ran './configure', then delete
>>> /usr/local/samba
>>> (after backing it up), if you used a different PREFIX, then delete
>>> PREFIX/samba
>> ok, this would force me to join a new machine as a restore is not
>> possible on an already productive DC regarding to the wiki.
> 
> Well, yes, it probably would.
> 
> 
> 
> 
>> then i'll do that next time, i thought i could do an inplace
upgrade
>> without touching/moving my roaming profiles i got on there.
> 
> It isn't recommended to use a DC for anything other than
> authentication, you really should have the roaming profiles on a Unix
> domain member
> 

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.

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. 
They specifically asked not to have roaming profiles for this reason, so 
I was just going to map the Dektop, Documents, Downloads, etc. folders 
(I think this is called Windows Profile Folder Redirection) using a GPO, 
which seems to be how most people are doing it these days.

Also, this page:
https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles

tells me:
-----------------
Whilst it is possible to use POSIX ACLs for the profiles share on an 
Unix domain member, it is recommended that you set up the permissions 
from Windows. To do this, see Setting up the Profiles Share on the Samba 
File Server - Using Windows ACLs.
-----------------

Hmm, well yeah, but I linux desktops too and the permissions need to 
work everywhere, so POSIX extended ACLs it is. Of course I have no 
intention of putting any shares on the DC, so that's not a consideration.

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?

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."

> 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.

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.???????????????????????
<<