Running remoteapp from TS1 inside a terminal server session on TS2

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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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 ??

IntrepidityAuthor Commented:
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.
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.
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.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.