OpenWebStart administration guide

Table of contents

Installation automation

The installation package provided by Mercedes-Benz AG consists of two files:

  1. The actual installation file "OpenWebStart_windows -x64_x_y_z.exe" The actual installation package is the unchanged OpenWebStart installation package from the manufacturer Karakun.
  2. A so-called response file named "OpenWebStart_windows-x64_x_y_z.varfile". This response file contains all configuration adjustments necessary for the use of OpenWebStart with the Aftersales applications of Mercedes-Benz AG.

X, y and z correspond to the current OpenWebStart version supported by Mercedes-Benz AG.

Important!
Do not use the installation package offered for download on the manufacturers page. It is not guaranteed to have been tested by Mercedes-Benz to work with the Aftersales-Applications, nor will it automatically set the required configuration options.

The required configuration adjustments are described in chapter Configuration specifications.

To integrate the OpenWebStart installation package into a software distribution, or in Terminal Server/Citrix environments, the response file can be supplemented with your own customizations.

For more information about usage of the response file, see the following pages:

User profile

The installation of OpenWebStart requires administrator privileges. It only installs the binaries, but does not create user settings. The user settings are stored in the user's local profile in the %userprofile%\.config folder. Downloaded files (JVMs and the application JAR file to start) are cached in the %userprofile%\.cache folder.
On first start of OWS by a standard user, OWS checks if the .config directory and the deployment.properties file exist. If not, OWS creates a new deployment.properties file based on default values available in C:\Program Files\OpenWebStart\.install4j\response.varfile . In case the required deployment.properties in the user profile needs more sophisticated settings, you may also create or provide the file over the course of the user's logon process (logon script).

Automatic Update of OpenWebStart

Mercedes Benz AG ensures that the Aftersales applications work correctly with specific OpenWebStart versions. It is recommended to deactivate the automatic program update integrated in OpenWebStart to make sure only supported versions are installed.

Please only use the installation package provided by Mercedes-Benz AG from our download page. This will always provide the latest version of OpenWebStart supported and tested by Mercedes-Benz AG.

You will be informed about necessary software updates through the regular communication channels: Market communication, XENTRY Portal and Service & Parts Net.

Configuration specifications

The following configuration parameters are mandatory for the successful launch of the Aftersales applications. The response file included in the installation package ensures that these configuration parameters are set during installation:

Varfile OpenWebStart Settings Remarks
sys.fileAssociation.extensions$StringArray = "jnlp","jnlpx" n.a. OpenWebStart will be associated with JNLP and JNLPX file associations
sys.fileAssociation.launchers$StringArray = "313","313" n.a. see above
ows.jvm.manager.server.allowFromJnlp = true JVM Manager > Configuration > Allow Server from JNLP file The JNLP-file is allowed to define which JVM is used to execute the application
ows.jvm.manager.server.allowFromJnlp.locked = true n.a. The user may not change the setting above
ows.jvm.manager.server.default = https://undefined JVM Manager > Configuration > Default update server URL An invalid download location is set to protect against downlading of untested JVMs
ows.jvm.manager.server.default.locked = true n.a. The user may not change the setting above
ows.jvm.manager.updatestrategy = AUTOMATICALLY_DOWNLOAD JVM Manager > Configuration > Update Strategy JVMs updated by Mercedes-Benz JVMs will be automatically downloaded from
ows.update.activated = false Updates > Check automatically for updates Deactivates the Auto-Update function
ows.checkUpdate = false see above see above
deployment.proxy.same = true Network > Manual proxy server > Advanced... > Use the same proxy server for all protocols ... Use the proxy server for all protocols

Usage of JNLP with Chromium

When using Google Chrome or the upcoming Chromium-based Microsoft Edge browser, a security warning appears when you download a JNLP file:
Chrome Security Warning

A direct execution of the JNLP file is not possible because no "Open"-Button is shown. The only solution is to enable the option "Ask where to save each file before downloading" in the Chrome advanced settings:
Chrome Download Settings

Using a proxy server

An optional proxy server can be configured in the OpenWebStart settings dialog, or for automated installations in the response file.

Important!
In version 1.1.4 of OpenWebStart, the proxy server support does not allow authentication (user & password, NTLM) of any kind. Make sure, that the service names required to access our applications are whitelisted in your proxy server's configuration. Most important remote addresses:
https://login.daimler.com
https://login.i.daimler.com
https://xentryportal.i.daimler.com
https://aftersales.i.daimler.com
https://vedoc-em1.i.daimler.com
https://vedoc-em2.i.daimler.com
https://retailfactory.mercedes-benz.com

Please do NOT whitelist download-openwebstart.com !
OWS 1.1.4 has got a fallback mechanism for the download of JVMs. In case the resource, which has been defined in the JNLP file is not reachable, OWS tries to download a matching JVM from download-openwebstart.com . This can lead to the result, that an unwanted JRE or JDK gets downloaded, and OWS uses this JVM continuously for different applications, even though this version has not been tested for e.g. usage with Aftersales applications. This fallback even is active, if the "Default Server URL for Updates" was configured to an invalid value.
To inhibit this download, the access to the internet for OpenWebStart should only be possible via a proxy server and require proxy authentication for access to download-openwebstart.com . As OWS isn't able to perform proxy authentication, this will prevent the unwanted access.
The developers of OpenWebStart are preparing an update for this problem, which hasn't been released yet.

Reset all settings

In case of application startup problems, the local cache of OpenWebStart can be deleted. It is located in the directory %userprofile%\.cache.

The configuration settings are located in %userprofile%\.config. If this folder gets deleted, the configuration data in the OpenWebStart settings dialog must be reentered and revalidated.

Terminalserver support / hints

OpenWebStart does not directly support installation in a terminalserver environment, but we can give you some hints which might be helpful when you try to integrate OWS into your own terminalserver solution. Mercedes-Benz Group AG does not actively or responsibly support installation in a terminalserver environment. Solving integration problems is up to the local administrator. Feel free to to contact us through CAC, you may report your problems or experiences with OWS. Any possible support will be carried out without engagement.

Changing the filesystem location for cache and configuration

OpenWebStart has adopted parts of the Freedesktop XDG Base Directory Specification and supports the following environment variables under Windows:

Environment variable Description Example
XDG_CACHE_HOME OpenWebStart stores its cached data (Java runtime environment and downloaded applications) relative to this base directory, inside the sub folder "icedtea-web". set XDG_CACHE_HOME=H:\XDG-Cache
XDG_CONFIG_HOME OpenWebStart stores its user specific configuration and optional log data relative to this base directory, inside the sub folder "icedtea-web". set XDG_CONFIG_HOME=H:\XDG-Config

The variables can be created in the per user profile, to make the values available for OpenWebStart with the login of the user. Der Administrator must ensure, that the directories are configured to have sufficient write and read access rights for the respective user.

Shared JVM:

It is not recommended to share cached JVM data (downloaded JRE or JDK) for all users at a common location. The effort required to administrate such a solution bears no relation to the profit to save some small costs for additonal storage space per user.

Registry keys

In case you want to implement a different installation process (not recommended), you must make sure, that some important registry keys will be set by your installation routine. For reference you can find the registry keys here:
OWS_RegKeys_2020-02-12.zip
You will have to check and adjust the paths in the files before applying the key data in any way!

Reduce memory footprint

Especially on terminal server systems one can watch the following scenario:

  • The server's got a huge amount of RAM installed.
  • When an OpenWebStart process starts, it allocates a pretty significant amount of main memory, which is not reasonable for the tasks the javaws.exe process actually performs.
  • Due to this "waste" of main memory, the terminal server is not capable to provide service for the planned number of users anymore.

You can easily monitor the memory consumption with Process Explorer 64 from the Microsoft Sysinternals Tools. The most reliable gauge for the memory consumption is the "Private bytes" column and summary. The Windows task manager is not a reliable instrument in this case.

Solution (experimental): You can try out the following:
As administrator: Append the following lines to the end of the file C:\Program Files\OpenWebStart\javaws.vmoptions

-Xms64m
-XX:+UseG1GC
-XX:MaxHeapFreeRatio=40

Save the changes.

The configuration options will cause the following changes to the javaws.exe process:

  • -Xms64m : Configure the JVM to initialize with 64MB heap size, and not with the automatically calculated 1/64 of installed RAM.
  • -XX:+UseG1GC : Configure the Java 8 based javaws.exe to use a different garbage collection algorithm (which is the default since Java 9). This algorithm enables to give back natively allocated memory to Windows, in case it is really "not used".
  • -XX:MaxHeapFreeRatio=40 : This configures the JVM to have not more than 40% of unused memory overhead. If the unused memory exceeds 40%, the JVM tries to shrink the allocated memory accordingly and release it to the OS. Please mind: Values lower than 40% mostly result in launch problems with the error message "The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firewall tool could block the execution."

Be aware of the following:

  • This modification affects all stage 1 launches of OpenWebStart for all users of the server. Stage 2 optimizations are part of the JNLP definition and not part of this solution.
  • The modification will not survive any OpenWebStart update. When performing an OWS update, make a backup of the modifications first, and after the update review and restore javaws.vmoptions again.
  • We successfully use this solution on Mercedes-Benz Group AG systems, nevertheless this solution proposal is without guarantee.

Last update: Mon Jan 31 21:37:14 CET 2022