Installing City Engine 2012.1 (CityEngine_2012_1_64bit_130381.exe) onto a multiuser Windows Active Directory Domain member 64-bit Windows 7 workstation, ArcGIS 10.1 installed and an Advanced (ArcInfo) concurrent seat selected and authorized.
The CityEngine install has some pretty unusual Windows installation behavior. Specifically, when using a Domain managed local administrators group member account, if the installation is performed "Run as Administrator" launch after installation fails. And then for that local administratos group Domain account, when the Welcome Wizard runs, the user account has no access to the default Workspace location of the "Run as Administrator" install. The Wizard closes with a message that it could not open that workspace.
Subsequent attempts to launch CityEngine result in a CityEngine License error message "CityEngine is not authorized for use..."
[ATTACH=CONFIG]22668[/ATTACH]
Workaround: [INDENT] The same domain local administrators group member account, or the local system Administrator account (activated for my deployments), can perform the installation and authorize CityEngine not "Run as Administrator" followed by launch of Welcome Wizard. But then other local & domain users are not able to launch CityEngine unless the default WorkSpace is set during initial Welcome Wizard run to a common use directory on the system. And, the esriLicense.config file has to remain in the account where created, and all users need to be granted read access to it.[/INDENT]
This authorization and configuration behavior is not common for a multiuser, Enterprise application and will cause a lot of issues and behaves more like a single use product. I hope you can get some assistance from the Esri product engineers on adjusting the installer and program behavior for next release of CityEngine as the extension has been picked up for classroom use by our Urban and Regional Design program in our College of Architecture. Installation glitches are impeding that classroom use.
In the interim, two questions for you that might allow a more flexible management of user configuration: [INDENT]1) where in the CityEngine program does the path to the esriLicense.config get recorded; could it be moved to a common location like C:\Program Files\Common\Esri, or C:\ProgramData\Esri?
2) is it possible to change the default Workspace opened on launch directly in a common configuration file, or possibly a per-user configuration file; where would that be found in the CityEngine program directories?[/INDENT]
Concerning 1) The problem ist that ArcGIS Administrator writes the .esriConfig file into the home dir and we go grab it there. As a workaround, you can copy this .esriConfig file into each Home via your login script.
Concerning 2) You can also set the workspace in CityEngine.ini :
-data <location> (OSGi) equivalent to setting osgi.instance.area to <location>
osgi.instance.area {-data} the instance data location for this session. Plug-ins use this location to store their data. For example, the Resources plug-in uses this as the default location for projects (aka the workspace). See the section on locations for more details.
Locations The Eclipse runtime defines a number of locations which give plug-in developers context for reading/storing data and Eclipse users a control over the scope of data sharing and visibility. Eclipse defines the following notions of location: User (-user) {osgi.user.area} [@none, @noDefault, @user.home, @user.dir, filepath, url] User locations are specific to, go figure, users. Typically the user location is based on the value of the Java user.home system property but this can be overridden. Information such as user scoped preferences and login information may be found in the user location. Install (-install) {osgi.install.area} [@user.home, @user.dir, filepath, url] An install location is where Eclipse itself is installed. In practice this location is the directory (typically "eclipse") which is the parent of the eclipse.exe being run or the plugins directory containing the org.eclipse.equinox.launcher bundle. This location should be considered read-only to normal users as an install may be shared by many users. It is possible to set the install location and decouple eclipse.exe from the rest of Eclipse. Configuration (-configuration) {osgi.configuration.area} [@none, @noDefault, @user.home, @user.dir, filepath, url] Configuration locations contain files which identify and manage the (sub)set of an install to run. As such, there may be many configurations per install. Installs may come with a default configuration area but typical startup scenarios involve the runtime attempting to find a more writable configuration location. Instance (-data) {osgi.instance.area} [@none, @noDefault, @user.home, @user.dir, filepath, url] Instance locations contain user-defined data artifacts. For example, the Resources plug-in uses the instance area as the workspace location and thus the default home for projects. Other plugins are free to write whatever files they like in this location. While users can set any of these locations, Eclipse will compute reasonable defaults if values are not given. The most common usecase for setting location is the instance area or, in the IDE context, the workspace. To run the default Eclipse configuration on a specific data set you can specify: eclipse -data c:\mydata
More detail Locations are URLs. For simplicity, file paths are also accepted and automatically converted to file: URLs. For better control and convenience, there are also a number of predefined symbolic locations which can be used. Note that not all combinations of location type and symbolic value are valid. A table below details which combinations are possible. Since the default case is for all locations to be set, valid and writable, some plug-ins may fail in other setups even if they are listed as possible. For example, it is unreasonable to expect a plug-in focused on user data (e.g., the Eclipse Resources plug-in) to do much if the instance area is not defined. It is up to plug-in developers to choose the setups they support and design their functionality accordingly. @none Indicates that the corresponding location should never be set either explicitly or to its default value. For example, an RCP style application which has no user data may use osgi.instance.area=@none to prevent extraneous files being written to disk. @none must not be followed by any additional path segments. @noDefault Forces a location to be undefined or explicitly defined (i.e., Eclipse will not automatically compute a default value). This is useful where you want to allow for data in the corresponding location but the Eclipse default value is not appropriate. @noDefault must not be followed by any additional path segments. @user.home Directs Eclipse to compute a location value relative to the user's home directory. @user.home can be followed by additional path segments. In all cases, the string "@user.home" is simply replaced with the value of the Java "user.home" System property. For example, setting osgi.instance.area=@user.home/myWorkspace results in a value of file:/users/bob/myWorkspace @user.dir Directs Eclipse to compute a location value relative to the current working directory. @user.dir can be followed by additional path segments. In all cases, the string "@user.dir" is simply replaced with the value of the Java "user.dir" System property. For example, setting osgi.instance.area=@user.dir/myWorkspace results in a value of file:/usr/share/eclipse/myWorkspace
I'd say per user .CityEngine authorization and configuration on an Windows Active Directory managed Domain following initial installation and authorization and lack of detail about the Eclipse and Java configuration details needed to make CityEngine reliable on a multiuser workstation using FlexNet Publisher concurrent licensing.
Concerning 1) The problem ist that ArcGIS Administrator writes the .esriConfig file into the home dir and we go grab it there. As a workaround, you can copy this .esriConfig file into each Home via your login script.
Concerning 2) You can also set the workspace in CityEngine.ini :
-data <location> (OSGi) equivalent to setting osgi.instance.area to <location>
osgi.instance.area {-data} the instance data location for this session. Plug-ins use this location to store their data. For example, the Resources plug-in uses this as the default location for projects (aka the workspace). See the section on locations for more details.
Locations The Eclipse runtime defines a number of locations which give plug-in developers context for reading/storing data and Eclipse users a control over the scope of data sharing and visibility. Eclipse defines the following notions of location: User (-user) {osgi.user.area} [@none, @noDefault, @user.home, @user.dir, filepath, url] User locations are specific to, go figure, users. Typically the user location is based on the value of the Java user.home system property but this can be overridden. Information such as user scoped preferences and login information may be found in the user location. Install (-install) {osgi.install.area} [@user.home, @user.dir, filepath, url] An install location is where Eclipse itself is installed. In practice this location is the directory (typically "eclipse") which is the parent of the eclipse.exe being run or the plugins directory containing the org.eclipse.equinox.launcher bundle. This location should be considered read-only to normal users as an install may be shared by many users. It is possible to set the install location and decouple eclipse.exe from the rest of Eclipse. Configuration (-configuration) {osgi.configuration.area} [@none, @noDefault, @user.home, @user.dir, filepath, url] Configuration locations contain files which identify and manage the (sub)set of an install to run. As such, there may be many configurations per install. Installs may come with a default configuration area but typical startup scenarios involve the runtime attempting to find a more writable configuration location. Instance (-data) {osgi.instance.area} [@none, @noDefault, @user.home, @user.dir, filepath, url] Instance locations contain user-defined data artifacts. For example, the Resources plug-in uses the instance area as the workspace location and thus the default home for projects. Other plugins are free to write whatever files they like in this location. While users can set any of these locations, Eclipse will compute reasonable defaults if values are not given. The most common usecase for setting location is the instance area or, in the IDE context, the workspace. To run the default Eclipse configuration on a specific data set you can specify: eclipse -data c:\mydata
More detail Locations are URLs. For simplicity, file paths are also accepted and automatically converted to file: URLs. For better control and convenience, there are also a number of predefined symbolic locations which can be used. Note that not all combinations of location type and symbolic value are valid. A table below details which combinations are possible. Since the default case is for all locations to be set, valid and writable, some plug-ins may fail in other setups even if they are listed as possible. For example, it is unreasonable to expect a plug-in focused on user data (e.g., the Eclipse Resources plug-in) to do much if the instance area is not defined. It is up to plug-in developers to choose the setups they support and design their functionality accordingly. @none Indicates that the corresponding location should never be set either explicitly or to its default value. For example, an RCP style application which has no user data may use osgi.instance.area=@none to prevent extraneous files being written to disk. @none must not be followed by any additional path segments. @noDefault Forces a location to be undefined or explicitly defined (i.e., Eclipse will not automatically compute a default value). This is useful where you want to allow for data in the corresponding location but the Eclipse default value is not appropriate. @noDefault must not be followed by any additional path segments. @user.home Directs Eclipse to compute a location value relative to the user's home directory. @user.home can be followed by additional path segments. In all cases, the string "@user.home" is simply replaced with the value of the Java "user.home" System property. For example, setting osgi.instance.area=@user.home/myWorkspace results in a value of file:/users/bob/myWorkspace @user.dir Directs Eclipse to compute a location value relative to the current working directory. @user.dir can be followed by additional path segments. In all cases, the string "@user.dir" is simply replaced with the value of the Java "user.dir" System property. For example, setting osgi.instance.area=@user.dir/myWorkspace results in a value of file:/usr/share/eclipse/myWorkspace
This is an open Esri NIMBUS reported bug -- NIM086586
Lists the work around of copying esriLicense.config to the user profile of each user.
It has no discussion of handling the workspace. But as noted, the osgi.instance.area {-data} should be placed by default into each users account if licensing authorization occurs. Or can use a common location at the initial launch following install as I note.
