6 Basic DOs and DON’Ts of MicroStation Workspaces
At EnvisionCAD we work on a lot of workspaces for our clients across the country. If you are responsible for the administration of MicroStation for an office of 2 users or 200 users, here are just a few DOs and DON’Ts we would like to share with you.
DO define the variables of standard resource files. As a minimum make sure the search paths for Cells, Levels, Linestyles, Seed File and Fonts have all been defined at the Corporate level.
DO NOT edit any configuration files delivered in a standard install. We have seen a lot of customized workspaces that have made edits to a standard file such as msdir.cfg or mslocal.cfg. Instead create a new configuration file that can be copied to a MicroStation config directory and used as the program launches. The new configuration file can start with the letter “z” this will ensure that its read last in the folder. For example “…config\system\zCompanySystem.cfg”
DO define the Workspace System folder back to the local computer. When you define _USTN_WORKSPACEROOT to go to your network drive that also will include the System directory. Add a second variable _USTN_SYSTEMROOT to point the system folder back to your local computer. This will ensure that the correct system files from the installed version of the software are being used. If the system files being used are the wrong versions it can have adverse effects on the program.
DO NOT use your User Configuration File (UCF) to set company standards. I will agree that this is the easiest solution but it is not recommend. Utilize the Standards and Project configuration files and keep the UCF for items that pertain to each user. By layering in the Corporate and Project level you can leverage additional benefits of a managed workspace.
DO create roaming profiles for your users. By default the MicroStation user is stored locally on each computer. Editing a few key variables will enable each user profile to be stored on the server. Each user can then keep their toolbars, preferences, function keys, button assignments, AccuDraw shortcuts etc. accessible. If the user moves to a different computer, office or re-installs the software, the user prefs and settings will not be lost.
DO NOT customize yourself into a corner. Over the years we have seen a number of custom interfaces for MicroStation that have gone too far with the toolbars, tasks, and pull down menus. Recreating an icon that already exists in MicroStation doesn’t make any sense to us. Making such drastic changes to the interface will cause the end user to lose productivity if they ever have to work outside customized workspace. Keep the core MicroStation interface intact, do not try to append inside the standard tools and pul-down menus. Add your new pull-down menus and new tasks outside the standard MicroStation interface.
People also read: 5 Signs You are a MicroStation Dinosaur
Don’t want to miss out on other great information? Subscribe to this blog or our monthly eNewsletter now!
9 Responses to “6 Basic DOs and DON’Ts of MicroStation Workspaces”
Mark Harrington Says:
With respect to the UCF issue, I learned from Bob that to TEST config settings, it is really nice to make the changes thru Workspace….Configuration, which places the settings in your UCF file. Once they are working, just cut them from your UCF file and paste them into the appropriate CFG file! Keeps the changes from adversely affecting unsuspecting users until you’re ready to roll them out.
Pat Coyne Says:
Agreed, these are all useful guidelines. The ‘roaming profile’ is addicting, once you use it you’ll never want to be without!
I would also add to plan for future versions — segregate your configurations by software version including data & resources (cells, dgnlibs, etc). Yes, it adds extra maintenance. Branch off quickly to your version from the start, it’s easier than trying to unravel a ‘mixto-verso’ effect later. It also allows for the graceful de-commissioning of old software versions no longer being used.
Variation on a theme:
At each workstation assign the _USTN_SITE variable via a Windows logon script which brings the workstation right to the server for configuration files. It avoids the need for distributing and maintaining ANY config files on the workstations.
Pat Coyne Says:
Using the _USTN_SITE suggestion above allows easy switch-over to test your configs off-line and thereby not disrupt others workgroup users. It can also make it easy to take your configs mobile on your laptops.
Can you elaborate a bit on the roaming profiles? Which are the key variables needed? Thank you.
Bob Mecham Says:
Marcus, here is a list of the key variables I define to setup roaming profiles.
Dave Akers Says:
What is your suggestion for launching Ustn when you have several different client configs and project configs? I know what I’ve used in the past which works, but I want to see if you have a new improved approach?
Bob Mecham Says:
Hi Dave, I personally use icon shortcuts to launch the different client setups I have on my laptop. I have about 20 client workspaces to keep track of all with multiple disciplines and projects so for me the icon option is the only way to go.
In my previous life as a CAD Manager for an Engineering firm I was using a hidden system config file to kick start the Site Standard / Project workspaces.
More than 3 years now! Still cant able to find a good way to export from DWG to DGN.
I found, that placing the _USTN_HOMEPREFS files on a network space, makes Microstation react less snappier 🙁