About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A full remote desktop provides a complete remote Windows workspace. RemoteApp presents published programs alongside the user's local applications. Choose between them by testing the work people must complete, rather than assuming one is inherently safer or that several applications require a full desktop.
Both can use the same Remote Desktop Session Host infrastructure. Microsoft's RDS roles guide describes collections of applications and desktops, access assigned to user groups, and non-administrative accounts for shared session hosts. Presentation does not grant installation rights or isolate one user's software from the rest of a shared server.
Start with the complete task
Launching the main application is only the first test. An accounts clerk might open an invoice, export a spreadsheet, edit it in a hosted Office application, attach the result to an email and print a copy. Name each application and whether it runs locally or remotely. That distinction affects file locations, copy and paste, default applications and user expectations.
RemoteApp can publish several programs. Microsoft documents that subsequent RemoteApps launched from the same client before sign-out use the same session. Using Office beside an accounting application is therefore not, by itself, a reason to reject RemoteApp. The specific integration still needs testing: a file association may open a different application than expected, a helper may require additional configuration, or an export may be saved somewhere the user cannot find.
A full desktop can make a complex remote workflow easier to understand because its applications and files appear in one workspace. That is a usability benefit, not proof of stronger security.
Make permissions a separate decision
On a shared host, the administrator should install and update approved software and compatible plugins for both presentation modes. A desktop does not entitle staff to add printer drivers, browser extensions or executable tools themselves. Keep standard-user accounts and application controls, and review permissions for every integration.
If a role genuinely needs administrative access, assess a separately isolated personal environment, with its own application compatibility, licensing, recovery and security approval. Microsoft's collection guidance distinguishes personal session desktops and explicitly granted administrative privileges. Do not turn an ordinary shared desktop into that environment merely by making the user an administrator.
A practical comparison
| Required workflow | Candidate presentation | What must be proved |
|---|---|---|
| A defined group of business applications with known exports | RemoteApp | All published programs, helper processes and file hand-offs work together |
| Frequent navigation across remote folders and several applications | Full desktop or RemoteApp pilot | Users can locate files and finish the workflow without confusing local and remote locations |
| A single kiosk task | RemoteApp with appropriate controls | Only approved functions are reachable; a simple appearance is not a security boundary |
| A plugin needed by everyone | Either mode | Administrator-managed installation, shared-host compatibility and update behaviour |
| A person must administer their own software | Separately isolated personal environment | Explicit approval and separation from other users, rather than elevated rights on a shared host |
These are editorial decision criteria, not Microsoft thresholds. One mandatory workflow that fails may outweigh many simple tasks that pass. There is no useful percentage of shell-dependent tasks that automatically decides the answer.
Run a workflow pilot
Use authorised test accounts and non-sensitive sample data. For each candidate, record the client platform/version, host version, application versions, profile model and enabled redirections. Include opening and saving files, exported reports, printing, reconnecting and signing out. Check the denied paths as well as the permitted ones: a user should not gain installation privileges just because a full desktop is visible.
Ask representative staff to complete the tasks without administrator assistance. Record correctness, usability problems and support instructions, then choose the mode that meets every essential requirement with an acceptable support burden. Keep the result tied to the tested versions; an application or client upgrade can change it.
This article is based on source research; no collection, application or client pilot was performed.
For related service information, see ThinPoint remote access.
This article was originally published on .