RSLogix 5k and Remote Desktop

Anyone care to explain how I can do the following:
Connect to engineering station through Windows Remote Desktop.
Use RSLogix 5000 installed on said engineering station.

2 easy steps one would think.
Yet it seems someone at Rockwell wants it to be somewhat more complicated.

Why use this setup:
In-house automation department.
We have IT provided computers with access to internal networks and mail systems. But subject to IT policies. These policies do NOT work well with engineering software.
We have our own computers which contain engineering software, which we manage completely independently.
We connect to these computers through Remote Desktop.

I don't understand the issue you're having.

This is (almost) a lost battle...There might be some hope for the future but does not look too good...
Using Windows services to connect to Rockwell Software PCs is limited to Server Class Operating Systems machines and even this scenario is not a breeze to implement.
The mainstream approach is the use of so called "Remote Control" software such as VNC to remotely connect to Rockwell Software PCs not running Server OSs.

jkerekes said:

I don't understand the issue you're having.

Click to expand...

It kept asking for FactoryTalk activation credentials.
Kept telling me it couldn't log me in.

So logged in to physical machine. Started RSLogix. Used Remote Desktop to take it over, RSLogix still works, but opening additional instance gives activation error and tells me the grace period has started.
Closed both instances, opened a new one, tells me activations is complete.
Tried and tested on second PC just to verify....

Guess this one is solved.... somehow.

When you sit down in front of an ordinary Windows desktop PC, you're called a "console user".

When you log into an ordinary Windows desktop PC using the Remote Desktop service, you're a "Remote Desktop User".

Even when you use the same login credentials, some functionality isn't the same. Try rebooting a PC via Remote Desktop... often you will find out you cannot.

The notorious interaction between Windows Remote Desktop and Rockwell Software used to be the way the RSLinx Service configuration worked. There used to be options in Windows XP remote desktop that would let RSLinx Classic interact properly with a remote desktop.

In your case the problem is FactoryTalk's network or local directory for access to FactoryTalk services like Activation.

I don't know enough details about your particular problem to give advice on how it works or how to improve your experience with it.

I agree, though, that non-Windows remote desktop services like VNC and TeamViewer tend to be the popular workaround.

Jeebs said:

Anyone care to explain how I can do the following:
Connect to engineering station through Windows Remote Desktop.
Use RSLogix 5000 installed on said engineering station.

2 easy steps one would think.
Yet it seems someone at Rockwell wants it to be somewhat more complicated.

Why use this setup:
In-house automation department.
We have IT provided computers with access to internal networks and mail systems. But subject to IT policies. These policies do NOT work well with engineering software.
We have our own computers which contain engineering software, which we manage completely independently.
We connect to these computers through Remote Desktop.

Click to expand...

Try TightVNC.

I like using it when there is a person at the other end so they can see what I am doing.

Works great if there is an operators says they are clicking a button and nothing happens or display doesn't appear correctly.

Saves a lot of time as our work centers are miles apart and on other side of mountain range.

To expand on what Ken said. Tools like Radmin, VNC, Logmein, Team Viewer,etc emaulate a console user login Vs.RDS.

There are many limitations on Remote Desktop Services but more on the Desktop OS like Xp, Vista, Win 7 and Win 8.

If your Rockwell software was installed on a server OS such as Server 2008 R2 or Server 2012 you would likely have a better experience. This is because the Server OS is designed and built to be a terminal server where the desktop OS is not.

dmargineau said:

This is (almost) a lost battle...There might be some hope for the future but does not look too good...
Using Windows services to connect to Rockwell Software PCs is limited to Server Class Operating Systems machines and even this scenario is not a breeze to implement.
The mainstream approach is the use of so called "Remote Control" software such as VNC to remotely connect to Rockwell Software PCs not running Server OSs.

Click to expand...

Sorry but this is false. It's not battle, not even an annoyance, it's a lack of understanding and is quite easy to overcome. I really don't understand why RDS gets such a bad rap.

The OP's issue isn't RDS it's Factory Talk security. For GOOD reason it doesn't allow RSLogix to launch for remote users by default. Setup Factory Talk security to allow remote uses and such and it works quite well. I have had engineers in Spain and Ireland RDP into US based Virtualized Windows XP, and Virtualized Windows 7 environments for RSLogix5000 development and testing. We've done this for 2-3 years now.

Ken Roach said:

...
Even when you use the same login credentials, some functionality isn't the same. Try rebooting a PC via Remote Desktop... often you will find out you cannot.....

Click to expand...

What functionality is missing? While not obvious, simply run "shutdown /r" in the run command to restart. If you want to release your remote session back to the console and 'unlock' it back to the end user rung "tscon.exe 0 /dest:console"

The Plc Kid said:

To expand on what Ken said. Tools like Radmin, VNC, Logmein, Team Viewer,etc emaulate a console user login Vs.RDS.

There are many limitations on Remote Desktop Services but more on the Desktop OS like Xp, Vista, Win 7 and Win 8.

If your Rockwell software was installed on a server OS such as Server 2008 R2 or Server 2012 you would likely have a better experience. This is because the Server OS is designed and built to be a terminal server where the desktop OS is not.

Click to expand...

RDS has treated me well for 8 years now, and even if they move to a Server as a host, it's still a Factory Talk Security issue. In my experience customers with high-level enterprise systems are setting up engineering workstations for remote support, and usually you have to tunnel through multiple RDS sessions to get to the workstation. All for security reasons, no more connecting your work laptop directly to their control networks. Other 3rd party options may not be an option.

It may not solve all of your issues, but I added the machine that I'm logging in from to the "computers" list in FT Admin console, and that got me around the FT asking for a login issue.

See technote #468494

Paully's5.0 said:

Sorry but this is false. It's not battle, not even an annoyance, it's a lack of understanding and is quite easy to overcome. I really don't understand why RDS gets such a bad rap.

The OP's issue isn't RDS it's Factory Talk security. For GOOD reason it doesn't allow RSLogix to launch for remote users by default. Setup Factory Talk security to allow remote uses and such and it works quite well. I have had engineers in Spain and Ireland RDP into US based Virtualized Windows XP, and Virtualized Windows 7 environments for RSLogix5000 development and testing. We've done this for 2-3 years now.



What functionality is missing? While not obvious, simply run "shutdown /r" in the run command to restart. If you want to release your remote session back to the console and 'unlock' it back to the end user rung "tscon.exe 0 /dest:console"



RDS has treated me well for 8 years now, and even if they move to a Server as a host, it's still a Factory Talk Security issue. In my experience customers with high-level enterprise systems are setting up engineering workstations for remote support, and usually you have to tunnel through multiple RDS sessions to get to the workstation. All for security reasons, no more connecting your work laptop directly to their control networks. Other 3rd party options may not be an option.

Click to expand...

You are correct if the OP does not have his FT Security settings correct it would produce this issue. I am not sure if any of the other RDS differences would affect logix 5K on windows desktop OS. I have never ran it that way because RDS performance on Desktop OS sucks compared to Server OS very much so on server 2012.

To anyone who needs something to help you sleep tonight here is a link with some of the differences of RDS when on Server OS 2012 Vs Win 7 https://technet.microsoft.com/en-us/library/dn283323.aspx

I use an uber ASUS laptop and then run GoToMyPC from an iPad (much lighter) and do my IO checkout using that.

The Plc Kid said:

... I have never ran it that way because RDS performance on Desktop OS sucks compared to Server OS very much so on server 2012...

Click to expand...

Certainly won't argue the 'ideal' environment, but depending on what the OP actually needs to do and the resources available RDP in to a desktop OS works w/o issue.

..."For GOOD reason it doesn't allow RSLogix to launch for remote users by default"...

@Paully's5.0

There is no good reason, especially not in caps......You cannot have RDS rights on a PC terminal unless you have domain/windows credentials...Why Rockwell needs BOTH Windows(OS) AND FTDirectory credentials when pushing RDS is something they have never given a straight answer to...I'd understand if AssetCentre is installed, however, when a hundred dollars Remote Control app could "bypass" this type of "security" it is safe to say that this one is there with the likes of pre 6.1 FTV database "masterpiece".

To clarify:

My experience with Rockwell can be counted in days. Using just one hand. From last Tuesday.
Coming from Siemens, the Rockwell world seems alien.
That would explain my ignorance. (well most/part of it )


RSLogix isn't the first to give issues with RDP, won't be the last. Most of the issues are in fact due to opening a new session when logging on through RDP. We've learned long since to use /console (XP) or /admin (Win7) when using mstsc.
Fun fact: while Paully's "tscon 0 /dest:console" is correct, it sometimes won't work because the current logged in user isn't a session 0 user. Usually that user is session 1.

Why use RDP in stead of any of the other solutions out there?
Well RDP is available on every computer with Windows OS.
It resizes the screen automatically.
Resource sharing.
It locks the physical computer.

As an inhouse automation dept, we don't have a need for laptops, unlike most other integrators. We have an office, with desks and desktops.
We have a production environment with at least one computer per production line.
Just about every PLC/HMI are connected to plant-wide Ethernet.
If I need to modify software, I can use one of the production computers, use RDP to gain access to one of the various engineering stations and do whatever I need to do.
Need to show something pertaining PLC/HMI in a meeting? Confiscate the laptop connected to the projector and show them. Has helped in many meetings.
Don't need to carry around a laptop and can still work just as flexible.

As for performance:
Win7 into Win7 has no performance issues at all.
In our case.
Within our own VLAN segment.
VPN from outside ..... well that has some latency, but not more than VNC.

Paully's technote provided what I think is the correct solution as it addresses my problem directly, thanks for that.