This article has been prompted by discussion within the comments section on my recent article, "Simple Windows Utilities Every Sage CRM Administrator Should Know", and an email from an ISV about best practice on restarting a system.  There is quite a lot to think of, and I am sure that I will have overlooked some points.

How to Reduce Login Bottlenecks and Improve User Experience

Every Sage CRM administrator eventually faces this situation.

A server needs to be restarted during working hours. Perhaps Windows updates were applied. Perhaps IIS needs recycling. Perhaps memory pressure requires a reboot. Whatever the reason, the result is often the same: the users all try to log back in at once!

And that is where the pain begins.

Sage CRM is not a single executable. It is a collection of moving parts that must initialise correctly before the system is truly ready to serve users.

When those components are still starting, and users begin logging in, bottlenecks can occur.

Let us look at how to manage this properly and reduce the impact on users.

Why Restarts Can Cause Bottlenecks

When Sage CRM starts, the following components must initialise:

• IIS and the CRM application pool

• The eware.dll ISAPI extension

• Apache Tomcat and its web applications

• CRM Services:

  • CRM E-mail Manager

  • CRM Escalation Service

  • CRM Indexer Service

  • CRM QuickFind Service

• Database connections and connection pools

• CRM metadata loading into memory

• Cache initialisation

If 20 or 50 users attempt to log in while this process is still underway:

• SQL connection pools can spike

• Metadata may load multiple times in parallel

• The application pool may recycle under pressure

• First logons appear slow or time out

The system is not broken. It is simply being asked to initialise and serve users at the same time.

The Most Important Step: Use Lock System

Before any planned restart during business hours:

Go to
Administration → System → Lock System

Locking the system prevents users from logging in while the environment is starting.

This avoids the classic scenario where:

• The login page appears

• Users assume the system is ready

• The backend is still initialising

Lock System gives the administrator control of the experience.

A best practice sequence is:

1. Notify users of maintenance

2. Lock System

3. Perform the restart

4. Validate the system is fully started

5. Unlock System

6. Notify users that CRM is ready

This single step removes most restart-related frustration.

Use a Controlled Restart Script

It is strongly recommended that partners and customers use controlled restart scripts rather than relying on ad hoc restarts.

Instead of allowing Windows to start services opportunistically:

Stop in order:

1. CRM Services

2. IIS

3. Tomcat (if separate)

Start in order:

1. IIS

2. Application Pool

3. Tomcat

4. CRM Services

Introducing short delays between stages ensures each layer is fully initialised before the next begins.

Several partners use Task Scheduler scripts to handle this cleanly and consistently. This is good operational practice.  Please see the comments here for some examples.

Warm the Environment Before Unlocking

One of the simplest and most effective techniques is to “warm” the system before unlocking it.

After the restart, but before unlocking:

Log in as Administrator and:

• Open a Company list

• Open a Person list

• Run a Quick Find

• Execute a small report

This forces:

• Metadata loading

• View validation

• Cache population

• QuickFind initialisation

In effect, you are priming the engine before allowing general traffic.

Advanced Option: Automated Warm Up via SOAP or REST

In larger environments, a lightweight script can:

• Perform a SOAP login

• Execute a simple FindRecord

• Call a REST endpoint

• Trigger QuickFind

This ensures that:

• Sessions are created

• Connection pools are active

• Metadata is loaded

• Java components are responsive

This reduces the “first real user is slow” effect.

It is not essential for smaller systems, but it is beneficial for larger deployments.

IIS Application Pool Settings Matter

You can further reduce cold start behaviour by tuning IIS.

Recommended settings include:

• Start Mode: AlwaysRunning

• Idle Time-out: 0 (where appropriate)

• Load User Profile: True

• Enable site preload

These settings help prevent unnecessary cold starts and improve resilience.

Staggered User Return

Another simple improvement:

Avoid announcing “system live” at exactly 9:00 AM.

Instead:

• Unlock

• Allow a small group to log in first

• Then notify the wider team

This reduces login surge pressure.

If You Are Restarting Frequently

If working hours restarts are common, it is worth investigating root causes:

• Memory pressure

• IIS recycling configuration

• SQL maintenance

• Windows updates

• Indexer backlog

• Service instability

A healthy Sage CRM system should not require frequent daytime reboots.

A Practical Working Hours Restart Model

Here is a recommended approach:

1. Notify users

2. Lock System

3. Run the controlled restart script

4. Wait for all services to report running

5. Log in as Administrator and warm the system

6. Check logs for errors

7. Unlock System

8. Notify users

This turns a potentially chaotic restart into a controlled maintenance event.

Final Thoughts

Managing restarts is not about avoiding downtime entirely. It is about controlling the user experience.

By:

• Using Lock System

• Restarting services in the correct order

• Warming the environment

• Tuning IIS appropriately

You can dramatically reduce login bottlenecks and help users get back to work quickly and smoothly.

These are simple techniques, learned through experience, that make a real difference in production environments.

I hope they prove useful in your own Sage CRM deployments.

And if you disagree with me or want to add any more advice, then please let me know by commenting below!