I know I've posted about this before, but I'd like to go over and discuss my situation once again. Some things I understand a bit better, whlie I still have questions about others.
I reproduced the "Configuration" directory structure on our network, using ConfigurationSetup.cfg and WorkSpaceSetup.cfg to redirect to that network drive. That seems to work well enough.
Our projects are stored on a Projects Drive, organized by project year, then project number, basically like this:
ORD/Connect configuration does NOT like this arrangement out of the box.
After a certain amount of trial and error for creating workspaces and worksets, I settled onto workspaces based on Project year and worksets by project number, with the workset CFG %include-ing the client standards configuration. Workspaces and worksets, including the workset CFG and the DGNWS, are saved into the network "Configuration" directory. Actual project CAD data is stored in the regular project directory as always. I developed a "front-end" VB .exe to gather project year, number and client to generate the workset CFG. The DGNWS is created from the client seed DGNWS when the project is first opened.
It's not the most robust solution, but it appears to be functioning.
We have a new employee who is very experienced with ORD, in terms of training and teaching. I'm not certain how deep her practical, project knowledge goes. She has told me that my approach is entirely wrong, and that we need to load all client configurations directly onto everyone's hard drive. She has also brought up concerns that, with my workspace approach, we will not be able to make full use of the DGNWS and will be missing out on a lot of useful features. Apparently the way around that is to move all of our CAD project files into the networked "Configuration" directory structure as worksets - out of the regular project directories. I brought up that we may not want to blow up the entire company way of storing project data, and she suggested that we just tell them that this is how it was going to have to be with OpenRoads.
I am willing to consider that I am overlooking some aspects of ORD setup with my ham-handed attempt to force it work with our existing directory structure. I'm sure I am not considering some advanced functionality that we could leverage for production. But I'm not convinced that we need to dictate how the entire company stores data just for the transportation department, and I'm equally unconvinced that our transportation projects need to have a different storage arrangement than every other project.
We are not using, and not (at this point) planning to use ProjectWise.
How do you all store your project data? Do you store DGN files in your ORD configuration, or does your company have a networked project repository? How do you account for that in your configuration, workspaces and worksets? I can see directing the worksets directory to the project drive to get it out from the Configuration directory (ensuring DGNWS write-access) but I don't think we could store the worksets with the actual project directories because defining configuration files to find them sounds impossible.
How do you manage locally stored client configurations? Are your users expected to keep them updated or does your IT department cooperate with you to "push" updated resources?
While the DGNWS sounds minorly useful, what features make it essential to project production? I know it can be used to fill out title blocks and create print sets, but is there anything else that we HAVE to have it for? And does it HAVE to be all defined on creation, or can properties be added to it after it is created. I know that you can't update it once it's in use, but could it be created from a seed file and then updated with the appropriate properties prior to project sheet creation? I don't know what I don't know, and I'll admit, I don't really understand why the DGNWS is so critical.
Are there other ways I could simplify or rework my configuration plan to work better with the Bentley preferences AND our corporate data structure?Thank you.
If you have your configuration up and running, then your co-worker cannot say it is wrong. It is just not how she thinks it should work. Did she state why the configuration needed to be on the local machines, rather than on your network ? I have witnessed our networked configuration cause considerable slowness, but this is mainly due to the network and not really the configuration. In any case there are specific offices where we have them set up locally.
Now for the DGNWS file, there needs to be read/write access if you plan on using it fully. A few variables that will help locate it with the other project data accessed by your users are: _USTN_WORKSETDGNWS, _USTN_WORKSETDGNWSTEMPLATE, and _USTN_WORKSETDGNWSROOT
Timothy Hickman
CADD Manager | CADD Department
timothy.hickman@colliersengineering.com
Main: 877 627 3772|
1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691
She comes from working at Bentley, so she is very staunch about doing things the Bentley way. I don't know how much practical experience she has in the production world. The Bentley way is great for what it is, but the real world is much messier and rarely ideal.
I don't know why she would insist that configurations be local, other than that's the Bentley way, and it requires no network administration.
Her approach is to use the Bentley way so that MicroStation/ORD sets everything up. That way, anyone can create a workset and it will work with no additional effort. That's commendable, but I can see that moment where someone makes a "new" workset for a project that already exists...Our regular (corporate) project creation is really strictly locked down, and I can't help but think that workset creation should be as well, at least a little bit.
I just worry that I am being too rigid and inflexible, thinking that I have the only solution. Maybe I am. And my solution isn't super robust, so I know I still have bugs to work out (I have trouble closing a drawing, then selecting another workspace to do something else). I'm a cranky old lady now But I don't want to upend our project directory structure if we don't have to, and I think we don't have to.
I guess part of the point of this post is to hear how other people are doing things, and to get some confirmation that, while this might be unusual, it's not WRONG.
MaryB
Power GeoPak 08.11.09.918Power InRoads 08.11.09.918OpenRoads Designer 2021 R2
Whenever someone says that you "...need to load all client configurations directly onto everyone's hard drive" (emphasis added) all credibility is lost.
There is always one more thing we can do to make our workspaces more efficient and flexibility but putting dozens (or hundreds?) of copies on individual computers is not one of them.
Here's my philosophy for these things.
As for your question about how do we manage workspaces. Some highlights of my preferences:
From your description, you are structured much like I prefer except for using the year for workspace. This is not wrong if it works albeit a little unorthodox. The use of include statements would make a bit nervous because they are somewhat notorious for allowing load order to get out of control.
Robert Garrett Senior Consultant
www.envisioncad.com
Robert:
As usual, I agree with every single thing you have mentioned here (mainly because we have done the same, although we are still carrying around the empty bag, LOL).
Best Regards,
Mark
Mary:
Robert's initial statement could not be more true, and in further reviewing your issues here, I really perceive that you have no real issues. The notion that every machine must include the client installation is absurd to me.
In our case, we have modified the MY_CIVIL_ORGANIZATION_ROOT variable in the WorkSpaceSetup.cfg (C:\ProgramData\Bentley\OpenRoads Designer CE 10.XX\Configuration) file to point to a network location for our workspace: G:\MICROSTATION\OPENROADS_DESIGNER_2022_R3\Configuration\Organization-Civil\.
Then we have defined the MY_WORKSPACES_LOCATION in that same file to point to G:\MICROSTATION\OPENROADS_DESIGNER_2022_R3\Configuration\Workspaces\.
You can readily note that Configuration\Organization-Civil and Configuration\WorkSpaces are merely clones of the default installer locations, now moved to a location on our G:\ partition.
So, a couple of changes to a single file found on the machines of all users is all that you need to make OpenRoads work just fine. Such changes can easily be automated for updates to the software. It seems to me- based upon your narrative- that you have done something similar. There is absolutely no reason to "upend" any of your network locations for OpenRoads to work the way that it should (and in any location you desire). Now,- as regards WorkSets- we have defined some custom pathing and parameters in these here. I can send you a copy of our default WorkSet template if you would like. By setting configuration overrides/ variables at the WorkSet level, we are able to use the "factory" _Civil Default Standards file as the software updates.
As regards the notion that "anyone can create a WorkSet", such an idea terrifies me personally. You are correct that WorkSpaces and WorkSets should be "locked down". There is a variable- MS_CONFIGURATIONOPTS- which can help with that issue; however, in current testing, it does not seem to respond properly (I know that at one time it worked just fine). Robert, do you know anything about this situation?
the funny thing about setting the CONFIGURATIONOPTS - your powerusers (at least the ones I have known) can simply create what they need outside the workpage interface. So you are merely stopping the junior users from creation....
also - there are a few DOTs that rely heavily on %include statements so you leveraging them is not out of the ordinary.