When a user opens \\server01\apps\ERP.exe, Windows reads the executable and its dependencies from the SMB share, but the program normally runs on that user’s workstation. Its instructions execute on the client’s CPU, its working memory belongs to the client, and its process appears in the client’s Task Manager. The server supplies files and possibly shared business data; it does not execute the desktop process merely because the EXE is stored there.
This distinction determines where process priority must be changed. Setting a priority class on the file server cannot raise the priority of ten independent processes running on ten client PCs.
Prove Where the Program Runs
On a client, launch the shared application and inspect Task Manager → Details or run:
Get-Process -Name 'ERP' -ErrorAction SilentlyContinue |
Select-Object Name, Id, MachineName, PriorityClass, CPU, WorkingSet64
The process should appear locally. Network activity may continue because the application opens shared data files, loads modules on demand, writes logs, or connects to a database. That traffic does not move the process itself back to the server.
There are important exceptions. With Remote Desktop Services or RemoteApp, the application executes inside a session on the remote server. A browser front end can call code on an application server. A desktop client can also connect to a separate database engine. Identify the architecture before applying any optimisation.
What Windows Process Priority Really Changes
Windows uses priority classes to decide which ready threads receive CPU time first. Microsoft’s scheduling-priority documentation describes the standard classes: Idle, Below Normal, Normal, Above Normal, High, and Real-time.
Most applications run at Normal. Raising one to Above Normal can make it more responsive when the client CPU is genuinely busy. It does not make code execute faster on an idle CPU and does not repair slow disk, network latency, database locks, or antivirus delays.
Use High only after measurement and testing. Microsoft warns that high-priority threads can consume nearly all available processor time. Real-time is inappropriate for an ordinary business application because it can interfere with operating-system work, input, disk flushing, and other critical activity.
Set Priority on Each Client
Task Manager can change a running process temporarily, but the selection usually disappears when the process exits. For a controlled test, PowerShell can set the process after it starts:
$process = Get-Process -Name 'ERP' -ErrorAction Stop
$process.PriorityClass = 'AboveNormal'
If several instances exist, handle each one:
Get-Process -Name 'ERP' -ErrorAction SilentlyContinue | ForEach-Object {
if ($_.PriorityClass -ne 'AboveNormal') {
$_.PriorityClass = 'AboveNormal'
}
}
This must run with appropriate rights on every workstation where the application process exists. It should match the real process name, not the friendly shortcut label.
Ways to Make the Setting Repeatable
Choose the least complicated method that fits application ownership:
- Vendor-supported setting: best when the software exposes one or the vendor can confirm the workload benefits.
- Launcher wrapper: replace the desktop shortcut with a signed local script that starts the UNC executable, waits for its process, and applies Above Normal.
- Scheduled task on each client: deploy a task at user logon that periodically detects the process and adjusts it. Group Policy or endpoint management can distribute it consistently.
- Enterprise process-management tool: appropriate when the organisation already uses a controlled product for persistent priority and resource rules.
A watcher should sleep between checks, stop cleanly, write only useful errors, and avoid changing unrelated processes with the same short name. Sign scripts where policy requires it, restrict modification rights, and test with a small pilot group before broad deployment.
Do not place a writable priority script beside the executable on an ordinary share and let every user modify it. That turns a performance tweak into a code-execution risk.
Why Priority Often Does Not Solve the Complaint
A multi-user business application stored on an SMB share can be limited by several independent paths:
| Symptom | Likely area to measure |
|---|---|
| Slow first launch for everyone | SMB read latency, antivirus scanning, DNS, executable signing checks |
| Slow only on one PC | Client CPU, RAM pressure, endpoint security, network adapter, profile |
| Freezes when several users save | File locking, database contention, application design, server storage latency |
| Fast launch but slow reports | Database query, index, server CPU, storage queue, application data path |
| Random disconnects | Packet loss, switch/NIC errors, power management, SMB session stability |
| Slow only during other VM workloads | ESXi CPU ready time, datastore contention, memory ballooning or swapping |
Measure a slow operation from both client and server. On the client, record CPU utilisation, per-process CPU, memory pressure, disk response, and network latency. On the server VM, measure SMB throughput, disk latency and queue, CPU, free memory, open files, and database behaviour. On ESXi, inspect host contention rather than assuming allocated vCPUs are equivalent to guaranteed CPU time.
ESXi Shares and Latency Sensitivity
CPU shares determine relative entitlement when virtual machines compete for host CPU. They do not give a lightly loaded VM an automatic speed boost, and a larger share value cannot fix a serial application or slow storage. A VM with too many vCPUs can even wait longer for scheduling if the host is constrained.
VMware latency-sensitivity settings are intended for workloads with proven low-latency requirements and corresponding reservations and host design. Setting a routine file-server or accounting VM to High is not a general performance recipe. First review CPU ready, co-stop, storage latency, network drops, NUMA placement where relevant, and actual contention.
For a small deployment, right-sizing vCPU and memory, using a low-latency datastore, current virtual hardware and supported drivers, reliable backups, and a clean network usually matters more.
Treat the Data Layer Separately
Some older applications let multiple clients open shared data files directly. In that design, SMB latency and file locks are central. Other applications use the share only for program files and connect to a database service. Optimising the EXE share will not fix a database query or record-locking problem.
Ask the software vendor:
- whether running the executable from a UNC path is supported;
- which database or shared-file engine it uses;
- whether local client installation with central data is recommended;
- which paths should be scanned or excluded by endpoint security;
- how updates remain atomic while users are connected;
- what server operating system and SMB settings are supported.
Never add broad antivirus exclusions solely to improve a benchmark. Use vendor-documented, narrowly scoped exclusions after a security review.
Windows 10 Is No Longer a Neutral Server Choice
Windows 10 reached end of support on October 14, 2025. Microsoft’s Extended Security Updates guidance explains the temporary ESU path for eligible devices, but ESU does not turn Windows 10 Pro into Windows Server or extend general feature support.
In 2026, a Windows 10 Pro VM serving a multi-user business application should have a documented migration plan. Confirm the application’s supported platform, client-connection requirements, backup consistency, database support, and licensing. A supported Windows Server release or vendor-approved application/database architecture is normally a stronger foundation than tuning an end-of-support desktop OS.
A Better Optimisation Order
First, reproduce one slow task and identify whether time is spent on the workstation, SMB transfer, shared-file locks, database work, server storage, or ESXi contention. Second, fix any unsupported operating system or application architecture. Third, validate network and storage latency, endpoint-security behaviour, backups, and database maintenance. Only then pilot Above Normal on one client if CPU contention remains visible.
Process priority is a scheduler preference, not a universal accelerator. Used carefully, it can protect responsiveness on a busy workstation. Used as the first response to a network application problem, it often hides the measurement that would reveal the real bottleneck.
