Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
3 tasks
danimo opened this issue Jun 12, 2013 · 28 comments
Closed
3 tasks
Labels
Enhancement Known Issue / Workaround ReadyToTest QA, please validate the fix/enhancement
Milestone

Comments

@danimo
Copy link
Contributor

danimo commented Jun 12, 2013

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
Copy link
Contributor Author

danimo commented Jun 12, 2013

Related: #575

@danimo
Copy link
Contributor Author

danimo commented Jun 24, 2013

@MTRichards

@dragotin
Copy link
Contributor

Not longer in scope of release 1.4.

@underflyer
Copy link

+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
Copy link
Contributor

cdamken commented Dec 30, 2014

@danimo @dragotin any news?

@guruz
Copy link
Contributor

guruz commented Jan 5, 2016

Related: #3673

@guruz guruz added this to the 2.2-nextminor milestone Jan 5, 2016
@dragotin dragotin added the p2-high Escalation, on top of current planning, release blocker label Feb 23, 2016
@Helios07
Copy link

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
Copy link
Contributor Author

danimo commented Feb 25, 2016

@Helios07 Please do.

@MTRichards
Copy link

YES @Helios07 that would be GREAT!

@Helios07
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

@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
Copy link
Contributor

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

@dragotin dragotin removed this from the 2.2.0-current milestone Apr 18, 2016
@dragotin dragotin removed the p2-high Escalation, on top of current planning, release blocker label Apr 18, 2016
@dragotin
Copy link
Contributor

dragotin commented Jun 2, 2016

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
Copy link

Hi, is this still under development?

@guruz guruz changed the title Support Windows Roaming Profiles Windows Roaming Profiles: Make it easier to allow roamed client configuration Sep 15, 2016
@guruz
Copy link
Contributor

guruz commented Sep 15, 2016

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.

ogoffart added a commit that referenced this issue Dec 6, 2017
Also use appName instead of appNameGui in order to compute the path

Issue: #2245

The reason is to respect the XDG spec on Unix (#1601) and might help
on windows roaming profiles (#684)
ogoffart added a commit that referenced this issue Dec 7, 2017
Also use appName instead of appNameGui in order to compute the path

Issue: #2245

The reason is to respect the XDG spec on Unix (#1601) and might help
on windows roaming profiles (#684)
ogoffart added a commit that referenced this issue Dec 7, 2017
Also use appName instead of appNameGui in order to compute the path

Issue: #2245

The reason is to respect the XDG spec on Unix (#1601) and might help
on windows roaming profiles (#684)
ogoffart added a commit that referenced this issue Dec 7, 2017
Also use appName instead of appNameGui in order to compute the path

Issue: #2245

The reason is to respect the XDG spec on Unix (#1601) and might help
on windows roaming profiles (#684)
@guruz guruz added this to the 2.5.0 milestone Dec 12, 2017
@guruz
Copy link
Contributor

guruz commented Mar 28, 2018

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

@michaelstingl
Copy link
Contributor

@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
Copy link
Contributor

ogoffart commented Mar 29, 2018

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

@ogoffart
Copy link
Contributor

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

@ogoffart ogoffart modified the milestones: 2.5.0, 2.6.0 May 30, 2018
@ogoffart ogoffart added the ReadyToTest QA, please validate the fix/enhancement label May 30, 2018
@ogoffart
Copy link
Contributor

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
Copy link
Contributor

guruz commented Jul 23, 2018

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
Copy link
Contributor

jnweiger commented Aug 3, 2018

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

@jnweiger jnweiger closed this as completed Aug 3, 2018
@ogoffart
Copy link
Contributor

ogoffart commented Aug 3, 2018

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
Copy link
Contributor

guruz commented Aug 13, 2018

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

CC @michaelstingl @ckamm for discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Known Issue / Workaround ReadyToTest QA, please validate the fix/enhancement
Projects
None yet
Development

No branches or pull requests