MicroStation Update 17 includes the new Manage Configuration utility. This enables MicroStation to switch between multiple configurations allowing further control and separation of standards for organizations working with serial clients or on major projects that require specific CAD/BIM standards.
This is equally beneficial for smaller organizations as this feature can support accessing, with minimal technical input, an entirely self-contained configuration supplied by a third-party.
For administrators, even when they are only managing a single configuration, it enables them to easily switch between production and development configurations.
Where a Custom Configuration is already used by Update 16, during an upgrade to Update 17 MicroStation picks up the path to this configuration from ConfigurationSetup.cfg and will list it with the Example configuration in the new Configuration panel:
If you install Update 17 and do not see your previous configuration, either nothing:
or only the Example configuration:
this will be because the previous ConfigurationSetup.cfg was not found. This can happen if a previous version is uninstalled and all remaining folders and files are deleted, whether manually or by an IT system process.
In this case simply launch Manage Configuration and click Add following the steps in this video (once the new configuration is created in the first few seconds the video goes on to show switching between configurations):
The required inputs, shown in this video, are a name and description that will appear in the UI, the choice of Custom Configuration location, the path to the Custom Configuration. This path is to the Custom Configuration root folder that contains WorkSpaceSetup.cfg. Ensure 'Visible' is ticked, if it is not the configuration will not be listed in the UI.
Clicking the Workspace Setup toggle displays the active configuration variables in the existing WorkSpaceSetup.cfg. These do not need to be changed to use an existing Custom Configuration.
Documentation is here for Update 17: Creating and Managing Configurations.
Configurations are stored in C:\Users\...\AppData\Local\Bentley\MicroStation\10.0.0\prefs\configuration.xml.
This file can be copied to any users provided that the path(s) stored in the XML for each configuration is/are valid for each user.
Each configuration is contained in a <ConfigurationModel> tag pair. The values entered in the Manage Configuration utility are stored in a similar order to the dialog:
Configuration Name: <Title>SMB Config</Title>Description: <Description>SMB Demo Config</Description>Set by application: <ConfigurationVariable>_USTN_CONFIG_SMB_Config</ConfigurationVariable>Type: <Type>Local</Type>Visible: <IsActive>true</IsActive>Configuration Folder: <Path>D:\_SMB\SMB_Resources\</Path> <IsSelected>true</IsSelected> <IsEditable>true</IsEditable>
Additional values set by the application are IsSelected, which identifies the user selected configuration and ConfigurationVariable, which is is an an identifier used by the application.
IsEditable is set by default to true for new configurations but set to false for the Example configuration to ensure new users have access to the examples for learning purposes.
The example configuration can be hidden by editing the XML, set the IsActive statement to false:
In MicroStation 17.1 we can use _USTN_USER_CONFIGURATION to hide the Configuration Manager and all configurations listed in configuration.xml. This is an interim step. The ability to hide Configuration Manager while making pre-selected configurations available for use is being worked on for MicroStation 17.2.
When _USTN_USER_CONFIGURATION is directed to a configuration path that configuration is the only one that will be visible in the UI, similar to its previous behaviour.
Why is the examples configuration locked and cannot be hidden or deleted? I already have problems with my users using the MetroStation workset in Opencities MAP PowerView but at least we can "remove from list". Costs us money in wage loss every time a user plays around with something like this rather than getting to the real work.
I understand the reason that the Examples Configuration is locked is to ensure that MicroStation based applications are always installed with at least one operational WorkSpace.
There is a note on how to change this in the "Manage Configuration XML Syntax" section above:
The example configuration can be hidden by editing the XML, set the IsActive statement to false: <IsActive>false</IsActive>
As discussed above and in the comments, the modified configuration.xml file needs to be distributed to all users. This can be done using Windows Account Policies or by a manually initiated batch file similar to the one described in CONNECT Edition - Deploying or Updating ConfigurationSetup.cfg.
I must say this is a REALLY bad way of implementing this level of configuration.
does everyone realize where this file gets placed ? as Marc says you can use windows or manually control this.
but - there is another twist to this. This file seems to be per product. So if I have MicroStation and ORD (for example) - I have two separate folders for the preferences. So there will be two separate XML files.
Has anyone else encountered this ?
Yes, it appears to be placed per Product. I haven't checked OpenRail or OpenBuildings yet.
it gets even better....it's different depending on the number of versions as well. For instance, if you have multiple ORD versions, then you may have 10.0.0, 10.0.0_1, and 10.0.0_2.