Problems with Installation for multiple users

Development Tools Cloud Editor
1

Hello.
I'm trying to install the Arduino Create Agent but when a select a destination path and click next, a pop-up window appears saying:

"There has been an error. Error trying to install file: destination ${windows_folder_startup} resolved to an empty value. The application will exit now."

I will appreciate if anyone could help me with this problem.
Regards.

2

Which version of windows ?
Are you installing as Administrator ?
What path are you trying to install to ?

It looks from the message you are trying to install directly to the startup folder which is not a good idea.

let it choose its own directory but change the drive letter if you want.

3

Hello, there! Thanks for you reply.

The pre-loaded route that the installer has is: C:\Users\E\AppData\Roaming\ArduinoCreateAgent
I did not change a thing. I click "next" and the message appears.

I tried to install it in: C:\ProgramFiles\Arduino, but the message still appears after i hit "next".

My version of Windows is Windows 10 build 1511.
I also tried to install it as Administrator.

4

the same here on windows 7 professional x64.
solution??

6

Hi we are working on a new release of the Plugin, it would be really great if you could install the development version and let us know if it fixes your issues http://downloads.arduino.cc/CreateBridge/staging/ArduinoCreateAgent-1.0-windows-installer.exe

Please remember to reinstall the plugin from the Getting Started flow after a while, so you can get all the updates that we will publish.

7

Create a folder named Startup here:
C:\Users\username\AppData\Roaming\microsoft\windows\start Menu\programs

2 Likes
8

I am also experiencing this problem when attempting to install this on Windows / Windows 10. Is there a resolution to this issue yet?

The purported resolution does not resolve the problem unless running the installation under a user context; when attempting to perform the installation under the System account, such as when performing an administrative install through a management suite like SCCM (or when doing so via other means), there is no user profile / %APPDATA% associated with the account. I believe this is the problem and the only resolution would be if there were a flag or something on the installer that allowed you to install the program for the local machine rather than in a per-user context.

The problem with installing it under a user account in an enterprise / other setting would be that the user accounts in the organization may not have administrative permissions to perform the installation. The only solution I have found to this is insecure: deploying the program to run under the current user, and starting the process using credentials of the local administrator account -- which would require credentials to be plain-text or otherwise decryptable in a script file or in the system memory. Performing the installation under the system is the only means by which the installation can be performed securely when a user account does not have permission to perform the installation when attempting to perform some means of silent/automated installation.

I believe the security certificate is also added under the user context and would need to be able to be added to the local machine certificate store, alternatively. That, or the script work-around would be to add the generated .cer files with to the local machine certificate root authority store / wherever else it goes.

There are other failings with the silent installation method, as well, such as prompting for the addition of firewall rules and adding the automatically generated self-signed security certificate. I also was unable to get the --prefix option working in order to set the installation directory. These prompts should never be present in a silent installer.

With great effort, I have been able to work around most of these issues by avoiding the silent installer making an AutoIt script to perform the install which, by the way, was not an easy task considering the failure of the installation screens to correctly report information on the controls (ie: inability to select controls by name, text for controls not being propagated correctly and detectable by AutoIt, etc.). The only issue I have been unable to resolve is running this under the local system, which, again, is the only secure method by which the program could be deployed to perform some manner of automated install.

Any ideas would be welcome.

PS: The issue is present on the development version referenced, as well; the issue is a bug in your installation wrapper or how you have it packaged.

Also of note, the registry entries for the install are created under the local system registry and not the user registry, despite the use of the user-context profile information being used. So, your installation package is, basically, attempting to perform the installation as a per-machine basis, but is using the user-context information to perform some aspects of the install (ie: putting in the shortcut, default installation folder, user certificate store, etc.)

9

Hi @someguy,

you are totally right; the agent is mainly user-centric right now, so we didn't spend a lot of effort on distributed installations.

However, we'd really want it to become easy to install also in an enterprise/school environment; the first couple of actions could be

  • create a really unattended installation mode which skips creating and installing the certificates (this mode should also fix the user/machine scope bug)
  • the sysadmin should create the intermediate self signed certificate, deploy it on all PCs and use it to create the "final" certificates to be copied in the installation folder

What do you think about it?
We are using InstallBuilder to create the installer but most of its work is creating the service and calling the agent with various flags to create the certificates.

Would it be easier if we provided a signed zip package only containing the agent and the config file? Probably creating the service manually is easier from a sysadmin style, and installing the certificates can be tuned on the existing infrastructure.

10

Please find at this URL a unsigned zip package only containing the agent and the config file.

Let us know if this helps

11

I have successfully gotten this working now. Here are the issues with doing an installation on multiple PCs that I found with your installer. I didn't try your zip package since I had already gotten this generally working.

Essentially, what you want is the equivalent of an MSI's ALLUSERS=1 option on your installer, which would eliminate the issues when executing under the local system account and is often the context in which per-machine installations are performed in a distributed manner (ie: via something like SCCM). An option like this would use available environment variables to do things like to determine the system paths for the installation directories / shortcuts. Right now, the primary problem that occurs due to the lack of this is the end-user account not having administrative privileges, and the installer not really supporting an unattended mode that can be deployed outside of using an actual account (ie: the local administrator account or some other account with administrative privileges under which the process can be impersonated; and impersonation is not going to work correctly from the system account, either, as it is a "special" type of account -- in many environments, as well, the local admin account may be disabled and/or renamed)

Some things that would be helpful as options:

  • Deploying with a specified cert. The default could be to do what you are doing now, but to add to the local machine cert store instead of the current user cert store if in the machine / admin context. If you do this. Since the program currently just generates one dynamically and adds it to the cert store (two, actually, but one appears to be unused; I had to check which one was actually getting added to the user cert store: ca.cert.cer is the one that is imported) . Since it is dynamically generated and then added, I have not found a way around the prompt other than AutoIt. I think this is probably fine in the per-user context, and the user would still need to be admin, but should still have the option to use a specified cert via a command line flag or something. What has to be done now is to import the cert to the local machine store via Import-Certificate command afterwards if it does not already exist.
  • Similarly, the firewall rules. These could be done in some user contexts silently if using something akin to Powershell's New-NetFirewallRule. I currently have to add the firewall rules using this command prior to the installation taking place (if they don't exist) to avoid the firewall prompt; since the rules already exist prior to the installation taking place, the program does not attempt to add them again.
  • All current drivers that a user could be prompted for should be installed with the program. When I was testing this in the browser, I was prompted to install a driver when I selected a board. So, if a user is not an admin, they would never be able to install the drivers.

I ended up copy the drivers from the full IDE package and install them prior to the installation taking place; they should be bundled with this, though, and also be available as a stand-alone download (maybe they already are? didn't check). Also note the certificate required to avoid prompt on installing the arduino.inf file the full IDE appears to be expired, which causes a prompt unless importing the certificate as a trusted publisher and ca prior to performing the driver installation. Some of the drivers in there don't seem to work, either and would require signing the driver (kernel mode would require additional steps on the cert side). Could use signtool / cat2inf for this and others with a self signed (kernel or non) certificate, but shouldn't be necessary. Some of these issues applied only to the legacy "zip" folder. I basically just added all .INF files from the full IDE drivers during install along with FTDI drivers from their site.

Having drivers / up to date drivers available for download so they can be deployed would be cool. Like just a standalone driver package. Or something like an automatic updater running task or file watcher for a downloaded drivers folder, and the updater could be scheduled under the system context and install the driver elevated without permissions for auto update. Something along those lines maybe

  • Ability to specify the install directory / shortcut directory via command line. Machine contexts optimally to the default machine directories (I'm just using AutoIt to type it into C:\Program Files (x86) as a root folder), user context how it is now is probably fine
  • Fix registry on per user / per machine context to be entries in HKCU and HKLM. Would have to think about what to do here to avoid conflict in something like an "autorun on login" setting to avoid two running at once if a user has individually installed it, or something.
  • Optional run on login or something, but defaulted to disabled and available to be specified by command line per machine / be configurable on per user. I could probably do this via task scheduler or something for each user, but for now I just left it as when they choose to launch
  • Optional do not run after install is complete
  • Maybe some kind of mechanism for localhost port range. More of an edge case, but if two users are both logged in running it, don't know if conflict could occur.
  • Documented process exit codes would be cool / silent install documentation on options available or how to change settings if some options are added in, and / or fix the ones that are there already; there needs to be a truly silent install
  • Make it so do not need to be administrator to work when program ran* (I had this issue early, so it could have been something else; but there are still other issues when not run as administrator as aforementioned
  • Consider different extension/package options for files the program retrieves/sends when working through browser; something less likely to be blocked by firewall or scanner other than .zip extension. More of an optional one, don't know what a good substitute would be, but you could just rename to the correct extension after file downloaded

A "portable" format may be a good option to have, but should deploy with some form of setup script for the certs and firewall rules or something that can be optionally used (and possibly provide some docs if not using it). The best option, though, would obviously be both an installer that could be used, along with a portable format -- with the focus being more on the former :open_mouth:

I didn't get a chance to check your .zip package since I had most of this done already and didn't have time to risk trying another method.

--

There are probably some other options to how I got it working, but these are the problems I noticed.

12

Hey,

I'm a teacher trying to get a connecton between what my students do at school and at home... Arduino Create seems like the tool to get this done cloudwise, but the installation on our school laptops in an account with admin rights doesn't give the account without admin rights the abillity to use the plugin (and
consequently the webeditor)... An admin approval while installing in the pupils account, didn't work either...

Does anyone has a work around for this problem, or should we wait for another version of the plugin?

Thanks in advance for your advice...

Stefan
Teacher STEM, Technology

13

Debugging info... Might be usefull...

{"Version" : "1.1.64"} 
{"Commands" : ["list", "open [portName] [baud] [bufferAlgorithm (optional)]", "send [portName] [cmd]", "sendnobuf [portName] [cmd]", "close [portName]", "bufferalgorithms", "baudrates", "restart", "exit", "program [portName] [board:name] [$path/to/filename/without/extension]", "programfromurl [portName] [board:name] [urlToHexFile]"]} 
{"Hostname" : "DESKTOP-NTK8295"} 
{"OS" : "windows"}
15

I did have to play with this due to the security concerns and was able to get it working with your standalone package, FYI. Despite the multiple threads and the fact that the overwhelming majority of computers in reality are Windows based, it doesn't seem much progress otherwise has been made nor effort to resolve these issues I previously mentioned other than just copying some exe files out of the main install and basically saying "here you go, good luck!". But whatever, you're welcome.

If anyone else is wondering:

  • First, you'll need to get whatever drivers you are going to use and pre-install. I just used whatever was in the IDE and a some FTDI bundle for our requirements and set them as dependency in SCCM. Note these have expired certificates so you will have to add the certs manually to the local store prior to doing a dpinst for the drivers or something.
  • Copy the files from Release 1.1.60: Don't return an error if the download tool fails · arduino/arduino-create-agent · GitHub to wherever. I chose C:\Program Files (x86)\Adruino Create Agent\1.1.60 since that's the release version they cited. I am guessing you can just do a full install of the latest .exe, though, and copy the two .exes, config.ini, and I grabbed the tray_iconWin.ico and tacked that onto a shortcut, too, since that wasn't in the release version mentioned above.
  • Give users full control over the folder you copied the files to. You need to do this for the program to be able to update. Better than giving them full admin rights, of course.
    Note: Not sure if they actually need full control or subsets under write/modify + read. I didn't get time to test this, so full control was the quickest way. Still insecure this way (and really anyway the user is getting these writes, regardless, without everything being signed/various other environment security requirements), but it's a bit faster than having to check the several other variations differencing write+modify permissions vs. just giving full control. Optimally, Arduino would have a service that runs under the system context to perform the update automatically / proxy through based on user request, so the user would only require read and I don't have the kind of time to make one for this right now. Alternatively, you would have to leave users at read and perform the updates yourself, but note it would be non-functional until you updated it, which is why the option I chose for now was just to do full control (though it's not a great security decision, still better than what is provided out of box)
  • Use the arduino_create_bridge.exe -generateCert flag, unless you want to go ahead and make your own certs with PS/OpenSSL. I actually started researching this a fair amount for a day and was fairly close to getting a working solution, but decided against rolling my own since I read a few threads on StackOverflow that Go does a few things internally with the crypto to mod the OpenSSL generated cert (didn't get far enough to test that accuracy or not) and was going to just compile the cert generation in Go to deploy. Then... I noticed this undocumented -generateCert flag in the main Go file, which solely generates the certs and then exits without doing anything else. Would have been nice to know that existed before digging into all the cert generation :open_mouth:
  • Add the ca.cert.cer file to the "Cert:\LocalMachine\Root store" (Trusted Root Certification Authorities) and the cert.cer file to the "Cert:\LocalMachine\CA" (Intermediate Certificate Authorities) store
  • Add the firewall rules. I noticed they just block inbound on public for the programs on TCP. I went ahead and did block TCP/UDP for the programs (arduino_create_bridge.exe and arduino_create_bridge_cli.exe) on all, but haven't gotten a chance to really experiment there to see which I will need to open up. When we make some firewall rule changes I'll play with it and see what is really needed, guessing private/domain are supposed to be allowed, but couldn't say for sure right now. Note that blocking public, as well, may jack you up on open Wi-Fi connections, but again not sure since I haven't really messed with this too much for our particular needs
  • Create the shortcut in the start menu and reference the icon location to the tray icon added when copying the release to point to the .exe.
  • Brag about how boss you are since you'd otherwise be hosed. And yea, I have it fully scripted and automated, but where's the fun in that? These steps will save you at least some time, and give you at least a little more guidance than what has been provided

PS. Still get driver prompts on the website, despite working drivers being loaded. Obviously, since the user does not have admin access they wouldn't actually be able to add them. Haven't played around enough since I'm basically just packaging this up for deployment and not really using it myself. Can you guys provide additional driver bundles / provide info on whatever detection you use / if latest IDE version drivers would bypass this prompt? Or, add the ability to ignore driver prompts in logged in web account settings or something like that? The one I was using to test was a genuine Uno; worked without issue, but still got the prompt. Not sure if it's the latest driver or not; like I said, I don't use these myself, just set it up. Don't know which board my end-users use, think it's a micro Uno or something. I'll find out later in the year if it works for them :open_mouth:

If I get time, I'll test more drivers, but I don't quite know when that will be. I have a fair amount of stuff to do in other areas currently, which is why the last time I looked at this was October 2017, and why I only got a couple of days to modify it this time around :{

16

Also note, I don't accommodate for the cert issue referenced here: Root Certificate installed during web editor setup -what for? - Cloud Editor - Arduino Forum

I'll probably toss in killing off the .cer/.PEM files after they are imported, too

I'll have to look and see on the root CA issue a little bit later. I believe this would break the chain on the intermediate, IIRC, but since it's added it should be good. I don't have my test box to play with ATM. Might not be until this weekend to see if something has to be done with that

Also, I believe it is self-signed from what I remember in the Go code, so any compromise would be machine-specific; the generate cert .Go file appears to use reader.Rand() to generate the keys / thumbs from what I see, which would be different on every cert generation. Assuming, of course, Go uses a cryptographically secure random generator (which I am guessing it does). Also assuming the thread is referencing the same certs generated on not some other cert that is used solely during the .exe call that is not present with -generateCert