teststand environment and users file location

[PoolMaster]

Windows 10 Pro (64-bit) with TestStand 2016 (64-bit) and menu item Configure::Environment.  TestStand NOT recognizing specified User's Database path inside the environment.

After creating a new environment, the 'StartupCfg.ini' file is included in the files generated within the specified folder.  This INI file contains the entry for indicating the location of the Users Database and has as its default value: UserListPath = ""

After starting SeqEdit.exe using the /env switch pointed to the associated 'tsenv' file, the path to the Users Database setting was changed in the menu item Configure::Station Options:User Manager tab. The 'StartupCfg.ini' file in the 'environment folder' showed the updated, non-default, path defined via the configuration dialog in TestStand.

TestStand was exited and restarted (using the /env switch as indicated previously) and the Login Dialog appeared as usual but the available users were the same as is found launching SeqEdit.exe without the /env switch.  Following this, the 'StartupCfg.ini' file in the environment was checked again and it still had the updated path to the users database.

TestStand WAS NOT using the environment's specified path for the users database.

This use of the 'default' users.ini file in the 'default system cfg' folder when using an

environment, with it's own specified user's database path, to appears to be a bug in the TestStand software.

NOTE: The original 'users.ini' file in the C:\ProgramData>\NI\TS\Cfg was present on the system for the above. As a test, I 'hide' this default user's database file and launched SeqEdit.exe in /env mode, changed the path again, exited TS, then restarted with the /env to find a blank 'users.ini' file was created in the 'C:\ProgramData>\NI\TS\Cfg' path, AND that the Configure Station::User Manager dialog was using the 'default path', still.

If this behavior is by design, it stinks.  Why copy the 'StartupCfg.ini' to the new environment if it will not be utilized?

Thanks in advance.

Dave

[Norbert_B]

Dave,

thanks for sharing your observation. Honestly, i first had to get a grip of what you refer to as in TestStand, user information is not stored in a database, but in the users.ini file. This file is a binary encrypted "standard" ini file format.

I confirm the behavior you observe. The users.ini file is ALWAYS loaded from the original <global> environment, regardless of the environment you are actually using.

This is by design.

That being said, i want to explain why design was chosen to disregard an environment specific users.ini file location:

Security. Imagine a case where some users have limited access rights, but they like to have more rights. If one of them had great knowledge of TestStand, he could create a users.ini including customs user rights for him and use an environment to load that file. The only right necessary required to do so would be "loading a different environment" (which cannot be suspended).

As a result, it would be easy to cancel any user management. Hence, R&D made the conscious decision to exclude specifically users.ini from environments.

There is already the feedback in place that this fact has to be documented in a way more approachable way. Your post indicates the urgency in doing this.

[PoolMaster]

Norbert,

The indicated scenario is certainly plausible but unrealistic.  I just looked at the default users.ini file on my system and other than TS version specific info in plaintext, it's all gibberish.  I suspect NI had a rogue developer that exploited this and now we all suffer for it.

I am sure the general philosophy, historically, is to use a single computer for one deployment, at least until TS2016 included the environment option.

The single Users Database file approach also means that on a system using multiple environments, TestStand (or more specifically, a deployed sequence with its files and 'environment') must share the same Users Database across all 'test procedures' available on that system.

Unless some external, pre-app launch utility is used to manage (e.g. copy/move) one of a selection of User Database files, used for each custom deployment (simple enough to do with a DOS batch file), all users can run all sequences on the computer unless some very specific User Groups are defined for each deployed sequence (annoying to manage at best). This certainly poses its own security problems as well.

In any event, what I was trying to do was manage a Users Database for the company's deployed test computers (users.ini on network drive) while using my 'isolated' development system (using its own environments since I manage 8+ projects with different content in their stationglobals.ini file, test report formats, etc).  I figure I'd just load the 'customized' environment, update user info, and the exit. All without a fuss. As expected, life is not so simple.

Thanks for the response.

Dave

[Norbert_B]

Dave,

while i understand your concern and dislike on that design decision, i want to comment on your remark on "the content of the users.ini is gibberish":

1. It is a binary encoded ini-file format. That means that (even though unlikely to happen) someone could eventually decode the file, change it and re-encode it. But the next point is what i was originally thinking of

2. You could use TS on another machine, create a users.ini file matching your "needs" and copy it to the environment location on the computer you want to 'infiltrate'. Restart TS with that environment and all is done

Keeping the users.ini limited to the ProgramData directory in the first instance doesn't necessarily prevent point 2. However, it is easier to manage write access to that one folder rather than to multiple, arbitrary folders.

As said initially: You can like or dislike that design decision. However, current implementation is as stated and allows no other options.

If you consider that security considerations are minor to the benefit of that feature, please file a feature request in the TestStand Idea Exchange forum.

[Vaaben]

I hate to bring up a ½ year old post - but fell it is needed:

The current implementation with NOT being able to locate the users.ini file in the environment is not useable / acceptable for us as we work on multiple projects each needing their own users.ini file - and it would be a hassle if we need to implement a wrapper around teststand that at start copies in the users.ini file from our environment, then start teststand and after teststand ends or at each update to the users.ini file, then copies it back from the default location to our environment location.

It would be workable if it is possible to programmatically load / refresh the users.ini doing startup in our process model - but I don't want to create all users from scratch programmatically

[hugo_fr]

Hi,

A simple workaround for multiple projects management with environment AND differents Users.ini :

[MattyTE]

This deserves so many more Kudos, and marked as the solution to the problem! Thank you hugo!