Windows Roaming Profiles: Make it easier to allow roamed client configuration

[danimo]

Current issues:

• Option required to store ownCloud sync dir outside of roaming area (Microsoft mandates that apps are supposed to write their data into %USERPROFILE% only, but that conflicts with roaming profiles, so sysadmins need to be able to specify an alternate, user-writeable default location.)
• Check if we need to distinguish between user and machine specific settings when storing the configuration
• Ensure graceful behavior if the client gets started on a second machine

This needs investigation. Also, we need to decide how to provide sensible defaults.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[danimo]

Related: #575

[danimo]

@MTRichards

[dragotin]

Not longer in scope of release 1.4.

[underflyer]

+1
even in 1.5.3 any client-config is saved in "locale Settings/application Data/owncloud".
So this config will not be saved in the server-profile on logout.
When the User logs on a new Computer he has to reconfigure all settings, also when the Client is already installed.

[cdamken]

@danimo @dragotin any news?

[guruz]

Related: #3673

[Helios07]

I just saw that there is some progress with this issue. From the comments I see here I am not completely sure if the problem is more regarded to implementation or design.
We have several users in some of our institutes using roaming profiles. If it would help you, I could ask some of them if they could tell me how they want to use the client the roaming profiles.

[danimo]

@Helios07 Please do.

[MTRichards]

YES @Helios07 that would be GREAT!

[Helios07]

Hi,
I spoke with some of our local administrators and gathered the following:
A typical scenario is that the admins are responsible for a larger amount of computers which are free to use by a certain group of users. The users might log in at any of them. The roaming profiles are used to make it unnecessary for the users to configure their profiles every time they use another computer. This becomes problematic, if huge amounts of data are stored in this profiles because they need to be copied to the computer when logging in. Therefore the admins want to keep the amount of data that is stored small.
If now users are able to choose the local sync path of their ownCloud clients freely, they might choose the profiles and increase the workload at the log in. This is also explained here:
https://anchorhelp.zendesk.com/entries/27754623-Get-Default-Data-Folder-Out-of-Roaming-Profile
As far as I understand, it is possible at the moment to set a certain directory for the sync client and exclude this from the profile replication: https://support.microsoft.com/en-us/kb/814592 Unfortunately, the user is still able to change the default path.
To conclude this, it would be most desirable, if the ownCloud client could be bound to a certain local directory via GPO (group policies).
As an example how this should look like you could have a look at chrome: https://support.google.com/chrome/a/answer/188446?hl=en

This request does not only exist for the Windows client, but also for Linux and MacOS X.

I hope, this helps :)

[MTRichards]

Excellent - thank you @Helios07 !
So the idea is to bind to a specific sync directory that can't be changed. In theory we can do that with our branding of ownCloud, so you can log in and set a directory and then download that version of the client and turn off the ability to set more sync locations. Alternative might be to store path on the server, but that introduces other complexities.

[Helios07]

Ok, I see the option to limit the client to be able to sync only one folder. But wouldn't the user be able to delete the original sync and create another one? This should be prohibited, too.
A practical problem might be that not all admins would like the same location. Since I am building the client for more than 20 institutions (universities and universities of applied sciences), this could lead to a lot of different clients I would have to build with every release.

[Bottswana]

To achieve this, we would need to create registry keys to configure each of
these use cases, then generate and ship .admx files to configure them from
the group policy editor.

I'm unaware if owncloud client uses the registry much on Windows presently?
I believe most of the configuration is done from the configuration file.
On 26 Feb 2016 8:04 a.m., "Holger" notifications@github.com wrote:

Ok, I see the option to limit the client to be able to sync only one
folder. But wouldn't the user be able to delete the original sync and
create another one? This should be prohibited, too.
A practical problem might be that not all admins would like the same
location. Since I am building the client for more than 20 institutions
(universities and universities of applied sciences), this could lead to a
lot of different clients I would have to build with every release.

—
Reply to this email directly or view it on GitHub
#684 (comment).

[MTRichards]

But wouldn't the user be able to delete the original sync and create another one? This should be prohibited, too.

We would have to disable this too.

[MTRichards]

@cdamken @felixboehm can you guys help us get more info on specifically what this means? Right now, @Helios07 has given us a good use case, we need some more specifics on this topic to get it done correctly. Thank you...

[dragotin]

I am moving this out of 2.2.0 milestone and remove the gold ticket.

[dragotin]

An alternative would be to distribute a list of pathes through group policies which the client must not use as local sync dir. That way users can not create a sync dir where it should not go.

[martinohansen]

Hi, is this still under development?

[guruz]

Just to document a possible way if you want to force the client config to be roamed:

We published the application with the parameter 
"C:\Program Files (x86)\ownCloud\owncloud.exe" --confdir %appdata%\Owncloud

In this way the settings are stored in the roaming profiles.

In owncloud there is an option "launch at startup'. This is done by a registerkey 
HKCU\Software\Microsoft\Windows\CurrentVersion\Run

We have created a GPO that checks if this registrykey exists. If yes, then it changes to open 
C:\Program Files (x86)\ownCloud\owncloud.exe --confdir %appdata%\Owncloud

Another workaround might be to use ownBrander to set a fixed sync path, local sync folder etc.

[guruz]

@ogoffart Can you summarize how 2.5 will behave differently to 2.4?

[michaelstingl]

@guruz I've got feedback that something already changed/broke in 2.4. Need to find that information… (will check with @SamuAlfageme next week)

[ogoffart]

In 2.5, the location of the config file has changed from %LOCALAPPDATA%\ownCloud\owncloud.cfg to %APPDATA%\ownCloud\owncloud.cfg.

[ogoffart]

So now that the config directory has changed, is there anything else that needs to be done for this issue?

[ogoffart]

I added the ReadyToTest tag because I think the 2.5 alpha should be better as we used the proper path for the config files.
I don't know much about what else needs to be fixed however.

[guruz]

2.5.0 beta1 is out :-)
https://central.owncloud.org/t/desktop-sync-client-2-5-0-beta1-released/14667
Everyone, please comment here if we can close this issue. Thank you.

[jnweiger]

Tested on a Fedora28 VM: upgrade from 2.4.2 to 2.5.1beta1

OK: settings are preserved in the GUI), config files migrated (backup preserved)

Tested on a WIN10 VM: upgrade from 2.4.2 to 2.5.1beta1 MSI

OK: settings preserved in the GUI
OK: %APPDATA%\ backup of .cfg is there too.

BAD: unlike linux, no link is left behind in the old %LOCALAPPDATA% location. @ogoffart downgrade issue here?
BAD: A 31MB copy of the downloaded *.msi package remains in %APPDATA/ownCloud #6690

[ogoffart]

BAD: unlike linux, no link is left behind in the old %LOCALAPPDATA% location. @ogoffart downgrade issue here?

Windows do not support symlink. And I tried a bit making a junction but it felt like too much work.
So yes, downgrading will get an empty config. But this isn't officially supported anyway.

[guruz]

@ogoffart What about copying the config directory on Windows?
(yes i know ugly but might have its benefits?)

CC @michaelstingl @ckamm for discussion.