Since using mslocal.cfg as my point to getting in front of Bentley, my workspace issues have been minimal. I have been able to configure Navigator, MicroStation, various "Power" products with the same mslocal.cfg starting with V8.5 through V8i Ss2, with only minor tweaks.

IMHO, this is the only way to fly. One shortcut offers the MicroStation Manager and users select the client via the PCF files and they are done. And the start menu or desktop shortcuts work since they are not pointing to mslocal while I am using a different file or command line switch.

On this, we can agree to disagree. Sometimes, I find I have to change : to = or = to : in client supplied files, among other things. But it's my go to solution and all assignments are saved at the correct level - system, site, appl, project, user.

I agree, Bear.  The System level files SHOULD be used as delivered, as well as the Database and Application configuration levels.  But some clients, DOTS, or other reviewing agencies provide workspaces that ignore this.  For those cases I am offering ways to use what they supply without editing the delivered files. The comment also applies to other variables where persons may need to set items and gives them alternative methods.  If they need to set the Application level folder, then it can be done this way as well.  I know a couple DOTS who use the Application level to set their workspace.

Again, ALWAYS USE the delivered SYSTEM, DATABASE and APPLICATION (appl) level files, but when you must change (one of) these because you are given a poorly written workspace, use one of these methods to keep from chaning the installed files. My apologies for not making that point.

ksumwalt, the point of not editing installed files is that you then don't need to worry about them as installs are redone, changed etc. Using a cfg file in the appl directory means nothing is effected by install changes.

Correct me if I am wrong, but:

The colon means "define if not defined already."  Therfore this line

    _USTN_WORKSPACEROOT : ${_USTN_INSTALLED_WORKSPACEROOT}

reads as

   If _USTN_WORKSPACEROOT is not already defined, assign it the value of _USTN_INSTALLED_WORKSPACEROOT

So if you simply assign a value to _USTN_WORKSPACEROOT BEFORE the line is read, you should not need to edit the delivered file. Add a line to mslocal.cfg at the very beginning to define this and you are good to go.  Since mslocal is specific to each machine anyway, it is a minor infraction on the rule of not cvhanging the delivered files.  Defining this in a shortcut, an OS environment variable may also work (untested by me) and keeps you out of the delivered files all together.

Is this not true?

This makes some people crazy, but this is exactly how I ave been doing it since J. And before workspaces were really exposed in the MicroStation Manager, editing the mslocal.cfg was where we used to have to place information for custom video cards and digitize tablets. I has always been the one file with no warnings about editing it.

I copy my mslocal.cfg and rename the copy to "Original_mslocal.cfg". I can always retrieve it for use with a command line switch or rename it back to restore OTB MicroStation.

I leave things in the config folders and its sub-folders to each PC, and have never tried to relocate upf files. I do have my interface folders on the network and when setting up a new user, we make them a ucf file and a user interface folder, right from the MicroStation Manager.

I've even had some success translating some similar approaches over to the Autodesk side of things.

Our PCF files are actually client files, but we generally have a survey version and a design version where a few different autorun vba macros run depending upon the task/discipline.

Some variables get assigned at the system level using variables that do not get their final values until the PCF stage. The variables assigned in the PCF are classified as project level, but the ones defined as the system level which get their values from the project variables are seen as system level variables.

I have to agree with Bear on this.  I place a .cfg file in the Config/Systems folder which calls a config file on the server but the config/appl location would probably work just as well.

Secondly moving the entire workspace can be problematic. You can run into issues when upgrading like the disappearing Task menus when GUI.dgnlib was introduced into the workspace.

We've had this discussion before about editing delivered cfg files and even Bentley staff don't recommend it. Why not use a cfg in the appl directory and direct it to _USTN_SITE??