user pref file

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.

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. 

Marc, can you confirm that the ability to set paths for all user files has been reinstated? This was an issue raised way back in beta testing. While we do run our files locally, we store them in a custom location that we have access to (don't you love It groups). With the use of our hta files in the build, each time you close the hta files the users files are then copied to the network. Gives us access to them and still gives users the ability to have their user files follow them to different machines.

Thanks,

HI Sean,

Yes, I can confirm that. There is some concern internally that we may see problems caused by UPFs being messed up by slow networks or other causes hence our continuing recommendation.

Please could you share more details about your solution with us?

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.

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, 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,

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.

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.