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

If you're setting and using the _USTN_CUSTOM_CONFIGURATION variable for your networked configuration, MicroStation will use the Organization folder there as the _USTN_ORGANIZATION folder. I've never had any issue with that.

I didn't even remember that since one of the first things I did was rename Organization folder to our company name which forced me to set _USTN_ORGANIZATION independently. I also rename workspaces and worksets folders which is why i set all the other variables too. whoops.

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

then why not do what Rod mentions and set the _USTN_CUSTOM_CONFIGURATION to point to your networked configuration ?

Because I need to support about 40 network locations, plus loading the workspace from the local hard drive, and ProjectWise managed workspaces for 3 versions each of ORD, OpenRail and OBM.

I use _USTN_USER_CONFIGURATION and point it to a folder on the root of the c: drive. This would be the same as using _USTN_CUSTOM_CONFIGURATION pointed at the same folder (which I used to do) but either kills all those paths that are set based on _USTN_CONFIGURATION. I have to set them to the correct location which varies across the company.

The single WorkSpaceSetup.cfg in that folder supports all applications and only one variable needs to be adjusted to point to any of our network file servers or keep pointing at the local folder.

This way all 9 applications get exactly the same ConfigurationSetup.cfg, pointing at exactly the same c: drive folder. To set where the rest of the workspace is coming from I set a single variable in this one WorkSpaceSetup.cfg and then manually set _USTN_ORGANIZATION, _USTN_WORKSPACESROOT and _USTN_WORKSETSROOT using that variable.

Although projectwise managed workspaces bypass all of this, by setting _USTN_CONFIGURATION in a CSB to a ProjectWise folder, so here I could use the automatic _USTN_ORGANIZATION, if I wanted to use Bentley's folder names, instead I use exactly the same WorkSpaceSetup.cfg inside of projectwise that I use locally and my magic variable that normally points at the network location to find the workspace now points at projectwise folders.

I have an application that can read the installed applications and put the ConfigurationSetup.cfg in place, plus modify the variable that points to the rest of the configuration in the one WorkSpaceSetup.cfg based on the user's picking of which office's server they want to use. It can also synchronize an entire configuration, including client configuration, to the local machine and again the one single WorkSpaceSetup.cfg controls it all. This absolutely saved our bacon for COVID work from home. Using an ORD workspace across a good VPN connection is terrible. OBM is virtually impossible to use across a VPN.

interesting twist.

so you have all the same configurationsetup.cfgs on all machines pointing to the same workspacesetup,cfg. on the local machine.

But inside the workspacesetup.cfg varies from machine to machine depending on where you need to direct that machine for its organization, workspace and workset.

and since the workspacesetup.cfg can only look at one place at a time, you change this on the fly based on a prechoice from the user ? where are they making this choice (office server they want to use) ? 

if my above statement is correct and this is how you are processing your configurations, I did have another question come to mind.

how do you handle the different versions (on one machine) all looking at the same workspacesetup.cfg - which would be pointing them all to the same organization, workspaces and worksets ?

I am currently in discussions (internally) on how to manage the various versions of client data as well as software being used.

if my above statement is correct and this is how you are processing your configurations, I did have another question come to mind.

how do you handle the different versions (on one machine) all looking at the same workspacesetup.cfg - which would be pointing them all to the same organization, workspaces and worksets ?

I am currently in discussions (internally) on how to manage the various versions of client data as well as software being used.

# 10.11 R1
%if $(_USTN_PRODUCT_FULLMARKETINGNAME) == "OpenRoads Designer CE - 2022 Release 1"
    %error You are using $(_USTN_PRODUCT_FULLMARKETINGNAME)
# 10.10 R2
%elif $(_USTN_PRODUCT_FULLMARKETINGNAME) == "OpenRoads Designer CE - 2021 Release 2"
    %echo You are using $(_USTN_PRODUCT_FULLMARKETINGNAME)
# 10.10 R1
%elif $(_USTN_PRODUCT_FULLMARKETINGNAME) == "OpenRoads Designer CE - 2021 Release 1"
    %echo You are using $(_USTN_PRODUCT_FULLMARKETINGNAME)
# 10.09
%elif $(_USTN_PRODUCT_FULLMARKETINGNAME) == "OpenRoads Designer - 2020 Release 3"
    %error You are using $(_USTN_PRODUCT_FULLMARKETINGNAME)
# 10.08
%elif $(_USTN_PRODUCT_FULLMARKETINGNAME) == "OpenRoads Designer - 2020 Release 2"
    %error You are using $(_USTN_PRODUCT_FULLMARKETINGNAME)
%endif

Tim Hickman said:

how do you handle the different versions (on one machine) all looking at the same workspacesetup.cfg - which would be pointing them all to the same organization, workspaces and worksets ?

This shouldn't be too much of a problem any more with ORD. Since ORD 10.9, 10.10, and 10.11 are in different locations. We keep different configurations for each release then point each version to its respective location.

Even for the WorkSets. We separate WorkSet cfg's by version so that only the projects for that version are available for selection.

Throwing MicroStation into the mix, the U17 release with the Configuration Manager helps resolve launching different WorkSpace locations from a single version of MicroStation.

@svancleave - yes I have looked at those variables along with the "version" ones (version ones not reliable)

@Rod - yes I have looked at doing this as well

was just curious on how Kevin was doing it ?

we have some clients with different versions of standards as well as different versions of the software (different projects of course) - so I cant neccessarily base things on client.

maybe I am just over thinking....

Most of the version specific stuff comes from our client workspaces so I put version detection in at that level. Our corporate level doesn't really have version specific stuff, but I do have some stuff I only load for OpenRoads and I just handle that with:

%if $(_ENGINENAME) == "OpenRoadsDesigner"

or
%if exists($(_USTN_ORGANIZATION)$(_ENGINENAME)/)

My WorkSpaceSetup.cfg does configure a number of variables I can use for more detailed version detection:

#-----------------------
# Product Version
#-----------------------
%if defined(_USTN_PRODUCT_VERSION_GENERATION)
	__PRODUCT_VERSION_MAJOR = $(_USTN_PRODUCT_VERSION_GENERATION).$(_USTN_PRODUCT_VERSION_MAJOR)
	__PRODUCT_VERSION_MINOR = $(__PRODUCT_VERSION_MAJOR).$(_USTN_PRODUCT_VERSION_MINOR)
	__PRODUCT_VERSION_FULL  = $(__PRODUCT_VERSION_MINOR).$(_USTN_PRODUCT_VERSION_BUILD)
%else
	# Get version info from registry using PRODUCTCODEGUID
	__REG_VERSION = ${registryread{"HKEY_CLASSES_ROOT\Installer\Dependencies\${MS_PRODUCTCODEGUID}\Version"}}
	# Versions read from the registry end in a \ and the last version number is 3 digits long
	# The \ in the version can be treated as a directory path. (But append a \ to the front for it to work)
	# THe . in the version can be treated as a file extension.
	__PRODUCT_VERSION_FULL  = lastdirpiece (\$(__REG_VERSION))          # remove the leading & trailing \
	__PRODUCT_VERSION_MINOR = noext ($(__PRODUCT_VERSION_FULL))         # remove the build number from the full version
	__PRODUCT_VERSION_MAJOR = noext ($(__PRODUCT_VERSION_MINOR))        # remove the minor number from the minor version
%endif
__PRODUCT_NAME = $(_USTN_PRODUCT_NAME)
__ERROR_INFO = [$(COMPUTERNAME), $(USERNAME), $(_USTN_PRODUCT_FULLMARKETINGNAME) $(__PRODUCT_VERSION_FULL)]

# Rendition server account version bypass
%if $(COMPUTERNAME) == "rendsvr1" || $(COMPUTERNAME) == "rendsvr2"
	__VERSION_CHECK_BYPASS = 1
%endif

(sorry about all the double _ that, when testing I wanted them to sort first and never really removed them)

I've never needed the full version number yet, so the fact that one reads a 2 digit build number and one a 3 hasn't come up yet but it's really only an issue with 10.09 ORD/OBM and ProjectWise Managed Workspaces (for some reason the _USTN_PRODUCT_VERSION_* variables don't exist until the product actually launches so only registry reads work in PW managed workspaces). Hopefully that bug gets fixed in PW before I need it.

This allows me to test to specific versions of products in workspaces, instead just on full versions. Example below allows me to allow 3 different products to use a particular workspace throwing an error for anything else. More could be added by copying/pasting that last block of TEST_VER/REMAIN_VER as needed.

#-----------------------
# Version Check
#-----------------------
# Define which versions are allowed to use this workspace.
# Separate different versions with \'s, do not put spaces around \'s
# Version numbers can be the major (xx.xx) or minor (xx.xx.xx) version
__ALLOWED_VERSIONS = MicroStation 10.17\OpenRail Designer 10.10.21\OpenBridge Modeler 10.10.20

# Error message info for user on version mismatch
__ALLOWED_VER_MSG  = MicroStation 10.17, OpenRail Designer 10.10.21, or OpenBridge Modeler 10.10.20

%undef __VERSION_CHECK

__CUR_VERSION_MAJOR = $(__PRODUCT_NAME) $(__PRODUCT_VERSION_MAJOR)
__CUR_VERSION_MINOR = $(__PRODUCT_NAME) $(__PRODUCT_VERSION_MINOR)

%if defined(__VERSION_CHECK_BYPASS)
	__VERSION_CHECK = Pass: Bypass
%else
	TEST_VER   = filename(${__ALLOWED_VERSIONS})
	REMAIN_VER = dir(${__ALLOWED_VERSIONS})
	%if ${TEST_VER} == ${__CUR_VERSION_MAJOR} || ${TEST_VER} == ${__CUR_VERSION_MINOR}
		__VERSION_CHECK = Pass: ${TEST_VER}
	%endif

	TEST_VER   = lastdirpiece(${REMAIN_VER})
	REMAIN_VER = parentdir(${REMAIN_VER})
	%if ${TEST_VER} == ${__CUR_VERSION_MAJOR} || ${TEST_VER} == ${__CUR_VERSION_MINOR}
		__VERSION_CHECK = Pass: ${TEST_VER}
	%endif

	TEST_VER   = lastdirpiece(${REMAIN_VER})
	REMAIN_VER = parentdir(${REMAIN_VER})
	%if ${TEST_VER} == ${__CUR_VERSION_MAJOR} || ${TEST_VER} == ${__CUR_VERSION_MINOR}
		__VERSION_CHECK = Pass: ${TEST_VER}
	%endif
	
	%undef TEST_VER
	%undef REMAIN_VER
%endif

%if !defined(__VERSION_CHECK)
	%error Incorrect product used. Allowed versions: $(__ALLOWED_VER_MSG) $(__ERROR_INFO)
%else
	%undef __CUR_VERSION_MAJOR
	%undef __CUR_VERSION_MINOR
%endif

I can also use those version numbers in folders if I need separate out specific resources:

• # Load resources for ProductName XX.XX.XX
• RESOURCE_DIR = $(_USTN_WORKSPACESTANDARDS)$(_ENGINENAME)_$(__PRODUCT_VERSION_MINOR)/

We don't use Client WorkSpaces as our WorkSpace level, outside of PW it's included in the WorkSet.cfg so it can differ per project. Inside of PW i have individual CSB's I assign at the Customer level (these get applied after Organization level but before WorkSpace level).

My client workspaces are identified by Client name, rough ORD/OBM version and client release date. For example I have both:

• Kansas DOT 10.08 2021-05-18
• Kansas DOT 10.10 2022-08-24

So existing projects already using KDOT's 10.8 can continue doing so until they need to upgrade, and new projects using the 10.10 version can start immediately and not wait for the other projects to upgrade. And when a project does upgrade they just change the %include in the workset, or we apply the new Client CSB to their project