How do you pre-configure for remote clients for the client launcher? Whenever I try the zip file on another computer it just creates a .ignition folder on that computer and uses a default vision-client-launcher.json instead of the one I configured in clientlauncher-data. How do you setup it up so that it uses the pre-configured settings?
The docs regarding remote clients and pre-configuration need to be updated for 8.0. In 8.0, it’s required that you extract the vision-client-launcher.json (and all other files in clientlauncher-data) into the user’s .ignition folder that is in their home directory. The launchers will always be looking for the launcher data to be in .ignition/clientlauncher-data.
I really hope there is a way to force a default configuration for all users like in 7.x and the home folder is not a hard requirement. We push the clients pre-configured to hundreds of users and do not want any end users setting up most of the config.
1 Like
Thanks James. Is there a way to automate the clientlauncher-data be moved to the users .ignition folder in their home directory?
You’ll have to come up with a batch file or script if you want hands-off automation of taking the client-launcher-data from the gateway and deploying it to a remote client.
I’m not sure I follow - the instructions I gave will allow for forcing a default configuration, you just have to overwrite the clientlauncher-data that is located in the user’s home directory. Or am I not understanding your concern?
So, right now we deploy the client launcher (7.9 version) into the ProgramData folder. There is an associated clientlauncher-data in that directory (next to the exe) that the client launcher uses for the configuration. It does not require the config to be in EVERY home folder. The home folders are problematic as many PCs are shared and the first time a user logs on or user folders on shared PCs are flushed the configs will be lost.
As long as the new client launcher doesn’t loose the ability to prioritize a clientlauncher-data folder placed next to the exe for its config, it should work the same as the 7.9 version. (I guess I should just fire up my beta VM and check 
)
I’m using 8 and it did not work. I’m not sure you can prioritize a clientlauncher-data folder. I’ve set the exe next to it and it just uses the users home folder.
Thanks for the clarification. I’ll put in a feature request to restore this functionality, but I don’t really have a timeframe as of yet.
1 Like
Devil's advocate - isn't this exactly what stuff like group policy is for? Should be possible to automatically set up this configuration through AD, although I'm definitely not an expert here.
On some projects we might assign a project or certain pages of a project for client access (based on a user log in script)
These clients laptops, iPads and devices are not part of our equipment so we want the easiest way for them to log on with out having to get to the gateway or see all the possible projects available as some of these projects could be named or associated with there competitors name.
Is it possible to build a client launcher that can be pre-configured for one project only and even better with a end date then emailed to the client with their log in details.
Our projects are not the typical factory based scada systems. We deplay machines all over the world that communicate back via mqtt and we have our company personal on site dor doing site reports etc. We want to share these reports and any down time analytics with the client engineers. So we want them to be able to log on to our projects but in the simplest way possible. Ideally just sharing the desktop created shortcut would be the easiest way but I gather that’s not possible.
I think we’ve ventured away from matching existing functionality and into new functionality.
FWIW, Perspective will allow you to deep link into any view of any project, no client launchers needed.
Agree, but group policies are cumbersome and our IT does not let anyone touch Group Policies outside of IT. They are really kind of a nightmare to work with sometimes. However, we have software management and deployment appliances that make software deployment 1000X easier than Microsoft built in stuff (and its cross platform when needed). Also, it allows our Ignition people to manage the install ourselves and have full control without needing to run to IT every time there is an update.