Launching Solid Edge KeyShot (And Other Applications) In Remote Desktop Connection (RDC) Session
Recently user @KevinAlexander asked in the Solid Edge Community about an issue he was facing with trying to run Solid Edge KeyShot through a Remote Desktop Connection (RDC) session…
This is actually working as designed and is because of a limitation with the RDC protocol. However, this got me to wondering if it was possible to apply some hackery to get around this limitation. As it turns out, yes, it is possible to bypass this limitation and get KeyShot to launch through an RDC session. Still interested? Then read on…
TL;DR & Geek Alert! It has been a while since I have written a technical blog post for the Community. I spend some of your time in this article walking you through how to actually identify and put together the final working solution. By giving you the thought process to the final solution this many then inspire you to come up with your own more refined solution to this issue. If you do not care about the geek stuff simply jump to the end of this article to get a final solution.
According to Wikipedia…
Open Graphics Library (OpenGL) is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. The API is typically used to interact with a graphics processing unit (GPU), to achieve hardware-accelerated rendering.
KeyShot as a 3D vector graphics rendering application requires OpenGL 2.0 or higher to be able to successfully display the graphics data generated by the KeyShot program.
Workstations with professional grade graphics cards installed will have OpenGL installed by the graphics card vendor as part of that professional graphics card driver software installation. OpenGL 2.0 dates back to 2004 so it is a fairly safe bet that most graphics cards/workstations in use today will have OpenGL 2.0 or higher installed by default.
This is why when working locally with KeyShot you do not have any issues because OpenGL 2.0 or higher must obviously be installed. We can verify the version of OpenGL running locally by using one of several different free utilities. Once such utility is GPU Caps Viewer. On my system, running locally we can see that I have OpenGL 4.3 running:
So why if we clearly have a version of OpenGL higher than the KeyShot minimum prerequisite of 2.0 installed does KeyShot not run in an RDC session?
Whenever you run an RDC session, you are connecting to the remote system using the display resources of the RDC application on your local system running RDC not the display resources of the remote system you are accessing. Unfortunately, the Microsoft RDC protocol does not support OpenGL above version 1.1. We can verify this by connecting remotely to the same system and check the OpenGL version in use when running remotely. In our working example, we can see that for the exact same system when connected through RDC, that the OpenGL version in use is now 1.1:
Whenever KeyShot is started, there are some prerequisite checks made, including the version of OpenGL running. As we have already determined that RDC only supports OpenGL 1.1 this is why KeyShot throws the error “KeyShot requires OpenGL 2.0 but (1.1.0) was found!”:
So is it possible to avoid this limitation of RDC only supporting OpenGL 1.1 and create some workaround to allow us to run and use KeyShot through a RDC session?
Actually, there are two workarounds to allow us to run KeyShot through an RDC session.
The first, and easiest workaround, is when being in the office and logged in to the physical machine start KeyShot and then leave it running. When you then go home (or to whatever offsite location) and then remote in, because KeyShot is already running, the OpenGL checks have already been passed and you can continue to work with KeyShot through RDC.
However, this solution is only practical if you can remember to first start KeyShot and leave it running before going offsite. How can you physically start KeyShot through an RDC session if you do not already have KeyShot running?
Well, it is actually possible to fake out the RDC session and run commands remotely as if those commands had been run from the physical machine. We do this by disconnecting our RDC session and connecting our running desktop back to the physical resources.
In order to connect our running Windows session to the physical resources we must first determine the current running session id number for our Windows session. There are several ways to determine this session number. For this example, we will use the command “tasklist.exe”. According to the tasklist.exe help…
This tool displays a list of currently running processes on either a local or remote machine.
Open a Command Prompt window, enter, and run the command tasklist.exe:
Depending on the active processes running this command can generate a lot of output. If you scroll to the bottom of the list and locate the tasklist.exe process you can then see the session number that we are currently running the Windows desktop under through the RDC session. In our example we can see that the session id is 1:
Note: do not assume that the session id will always be 1. It can and will differ for many reasons.
So now that we have determined our running session number, how does this then help us solve our actual problem? Well, we can now use this session number to disconnect our RDC session and connect it back to the physical hardware on the remote workstation.
So how do we connect our RDC session back to the physical machine? By using the command “tscon.exe”. According to the tscon.exe help…
Attaches a user session to a remote desktop session.
Open a Command Prompt window, enter and run following command line tscon.exe 1 /dest:console where the “1” is the session id we had determined in the earlier steps:
As soon as we run this command, our RDC session is automatically disconnected and we are informed of this:
If we then RDC back in to our desktop, however, nothing appears to have changed after having run this command. The RDC session is still running OpenGL 1.1:
So how are all of these steps actually useful in resolving our issue? We can now combine these individual commands in to a single DOS batch script that will then perform all of the following steps automatically for us in the RDC session:
- Determine the current RDC session id number.
- Disconnect our RDC session and connect the running desktop back to the physical hardware.
- While the running desktop is connected to the physical hardware, then start KeyShot.
In the remote system, In a text editor, create a new text file with the .cmd extension. In our example below, we have created the file Run_KeyShot_Remote.cmd:
In this script place the following three lines of commands with each command on a separate line. For the last line you must specify the full location of the KeyShot executable as located on your system. Also remember to enclose your KeyShot command line within quotes:
for /f “tokens=4 delims= ” %%i in (‘tasklist’) do set SessionId=%%i
tscon %SessionId% /dest:console
“C:Program FilesKeyShot7binkeyshot.exe”
Save our batch script file edits and close out the text editor.
Now from our RDC session, run this batch script file by double-clicking on the file from within Windows Explorer:
A DOS command shell will be launched, and our commands will be executed in order, one line at a time. Once the tscon.exe command is executed our RDC session will once again be disconnected. As we have previously demonstrated when using this command earlier, this disconnect is expected behaviour:
As soon as our RDC session is disconnected, the next line of our DOS script to start KeyShot will be run. Because we are no longer running our RDC session and the desktop is currently connected to the physical hardware KeyShot will now run and pass the OpenGL prerequisites check.
Allow a few seconds for KeyShot to start up, then reconnect our RDC session:
We can see that KeyShot has been successfully started and is now physically running in our RDC session even though we still have the limitation of OpenGL 1.1 through the RDC session:
All of this has been made possible by incorporating a few out-of-the-box operating system commands in to a simple DOS script. However, this is an extremely simplified DOS script that has many less than desirable traits to it including visible output of our commands processed, a window that remains open while KeyShot is running, et. al.:
With some extra effort we can beautify this script further to make a much more desirable and presentable end solution. However, the mechanics to build a more robust solution are beyond the scope of this article. To help you with this I have attached a more complete finished script below for your convenience. Note the file extension had to be changed to .txt to avoid being blocked by various security layers.
Simply open this file and save it to the .cmd file extension. To then use, copy the saved .cmd file on to your remote system with KeyShot installed, edit the script to point to your KeyShot executable location, start a RDC session, and then double-click on this script to launch KeyShot from within your RDC session:
The attached DOS script has some more functionality added to it compared to the simpler script shown earlier:
So now that we have determined a way to start KeyShot from a RDC session in such a way that we bypass the KeyShot prerequisite checking when running from RDC, we can now apply this same logic to many other software programs (Solid Edge, cough, cough!) that may otherwise be limited by not running from within a RDC session:
Time for the traditional caveat; YMMV and the details contained within this article are for informational purposes only and this workflow is most definitely not supported by Siemens PLM & GTAC.
Addendum: For whatever annoying reason the Community site is refusing to allow me to upload a .txt file attachment. I am not going to rewrite the article to account for this nor am I going to pursue having the Community Admin address this. You can download the finished script directly from my GitHub site:
https://raw.githubusercontent.com/uk-dave/SolidEdge/master/RunKeyShotRemoteDesktop.cmd
