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

I've played with the configration.xml here's some things I've noted:

• If a user has selected a configuration (say the examples one) and you set the IsActive to false, that configuration will still be the selected one in the UI, the workspaces dropdown will show the Examples workspaces.
  • If you DELETE the Examples <ConfigurationModel> entries, and the remaining entry has IsSelected to true this will force the interface to use that Configuration
• If you have 1 entry in the Configuration.xml and it's IsSelected is set to false, nothing will be selected in the UI and the workspaces drop down will have no entries (the workset drop down won't appear at all). You'll have to manually select the one entry before the workspace selection becomes active
• If multiple entries have IsSelected set to true, the last one in the file wins.
• There is no way (that I could find) to disable the "Managed Configurations" option. You can prevent the from modifying existing entries (without editing the xml file directly) by setting IsEditable to false. However they can create a new one and edit it.
• The Types available are Local, Network/Shared Drive and ProjectWise Drive. The ProjectWise Drive entries have your company's name in them so you can have multiple projectwise drive configurations.
• When selecting a folder for creating a configuration it must have a workspacesetup.cfg file in the folder. Doesn't have to be valid or actually have anything in it, just has to exist.

This feature actually started shipping in ORD (and I think OBM but I don't follow it as close). Looks like I created a configuration.xml file for the tool i have for updating user's configurations in November of last year. The format of the 2 XML files appears identical (although the Microstation one the xml header claims to be utf-16, but the file format is utf-8. no idea if that causes issues).

In my configuration I removed the unneeded configuration and setup the one config for what we do. I initially thought this might be useful for flipping between FDOT's config and our normal config but using this to accomplish it requires the user set the configuration in the UI. Leveraging FDOT's custom application icons we can switch on the fly and the user really doesn't have to do anything.

I still want a variable to be able to move the configuration.xml file so I don't have to maintain 5 of them (2 versions of ORD, 2 versions of OBM and MicroStation) for each user.

This is my Configuration.xml from ORD (we had already switched to using _USTN_USER_CONFIGURATION variable in configurationsetup.cfg as it works better for us)

<?xml version="1.0"?>
<ArrayOfConfigurationModel xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<ConfigurationModel>
		<Title>HNTB Configuration</Title>
		<Description>HNTB Server Configuration</Description>
		<ConfigurationVariable>_USTN_USER_CONFIGURATION</ConfigurationVariable>
		<Type>Local</Type>
		<IsActive>true</IsActive>
		<Path>C:\CADDLib\Connect\</Path>
		<IsSelected>false</IsSelected>
		<IsEditable>true</IsEditable>
	</ConfigurationModel>
</ArrayOfConfigurationModel>

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?

to add to this frustration is that they decided that XML is to be used - why ? 

so we now need to know XML as well as editing the normal text files and the syntax needed for the configurations, etc...

I just hope they don't do the usual Band-Aid approach and piece meal a bad workflow into the products like they have been for so long.

I think you have mis-worded what the new feature is. It is not an extended management layer because management has always been able to work with this (in the background). This is an exposer to the user to now have an additional choice in the interface.

Due to some difficulties with some client DOTs I have to keep complete configurations separate from others. I have these load in various ways (desktop icons, etc...).

With this new feature it will be possible to have the user access these from one interface.

The problem with what has been created here, is that this is controlled from the user and not management.