user pref file

Hi,

how to make my personal.ucf is written in the same directory as my personal...UPF (on the network)

I've created:

_USTN_HOMEROOT                     =     $(_USTN_ORGANIZATION)USERS/$(USERNAME)/$(computername)/

_USTN_LocalUserAppDataPath         =  $(_USTN_HOMEROOT)/

but still the personal.ucf is written to:

C:\.....\AppData\Local\Bentley\OpenBuildingsDesigner\10.0.0\prefs  (on the computer where OBD is installed)

what other variable do I have to change too

regards,

Rik

Parents
  • You should find that it is possible to relocate the UCF in Update 5 (this was a platform change first available in MicroStation). I have not checked this in OpenBuildings Designer yet but will do so soon. Previously every file other than the UCF could be relocated.

    Note that we continue to recommend that user preferences are always stored on the local drive, using IT system functions to enable roaming.

    Regards

    Marc

  • Hi, Marc

    We in the company all store the preferences on the server, as we use different machines for drawing it is interesting to store the settings in one directory on the server. So if we change machine, we can save a copy of the preference directory. It is important to have a separate directory per machine because versions or preferences can be different from one machine to an other. 

  • Rik,

    It looks like OneDrive has potential to be a solution for roaming user prefs, this works in my initial teat at least, needs some more research to check for unforeseen consequences before firming up on it though:

    _USTN_HOMEROOT = $(OneDriveCommercial)/OBD_User/

    OneDriveCommercial is a Windows environment variable that points to the OneDrive for Business root folder; OneDriveConsumer points to the consumer root folder.

    There may be a 'gotcha' if OneDrive file sync clashes with MicroStation file locking so slightly wary of this at the moment.

    Credit to Kevin van Haaren for pointing out these variables over in the Product Administration Forum.

    Regards

    Marc

  • I can confirm this works, I have stored prefs and workspaces on google drive and OneDrive for the last few years. You may find the odd file sync issue but generally nothing to worry about. 

  • Marc, will we get back to a stage where we can just redefine the variable rather than having to undefine it first? All we asked for during the beta testing, when this was first raised, was that we have this changed back to what we had before.

    Thanks,



  • Marc,

    I have seen the same issue and no longer store user files on the network. This has been seen even on quicker networks.

    What we prefer to do is have all users files in a single custom location.

    C:\Apps\Users\$(username)

    We also use the location to install all software packages. The reason for this is that IT lock down the Program Files (etc) location and we need to copy a text file into the Appl directory.

    What we then do is each time the hta application we use is closed, it copies the user files to the network. If a user swaps machines and they already have existing user files then they are copied down to the machines. If they are a new user, then they get a fresh copy of all files.

    Thanks,



  • Sean,

    The configuration sequence is such that _USTN_USERCFG is defined early on in the system configuration files. We have been maximising the separation between system and user editable CFGs so that all user configuration takes place after "C:\ProgramData\Bentley\OpenBuildings CONNECT Edition\Configuration\ConfigurationSetup.cfg", this is why the %undef is required.

    There are ongoing discussions on this topic but I doubt if we will see significant change in the immediate future. Any changes that we make to the initial start up system CFGs, msconfig.cfg for instance, have to work with all of the other applications based on the (MicroStation) Power Platform so cannot be made lightly.

    Regards

    Marc

Reply
  • Sean,

    The configuration sequence is such that _USTN_USERCFG is defined early on in the system configuration files. We have been maximising the separation between system and user editable CFGs so that all user configuration takes place after "C:\ProgramData\Bentley\OpenBuildings CONNECT Edition\Configuration\ConfigurationSetup.cfg", this is why the %undef is required.

    There are ongoing discussions on this topic but I doubt if we will see significant change in the immediate future. Any changes that we make to the initial start up system CFGs, msconfig.cfg for instance, have to work with all of the other applications based on the (MicroStation) Power Platform so cannot be made lightly.

    Regards

    Marc

Children
  • Marc, in the past the ucf location was set, but we could always change it at other levels. I agree that there are issues with what a user can change, but IMO this one is the least of the problems and one more the domain of the admins. Now the config is locked, not ideal, but at least it can be undefined. 

    The whole reason I use the cascaded cfg's is to keep users from being able to make changes. I can set variables at any level (company, site, project.client) and then lock them before the users can do any damage.



  • Sean, I'm completely with you on this.

    The previous situation was that this config could be redefined by modifying mslocal.cfg or other files in the system folders. This required good understanding of the configuration syntax and often complex use of that syntax. A large portion of our user base lacks that understanding or has not interest in learning it so we are working towards user-friendly solutions while doing our best to ensure that the more complex environments and knowledgeable people like you are still able to tune and protect their systems.

    One of the objectives of the CE configuration changes is to have a clear distinction between what is installed with the application which should be left alone and the user's configuration that can be customised as required and protected appropriately. In terms of your approach essentially what has changed is the point at which your hta files start to take effect.

    Regards

    Marc