Infor Factory Track Session Timeout Configuration via web.config

Session timeout is one of the configuration items that receives the least attention during a Factory Track go-live and generates the most support tickets in the months that follow. In a manufacturing execution environment, the consequences of getting it wrong are operational, not abstract.

At the permissive end, a timeout set too high leaves authenticated sessions open on shared shop floor terminals long after an operator has moved on. Factory Track is routinely deployed on shared kiosks and barcode scanning stations where a single terminal is used by multiple operators across a shift. An active session belonging to one operator remains fully accessible to anyone who approaches that terminal, with no reauthentication prompt. In environments subject to FDA 21 CFR Part 11 traceability requirements, ISO 9001 access control clauses, or internally mandated IT security policies, that exposure is a compliance failure with audit consequences, not a configuration oversight that can be deferred.

At the restrictive end, a timeout set below the normal duration of a shop floor task generates constant reauthentication friction at exactly the wrong moments. The pattern appears reliably in post-go-live support queues: an operator steps away from a Factory Track terminal for 12 to 15 minutes to manage a material transfer or a quality hold, returns to find their session expired, and loses transaction continuity while working through the login sequence again. In a high-throughput manufacturing line, that interruption compounds across dozens of operators and hundreds of daily interactions.

Shift-change workflows introduce a further dimension. In Factory Track environments integrated with Infor Workforce Management for labor tracking and clocking, a session that expires mid-transaction during a shift handover can leave a clocking record in an indeterminate state. Depending on your integration topology, resolving that requires manual correction in Infor WFM or, if labor data flows through Infor ION into Infor LN, a correction at the ERP layer that bypasses the normal automated flow. Configuring session timeout correctly is therefore as much a data integrity requirement as it is a security one.

Understanding the web.config Role in Factory Track Session Management

Factory Track is deployed as an ASP.NET web application hosted under IIS, and its session behavior is governed at three distinct configuration layers that interact in ways that catch even experienced administrators off guard.

The first layer is the sessionState element inside the system.web section of the application-level web.config. This controls how long the server-side session object is retained in memory after the last HTTP request from a given client. It is the setting most practitioners reach for first, and it is the right place to start, but it is not sufficient on its own.

The second layer is the forms authentication configuration, also inside system.web, which controls the lifetime of the encrypted authentication ticket carried in the client-side browser cookie. According to the ASP.NET forms authentication documentation on docs.microsoft.com, this ticket expiry operates on a separate clock from the server-side session lifetime. When the ticket expires, the user is redirected to the login page regardless of whether their session is still valid server-side. The slidingExpiration attribute on the forms element determines whether that ticket lifetime resets on each request or counts down from initial login. The interaction between this layer and sessionState is where the majority of misconfiguration problems originate in live Factory Track environments.

The third layer operates entirely outside web.config. The IIS application pool idle time-out, stored in applicationHost.config and managed through IIS Manager, controls how long IIS allows the worker process serving Factory Track to remain inactive before terminating it. When the worker process is terminated, all InProc session state is destroyed simultaneously, irrespective of the sessionState timeout value in web.config. Understanding all three layers before touching any single value is what separates a targeted configuration change from a troubleshooting spiral.

Locating the Correct web.config File in Your Factory Track Installation

In a standard Factory Track on-premises deployment, the application is installed under an IIS site root such as C:\inetpub\wwwroot\FactoryTrack or a custom path defined during installation. The application-level web.config at the root of that directory is the authoritative source for session configuration within the Factory Track application context.

IIS operates a hierarchical configuration model, and multiple web.config files may be active simultaneously at different scopes. A machine-level web.config at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config establishes defaults for all ASP.NET applications on the server. If the application-level web.config does not explicitly declare a sessionState element, that machine-level default applies silently. This is the source of a recurring diagnostic puzzle: the Factory Track application-level web.config contains no sessionState element, the observed timeout appears to be 20 minutes, and the administrator cannot locate where that value originates. The machine-level framework default is the answer, as documented in the ASP.NET configuration hierarchy reference on docs.microsoft.com.

In multi-tenant IIS environments where Factory Track runs alongside other Infor applications on the same server, a site-level web.config may also apply to all applications under a given IIS site, sitting between the machine-level defaults and the application-level file. Before modifying any timeout value, open the IIS Manager Configuration Editor, navigate to the Factory Track application node, and inspect the source column next to each setting to confirm which file is currently authoritative for the running application.

If your deployment surfaces Factory Track through the Infor OS portal, Infor OS manages its own session context through the portal layer, configured separately through the Infor OS administration console. Verify your deployment topology before assuming all session behavior is under web.config control.

Configuring the sessionState Timeout Parameter

The sessionState element in system.web is the primary lever for controlling how long an authenticated user’s server-side session data is retained. The ASP.NET sessionState element reference on docs.microsoft.com specifies that the timeout attribute accepts an integer value in minutes, with a framework default of 20 when the attribute is absent.

For Factory Track shop floor terminal deployments, the appropriate value depends on your shift structure, typical operator task durations, and security policy. A value between 30 and 60 minutes is common for production floor kiosks where operators may step away for extended task cycles. Administrative workstations typically warrant a shorter value of 15 to 20 minutes, aligned to internal access control requirements.

When mode is set to InProc, the timeout behaves as a sliding window: each HTTP request resets the idle counter from zero. A session expires only when the user has had no application interaction for the full configured duration. Setting the value above your shift length creates compliance exposure. Setting it below the duration of a typical transaction sequence generates the operational disruption that drives floor-level complaints within days of go-live.

<configuration>    <system.web>      <sessionState mode="InProc" timeout="30" />    </system.web>  </configuration>  

Replace the timeout value with the integer appropriate to your environment. If your deployment uses SQL Server or StateServer session mode rather than InProc, the timeout attribute still governs session expiry, but session data survives application pool recycling, which changes the IIS idle time-out calculus discussed in the next section.

Setting the Forms Authentication Timeout and Alignment with Session Timeout

The forms authentication timeout operates on a separate clock from sessionState, and failure to align the two values is the most common misconfiguration pattern in Factory Track production deployments. The forms element inside system.web/authentication governs the lifetime of the encrypted authentication ticket in the client browser cookie. When that ticket expires, ASP.NET redirects the user to the configured login URL regardless of whether their server-side session is still active and holding transaction context.

The slidingExpiration attribute controls whether the ticket lifetime extends on each request. When set to true, the cookie expiry is renewed with each HTTP interaction, mirroring the sliding behavior of InProc sessionState. When set to false, the ticket counts down from initial login and expires at a fixed interval. In most Factory Track environments where continuous operator engagement is expected, slidingExpiration should be true, and the forms timeout should match the sessionState timeout so both clocks advance in parallel.

A mismatch where the forms timeout is shorter produces a failure that is difficult to diagnose without understanding both layers: the operator is redirected to the login page while their server-side session is still valid. A mismatch in the opposite direction, where the forms timeout exceeds the sessionState timeout, allows the authentication cookie to remain valid after session data has been discarded server-side. The next request passes cookie validation without a login redirect, but the session is new and any in-progress transaction context is gone without warning.

<configuration>      <system.web>        <authentication mode="Forms">          <forms               loginUrl="~/Account/Login"               timeout="30"               slidingExpiration="true" />        </authentication>        <sessionState             mode="InProc"             timeout="30" />      </system.web>    </configuration>  

Keep both timeout values identical unless your security policy explicitly requires the authentication ticket to expire before the session. In environments enforcing an absolute session limit for compliance, set slidingExpiration to false and align both values to the required fixed duration.

IIS Application Pool Idle Time-Out and Its Impact on Factory Track Sessions

The IIS application pool idle time-out is the configuration setting most frequently overlooked in Factory Track deployments, and it accounts for a disproportionate share of unexplained session drops reported by night shift operators and weekend production crews. The default value in IIS is 20 minutes. If no HTTP requests reach the Factory Track application pool for 20 consecutive minutes, IIS terminates the worker process to reclaim server memory. All InProc session state is destroyed at that moment, every active session on the server is invalidated, and the next request from any connected user results in a new session and a login redirect, regardless of the web.config sessionState timeout.

This behavior is documented in the IIS processModel configuration reference on docs.microsoft.com. The idle time-out setting is stored in applicationHost.config and configured through IIS Manager by selecting the Factory Track application pool, opening Advanced Settings, and locating Idle Time-out (minutes) under the Process Model group.

For Factory Track production environments running InProc session mode, set the Idle Time-out value to 0 to disable automatic worker process shutdown due to inactivity. This supports 24-hour manufacturing operations where transaction volume may drop to near zero during overnight skeleton-crew shifts without that silence translating into a forced session reset for connected users.

If infrastructure constraints make disabling idle time-out impractical, switching sessionState mode from InProc to SQLServer resolves the dependency between worker process lifecycle and session durability. Session data is then stored in a SQL Server session state database and survives recycling events. Also review the application pool scheduled recycling interval, which defaults to 1,740 minutes in IIS. A scheduled recycle carries the same InProc session destruction consequence and should be evaluated alongside idle time-out when hardening a Factory Track pool for continuous manufacturing operations.

Applying Configuration Changes Without Service Interruption

The ASP.NET runtime monitors web.config using a file system watcher, and any save to the file triggers an automatic application domain restart. A web.config change on a live Factory Track server immediately invalidates all active InProc sessions on that instance. On a production manufacturing floor, this is functionally equivalent to logging out every connected operator at once.

Stage web.config changes during a planned maintenance window aligned to a natural operational break, typically a shift change or a scheduled line stoppage. Before applying the change, confirm that no time-critical transactions are open in Factory Track and that supervisors on the floor are aware of the impending application restart.

After saving the modified web.config, verify the application domain has restarted by checking the Windows Application Event Log for an ASP.NET event indicating the application domain was unloaded and reloaded. Use the appcmd command-line tool to confirm the running state of the Factory Track application pool. To verify the new sessionState timeout is in effect, open the IIS Manager Configuration Editor, navigate to the Factory Track application, select system.web/sessionState, and confirm the timeout value and its source file match your intended change.

In high-availability deployments where Factory Track runs across multiple IIS nodes behind a load balancer, apply the web.config change to each node in sequence and validate the configuration on each before proceeding. Configure sessionState mode for SQLServer in these topologies so that sessions are preserved at the database layer during the rolling restart rather than lost when the InProc store on any node is cleared.

Common Misconfiguration Scenarios and How to Diagnose Them

The first scenario that surfaces repeatedly in Factory Track post-go-live engagements is a timeout value modified in the wrong web.config file. An administrator opens the machine-level web.config at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config rather than the application-level file in the Factory Track site root. The machine-level change has no visible effect because the application-level file takes precedence. The administrator increases the value further, still sees no change, and concludes the setting has no effect. The diagnostic step is to open the IIS Manager Configuration Editor for the Factory Track application, navigate to system.web/sessionState, and read the source column. That column identifies precisely which file is supplying the current effective value. If it does not point to the Factory Track application-level web.config, either that file lacks an explicit sessionState element or a value at a higher scope is being resolved in an unexpected direction within the hierarchy.

The second scenario involves forms authentication timeout shorter than sessionState timeout. Operators report being redirected to the login page during active shifts, but IT confirms the sessionState timeout is correctly configured at 45 or 60 minutes. The diagnostic step is to inspect the forms element inside system.web/authentication in the application-level web.config. If the timeout attribute is set to the ASP.NET default of 30 minutes and slidingExpiration is false, every operator faces a forced reauthentication every 30 minutes regardless of the sessionState value. Aligning the forms timeout to the sessionState timeout and enabling slidingExpiration resolves the issue. Teams working through configuration alignment of this kind as part of a broader hardening engagement will find this intersection of ASP.NET and IIS governance central to the Factory Track administration work carried out through Sama Consulting’s Factory Track consulting practice.

The third scenario is the IIS application pool idle time-out conflict. The web.config timeout values are correctly aligned, but operators on night shift or weekend skeleton-crew runs report session drops that day shift operators never encounter. The pattern of failures correlating with low transaction volume periods is the diagnostic signal. Check the Idle Time-out value for the Factory Track application pool in IIS Manager Advanced Settings. If it is set to the IIS default of 20, and InProc session mode is in use, that is the root cause. Setting the value to 0 resolves it immediately. Validating the IIS application pool configuration alongside the web.config is a standard step in the Factory Track administration guidance that the Sama Consulting Inc Infor practice applies across on-premises and hybrid deployments.

For teams managing Factory Track as part of a wider Infor landscape that includes Infor LN or Infor CloudSuite Industrial, the configuration governance work extends beyond the Factory Track web.config into the broader platform stack, which is covered through Sama Consulting’s Infor CloudSuite services. Technical coverage of related Infor administration topics is published in the Sama Consulting insights archive, which includes material on Infor Workforce Management configuration, Infor ION integration administration, and ERP platform governance across the Infor manufacturing product family.

Meta description: Technical guide to configuring Infor Factory Track web.config session timeout covering sessionState, forms authentication, and IIS application pool settings.