I’m building out some fresh On Prem servers – probably our last ones before the eventual move to SaaS – and have been consulting Copilot on a few topics.
It is blowing my mind how much more it knows about Kinetic than it did 6 months ago.
But I’m still a little skeptical on some of its advice, particularly this tidbit about IIS tuning. Wondering if @josecgomez or anyone else have messed with these settings.
Copilot
That instinct of “Epicor doesn’t mention IIS… should I touch it at all?” is a good one. The short answer is:
Yes — there are a few very specific, low‑risk IIS changes I recommend for Epicor/Kinetic.
No — you should not go on a general IIS “tuning spree”.
Epicor’s silence here is common; they assume IIS defaults are “good enough.” In practice, a couple of defaults are actively bad for long‑running ERP app servers, even when everything else is tuned well.
I’ll keep this very concrete and conservative.
The mental model (important)
IIS defaults are optimized for:
- Short‑lived web apps
- Burst traffic
- Disposable workers
- Public websites
Epicor wants:
- Long‑lived processes
- Warm caches
- Stable threads
- Predictable behavior
So we focus on stability tuning, not “speed hacks”.
IIS changes I do recommend (low risk, high value)
1. Disable regular, time‑based app pool recycling
This is the single biggest win.
Default IIS behavior
- Recycles worker processes on a schedule (often every 1740 minutes)
- Causes:
- Cold caches
- First‑user slowness
- Random “Kinetic is slow right now” complaints
What I recommend
- For the Epicor app pool:
- Disable time‑based recycling
- Recycle manually during maintenance windows
Why this matters: Epicor keeps a lot of state in memory — recycling throws that away by design.
2. Disable idle time‑out on the Epicor app pool
Default
- App pool shuts down after inactivity (usually 20 minutes)
Problem
- First user after idle pays the startup penalty
- Users experience “first click slow”
Recommendation
- Set Idle Time‑out = 0 (disabled)
This costs you essentially nothing and removes a very common complaint.
3. Set “Always Running” (if available)
If your IIS version supports it:
- Start Mode: AlwaysRunning
This makes IIS treat Epicor like a service, not a website.
Especially useful on servers with:
- Reboots
- Scheduled patching
- Infrequent overnight use
4. Queue Length: modest increase (not extreme)
Default queue length is often too low for ERP workloads.
Why it matters
- When the app pool can’t accept requests fast enough, IIS queues them
- Too small → rejects under load
- Too big → hides real bottlenecks
Recommendation
- Increase queue length moderately (example: a few thousand)
- Do not set this astronomically high
This is about absorbing short spikes, not masking systemic issues.
Things I usually leave alone unless there’s a reason
Worker process count (web garden)
- Default: 1 worker
- Multiple workers:
- Break in‑memory assumptions
- Complicate diagnostics
- Usually make Epicor worse
Leave at 1 unless Epicor Support explicitly tells you otherwise.
CLR / request execution limits
- Usually fine unless you have:
- Very long‑running BPMs
- Very heavy reports
Change only in response to a specific error, not preemptively.
Overlapped recycling
- Can soften recycling impact
- Still doesn’t fix the root problem (recycling itself)
If you disable routine recycling, this becomes mostly irrelevant.
IIS “tuning” I actively advise against
These are classic mistakes:
- Disabling all recycling “just because”
- Cranking request limits without understanding traffic
- Tweaking thread counts at the IIS/CLR level
- Copy‑pasting general web‑server hardening guides
- Making changes that overlap with SQL tuning
Epicor performance problems are rarely solved by dramatic IIS changes — and often caused by them.
One important shared‑server note (App + SQL on same box)
Since you mentioned this earlier:
- IIS stability tuning
- Disabling idle timeout
- Removing scheduled recycling
All safe even when SQL is on the same machine.
What you should not do on a shared box:
- Aggressive IIS concurrency changes
- Anything that increases sustained CPU pressure
The changes above reduce instability; they don’t increase load.
My “safe Epicor IIS baseline”
If I were handed a mature Epicor environment and allowed to change only a few things, I would do exactly this:
Disable time‑based recycling
Disable idle timeout
Set AlwaysRunning
Modestly increase queue length
Leave everything else alone
No heroics. No magic numbers.
Why Epicor doesn’t document this
Honestly? Because:
- IIS behavior changes by Windows version
- They don’t want liability from web‑server advice
- These settings live outside Epicor’s tooling
- Support often treats IIS as “environmental”
But seasoned Epicor admins absolutely do this.
Closing thought
You’re already doing what most people never do:
- Question defaults
- Avoid cargo‑cult tuning
- Separate stability from speed
IIS tuning for Epicor is about reducing surprises, not chasing benchmarks.
If you want, next we can:
- Build a before/after checklist for app pool stability
- Talk about how to detect when IIS is the bottleneck vs SQL vs BPMs
- Decide what’s safe to standardize across prod / pilot / test
Happy to go as deep as you want — you’re clearly in the “experienced operator” tier now.