Is there any way to prepopulate the session for a particular RDP client. For example HMI-301 should always logon to TSERV3 Session1. Setting up the thin client (Wyse) to connect to TSERV3 is easy but I cannot find a way to setup the session automatically. I do not want to set this up in the reserved list as I need the engineers to have the flexibility of changing it when required.
What I am trying to do is have it pre-selected for operations so they leave it alone and do not pick the wrong session for the HMI.
Anybody done something like this before?
Steve,
If you have unique sessions with different area assigments, the user will need to logon and pick the session.
If you don't want to reserve Users or Nodes for the sessions and all the sessions have the same area assignments, you can enable DeltaV Autologon (see pic) on Flexlock. This will pick a session automatically and logon to DeltaV without User intervention. This will work as long as a session is available and the username being used to connect to the remote session is the same as the DeltaV account (which I have typically seen is the case).
Regards,
Matt
In reply to Matt Stoner:
Thanks for the suggestion however all sessions are logged on to windows using a default account. The user then logs onto DeltaV using their specific credentials. At this stage they should pick a session. One session is reserved for each HMI but users are not selecting the correct session and then others are complaining they cannot log on to the session for that HMI.
The restriction I have is that I cannot reserve sessions as engineering wants to flexibility to log onto any session.
Regards
Steve
In reply to Steve Linehan:
Sounds like you are in a no win situation... :)
The PROCONEX DeltaV Idle Timeout Security application was developed as a session director (in addition to a replacement for the DeltaV Screen Saver Application within terminal services.)
It has been deployed to at least a dozen different sites for the exact reason you cite over the last 8 years. The application directs terminals to dedicated sessions using a default user. This forces operating terminals log in to their dedicated session, but does not restrict log in to pro sessions. Please contact me if you think this might suite your needs.
In reply to Youssef.El-Bahtimy:
I've liked using terminal server sessions for engineers, but not for operators for reasons similar to those already mentioned in this thread. Moving toward virtualization might replace remote clients with virtualized pcs and this concern become less of an issue.
The application Youssef mentioned might be a solution. While a utility like this can certainly be helpful, I would certainly rather Emerson take the lead on developing such utilities so they are embedded in the system and migration proof.
In reply to Michael Moody:
Michael
Interesting comment, I think Youssef wrote an article on this site recently comparing these two options. The solution proposed by Youssef looks interesting.
Michael,
We have played both sides of the discussion regarding terminal services vs. vm's with zero clients and have had success in both.
Terminal services would be nearly perfect if we could have distributed servers so clients could connect based on availability and loading (and floating licenses of course),
but vm's with zero clients would be nearly perfect if patch management could be performed against a hot spare vm and cutover seamlessly (maybe that is possible, I'm a little out of touch!)
In reply to John Rezabek: