Running remoteapp from TS1 inside a terminal server session on TS2

Posted on 2008-10-01
Last Modified: 2013-11-21
We have two physical locations with terminal servers present in both locations. These locations are not yet joined in AD. Today some users access terminal server on the other location to access needed software. The following would off course be implemented AFTER joining the two locations in the same domain.

Example: Remote users connecting to terminal server on location1(where home folder and most shared recources they need are present) also need access to for example CRM app on location2. Any problems assosiated with running CRM from terminal server location2 as remoteapp inside a terminal server session in the terminal server on location1? Credentials would have to be passed on as in the single sign on process so users don´t get asked about this a second time when accessing the remoteapp. Can I restrict this adding path to the terminal server on location2 in software restriction as allow? I do not want to open up for network access for users accessing the terminal server, but if I have to I have to. I don´t even know if this setup will work at all..?

The CRM application in question has the database running on a server in loc2, and the client isn´t capable of a connection over VPN due to need of bandwith to database. The clientsoftware for the application can because of this not be installed in the terminal server in location1. Running as a remoteapp from terminal server in loc2 should however not be a problem.

This also mean that a single user access 2 terminal servers with the same credentials at the same time. Any issues here?
Question by:Intrepidity
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2

Expert Comment

ID: 22620408
If you are using roaming terminal services profiles, keep in mind that the 2nd session that connects to the application session on TS2 will load the same profile.  Usually, it's not recommended to have two simultaneous sessions on two servers (or even on the same server), as the profile gets updated on the common network location after the user logs off.  This can result in a locked condition on the profile hosting server, which would possibly prevent the user profile from updating properly.  If the profile stays open for any significant amount of time, and if it's still open/locked when the user next tries to login, USERENV errors will begin showing up.  Additional profile copies will accumulate as either TEMP profiles are created or secondary/tertiary, etc. profiles are created (that's the username.domain profile folder for the first duplication, followed by username.001, 002, 003, etc for each succeeding profile failure.

On the 2nd terminal server that's serving just the application, you might be able to configure it with either a local policy, or a gpo that only applies to it that restricts the updating of the network location---as if it were a locked down profile.

Question:  Does your CRM application have it's own authentication within itself, or does it use the existing user's Windows credentials?  I'm suspecting that it must be Windows, since it's indicated that the user doesn't have to enter a 2nd set of credentials.  If the CRM app WERE using it's own security, I'd suggest something like using a 'common' or single user account to make the actual 2nd connection, instead of the user using their own again--this'd avoid any profile corruption/conflilcts with the user using their own profile twice.

You might also have to ramp up your licensing, as this may be considered as two TS Cals per user ??


Author Comment

ID: 22627798
Well I'm hoping this won't have any licensing issues - but I'm probably too optimistic here.

Users at loc1 will log onto ts1 and users at loc to will log onto ts2. Users from loc1 will have to be able to run crm app from loc2. This is where I want to use remoteapp since the application can't be run over a VPN connection.

The CRM application is not integrated with AD and use it's own authentication, so a single account for this purpose is an option.

Haven't decided on using roaming terminal services profiles or not.
LVL 32

Expert Comment

ID: 22628103
I double up on TS occasionally.  I don't use roaming profiles.

Login to the TS, then use that for Remote Desktop to workstations or servers.

Login to workstation via SBS2003 Remote Web Workplace.  From there, Remote Desktop to server.

The trick roaming profiles.  Turn it off, or you will have terrible login times...sometimes 5-10 minutes if you've never logged in.

Plus, as BobintheNoc stated, profile updates upon logout...but you still have the first logon active.  Wreaks havoc with files sitting on the desktop, icons, etc.

Accepted Solution

BobintheNoc earned 250 total points
ID: 22641736
Making CRM available via a TS application is certainly an option, however in today's modern programs, they should have, or at least have plans for delivery via HTTPS, where you can access the full functionality via a web browser.  Using a web interface will improve the availability of your CRM too, for all users.  You'll find, that while Terminal Services communications are usually allowed on various hotel/hotspot/airport internet access points, but you will also find that many of these public free access systems block everything except Web traffic.

As for the profiles,  I mistakingly called them Roaming TS Profiles.  While they do operate very similarly to Roaming profiles and are usually stored on a remote server share somewhere, they aren't the exact same thing as Roaming profiles.  A TS profile is it's own animal.  Depending on the numbers of users that you have, and the need for 'look and feel' issues, you'll probably WANT to use TS Profiles (set in each user's AD account under the Terminal Services Profile attribute fields.  If you don't use a TS profile, the user profiles will operate LOCALLY per server.  If you choose to go via Local profiles only, make sure you've got pleanty of storage space on the system drive for that server.  You'll really want to study this need, things like the locations of the default SAVE location for documents (the My Documents folder---to redirect or not) and HOME DRIVE values (where TS individual configuration settings are stored for multi-user settings on a single system), whether they can save to their 'DESKTOP' space, etc, will come into play.

The magic behind terminal services is that it allows multiple, simultaneous users to have their own unique environments and application settings all on the same system at the same time.  Running ONE user on a computer is TRIVIAL and Microsoft has figured out all the ins and outs, but running many applications per user, with multiple users on a single computer is not as easy as it would sound.  The isolation of each user's environment is a tricky thing, especially if the application(s) are NOT terminal server aware.  There is a lot of redirection done by the terminal server to make sure users don't cross each other in settings or security.  TS Profiles helps tremendously.  It is agreed that many people have trouble with TS Profiles, but, sadly, its usually a necessity for serious, production utilization.  If you're expecting TS to play a significant role in your users' world, and you're expected to deliver the types of services/functionality of a medium sized business or larger, you'll need TS Profiles.  If you're only a couple dozen people or smaller organization and TS will play only a minor role in how users work, you
may be able to 'wing' it, but there will always be comments/chatter about how the terminal server isn't as good as 'using my actual desktop computer.'

To enjoy the full benefit of TS Profiles, get to know it.  Understand it, and prepare to pull lots of hair out, but overall, it's there for a very valid reason.  One last comment on TS profiles---

  DO NOT, REPEAT, DO NOT, USE YOUR EXISTING STANDARD ROAMING PROFILE AS A TS PROFILE.  As in, do not point your TS PROFILE properties to the same location as you do a ROAMING PROFILE.  Make sure they are separate and NOT intermingled.  Bad things will happen if you try.


Featured Post

Optimize your web performance

What's in the eBook?
- Full list of reasons for poor performance
- Ultimate measures to speed things up
- Primary web monitoring types
- KPIs you should be monitoring in order to increase your ROI

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

After having deployed hundreds of thousands of Terminal Services seats worldwide, I still see all the time people asking me that same old question: "If TS/RDS is that reliable why are you telling me I should reboot it that often? My DC/SQL/Exchange/…
Welcome to my series of short tips on migrations. Whilst based on Microsoft migrations the same principles can be applied to any type of migration. My first tip Migration Tip #1 – Source Server Health can be found listed in my profile here: http:…
In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…
Add bar graphs to Access queries using Unicode block characters. Graphs appear on every record in the color you want. Give life to numbers. Hopes this gives you ideas on visualizing your data in new ways ~ Create a calculated field in a query: …
Suggested Courses

626 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question