Connect edition 17 - How can I remove unwanted configurations from GUI?

Documentation is here: Creating and Managing Configurations (bentley.com). The XML syntax is not currently included in help. It is covered by this new blog: Configuration Tips - Manage Configuration Utility.

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.

The example configuration can be hidden by editing the XML, set the IsActive statement to false:

<IsActive>false</IsActive>

Development is continuing to work on this feature so these comments will be taken note of.

This feature was introduced in response to demand from our users for multiple configurations and does offer a more flexible mechanism for control of configurations, we need to do some further work to address the questions in this thread.

Why was this feature introduced if development is still working on it?
Why was it developed with no way to protect it from the users?

Does the configuration.xml NEED to be local, or is there a way to locate that on a network drive as part of an Organization configuration?

Yeah, I'm not sure what they're thinking as well. This also seems to go against some of what they seemed to want to do with the OneConfiguration concept.

I think part of the reason they added this was for ProjectWise Drive configurations. Since you may have ProjectWise Drive connections for different company's ProjectWise, the user being able to switch which ProjectWise drive config they're using may be important for this to work.

But at the same time it seems like an easy way to break ProjectWise managed workspaces which we currently have. If one of my user selects the wrong configuration (say another company's ProjectWise Drive) then uses my managed workspace, the other company's ConfigurationSetup.cfg will still be processed and may cause weird effects in my workspace.

Also, what happens if a user double-clicks a DGN file on a regular server. Today it uses the WorkSpace/WorkSet branding to get the correct workspace, but what if your configuration is set to something else? Does it check each configuration you have setup for the correct WorkSpace/WorkSet. Will they start branding the Configuration selected into DGN files too?

I've also noticed that they have moved the following variables from the "personal.ucf" file to "C:\Users\<username>\AppData\Local\Bentley\MicroStation\10.0.0\prefs\cache.ucf":

• _USTN_WORKSETNAME
• _USTN_WORKSPACENAME

In the same, you'll also find these variables

• _PROJECTWISE_DRIVE
• _USTN_LAST_ACTIVE_CONFIGURATION

My two cents.

I also see a variable in the personal.ucf :

_USTN_LAST_ACCESS_CONFIGURATION

which is a bit confusing from 

_USTN_LAST_ACTIVE_CONFIGURATION

in the cache.ucf

Well this is cute. There is a new variable:

_USTN_CACHECFG that points at the cache.ucf file. It is locked.

There is also a _USTN_CACHEWSCFG that points at a WORKSPACE.ucf where WORKSPACE is the name of the (current?) workspace, the path is the user prefs folder. This file doesn't exist on my system howerver.

I added a variable to the cache.ucf to see the order it is loaded in and it loads before the Personal.ucf so theoretically anything in the Personal.ucf should override the cache.ucf.

I've no idea why these cache files are needed either.

looks like Bentley's getting ready for an early easter egg hunt. 

looks like Bentley's getting ready for an early easter egg hunt. 

No idea what that thing is for (for someone else), but I'd like to know if I can just make it all go away. I hate having stuff like that up on my screen that I must constantly ignore.

Hi Bob,
I haven't tried this with Update 17, but you could try setting both _USTN_USER_CONFIGURATION and _USTN_CONFIGURATION to your configuration path (as either command line arguments or as Windows Environment Variables) and that should ignore the local and custom configuration setups.