In short
To publish RemoteApp and make it available through the Remote Desktop web client on Windows Server 2025, first validate the underlying Remote Desktop Services deployment, publish the application from the target session collection, install the RDWebClientManagement PowerShell module on the RD Web Access server, import the RD Connection Broker certificate, publish the web client package, and test access from a supported browser.
This guide owns one specific workflow:
Working Windows Server 2025 RDS deployment → session collection → publish RemoteApp → verify user authorization → prepare RD Web Access → install RDWebClientManagement → import RD Broker certificate → publish the web client → open the web-client URL → launch the RemoteApp as a normal user → verify licensing, certificates, redirection and sign-out
It does not replace the broader Remote Desktop Services Configuration on Windows Server 2025 guide. That page owns the base RDS deployment. This page starts when Connection Broker, RD Web Access, RD Session Host, licensing, and a session collection already exist.
Microsoft's current documentation lists Windows Server 2025 for the Remote Desktop web client and RDS collection workflows used in this guide. Because RDS architecture, certificates, licensing, and application behavior vary by environment, validate the sequence in your own deployment before production rollout.
Why use RemoteApp with the Remote Desktop web client?
RemoteApp lets an administrator publish a specific Windows application from an RD Session Host instead of giving every user a full Windows desktop. The Remote Desktop web client gives authorized users a browser-based way to reach the applications and desktops published to them.
That combination can fit teams that need centrally hosted Windows software but want a narrower user experience than a full remote desktop.
| Requirement | RemoteApp + web client fit |
|---|---|
| Users need one or several Windows applications | Strong fit |
| Users should not receive a full server desktop | Strong fit |
| Users connect from Windows, macOS, ChromeOS, or Linux browsers | Good fit with supported browsers |
| Users need mobile-browser access | Not a fit; Microsoft currently says mobile devices are not supported by the web client |
| Users need a complete Windows desktop | Publish a desktop collection instead of only RemoteApps |
| Users connect from the public internet | Plan RD Gateway, certificates, MFA, and external access separately |
Microsoft documents web-client access from modern browsers on Windows, macOS, ChromeOS, and Linux. The user still needs valid RDS authorization and the correct published resource.
Prerequisites
Do not begin with the web-client PowerShell module if the underlying RDS deployment is not already healthy.
Confirm the following first:
- Windows Server 2025 is patched.
- The RDS deployment has an RD Connection Broker.
- RD Web Access is installed and operational.
- At least one RD Session Host is part of a session collection.
- The application you want to publish is installed on every Session Host that can serve the collection.
- A normal Active Directory test user can access the collection.
- RDS licensing is configured for the intended production model.
- DNS resolves the names used by the deployment.
- Certificates for the RDS deployment are installed and trusted as required.
- External users have a controlled access path such as RD Gateway where the architecture requires it.
- You have a rollback path before changing the production web client.
If the base RDS deployment is incomplete, finish Remote Desktop Services Configuration on Windows Server 2025 first.
Licensing warning before web-client rollout
RemoteApp sessions are Remote Desktop Services sessions. A browser does not remove the licensing requirement.
Microsoft's current web-client administration guidance warns that the web client should be used with a Per User RDS CAL configuration rather than Per Device because Per Device mode can result in licenses being consumed incorrectly for web-client users.
Review RDS CAL Licensing on Windows Server before production rollout. If Raff provides the RDS workload under a hosted service-provider licensing model, confirm the applicable hosted RDS entitlement separately.
Step 1 — Verify the session collection
Open Server Manager on the RDS management server.
Go to:
Remote Desktop Services → Collections → select the target collection
For this example, assume the collection is named:
OfficeApps
Before publishing an application, verify:
- the expected RD Session Host belongs to the collection;
- the intended user or Active Directory group is authorized;
- the application exists on the Session Host at the expected path;
- the collection is configured for the resource model you intend to publish.
You can inspect collections with PowerShell:
Import-Module RemoteDesktop Get-RDSessionCollection
Then inspect the target collection:
Get-RDSessionCollection ` -CollectionName 'OfficeApps'
Verification: Server Manager and PowerShell should both show the intended collection and Session Host.
Step 2 — Install and test the application on the Session Host
RemoteApp does not package or virtualize the application for you. The application must already run correctly on the RD Session Host.
Before publication, validate:
- the application launches;
- required runtimes are installed;
- file paths work;
- database or API connectivity works;
- the application can save data;
- user-specific configuration behaves correctly;
- the application's own license permits multi-user/RDS use;
- updates and reboots do not break the application path.
Do not publish an application to users before it works locally on the Session Host under the intended user context.
Step 3 — Publish the RemoteApp from Server Manager
Open:
Server Manager → Remote Desktop Services → Collections → OfficeApps → RemoteApp Programs → Tasks → Publish RemoteApp Programs
Select the application you want to publish and complete the wizard.
After publication, the application should appear under RemoteApp Programs for that collection.
Microsoft also provides the New-RDRemoteApp cmdlet.
Example:
Import-Module RemoteDesktop New-RDRemoteApp ` -CollectionName 'OfficeApps' ` -DisplayName 'Contoso Accounting' ` -FilePath 'C:\Program Files\Contoso\Accounting.exe' ` -ShowInWebAccess $true
Replace the example application name and path with the actual executable.
-ShowInWebAccess $true makes the RemoteApp eligible to appear through RD Web Access for authorized users.
Verify the result:
Get-RDRemoteApp -CollectionName 'OfficeApps'
Step 4 — Restrict the RemoteApp to the correct users
Publishing the program is not the same as authorizing every user.
Use the collection's user group plus RemoteApp-specific restrictions where needed.
A practical structure is:
AD user → RDS application security group → session collection authorization → RemoteApp authorization → published application
For example:
CORP\RDS-Accounting-Users
New-RDRemoteApp supports -UserGroups when a RemoteApp should be scoped more narrowly.
New-RDRemoteApp ` -CollectionName 'OfficeApps' ` -DisplayName 'Contoso Accounting' ` -FilePath 'C:\Program Files\Contoso\Accounting.exe' ` -ShowInWebAccess $true ` -UserGroups 'CORP\RDS-Accounting-Users'
Test with both an authorized and an unauthorized user. A proper security test proves that users who should not receive the application cannot see or launch it.
Step 5 — Confirm RD Web Access is working
RD Web Access is part of the Remote Desktop Services deployment and provides the resource layer used by authorized users.
Before adding the web client, verify the RD Web Access role is healthy and that the deployment certificates and DNS names are correct.
The web client is not a replacement for Connection Broker or RD Web Access. It presents published applications and desktops through the browser on top of the existing RDS deployment.
For external access, do not expose Session Hosts directly just because browser access works. Review Remote Desktop Gateway vs Direct RDP and Add MFA to Remote Desktop Services before public rollout.
Step 6 — Install the RDWebClientManagement module
On the RD Web Access server, open PowerShell as Administrator.
Install the module:
Install-Module -Name RDWebClientManagement
If PowerShell asks whether you trust the repository, verify that you are using the expected PowerShell Gallery source before accepting.
After installation, open a fresh elevated PowerShell session and verify the module:
Get-Module -ListAvailable RDWebClientManagement
List its commands:
Get-Command -Module RDWebClientManagement
Step 7 — Download the latest Remote Desktop web client package
Run:
Install-RDWebClientPackage
This downloads the current web-client package supported by Microsoft's management module.
Avoid hard-coding a package version unless you have a specific reason to pin it.
Step 8 — Export the RD Connection Broker certificate
The web client requires the RD Connection Broker certificate to be imported into the web-client configuration.
Use the certificate currently assigned to the RDS deployment's Connection Broker role. Export the public certificate as a .cer file. Do not export or expose the private key for this step.
Example path:
C:\RDS\BrokerCert.cer
Verify:
- the certificate corresponds to the Connection Broker configuration;
- the certificate is valid and not expired;
- the expected name is present;
- the public certificate file is available on the RD Web Access server;
- no private key is exposed unnecessarily.
Step 9 — Import the RD Broker certificate into the web client
On the RD Web Access server, run:
Import-RDWebClientBrokerCert 'C:\RDS\BrokerCert.cer'
Microsoft instructs administrators to run this again when the RD Broker certificate is renewed or replaced. If the broker certificate changes but the web client configuration is not updated, users can receive an unexpected server authentication certificate error.
Step 10 — Publish the Remote Desktop web client
Microsoft supports publishing a Test package first and then a Production package.
Start with the test client:
Publish-RDWebClientPackage -Type Test -Latest
After validation, publish production:
Publish-RDWebClientPackage -Type Production -Latest
Microsoft documents the production URL format as:
https://server_FQDN/RDWeb/webclient/index.html
The hostname should match the name covered by the RD Web Access public certificate.
The corresponding test path is:
https://server_FQDN/RDWeb/webclient-test/index.html
Step 11 — Sign in as a normal user
From a supported desktop browser, open the production or test URL.
Microsoft currently documents support for modern browsers including:
- Microsoft Edge;
- Google Chrome;
- Apple Safari;
- Mozilla Firefox 55 or later.
The web client can be used from Windows, macOS, ChromeOS, and Linux. Microsoft currently says mobile devices are not supported by the web client.
Sign in using the format expected by the RDS environment, commonly:
DOMAIN\username
Use a normal non-administrator test account that belongs to the intended RDS application group.
The All Resources view should show only the applications and desktops assigned to that user.
Step 12 — Launch the RemoteApp from the browser
Select the published application.
The browser may ask for permission to redirect local resources such as clipboard or printer access. Choose settings that match your policy.
Test more than whether the application window opens:
| Check | Expected result |
|---|---|
| Authentication | Normal user can sign in |
| Authorization | User sees only assigned resources |
| Application launch | RemoteApp opens successfully |
| Application identity | Correct application and version opens |
| File access | Intended server-side paths work |
| Clipboard | Works or is blocked according to policy |
| Printing | Works or is blocked according to policy |
| Reconnect | Session behavior matches design |
| Sign-out | Session closes cleanly |
| Unauthorized user | Cannot see or launch the RemoteApp |
If the application launches only for an administrator, fix application permissions or user-profile dependencies rather than granting administrator rights to end users.
Step 13 — Verify the URL and certificate chain externally
Test from a client that is not the RD Web Access server itself.
Verify:
- the public hostname resolves correctly;
- the certificate presented by the web endpoint is trusted;
- there are no browser certificate warnings;
- the URL hostname matches the certificate;
- external access reaches the intended gateway/web-access path;
- internal Session Hosts are not accidentally exposed directly to the internet;
- the application launches from the intended user network.
For public production access, use Remote Desktop Gateway vs Direct RDP to validate the external access architecture.
RemoteApp vs full desktop publishing
Use RemoteApp when users need only one or several Windows applications rather than a complete Windows desktop.
| User need | Better publication model |
|---|---|
| One accounting, ERP, or business application | RemoteApp |
| Two or three focused line-of-business apps | RemoteApp |
| Complete Windows work environment | Full Remote Desktop |
| Server administration | Administrative access, not normal RemoteApp access |
| Browser access to a hosted Windows application | RemoteApp + web client can fit |
Do not publish a full desktop simply because it is easier if the real requirement is only one application. Narrower publication reduces the normal user's accessible surface and provides a more focused experience.
How to update the Remote Desktop web client later
When Microsoft publishes a newer client package, use:
Install-RDWebClientPackage
Optionally publish it to the test endpoint first:
Publish-RDWebClientPackage -Type Test -Latest
Then promote it to production:
Publish-RDWebClientPackage -Type Production -Latest
Use a test user before promoting an update when RemoteApp is business-critical.
Certificate renewal procedure
When the RD Broker certificate is renewed or replaced:
- export the new public certificate as
.cer; - copy it to the RD Web Access server;
- import it again with
Import-RDWebClientBrokerCert; - republish the production web client;
- test a RemoteApp launch.
Example:
Import-RDWebClientBrokerCert 'C:\RDS\BrokerCert-New.cer' Publish-RDWebClientPackage -Type Production -Latest
Common Remote Desktop web client problems
The RemoteApp does not appear
Check:
- the program is published in the correct collection;
ShowInWebAccessis enabled;- the test user is in the collection's allowed group;
- RemoteApp-specific user groups allow the user;
- the user signed into the correct RDS deployment;
- RD Web Access can reach the deployment correctly.
The web client loads but the app does not launch
Check:
- RD Connection Broker health;
- Session Host health;
- RD Gateway/external access path;
- certificates;
- user authorization;
- RDS licensing;
- application executable permissions;
- event logs on the RDS servers.
Unexpected server authentication certificate error
If the RD Broker certificate was renewed or replaced, re-import the new broker certificate:
Import-RDWebClientBrokerCert 'C:\RDS\BrokerCert-New.cer'
Then republish the production client.
The browser shows a certificate warning
Verify the hostname used in the URL matches the RD Web Access public certificate and that the certificate chain is trusted by the client.
Per-device licensing warnings appear
Microsoft's web-client administration documentation warns about Per Device CAL mode and recommends Per User licensing for the web client. Review the licensing design rather than bypassing the warning.
Users see more applications than expected
Review both the collection authorization and each RemoteApp's user-group scope. Do not rely on hiding icons as an access-control mechanism.
Security checklist before production rollout
Before sending the URL to users, confirm:
- RDS licensing matches the production deployment model.
- Normal users have no unnecessary local administrator rights.
- Only intended AD groups can access the session collection.
- Each RemoteApp is scoped to the correct users/groups.
- RD Web Access uses a trusted certificate.
- The RD Broker certificate imported into the web client is current.
- RD Gateway or another approved external-access architecture is configured where required.
- MFA is enabled when the risk model requires it.
- Session Hosts are not broadly exposed through public RDP.
- Clipboard, drive, printer, and device redirection policies are intentional.
- Windows Server and the published application are patched.
- Backups and restore testing exist for application data.
- A normal user has passed the complete browser launch test.
- An unauthorized user has been tested and denied.
Where Raff fits
Raff Windows VMs can provide the Windows Server infrastructure used for RD Session Host, Connection Broker, RD Web Access, and other RDS roles in a planned deployment. The RDS architecture, Microsoft licensing, application licensing, certificates, user groups, gateway design, MFA integration, and application testing still need to be configured for the production environment.
For teams evaluating server capacity, use Windows VPS Sizing for Remote Users before moving several users onto one Session Host.