ORD/CONNECT One User Preference across multiple workspaces?

i'm back onto setting up my ORD workspaces for clients.

I plan to use the default location for userpreferences to simplify things. This will require me to lock down a few variables in our Organization configuration.

My question is, is there any HARM in using the same user preferences for multiple clients? As far as I can tell, user preferences are personal preferences, and shouldn't really be dependent on client setup, but I'm not certain about that. Some of the clients have user preference seeds, some of them do not. Can you think of anything in

MS_DOCKINGPREF = $(_USTN_PREFNAMEBASE).docking.xml
MS_GROUPPANELPREF = $(_USTN_PREFNAMEBASE).GroupPanels.xml
MS_SAVEMENU = $(_USTN_PREFNAMEBASE).Attached.men
MS_RIBBONPREFS = $(_USTN_PREFNAMEBASE).RibbonState.xml
MS_FKEYMNU = $(_USTN_PREFNAMEBASE).funckey.mnu
MS_USERPREF = $(_USTN_PREFNAMEBASE).upf

that would be essential to functioning in a specific client environment?

_USTN_PREFNAMEBASE does vary from client to client. I believe that is what I would need to lock down. Either that, or _USTN_HOMEPREFS...

I plan to %lock _USTN_USERNAME = $(USERNAME)

Can you think of anything wrong with this?
If I need to allow for separate preferences for each client, I can do that, but it would be cleaner and neater if I could just go around that.

  • Mostly 2 reasons for us (or maybe me):

    1. The default location of the paths are deep, walking a user through going to that folder to do something is prone to mistakes.
      1. For ORD/OBM/OpenRail figuring out which of the 10.0.0, 10.0.0_1, 10.0.0_2 folders has their actual preferences is a super pain.*
    2. Backups. Nothing upsets a user like losing their function key menus or custom ribbon (this was one of the reason I stopped using our client file paths/seed files. It would reset the function key menu everytime they switched clients).

    * - the user preference folders 10.0.0* are created at first open, so if you open ORD 10.10 then 10.09 then 10.11 your preferences will be:

    • 10.0.0 - ORD 10.10
    • 10.0.0_1 - ORD 10.09
    • 10.0.0_2 - ORD 10.11

    The only way to tell which one is memorizing the names of the dirsig_ files ORD creates to mark the version using that folder or opening the dirsig file to see what path is in it. The DirectoryExplanation.txt also shows which ORD it's for.

    I'm hoping OneDrive will give us an easier way for users to find the preference files easier, and OneDrive will handle the backups and user's can restore their own files. Additionally the files will follow them to a new computer when we swap them out (although with my system they'll have to copy or rename them to the new computer name when they do).

    I got burned way back in MicroStation J with putting user preference files on a network drive so I've never done that again, but i definitely have always moved them to an easier to find & maintain location.

     

  • Usually because we either want things on our network so they are backed up, or we want them to "roam" if our users use more than one computer. Not to mention, the more files we can manage from the network, the fewer times we need access to any user's computer.

    MaryB

    Power GeoPak 08.11.09.918
    Power InRoads 08.11.09.918
    OpenRoads Designer 2021 R2

        

  • @Rod - correct.So there is still a local file.

    I do not understand why so many people want to mess with the prefs folder and files ?

    any time I have every dealt with a preference having issues is when they move them. 

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • Yes. I'm debating adding a %include to the Personal.ucf (all of them) that will include a UCF from OneDrive, but we rarely need to add things to the ucf, our more typical usage is to clean everything out of the UCF to fix issues rather than adding things. The %include wouldn't fix that.

     

  • It has to be. There is no way to rename or repath that file.

    It is locked internally by MicroStation.

    Rod Wing
    Senior Systems Analyst