• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 67
  • Last Modified:

Remote Desktop application Vs RemoteApp

I have a Microsoft Access application that is running on Server "2012 R2".  Currently, users login and run the application via RDP.  Whilst this works well, I have come across the term "RemoteApp", where the user can run the application as if it's running locally, making it easy to switch between our application and those running locally. In some cases, this might be a nice option, but I do have a couple of questions about it.

1. Does it have any obvious downsides?
2. Does it help reduce the load on the server in any way?
3. I can currently logon to a users session and help them out (if they need me to).  Would this still work?

Thanks as always
0
Andy Brown
Asked:
Andy Brown
2 Solutions
 
Gustav BrockCIOCommented:
1. It is not useful if the user, for example, wish to switch printer or do other things you usually take for granted on a normal Desktop
2. No
3. Yes

It's a very nice feature. Also, are you aware of the Remote Desktop Tool
0
 
Anders Ebro (Microsoft MVP)Microsoft DeveloperCommented:
It is my understanding that RemoteApp is basicaly a Remote desktop session that is "locked" into just using/starting the App of your choice.
1
 
Andy BrownDeveloperAuthor Commented:
Thank you both.  I'll certainly take a look at this as an option.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
BitsqueezerCommented:
Hi,

we'll do the same here with Access ADP files (ADE) with RemoteApps. It es the very best way of using Access as a frontend because
  • the application can run on a terminal server or also many terminal servers so you can spread the workload for the frontend.
  • if the backend server (SQL Server in our case) has not enough performance running on one server you can spread it also by using SQL Server clusters or Windows clusters.
  • you have a consistent installation because you can be sure that all users uses the same Office versions or any installed DLL you want to use as all are working on the servers
  • printers are no problem because you can simply use a setting in the RDP file (Remote Desktop and also RemoteApp) which makes it possible to forward the local installed printer queue to the Terminal Server, so the user can choose a printer driver installed on the Terminal Server and also all locally installed printers
  • The same can be done with all locally installed hard drives and network shares, a simple option in the RDP file can map them to the Terminal Server so all are automatically added to the user. When he uses for example the standard Office "Save" or "Open" dialogue he sees all his local drives as drives on the server beginning with his computer's name.

Cheers,

Christian
2
 
Andy BrownDeveloperAuthor Commented:
Thanks Christian - I really appreciate your help, but haven't quite got what you mean.

"the application can run on a terminal server or also many terminal servers so you can spread the workload for the frontend."

Our front and back-end reside on the same server, which user RDP into.  So, I'm not sure how terminal server would come into play, or more interestingly - how we can spread the workload for the frontend.

Thanks again.
0
 
BitsqueezerCommented:
Hi,

it depends a little bit on your setting but normally you would split a database into a frontend and backend. The backend is used by all users, for the frontend each user gets a copy into his own folder. This is then added into the Terminal Server RemoteApp Manager provided by Windows. In the end the user gets an RDP file which this tool can also create for you.
As the server name is also inside of the RDP you can easily move a frontend to a second Terminal Server and send the user a new RDP file which then contains the other Terminal Server name - for the user there is no difference. And the frontend should also be able to work with the backend on the other server.

But in general I would strongly recommend to move the backend to a separated server because the user could browse through the servers harddisks and maybe destroy the backend (if it is an Access backend which it hopefully is not).

Additionally you should use a login script for the Terminal Server which separates users which should only use the RemoteApps and users which should use the complete Remote Desktop - the Windows tools cannot do this so everyone who gets access to the Terminal Server RemoteApp can also open a normal Remote Desktop which you normally don't want.

I've made a simple cmd file which looks like that:
@echo off
IF %username% EQU FirstUser goto startExplorer
IF %username% EQU SecondUser goto startExplorer
ISMEMBER.EXE Administrators >nul
IF %ERRORLEVEL% EQU 1 goto startExplorer
ISMEMBER.EXE RemoteDesktopForbid >nul
IF %ERRORLEVEL% EQU 0 goto startExplorer
:logoffUser
REM C:\Windows\System32\logoff.exe
echo Member
goto BatchEnd
:startExplorer
echo Start Explorer
Start C:\Windows\explorer.exe
:BatchEnd

Open in new window


Then I've created a local user group on the Terminal Server named "RemoteDesktopForbid" where I insert all users which should not use the desktop itself but only the RemoteApps. The script uses the "IsMember.exe" tool from www.intelliadmin.com" to check if the user is in this group and then immediately log him off if he tries to login with a normal RDP desktop session.
The script also has some hard coded usernames which are bypassed so that they do not get logged off.

Cheers,

Christian
0
 
Andy BrownDeveloperAuthor Commented:
Brilliant - let me have a look into that.

Even in its current form - the RDP settings for each user are quite tight (from what I am told).  They don't have access to anything other than the application (no Explorer, TaskManager etc).  However, they are using a full RDP licence (with the resources that entails), and as far as I am concerned, anything that can reduce the server resources, makes it better, commercially.
0
 
BitsqueezerCommented:
Hi,

yes, of course a RemoteApp is also a "normal" Remote Desktop session and so it is of course using one Terminal Server Licence.

In our case we are using a Terminal Server Licence Server from Microsoft where any existing Terminal Server can connect to (can be done in the MS Terminal Server Configuration Tool). That has the advantage that all Terminal Servers can share the same pool of licences. So you don't need to buy i.e. 50 licences for two Terminal Servers each but instead in this example 50 licences overall and install them on the Licence server. Normally not any Terminal Server is connected by any existing user so if there are 15 on TS1 and 20 on TS2 they can together use these 50 licences. That makes it easier to purchase only the number of licences you really need over all Terminal Servers regarding the number of users connecting at the same time. This is especially useful if you share the Terminal Server worldwide and users are connecting in different time zones so they are not online at the same time.

Yes, that's what RemoteApps are good for: To give them only access to one specific application which seems to run on the user's computer. But be careful: Although the user has no Explorer to start a simple "Open" dialogue of the standard Office dialogues is enough to do a lot of things you don't want your users to do. With that you have nearly the full possibilities which also the Explorer has including starting programs. If you use for example an Excel installed on the Terminal Server and your Access application allows to export some data and open it in an Excel installed on the Terminal Server (which is possible with Remote App, Excel would be another new window on the user's computer running on the Terminal Server!) the user could easily use Excel to switch to VBA and use for example the "Shell" command to execute an Explorer or any other program you don't want them to start. So for any file or printer choosing I would strongly recommend to program an own dialogue with an Access form where you can decide on your own what to display or which functionality it should provide - very much more secure.

And the last, as I said above, you should not use the Terminal Server for the database itself, as the Terminal Server has a lot to do to handle all the user frontends and user accounts, which can heavily disturb the performance for all users if the database is also on this server - independent if it is a real database server or only an Access backend.

Cheers,

Christian
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now