I'm piloting Windows Server 2025 RDSH as a replacement for non-persistent Windows 10 desktops. Performance has been excellent, and users mainly need Office, browsers, PuTTY, 7-Zip, and a few other lightweight applications delivered mostly through App Volumes.
The remaining challenge is locking down server tools for standard users, especially Server Manager. I've tried several AppLocker rule combinations, but the results have been severe: the Start menu stops working, Outlook and Teams become unreliable, and some App Volumes applications fail to launch.
I've already configured the policy that prevents Server Manager from opening automatically at logon, but users can still find and launch it from the menu or by running it directly. Some of these users are technically capable, and I want to prevent them from changing network settings, disks, software, or other configuration that could affect the RDSH host. Is AppLocker the right tool, or is there a safer combination of permissions and Group Policy settings for this scenario?
3 Answers
First make sure the users are not members of Administrators or any other privileged local or domain group. A standard user can open Server Manager, but they should not be able to make administrative changes without elevation. Preventing it from launching automatically is usually enough, and you can disable the scheduled task that starts Server Manager at logon if necessary.
Trying to block the entire application with broad AppLocker rules can interfere with Windows shell components and packaged applications, which explains the Start menu, Teams, Outlook, and App Volumes failures.
If you have a specific executable that genuinely must be blocked, use a narrowly scoped AppLocker or Software Restriction Policy rule and test it in audit mode first. Avoid broad path or publisher rules that catch shared Windows components, shell processes, or application dependencies. Apply the policy only to the intended user group and validate it on a clone before using it on production hosts.
Exactly. Hiding the shortcut is not an access-control boundary, but standard users also should not gain the ability to change server configuration merely because Server Manager opens. Focus on group membership, delegated rights, and specific administrative tools instead of blocking the whole management framework.
There is a built-in Group Policy setting under Computer Configuration → Policies → Administrative Templates → System → Server Manager called “Do not display Server Manager automatically at logon.” That stops the automatic launch, but it does not remove Server Manager or prevent a user from starting it manually.
Use that policy for convenience, then enforce security through least-privilege permissions and targeted GPO restrictions rather than blocking Server Manager wholesale.
That makes sense. My main concern is preventing technically capable users from changing host configuration, rather than simply hiding the Server Manager shortcut.