adding command line options to the Nextcloud client setup exe or create a msi setup file

[FINIUS]

I would suggest to add a support of command line installation options to the Windows Nextcloud client to make administrators able to predefine some basic config settings (like server URL, authentication/username, sync options, etc) to enhance user experience as no GPO package is available to autoconfig Nextcloud after installation on an enterprise level.

[michaelstingl]

Related: https://github.com/owncloud/client/issues/1419#issuecomment-321276717

[Square252]

+1, major drawback for many of our customers. We got around 2.000 possible client to deploy in one environment. The complete lack of automated install or configuration options is one major reason our nextcloud instance isn't used that much... Some customers are even switching to crappy stuff like cryptshare :/

[mathiasconradt]

@camilasan Is this feature request (.msi) currently on the roadmap (if so, is there an approx. target date) or not with a fixed schedule yet?

[aTanCS]

MSI package would be a better variant.

[mathiasconradt]

@aTanCS yes, I also meant the .msi package :)

[camilasan]

@mathiasconradt It is currently not in the roadmap but of course we can prioritize it if there is such demand. We will make time for it ;) Is that what you need?

[FINIUS]

+1

Am 30.07.2018 um 14:54 schrieb Camila Ayres notifications@github.com<mailto:notifications@github.com>:

@mathiasconradthttps://github.com/mathiasconradt It is currently not in the roadmap but of course we can prioritize it if there is such demand. We will make time for it ;)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/nextcloud/desktop/issues/59#issuecomment-408853090, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFCtDXTV1ECQ8pa0dKgDirVGgJAKBTljks5uLwIUgaJpZM4Qp1I-.

[Linuxfabrik]

+1

[cyber035]

+1

[pantherale0]

+1

[carloscaballero]

+1 I would like to be able to modify all nextcloud clients: Windows, Linux, Android, Apple

[maghog]

+1

[johnripper1]

+1

[mjuddi]

+1

[bluikko]

Any updates on the MSI installer file? Should definitely be on the roadmap in my opinion.

It would be very inconvenient to deploy the desktop client for Windows manually.

Edit; OwnCloud actually has an MSI installer now so that's another point where NC loses out.

[User867]

Hello people,

Big +1, as we want to deploy Nextcloud on all our machines. Cannot be done manually... Is anyone working on the MSI actually ?

[johnripper1]

As there is no improvment within in this two year long discussion why this feature is not required at all:

EOLing nextcloud here.

[ndom91]

For those of you trying to provision the nextcloud client to Windows workstations, maybe checkout chocolatey: https://chocolatey.org/packages/nextcloud-client

It is an apt-get / npm / pip like package manager for windows through which you can deploy software (incl. exe's!) via AD as well.

[BloodyIron]

There's a very big drive for nextCloud working well in the corporate/org space, and being able to not only deploy nextCloud desktop clients en-masse, but also have it automatically configured based on the user being installed for (or perhaps SSO via kerberos on the local system) would have very high value for many installations of any size. Be it 50, or 50,0000.

Why aren't we prioritizing this? This tangibly leads to increased installations, especially for very large environments. There's no way very large environments are going to do this without the ability to automate the installation and initial configuration (let alone central management of that).

[bluikko]

Why aren't we prioritizing this? This tangibly leads to increased installations, especially for very large environments. There's no way very large environments are going to do this without the ability to automate the installation and initial configuration (let alone central management of that).

This is so correct. MSI is the standard way to deploy software on Windows. For corporate installations it is a hard requirement. Larger installations could do with an EXE installer, given it has support for the correct switches. But especially in medium-sized installations MSI is the only right way to go.

[johnripper1]

A rollout via e.g. SCCM with basic configuration options is possible already. Not very conviniant but its possible.

The more bigger issue is a centralized configuration.

I'm just not able to do manual configuration for my organization and therefore I will set this to production.

[BloodyIron]

Also, how exactly do we handle the desktop client on a system where multiple people login? Can we get the client to auth via local Kerberos ticket, or session, or? (same question for Linux/OSX)

[Highview-Lucas]

A rollout via e.g. SCCM with basic configuration options is possible already. Not very conviniant but its possible.

So much this. It seems every release of the client needs it's own testing cycle to see which switches can be passed in to the installer to have it both install, and not irritate the users. (2.3.something rebooted without warning!)

SCCM + MSI == Easy Mode. SCCM + MSI + GPOs would be perfect - but it's GPOs, I'd understand if you didn't want to support them. Being able to pass in a config would be so, so so nice.

[User35123]

+1

[bluikko]

Being able to pass in a config would be so, so so nice.

What configuration does this "pass in a config" refer to?

In my opinion, ideally passing any files to install should not be needed:

• If you mean configuration for setup - it'd be an MSI file, just use a transform.
• If you mean configuration for the program like where is the server - a file could be passed with GPP or, even better, the program could be configured with registry/GPO. I assume it is a cross-platform application and support for Windows registry might not fit. But surely that would be the standard way of doing things in Windows.

[Highview-Lucas]

What configuration does this "pass in a config" refer to?

Ideally, it would mean "my users never see the first-run wizard because by the time they click on the NC desktop icon, it's already been done"

As it stands the first thing they have to do is answer a question between "login" or "register" and then some extra details they do know, but pretend not to, and the a whole page of options that basically boil down to "it's irrelevant, press next"

(side question: why do we even have a register button?)

The client is mostly fine for people that want to install nextcloud on their desktops. It's completely not for someone that wants to deploy it to several hundred devices at once, and have the end users use it.

[bluikko]

Understood. I totally agree. There must be a way to deploy it automatically.

[gvansanden]

+1

[it25fg]

A simple question: Would it be simpler instead of creating a full-fledged installer if the desktop client could act upon some environment variables? Just like the ones documented in https://docs.nextcloud.com/desktop/2.5/advancedusage.html#environment-variables ? Nearly every prospect or customer is asking me about how to deploy the desktop client with predefined defaults, and the only remaining answer is "generate some config and deploy it before installing the client".

[gvansanden]

@it25fg I'd like that too...

[BloodyIron]

Also, I'd like to point out this functional need should not just be scoped for Windows. We should figure out a way to do the same functional aspects for Linux and OSX users (have the client install with pre-defined parameters already). So that there is a consistent UX from one OS to another.

One thought, maybe make it so you can download an "installer for this user" or something like that? Whereby the admin can download for a user on their behalf, or the user can download when logged into the web interface.

There are some scenarios where this doesn't work though, such as if the users don't have access to install stuff, or if there are very large number of users to be setup. We would need to figure out a way to do that en-masse too.

Just some thoughts, but I do think this is something very desirable to controlled IT environments of any org (biz or otherwise).

[johnripper1]

Two year and absolutly nothing happend.

Ive been asked a lot of times too, how to deploy and config the client with WSUS, SCCM or simular.

Just lost another project to the onedrive, fully integrated client with all the benefits of deployment, sso, and auto config.

Frustrating...

[Highview-Lucas]

A simple question: Would it be simpler instead of creating a full-fledged installer if the desktop client could act upon some environment variables?

Please no. that guarantees you need to reboot the machine, and I can guarantee 50% of my users won't, so it won't actually change the outcome.

Two year and absolutly nothing happend.

There have been a couple of quick new major versions lately, so I popped over to check the commit logs. there are a lot that say "loop optimisation". It's getting to the point where I'm going to have to fork it to make it do the things I need, what I don't have is time!

[it25fg]

Please no. that guarantees you need to reboot the machine, and I can guarantee 50% of my users won't, so it won't actually change the outcome.

Who would need a reboot? The Nextcloud client is not a service. If the admin feels he must force client machines to reboot on every single installation, he should use some framework that enforces that (which, i would presume, will exist in companies interested in automatic software rollout anyway).

As a side note: they already tried to incorporate such "functionality" but did not get it right: https://github.com/nextcloud/desktop/issues/1040

To clarify: my question is about users being (at least) adventorous, and when they see the client for the first time, deciding the wrong things (for instance, 'sign up for a service' even though their account was already provisioned). That way, an admin or help desk has to repair mistakes of users. I have asked for a means that the admin can use to predefine things that are usually predefined (company defaults: user drive letter, default server, login name).

[BloodyIron]

To be fair, if you're managing a suite of Windows systems and you don't have a reboot schedule, well then you're not properly applying security updates, and you have bigger problems.

I'm not saying the NC agent should require a reboot, but more that it is a moot point.

[Highview-Lucas]

Who would need a reboot?

environment variables tend not to exist prior to a reboot. given you can completely replace a GFX driver without a reboot in windows 10 now, forcing a reboot from something as non-essentilal as a sync client isn't a reason to need a reboot.

but, we're arguing the same side of the same argument: the client does nothing to make life easier as an admin.

To be fair, if you're managing a suite of Windows systems

I am, and i deliver the NC client via SCCM, which means there's one standard place to get one standard version for all of my users, which they can add or remove as they see fit.

but you are correct, it is a moot point. the software needs to function better. .... which was the topic of the thread 2 years ago, and we're still asking for the same thing.

[BloodyIron]

Configuration Management systems (SCCM, Puppet, etc) are a primary reason this aspect needs to be developed. If we can get NC to be rolled out to a limitless number of users in an organisation, this will massively improve NC adoption.

Come on devs!

[johnripper1]

To all using SCCM: How do you handel the update of the client on the user Desktop?

Pushing out an update of the client, results in the shutdown of the application within the user context and then the update of the nextcloud client by SCCM/Software Center. Of course all silent. BUT the problem is that afterwards the client is not started automatically. So in many enviroments I force a restart of the maschine to make sure the client is up and syncing. On the first wave I didnt do that, was resulted in an out of sync directories, while the user didnt notice that, as everything was run in the background.

Another big issue of nextcloud client.

Like saied: compared to OneDrive, the nextcloud application is really missing a lot of Integration in a professional environment.

[Highview-Lucas]

in short: poorly.

create a new app, supersede old version, deploy with "uninstall old" and "available" (instead of required). with the current version if you follow it's prompts just reinstalls the old version instead of the new version.

I detect on the version number of nextcloud.exe and added the random return code (1223) as a success - if you don't do that it stays on "failed, retry" forever. i use the uninstall.exe in the installed nextcloud directory - but it's currently asking questions even with /S

As for why it does not run - i'm halfway thinking of making some kind service that runs the sync client for me - the client also crashes silently, i'm thinking with a service i can check to make sure it's running periodically

[FEKJHhrgfre]

The MSI is needed, the GPO's would be welcome.

[it25fg]

The MSI is needed, the GPO's would be welcome.

MSI and GPO's -- a Micro$~1-only thing... wouldn't it be better to ask for a portable mechanism such as environment variables which could be set up by every system nowadays?

[bluikko]

This issue is not so good because it conflates two different issues.

It should be split into two:

• Environment variables for configuration.
• MSI installer.

[ndom91]

@bluikko - very good point.

I think an MSI installer should be a separate issue as well.

It would then make sense to devise a way to configure the roll out platform independently, i.e. Env variables as has been suggested before, or a config file. The MSI installer could consume these on windows, and on Linux/Mac, for example, the config file could just be placed in the correct dir or env variables set.

[BloodyIron]

Env variables aren't a way to streamline the process of authentication setup though, as that could be retrieved by another app and reversed to get credentials.

Also, this needs to be planned for a way to set it up so multi-user on the same system works. Whereby, the logged-in session are the creds used for nextCloud, be it kerberos or otherwise.

[BloodyIron]

The fact it ignores silent for uninstall clearly demonstrates it is not properly written for an environment like that, or even Linux configuration management environments. This aspect too is a problem. And the upgrade of the agent should be done in-place and not involve an uninstall/reinstall, unless you're using a package management system like Aptitude/Yum/whatever (which is not Windows). To reiterate, in Windows, the upgrade process should be done in-place.

i use the uninstall.exe in the installed nextcloud directory - but it's currently asking questions even with /S

As for why it does not run - i'm halfway thinking of making some kind service that runs the sync client for me - the client also crashes silently, i'm thinking with a service i can check to make sure it's running periodically

[johnripper1]

"Env variables aren't a way to streamline the process of authentication setup though, as that could be retrieved by another app and reversed to get credentials." What a bullshit! Env. variables are not used for auth, just how the software behave. Of course the auth is done with user cred. And if you consider this unsave: onedrive is doing exactly that.

[wiswedel]

@johnripper1 please watch your language

[it25fg]

@BloodyIron

Env variables aren't a way to streamline the process of authentication setup though, as that could be retrieved by another app and reversed to get credentials.

You misunderstood my point, to a degree. I wanted to propose that environment variables could be used for predefining a connection (URL or server), a login name (whatever is configured as default login scheme in Nextcloud) and optionally a default position of the local folder (depending on company standards about drive mappings/home etc.).

Regarding credentials, I agree with you: Credentials don't belong into the environment; these should be asked for, just the same way as it would happen when credentials have changed: the client pops up the password dialog.

[BloodyIron]

I think Env variables could work for non-credential aspects (username should not be included)

However, I think one of the challenges there is making it so that those parameters don't cause problems for multi-user single systems (think, factory floor). Whereby:

1. You don't grant access to stuff when you switch your Windows session to another user (that they shouldn't have access to)
2. When you switch Windows session to another user (switch user) it "mounts" the NC content for the user it just switched into
3. The NC agent/daemon/service/client sync's content accurately for all users logged in

Generally, I'm not sure how to account for all scenarios, but to make it multi-user aware, not just for Windows, but Linux, OSX, even Android/IOS.

I think this is also a critical part of expanding the parameter aspects of the nextCloud installation. Bit of a mouth full, sorry.

@BloodyIron

Env variables aren't a way to streamline the process of authentication setup though, as that could be retrieved by another app and reversed to get credentials.

You misunderstood my point, to a degree. I wanted to propose that environment variables could be used for predefining a connection (URL or server), a login name (whatever is configured as default login scheme in Nextcloud) and optionally a default position of the local folder (depending on company standards about drive mappings/home etc.).

Regarding credentials, I agree with you: Credentials don't belong into the environment; these should be asked for, just the same way as it would happen when credentials have changed: the client pops up the password dialog.

[Highview-Lucas]

please stop saying "environment variables", it means you're thinking about them, and they're a terrible solution - especially when the request was "command line options, or a OS-Native install method"