[ORD] ...\Configuration\Organization\ pathed to network drive?

There are a bunch of .cfg files automatically included if they are present. For example in our WorkspaceSetup.cfg I define _USTN_ORGANIZATION and all the .cfg files in that folder are automatically loaded (in alphabetical order).

Once a WorkSpace & WorkSet are selected, all the cfg files in _USTN_WORKSPACESTANDARDS and _USTN_WORKSETSTANDARDS are included automatically.

I recommend going through the msconfig.cfg in the Config folder in the where the application is installed. That shows all the cfg files that get loaded and in what order.

As for order of loading things, the default order is:

Organization -> WorkSpace standards -> workset standards

if you use Organization-Civil, that isn't automatically loaded, it's usually loaded by the workspace or workset with a manual %include.

I like putting our corporate standards in Organization because I can lock things before the workspace or workset handle them, and what I put there is loaded by all projects.

I agree with Kevin, but it is hard to see exactly what you are doing. It seems like you are splitting everything out Organization in one location, workspaces in another and then your projects/worksets in yet another location....

I'm not actually trying to do anything terribly different than ORD already does:

On my network:

On my computer:

On my network:

The only thing I really want to do is bypass the local configuration at the Organization level (and beyond) to send it over to the network. The other caveat is that we have a separate project drive for all of our projects. While I can store the project/workset CFGs & DGNWSs in the ...Workspace\Worksets\ directory I need the workset CFG itself to redirect to the project directory. That part isn't hard. It's figuring everything upstream that's got me running around and overthinking.

Kevin's suggestion to redirect _USTN_ORGANIZATION in WorkspaceSetup.CFG actually seems to have worked. I don't have a lot of organizational standards (beyond a collection of cell libraries) but I do have a few (including the variable pointing to the project drive).

In WorkSpaceSetup.cfg I define all variables that pertain the the overall setup of the configuration. In Organization I put actual settings/files that are used with the product(s) themselves.

So our WorkSpaceSetup.cfg has:

• _USTN_ORGANIZATION
• _USTN_WORKSPACES_ROOT
• _USTN_WORKSPACE_ROOT
• _USTN_WORKSPACESTANDARDS
• _USTN_WORKSETS_ROOT
• _USTN_WORKSET_ROOT
• _USTN_WORKSETSTANDARDS

Although I currently let user prefs go with the defaults this is the file where I'll set them to our company's OneDrive once I'm happy with how what I setup is working.

Things I've noticed setting up ORD (although most apply generally):

• I lock all these varaibles in case i miss removing them from a client's workspace.
• Beware the variables with hidden s in them (_USTN_WORKSPACESROOT vs _USTN_WORKSPACEROOT). Whoever didn't put a _ in front of ROOT is killing me. Fortunately now that I have these set the way I like it doesn't screw with me as much.
• if you look at msdirs.cfg in the config/system folder of the application (not msdir.cfg in the root of the config folder) you'll see Bentley "conveniently" defines and loads variables from certain folders in the workspace & workset standards folders.
  • These are defined at the system level so may load before your organization standards.
    • You can force your Organization standard stuff to load before these by using < in assigning paths
  • I would probably make sure these folders exist even if you don't put anything in them
    • I haven't confirmed but I believe these folders not existing causes issues for projectwise managed workspaces.
  • If your going to use these folders, don't double add the path in your own cfg, it makes ORD process all the dgnlib files in the folders each time it appears in the variable.
  • If you really want to get rid of these definitions you can re-define the variable to be just the $(SYSTEMROOT) folders in your workspacesetup.cfg:
    • MS_DGNLIBLIST           = $(_USTN_SYSTEMROOT)/dgnlib/*.dgnlib
    • if there is no systemroot folder you can %undef and let them be created in your organization/workspace/workse.
    • This probably isn't worth the effort unless you think it's causing problems for you

Like you I've got little in our organization standards, I have had to create some empty folders in ours to make things work, ours has empty folders named: Descartes, Prostructures and SPC