Deploying TestStand with and Environment File

[Jorr-El]

TestStand Version: 2020 (64-bit)

OS: Windows 10

I am trying to create a deployment in TestStand 2020 and use an environment file in the deployment. When I go to the "Distributed Files" tab, the Deployment utility asks if I want to "Analyze Source Files". When I do, the build fails and I get this error:

Error -18360 occurred at Exception occured in TSAPI: Changing environments requires the ConfigEngine privilege.
in Set Active Environment - TestStand.vi->Analyze - Initialize.vi->Update File Info - TestStand.vi->Analyze - TestStand.vi->Distribution Wizard GUI - TestStand.vi->Deployment Utility Splash Screen - TestStand.vi

The TS Sequence Editor has already been switched over to the environment file I'm trying to deploy with the deployment utility. I am logged in as an administrator into TestStand. I have checked my users.ini file in the Sequence Editor and on-disk, and the administrator user has the "ConfigEngine" privilege granted to it. I need to know how I can either make the Deployment utility switch environments or how to make sure the Deployment utility recognizes that I do have the "ConfigEngine" privilege. Kind of seems like a bug at this point because I can't make a deployment with any .tsenv files at the moment.

Anyone have any success making a deployment with a .tsenv file?

[James_Grey]

As a workaround, have you tried unsetting Station Options>>User Manager>>Check User Privileges?

[Jorr-El]

Thanks for the response James_Grey.

I just tried what you suggested, but unfortunately I got the same error

I also restarted TestStand to make sure the change in configuration took, but I got the same error again when trying to deploy.

Could someone else try to quickly make a custom .tsenv file and make a deployment? I'm finding I am unable to make a deployment even when the "custom" .tsenv file has essentially no changes from the global environment.

[Jorr-El · Accepted solution]

I got it working. I saw a thread (linked below) from TestStand 3.5 that said I needed to completely uninstall TestStand and reinstall in order to fix the issue. What I did was:

1. Uninstall TestStand
2. Go through ProgramData, Program Files, AppData, Public Documents on my computer and delete everything left over by TestStand
3. Install TestStand
4. Repair the install of TestStand

Now it works.

https://forums.ni.com/t5/NI-TestStand/Why-do-I-a-18360-error-in-teststand-3-0/m-p/1753710/highlight/...

Seems like what Doug (dug9000) explained may have been the cause, as I had been working on customizing the login/logout behavior of TestStand with a custom OI I was building, but if that's the case then I feel like that's a pretty significant bug:

If ApplicationMgr.LoginOnStart == FALSE, the TestStand Deployment Utility can't authenticate and fails to switch environments for an environment deployment.

[Jorr-El]

I actually just tested it out. I changed the property for ApplicationMgr.LoginOnStart == FALSE and tried the deployment again, and I got the same error. 

After encountering this error, I was not able to get it to go away again, even if I set the property back to TRUE.

For more detail, I am using Property Nodes in a LabVIEW Custom OI to set the following properties:

Engine.StationOptions.RequireUserLogin = TRUE

ApplicationMgr.LoginOnStart = FALSE

After doing these two calls, it appears that the TestStand Deployment Utility becomes unusable to create a deployment with a TestStand Environment File. Even if I reverse the LoginOnStart variable to TRUE, I still encounter the same error using the Deployment Utility

[Jorr-El]

I have an open service request with NI about this, and they've been able to reproduce this problem on their end. Apparently calling the TestStand API from a LabVIEW Custom Operator Interface to disable LoginOnStart and setting RequireUserLogin causes the Deployment Utility to irreversibly break when trying to deploy from environment files.

This bug does not exist in TestStand 2021 64-bit working with LabVIEW 2021 64-bit, so I will be just upgrading our versions of TestStand and LabVIEW to avoid the issue.

Not sure whether or not NI R&D is going to address this bug in TestStand 2020 or not, but that's up to them and what their priorities are, and since it's not happening in TestStand 2021, it might not make it very high up the priority list.

[Jorr-El]

I upgraded to LabVIEW 2021 SP1 (64-bit) and TestStand 2021 SP1 (64-bit) and the issue is not resolved. I still get the same exact behavior and error when trying to run the TestStand deployment utility after trying to run a custom OI.

Seems like a rather significant bug if making an API call to TestStand completely borks the TestStand Deployment Utility.

[Jorr-El · Accepted solution]

NI Support got back to me. A bug has been filed with NI R&D for this issue:

Bug #2186839

---

Workaround:
I deleted the API calls from my custom OI code that did two things:

1. I had a VI that used the TestStand Engine reference to call the Engine.StationOptions property and set "RequireUserLogin" to TRUE. I deleted this VI from my code entirely 
1.  
2. Inside of configureApplicationManager.vi, I deleted the property node call on the Application Manager that set "LoginOnStart" to FALSE
1. 
3. After doing this, my custom OI code no longer breaks the TestStand Deployment Utility. What's strange is that if you try to change the ApplicationMgr.LoginOnStart back to TRUE and run the code again, it doesn't fix the behavior of the Deployment Utility. Once the Deployment Utility is broken, it stays broken.

[vishal_s]

When Engine.StationOptions.RequireUserLogin = TRUE and ApplicationMgr.LoginOnStart = FALSE, TSDU can't force the user to login unlike in SeqEditor or a UI, so essentially there is no active user. This is what prevents the specified environment from loading. Loading an environment checks if the active user has the required permissions to do it.

TSDU also can't update any configuration changes being done in another instance of the TS engine. TSDU needs to be restarted for changes to reflect. This is why changes to the options (API calls) does not reflect in TSDU unless it is restarted.

Thus workaround after TSDU gets into a state where it can't load an environment, is to revert the option values and then restart TSDU.