Java version client sadness

I believe we will be switching to Native client launchers soon. Unfortunately we are just having way too many issues with various versions of Java 6,7,8. I was able to get some users to upgrade from Java 6 > 7, but then after going Ignition 7.8 > 7.9 the clients cant launch. There are tons of areas of Java caches and it seemly takes hours per system to find them all for our IT folks.

Any other advice besides NCL? I like WebStart for the user convenience, but I am sick of it causing us downtime! How do others launch clients and maintain the links on users system? We have a high-project environment with low number of users per project.

You said you don’t want to hear it, but all my troubles with webstart are a faint memory since I switched to the NCLs. Highly recommended.


Here is what I use.

  • A folder with a copy of the NCL plus pre-made links.
  • A batch file to handle the installation. The batch file removes any webstart apps and the user’s .ignition folder, copies the folder with the NCL into the user’s profile, then copies the links to the desktop.
    @echo off
    ECHO Removing user's .ignition folder...
    rd %userprofile%\.ignition /q /s
    ECHO Removing Java Webstart applications...
    javaws.exe -uninstall
    ECHO Copying Client Launcher...
    XCOPY "H:\Everyone\Hudson Tech Eng\Ignition Client Startup\IgnitionClientStartup" %userprofile%\IgnitionClientStartup /i /y
    ECHO Adding links to desktop...
    XCOPY %userprofile%\IgnitionClientStartup\*.lnk %userprofile%\Desktop /y
    ECHO Installation complete!


We do something similar to JordanCClark with the NCL and pre-made links in a folder, except we had IT add the folder to every machine and placed the links on the default desktop. So any user logging on already has desktop links to the projects. Works like a charm!

1 Like

Thanks @JordanCClark and @pturmel. The deployment was bothering me as a potential issue, but sounds like a little bit of work to get the NCL deployment right is well worth it in the long run.

I like the batch script. I’m thinking of making an installer that IT can push to all PCs and just leave the link in the start menu, which would be invisible to most (only about 2-5% of systems use ignition apps right now) but its ready and waiting for anyone that needs to launch an app.

I’m doing some testing today with bundling JRE with the launcher and pre-configuring launch.xml to the local sites gateway. I think if I can then deploy that to Program Files with a link in All User Start menu, that will cover me good and these headaches can be over. I would then just need to update many of my email alerts and custom alarms to not give a direct link to the JNLP but instruct the users to use the client launcher.

I think a great path forward for the NCL would be to include a URL handler into the NCL. Then you could do something like ignition://ignitiongateway:80/projects/AwesomeIgnitionProject or ignition://ignitiongateway2:80/designer and the host OS could pass this to the NCL to direct launch appts from web links! Thoughts?

1 Like

[quote=“ryanjmclaughlin, post:5, topic:14033”]
I think a great path forward for the NCL would be to include a URL handler into the NCL. Then you could do something like ignition://ignitiongateway:80/projects/AwesomeIgnitionProject or ignition://ignitiongateway2:80/designer and the host OS could pass this to the NCL to direct launch appts from web links! Thoughts?
[/quote]That is a great idea! I’ll look at this for my Linux systems.

So I spent some time with the application installer builder InnoScript. It’s not bad and fairly straight forward.

Basically I build an installer that will put the client launcher in the ProgramData folder along with a custom launch.xml with the gateway name and a JRE folder with 32 or 64bit JRE depending on the client arch. Additionally, the install puts a link in AllUsers Start Menu to Ignition Applications which points to the clientlauncher.exe

The installer can run graphically or completely silent. I’m testing on a few PC’s but looks like I can get IT to approve to deploy to all systems to lighten their headaches with clients and eliminate the need to manage Java installs.

Needs some final deployment testing, but so far this is slick. If anyone wants a copy of the installer build script let me know. Only issue is ensuring the client uses the java version in the JRE folder and not the system JRE, but sounds like Inductive will be able to fix that soon.


I think I got this working. Not sure why its creating 2 launcher links, the client launcher itself and its shortcut.

After desktop on the line below I specified to create a folder rather then separate links on the desktop.
XCOPY %userprofile%\IgnitionClientStartup*.lnk %userprofile%\Desktop\FOLDER\ /y

Is there a backslash before the *.lnk? I assume it’s a typo, but it’s got to be asked.

Yeah, it was a typo. I copied and pasted my code but removed the specific project titles and must have erased the back slash.

I still dont know why its creating 2 x NCL links. Its works so i’m not going to mess around with it.

@echo off
ECHO Removing user’s .ignition folder…
rd %userprofile%.ignition /q /s
ECHO Removing Java Webstart applications…
javaws.exe -uninstall
ECHO Copying Client Launcher…
XCOPY “C:\Client Startup\ClientStartup” %userprofile%\ClientStartup /i /y
ECHO Adding links to desktop…
XCOPY %userprofile%\ClientStartup\*.lnk %userprofile%\Desktop\NewFolder\ /y
ECHO Installation complete!

I am using a version of this script to deploy the NCL client and install jre. After testing and writing up documentation to provide our client, it occurred to me that our client’s IT would probably want to use an admin account to do the installation rather than logging in to the user’s account to do the update.

If that is the case, wouldn’t they lose access to the user’s %userprofile% environmental variable, which is needed to make scripts like this work?

It should be possible to install to the all user’s directory, but I think our client would want to install for just one user on the machine.

Does anyone have any ideas on how to improve the script so that it will run correctly when logged in as an administrative user rather than the user that will be running Ignition? One idea is to prompt for the account to install under and assume that the path will be C:\users\account.

Thanks for any replies.

I handled it by pointing the user to the installation folder. If someone needed it, it was there. :slight_smile:

If I were doing this from an IT pov, I would do it through via logon script, checking a user was in a specific group. %userprofile% remains intact.

I had thought of having the user’s install it themselves, but I’m afraid that might not go too well. I do like the idea of a login script to do the install, I will look into that as a possible solution. Thank you for your response.

Our client has just made a request that the Ignition client be installed in a way that it can be run by any user that logs into the PC (if the user has the required group membership to clear security). I think that solution would remove the %userprofile% dependency.

I want to install the client directories under C:Program Files and the icon in the public Desktop directory so that it is available to all users, as mentioned in this discussion previously. I see how I can configure the icon to point to clientlauncher.exe file that normally resides in C:\Users%userprofile%\AppData\Roaming\Inductive Automation\Client Launcher, but I do not see a way to link to the files that are installed under C:\Users%userprofile%.ignition. Now that I think about it, I believe that directory can be deleted and will be rebuilt by Ignition, so maybe I don’t need to worry about it. I see that .ignition is deleted but not recreated in the example script above, so I think this may be the case.

I’m going to test this now.

It’s not documented, but if you put a file called redirect.txt into %userprofile%/.ignition/, and populate it with an exact path, the client should use that redirect file path as its “home” directory.

Thanks for that tip!

Oh, and if you’re on 8.x, the new client and designer launchers will use a local folder called clientlauncher-data/, if it exists next to the actual launcher executable.