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.
On a shared Remote Desktop Session Host, published application icons are not an application-control policy. Standard-user permissions are essential, but administrators also need to decide which executables, scripts, installers and supporting components may run.
Two Microsoft technologies have different scopes. AppLocker can apply rules to particular users or groups. App Control for Business, formerly Windows Defender Application Control (WDAC), applies policy to the device as a whole, affecting all its users. That distinction matters when several business roles share one server.
Check the actual Server support boundary
The current AppLocker overview covers Windows Server 2016, 2019, 2022 and 2025, and explicitly excludes Server Core installations. Its availability on a session host should not be described as requiring a Windows client Enterprise edition.
Older client-edition rules also should not be generalised to current Windows releases. Microsoft's requirements page explains changes for supported Windows 10/11 versions. Confirm the server installation type, build and policy deployment mechanism rather than importing an old client rule.
Microsoft's App Control and AppLocker comparison states that App Control policies can be applied on Windows Server 2016 and later, but individual features and deployment methods vary. A design using supplemental policies or managed installer needs its own version check; those capabilities are not promised for every Server release by the broad product name.
Choose the policy scope
| Requirement | Candidate | Boundary to validate |
|---|---|---|
| Different application permissions for finance and operations on one host | AppLocker user/group rules | Every relevant executable and supporting component; this does not create separate machines |
| An approved baseline for all code on a host | App Control for Business | Device-wide impact, supported feature set and management/recovery tools |
| Device-wide baseline plus role-specific restrictions | A deliberately combined design | Interaction between policies, audit evidence and supportability on the exact version |
Microsoft generally recommends App Control where it can meet the organisation's needs, while identifying shared-computer user/group restrictions as an AppLocker use case. Neither choice removes the need for standard-user accounts or normal patching.
An installation folder is not proof of trust
AppLocker supports publisher, path and file-hash conditions. A publisher rule can cover signed files across selected products or versions, but an overly broad publisher allowance may permit more software than intended. A hash rule identifies exact file content but needs maintenance when approved binaries change.
A path rule trusts a location. Microsoft's path-rule guidance warns that non-administrator-writable subdirectories can allow unwanted code to run beneath an allowed path. Before relying on a path, validate write permissions throughout the allowed tree, including updater-created folders. Avoid user-writable locations. Merely finding the application under Program Files is not sufficient evidence.
Review default rules and exclusions explicitly. They are starting points, not an automatic approved-software inventory. Include application helpers, report engines, browser integrations, scripts, installers, scheduled components and administration/recovery tooling in the design.
Leave audit mode when coverage is sufficient
Microsoft documents AppLocker's audit-only mode for observing policy effects before enforcement. Use a representative isolated pilot, and review the logs for every required workflow and user group. Do not define success as simply spending one week in audit mode.
Coverage should include startup, daily work, reporting, month-end operations where applicable, an approved application update, rollback and support access. A quiet week without the monthly report says nothing about that report's helper executable. Investigate would-be blocks and justify allowances rather than permitting every observed file indiscriminately.
Before enforcement, validate recovery through an authorised management route on the test environment. Do not assume a local administrator automatically bypasses every application-control policy. Confirm the actual policy rollback method and access to the tools required to perform it.
No application-control policy, permissions or recovery process was tested for this article. It is a design checklist; enforcement needs deployment-specific evidence and approval.
Related service: ThinPoint remote access.
This article was originally published on .