This blog gives a consolidated overview of the most common SMB timeouts in Windows and their behaviors. Some of these legacy timeouts or timers are optional, implementation specific, not defined or not required by the protocol specifications. Let’s recall that MS-CIFS documents the protocol implemented in Windows NT and Windows 98, whereas MS-SMB describes the extensions added in Windows 2000 and beyond.

A subsequent blog discusses “SMB 2.x and SMB 3.0 Timeouts in Windows”:

NOTE: For questions on MS-CIFS and MS-SMB documents, please post in the Open Specifications Forum: Windows Protocols at

SMB exchange timeout

Here, I am using the term “exchange timeout”. There is no such definition in the specifications.
The exchange timeout can be defined as the maximum amount of time that the client redirector waits for a server to respond to a timed SMB message. There are three variants of SMB exchange timeout that are observed commonly in Windows: client session timeout, extended session timeout, offline file timeout.

Client session timeout
It is the most common exchange timeout. This is defined in [MS-CIFS] as a system-wide parameter Client.SessionTimeoutValue. This value can be configured through the SessTimeout registry key [KB102067].
Value type: Dword
Value name: SessTimeout
Default:    45 seconds (Windows NT)
Default:    60 seconds (Windows 2000)

Extended session timeout
This optional timeout may be useful in high latency networks. It applies to a timed exchange with a server listed in ServersWithExtendedSessTimeout.
Value type: Dword
Value name: ExtendedSessTimeout
Default:    1000 (seconds)
Value type: Multi-string
Value name: ServersWithExtendedSessTimeout
Default:    <null>
These were introduced in Windows XP.

Offline file timeout
The client uses this optional timeout for a timed operation on an offline file, normally indicated by the FILE_ATTRIBUTE_OFFLINE attribute. This timeout can be configured with the registry parameter
Value type: Dword
Value name: OffLineFileTimeoutIntervalInSeconds
Default:    1000
This was introduced in Windows 2000.

Request Expiration Timer

This optional timer controls the scanning interval of outstanding commands. It is used as a scavenger cycle for outstanding commands that met their exchange timeout deadlines. Windows NT and Windows 98 CIFS clients implement a default value of 30 seconds for the Request Expiration Timer.
When an outstanding command has passed the exchange timeout, the client should close the connection if this remains idle. The time the client effectively closes the connection will vary, but bounded to a minimum of Client.SessionTimeoutValue.
For example, let’s assume that at a 30 seconds scanning interval, an outstanding command has a 60 seconds session timeout due to expire in 5 seconds, the redirector will close the connection at the next scavenger cycle. The effective connection closing time would be around:
Session timeout (60 sec) – time due at the scavenger timer (5 sec) + next scavenger time (30 sec) = 85 sec.
Commands exempt from the Request Expiration Timer
The list of exempt commands is defined in MS-CIFS Request Expiration Timer Event.
• Read and write commands issued on an Open to a named pipe via the following commands:
• SMB_COM_LOCKING_ANDX Request with the Timeout field set to a nonzero value

The Echo behavior

An Echo request is sent to determine whether or not an idle connection has been lost. For an outstanding timed network operation, the connection would be closed upon the expiration of the exchange timer. The Echo mechanism does not prevent the connection from being closed if there is no response to any outstanding command beyond the exchange timeout. This way, the client avoids continuing Echo-probing a known dead connection. If the server is responding to Echo requests, the client will wait until the exchange times out, and the client will not send any interim response to the calling application.

OpLock Break Acknowledgment Timer

This timer controls the time the server waits for a client to acknowledge an OpLock break request, if an acknowledgement is required. If an OpLock break acknowledgment is not received before the timer elapses, the server locally breaks the lock. This is controlled through the OplockBreakWait registry [KB129202].
Value type: Dword
Value name: OplockBreakWait
Default:    35 (seconds)

Idle Connection Timer

This is the amount of time that a connection can be idle before being disconnected. An idle connection is defined as a connection which has no existing open handles (no open files, directories, search contexts, etc.), and no pending operation. The Idle Connection Timer is implementation-specific.
When the server receives a message, Server.Connection.IdleTime is set to the current time plus Server.AutoDisconnectTimeout [MS-CIFS].
On Windows servers it can be configured through the Autodisconnect registry key [KB297684].
Value type: Dword
Value name: Autodisconnect
Default:    15 (minutes)
The Autodisconnect can also be configured through group policy:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
"Microsoft network server: Amount of idle time required before suspending session"

In older Windows clients (e.g. Windows 2000, Windows 2003), the client closes an idle connection based on the KeepConn workstation parameter [KB819108].
Value type: Dword
Value name: KeepConn
Default:    600 (seconds)
KeepConn is no longer used, except in Installable File System Kit (IFSKIT).

Unused Open Search Timer

This optional timer that controls the amount of time that an open search can stay unused before the server closes the search context. It is used as maximum age to scavenge open searches, see Server.SrvSearchMaxTimeout [MS-CIFS].
On Windows, the unused search timer can be configured as
Value type: Dword
Value name: MaxKeepSearch
Default:   3600 (seconds)
Range: 10 – 10,000

This legacy timer was for MS DOS applications which did not have the capability to issue a “close search” primitive, such as Win32 FindClose, to explicitly close a search.

Authentication Expiration Timer

This timer was introduced in MS-SMB. It is used to periodically scan and mark authenticated sessions as expired when their specific expiration time is reached. If a session is expired, SMB operations will receive STATUS_NETWORK_SESSION_EXPIRED and the client must re-authenticate. Note that the server does not enforce session expiration on the following commands while the authentication state of a session is expired:
- SMB_COM_SESSION_SETUP_ANDX for session renewal,
- SMB_COM_FLUSH (see KB 943459) ,
- SMB_COM_LOCKING_ANDX as an oplock break acknowledgement (see KB 943459),

Note that KB 943459 does not apply to SMB 2. The fix was done on srv.sys (SMB server) and mitigates older SMB clients that are not capable of re-authenticating upon receiving a STATUS_SESSION_EXPIRED error in response to an oplock break acknowledgment.
More details are discussed later on session expiration and dynamic re-authentication.

Authentication-specific expiration is driven by the authentication package. For instance, NTLM authentication has no explicit expiration time; authentications done with NTLM do not explicitly expire.
For Kerberos authentication package, the service ticket’s endtime is derived from the MaxServiceTicketAge when the ticket is issued, as documented in [MS-KILE]. The default MaxServiceTicketAge is 10 hours and can be adjusted though Group Policy Management Console under Default Domain Policy/ Account Policies / Kerberos Policy.
In addition, even if a session did not explicitly expire, the server may forcibly disconnect the user SMB session based upon a group policy setting and user’s logonHours [MS-ADA1].
The group policy setting is:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
"Microsoft network server: Disconnect clients when logon hours expire"
This policy sets the registry key:
When this policy is enabled, the SMB session is disconnected when the user's logon hours expire.
When this policy is disabled, the session remains valid as long as it stays connected, even after logon hours expire, provided the session did not expire.
This policy may be configured on the Default Domain Policy and propagated through group policy to the computers. 
As an example, let’s assume contoso\user1 has logonHours configured to “Logon Denied” between 5:00 PM and 9:00 AM.  An SMB share \\server2008r2\Share is accessed from a Windows XP SP3 client at 4:59:30 PM where enableforcedlogoff is enabled. Once the clock ticks 5:00 PM, the client falls in logonHours expiry and the session is dropped. At 5:05 PM, when user1 attempts to access the share, a similar error is observed:

\\server2008r2\Share is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
Logon failure: account logon time restriction violation.

Session expiration and dynamic re-authentication
In Windows implementation, SMB session expiration is enforced based upon the client’s support of dynamic re-authentication capability [MS-SMB].
If the client enables the CAP_DYNAMIC_REAUTH capability bit, the server will enforce session expiration. If a client does not set CAP_DYNAMIC_REAUTH, the Windows server does not return STATUS_NETWORK_SESSION_EXPIRED. 
The SMB dynamic re-authentication feature was introduced in Windows XP. From there, Windows-based clients set the CAP_DYNAMIC_REAUTH capability bit to indicate to the server that the client supports re-authentication when the Kerberos service ticket for the session expires.
Windows servers do check CAP_DYNAMIC_REAUTH:
• If clientCapabilities sets CAP_DYNAMIC_REAUTH, the server will set Server.Session.AuthenticationExpirationTime to the expiry time returned by AcceptSecuirtyContext.
• If clientCapabilities does not set CAP_DYNAMIC_REAUTH, the server will not set Server.Session.AuthenticationExpirationTime, basically a CAP_DYNAMIC_REAUTH capability bit not set by the client means the session will not expire on the server side.


[MS-CIFS]: Common Internet File System (CIFS) Protocol
[MS-SMB]: Server Message Block (SMB) Protocol
[MS-WKST]: Workstation Service Remote Protocol
When the Kerberos ticket expires for a Kerberos-authenticated SMB connection that is created to a Windows Server 2003-based server, the oplock on a file cannot be broken in a timely manner
LanmanWorkstation Parameters: SessTimeout
LanmanServer Parameters: MaxKeepSearch
Remote Storage and Windows 2000
How to Troubleshoot Event ID 2009 Errors
“Microsoft network server: Disconnect clients when logon hours expire”
HOW TO: Limit User Logon Time in a Domain in Windows Server 2003