2X published app can't write temp file

[EJohnston]

We are currently trying out 2x Application Server with our Windows TS. The main purpose for using the Application Server is to publish the client for our ERP application.

The application creates temporary files in a folder when it prints reports. The folder is under C:\OpenEdge\wrk on the terminal server where the application is running. For some reason, it cannot create the temp file it needs to print the report when using the 2x Client.

I've tested this using the same TS login with running the application logged into the TS with Remote Desktop in Windows, and with running the application using the 2x Client.

It is able to create the file without issues with Remote Desktop, but gives and error stating it cannot create the file when using the 2x Client.

Could there be some reason that the application is getting confused finding the path, or for whatever reason doesn't recognize that the user does have write permissions for that folder?

We're currently at a loss. Any ideas on what else we could try? Any help is greatly appreciated.

 

[nixu]

Using Microsoft's TS client go the program's tab and enter the ERP application details.

Log on to a TS and try to print.

Does this work??

nixu

 

[EJohnston]

I figured it out after reading nixu's reply. For anyone else that has a similar issue, this is what happened:

I had originally just dragged the shortcut for the application over to the publish area in the 2x Console and that resulted in the correct settings for the target and start in fields.

The application does require a mapped drive, so I created a batch file that ensures the drive is mapped prior to launching the application.

After that, I changed the target using the browse (elipsis) button next to target in the 2x Console. It started the path with %SystemRoot% instead of C:\ in both the target and start in fields.

After changing %SystemRoot% back to C:\ and changing the start in field back to what it was from the original application shortcut, it works as expected. I just missed that it used the environment variable when I browsed for the batch file.

So the problem is solved. Thanks for the reply Nixu!