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

Apparently, just including this directory at the network level is not enough. Not surprising, because I haven't seen anything to redirect to it...

I would like to include some organizational standards (at the network level because I don't plan on doing anything more on the local level than I have to) but I'm not certain how to accomplish that without jumping ahead of system files or redirecting incorrectly.

What would be the best way to do this? I could add an %include somewhere, but at what level would I do that? Before Workspace? During Workspace? Add something to ConfigurationSetup.cfg or WorkSpaceSetup.cfg?

  • 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) ? 

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • 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.

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • # 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
    to keep some projects from getting their files upgraded by a newer product or read only dialog by an older product by mistake may be you could add this at the Workset cfg level. Not sure if the _USTN_PRODUCT_FULLMARKETINGNAME is in every product. Might have to query a lot

  • 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.

    Rod Wing
    Senior Systems Analyst