Working off a networked Workspace for one specific client (we do outsourcing), our current setup is through the mslocal.cfg pointing to the shared workspace.
However in future each new Client is highly likely to have their own Workspace with own standards and Datasets etc.
Editing the mslocal.cfg for each Client Workspace does not seem very practical although for the moment I cannot find any other way....Any suggestions out there?
We do it by setting the Windows variable _USTN_WORKSPACEROOT to the networked workspace.
This is the only thing which is done on the client, the rest is configured on the server.
No need to do anything when a new Microstation is installed on the client either.
I mean i want each user to have the choice of workspace - choose between 4 or 5 diferent workspaces typically...
What do you mean by "Windows" variable anyway?
As we can see there are many ways to set up client specific, company specific, dataset specific configurations.
A lot of what I see CAD/BIM managers doing is setting up shortcuts for each specific workspace, each shortcut points to a specfic configuration file, which defines the workspace location, thus using the client standards. Project configuration files can define the datasets, user configuration files can define user specific things like, for example, each user having their own function key menu.
Mslocal.cfg is not changed in this method. The users need the shortcuts added to their machines, that is all I need to do to "touch" their machines.
To do this the "-wc" command line argument is used. Here's an example of what a shortcut looks like in Configuration Explorer's Shortcut Creator tool:
Here is a list of command line arguments available for Bentley DGN based applications (from the Configuration Explorer help):
Argument
Result
-Debug
Writes the configuration variables and their settings to a debugging variable definition file, and exits.
-Help
OR
-?
Displays the entire list of command line arguments for ustation.exe.
-I<parameters>
Passes parameters to MS_INITAPPS, which is a list of initial startup MDL applications.
-M<model_name>
Specifies the model to open at startup.
-O
Does not open any references.
-QP<password>
Specifies a password for a protected file.
-R
Opens the DGN file in read-only mode.
-RestoreDefaults
Restores the default settings, and exits.
-RestoreDefaultsQuiet
Restores the default settings, and exits with no output.
-S<startup_file>
Writes text to the command queue, in the startup file, after startup.
-WA<mdl_application>
Specifies an MDL application to initialize at startup. (This is the same as MS_INITAPPS.)
-WC<path_to_configuration_file>
Specifies the configuration file to use at startup, and the path to that file. Example: -wcC:\Program Files\Bentley\MicroStation V8i (SELECTseries)\MicroStation\config\MyConfig.cfg
-WD<database>
Specifies the database configuration.
-WI<interface>
Specifies the interface configuration.
-WP<project>
Specifies the project configuration.
-WS<configuration_variable>
Specifies a configuration variable to be defined.
Example: -wsMS_SECURITY_LEVEL=HIGH
-WU<user>
Specifies the user configuration.
-WR<path>
Specifies the path to the workspace's root (_USTN_WORKSPACEROOT).
Example: -wrC:\Bentley\Workspace\
Good stuff Paul, thanks for that.
Chris, hope this screenshot makes it clear, even if it is from a norwegian Windows 7 system.
Edit Control Panel - System - Advanced - Environmental Variables - System Variable - New - USTN_WORKSPACEROOT
'So in the end multiple mslocals , multiple workspaces and multiple shortcuts do the job. Simple and pretty much bullet-proof.'
Except when it comes to versioning your builds based on new product releases. This has been covered in other threads, but it's worth avoiding the use\editing of any delivered cfg files.
One cfg for each client is all you would need and a boot/start for each build is required for each client here as well. Larger systems can be managed through a similar build and a hta file. I'll post an example when I get a chance.
Basically this runs in a similar fashion to what you have now, but uses independant cfg files.
Thanks for the screenshot Andreas, understand. Interesting way to do, first time I come across that one.