Infor Factory Track Session Timeout Configuration: The On-Premise Admin’s Definitive Guide to Web.config, IIS, and Inactivity Management

If you manage an on-premise Infor Factory Track deployment, few things derail shop floor productivity faster than a poorly tuned session timeout. Workers mid-transaction on a barcode scanner suddenly get kicked back to the login screen. Supervisors lose unsaved labor entries. Receiving clerks have to re-authenticate every ten minutes on a busy dock. These are not hypothetical complaints — they are the actual support tickets that land in my inbox week after week.

The root cause is almost always the same: default session settings that were never deliberately configured for a manufacturing environment. This guide covers exactly what to change, where to change it, and why each layer of the stack matters — so your Infor Factory Track environment behaves like a precision production tool rather than a leaky web app.

Why Session Timeout Is Uniquely Critical in Factory Track

Factory Track is not a traditional office application. Its users — warehouse associates, machine operators, receiving staff — interact with it in short, intense bursts rather than continuous sessions. A receiving clerk might scan 40 items in 4 minutes, then walk away for 20 minutes to move a pallet. A session that expires in 15 minutes (ASP.NET’s default) will consistently drop that worker right in the middle of their operational context.

On top of that, Factory Track’s Mongoose-based web application runs across a range of form factors: desktop browsers, Zebra handhelds, Honeywell scanners, and wall-mounted kiosks. Each device category can have different idle patterns, and a single global timeout value rarely serves all of them well. Understanding the configuration layers gives you the flexibility to align session behavior with actual operational reality.

The Three Layers That Control Session Timeout

Getting Factory Track session management right requires touching three distinct layers: the ASP.NET application configuration (web.config), IIS application pool settings, and the Factory Track application-level parameters. Changing only one and ignoring the others is the most common reason implementations still timeout unexpectedly after an admin swears they “already fixed it.”

Layer 1: The web.config File — Your Primary Control Point

For on-premise Factory Track deployments, the web.config file lives in the Factory Track web application root directory — typically something like C:\inetpub\wwwroot\FactoryTrack\ or a path defined during your installation. This XML file governs session state behavior at the ASP.NET runtime level.

Session State Timeout

The core timeout parameter sits inside the <system.web> node:

<system.web>    <sessionState      mode="InProc"      timeout="60"      cookieless="false"      cookieName="ASP.NET_SessionId" />  </system.web>

The timeout attribute is expressed in minutes. The ASP.NET default is 20 minutes — far too short for a shop floor context. For most Factory Track deployments, a value between 60 and 120 minutes is appropriate for workstations and scanning stations. For kiosk-style deployments where the device is always logged in, some teams set this to 480 (8 hours) to match a full shift.

Important: The timeout value resets on every server-side request. A user who scans a barcode every 30 minutes will stay authenticated indefinitely with a 60-minute timeout — the clock restarts each time the scanner sends a transaction to the server.

Forms Authentication Timeout

Factory Track uses Forms Authentication for most on-premise deployments. This has its own independent timeout setting that many admins miss entirely:

<system.web>    <authentication mode="Forms">      <forms        loginUrl="~/Login.aspx"        timeout="120"        slidingExpiration="true"        cookieProtection="All" />    </authentication>  </system.web>

The timeout here is also in minutes and controls the authentication ticket lifetime. Critically, slidingExpiration="true" means the ticket renews on every request — mirror this behavior with your session state timeout or you will create mismatches where the session survives but the auth ticket expires (or vice versa), producing confusing error states.

Best practice: Set Forms Authentication timeout equal to or slightly higher than your sessionState timeout. If sessionState is 60 minutes, set Forms Authentication to 65–70 minutes.

HttpRuntime Execution Timeout

There is a third web.config value that trips up Factory Track deployments processing large inventory transactions or complex shop floor moves:

<system.web>    <httpRuntime      executionTimeout="600"      maxRequestLength="10240" />  </system.web>

The executionTimeout (in seconds) determines how long ASP.NET will process a single request before terminating it. The default is 110 seconds. For Factory Track scenarios involving bulk inventory adjustments, receipt posting, or integration-heavy transactions connected to Infor LN or Infor ION, bumping this to 600 seconds (10 minutes) eliminates premature request termination that users misdiagnose as a “timeout.”

Layer 2: IIS Application Pool Settings

Even with perfectly tuned web.config values, IIS can override everything at the application pool level. There are two settings to review in IIS Manager under the application pool assigned to your Factory Track site.

Idle Time-out (minutes)

Found under Application Pools → Advanced Settings → Process Model → Idle Time-out, this setting recycles the worker process when it receives no requests for the configured period. The default is 20 minutes — meaning after 20 minutes of zero traffic (not per-user idle time, but zero traffic to the entire app), IIS kills and restarts the worker process. This terminates all in-memory sessions.

For InProc session mode (the Factory Track default), this is catastrophic because all session data lives in the worker process memory. Set this to match your expected low-traffic window — for a 24/7 plant, set it to 0 (disabled). For a single-shift environment, 480 minutes covers a full 8-hour shift with some buffer.

IIS Manager → Application Pools → [FactoryTrackPool] → Advanced Settings    → Process Model → Idle Time-out (minutes): 0

Regular Time Interval Recycling

Under Recycling → Regular Time Interval, IIS defaults to recycling the application pool every 1,740 minutes (29 hours). In a shift-based manufacturing environment, schedule this recycle during a planned downtime window — typically between shifts — rather than letting it happen randomly:

Recycling → Regular Time Interval:  0  Recycling → Specific Times:         06:00 (before first shift)

Layer 3: Factory Track Application-Level Inactivity Settings

Beyond the web infrastructure, Factory Track itself has application-level parameters that govern user inactivity behavior independently from ASP.NET session expiration. These are accessible through the Factory Track administration interface rather than the file system.

In the Factory Track Admin Console, look for the Application Settings or Security Configuration section depending on your version. Parameters of interest include:

• Auto-Logoff Timeout: This triggers a client-side countdown and logs the user out at the application level, separate from the server-side session. Align this with your web.config session timeout or ensure it fires before the server session expires to give users a graceful warning.
• Screen Lock vs. Logoff: Some Factory Track versions support screen locking rather than full logoff on inactivity. For shared kiosk deployments, screen lock with PIN re-entry is significantly less disruptive than a full session termination.
• Device-Specific Profiles: If your deployment includes both desktop workstations and handheld scanners, configure separate timeout profiles where the platform supports it. Handhelds typically need longer timeouts due to the physical nature of warehouse work.

On-Premise Deployment: The Settings Checklist

Here is a consolidated reference for what to validate on every on-premise Factory Track environment:

Session Mode: InProc vs. State Server vs. SQL Server

Factory Track on-premise deployments almost universally run in InProc session mode because it is the fastest and requires no additional infrastructure. However, InProc has a critical vulnerability: any application pool recycle wipes all active sessions. Every user gets logged out.

For high-availability requirements or environments where unplanned IIS restarts are common, consider upgrading to SQL Server session state mode:

<sessionState    mode="SQLServer"    sqlConnectionString="Data Source=SQLSERVER;Integrated Security=True"    timeout="120" />

SQL Server session state survives IIS recycling, server restarts, and even load-balanced multi-server deployments. The trade-off is slightly higher latency on session reads and writes. For most single-server on-premise Factory Track deployments, InProc with a well-tuned IIS recycle schedule is sufficient. For larger multi-server or high-availability environments — particularly where Factory Track integrates with Infor CloudSuite as part of a hybrid architecture — SQL Server session mode is worth the added complexity.

Common Mistakes That Cause Unexpected Session Drops

After working through dozens of Factory Track environments, these are the mistakes I see consistently:

• Setting web.config timeout without touching IIS idle time-out. The IIS default of 20 minutes will keep overriding your 120-minute web.config setting. Both must be configured in concert.
• Mismatched Forms Auth and sessionState timeouts. When Forms Authentication expires before the session, users see cryptic error pages rather than a clean login redirect. When the session expires before Forms Auth, users get redirected to login but their auth cookie is still valid — which can cause redirect loops in some versions.
• Ignoring the impact of application pool recycling during shift changes. If IIS recycles at 2:00 AM on a 24/7 plant floor, third-shift workers lose their sessions. Audit your recycle schedule against your actual shift patterns.
• Treating all Factory Track clients the same. A desktop PC in receiving and a Zebra TC8300 on the dock floor have fundamentally different usage patterns. Where Factory Track supports per-device or per-role profiles, use them.

Getting Expert Help When Configuration Gets Complex

Session timeout configuration is straightforward in theory but becomes genuinely complex in practice — especially when Factory Track sits within a broader integration landscape that includes Infor ION connections, real-time ERP synchronization, and multi-device deployments across large facilities.

If your team is troubleshooting persistent timeout issues, planning an on-premise upgrade, or evaluating a migration path to a cloud-based architecture, the Sama Consulting Factory Track practice has worked through these exact scenarios across aerospace, automotive, and industrial manufacturing environments. Our system optimization and performance tuning services cover this layer of the stack in depth, and our team is available for targeted assessments or full engagement support. You can also explore our broader Infor insights for implementation guidance across the full Infor product suite.

For a direct conversation about your Factory Track environment, reach out to the Sama team — we’re happy to start with a focused diagnostic before recommending any path forward.

Article authored by the Sama Consulting technical team — Infor implementation and integration specialists with over 20 years of on-premise and cloud ERP experience across manufacturing, distribution, and industrial sectors.