Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs.

Note: Some of the information in this section is subject to change because it applies to an unreleased, preliminary version of the Windows Server operating system, and thus may differ from the final version of the server software when released. All behavior notes that pertain to the unreleased, preliminary version of the Windows Server operating system contain specific references to Windows Server 2016 Technical Preview as an aid to the reader.

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system

  • Windows Server 2016 Technical Preview operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms SHOULD or SHOULD NOT implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that the product does not follow the prescription.

<1> Section 1.6: The following table illustrates the support of SMB 2 protocol on various Windows operating system versions.

Operating System

SMB 2 dialects supported

Windows 10, Windows Server 2016 Technical Preview

SMB 3.1.1, SMB 3.0.2, SMB 3.0, SMB 2.1, SMB 2.0.2

Windows 8.1,  Windows Server 2012 R2

SMB 3.0.2, SMB 3.0, SMB 2.1, SMB 2.0.2

Windows 8, Windows Server 2012

SMB 3.0, SMB 2.1, SMB 2.0.2

Windows 7, Windows Server 2008 R2

SMB 2.1, SMB 2.0.2

Windows Vista operating system with Service Pack 1 (SP1), Windows Server 2008

SMB 2.0.2

Previous versions of Windows

None. They support the SMB Protocol, as specified in [MS-SMB]

Windows Vista RTM implemented dialect 2.000, which was not interoperable and was obsoleted by Windows Vista SP1.

<2> Section 2.2.1.1: If SessionId is not equal to zero, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview fail the SMB2 NEGOTIATE request with STATUS_USER_SESSION_DELETED.

<3> Section 2.2.1.2: Windows clients set this field to 0xFEFF.

<4> Section 2.2.1.2: Windows servers do not use this field in the request processing and return the value received in the request.

<5> Section 2.2.1.2: If SessionId is not equal to zero, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview fail the SMB2 NEGOTIATE request with STATUS_USER_SESSION_DELETED.

<6> Section 2.2.2: Windows–based SMB2 servers leave this one byte of ErrorData uninitialized and it might contain any value.

<7> Section 2.2.2.2.1: Windows servers will never follow a symlink. It is the client's responsibility to evaluate the symlink and access the actual file using the symlink. A Windows server only returns STATUS_STOPPED_ON_SYMLINK when the open fails due to presence of a symlink.

<8> Section 2.2.2.2.1: Windows-based servers will return an absolute target to a local resource in the format of "\??\C:\..." where C: is the drive mount point on the local system and ... is replaced by the remainder of the path to the target.

<9> Section 2.2.3: Windows-based SMB2 servers fail the request and return STATUS_INVALID_PARAMETER, if the DialectCount field is greater than 64.

<10> Section 2.2.3: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview fail the request with STATUS_NOT_SUPPORTED if the Reserved field is set to a nonzero value.

<11> Section 2.2.3: A Windows Vista RTM–based client would send a value of zero in the Dialects array in SMB2 NEGOTIATE Request and a Windows Vista RTM-based server would acknowledge with a value of 6 in DialectRevision in SMB2 NEGOTIATE Response. This behavior is deprecated.

<12> Section 2.2.3: Windows Vista SP1 and Windows Server 2008 do not support this dialect revision.

<13> Section 2.2.3: Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 do not support this dialect revision.

<14> Section 2.2.3: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 do not support the SMB 3.0.2 dialect.

<15> Section 2.2.3: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not support the SMB 3.1.1 dialect.

<16> Section 2.2.4: A Windows Vista RTM–based client would send a value of zero in the Dialects array in SMB2 NEGOTIATE Request and a Windows Vista RTM–based server would acknowledge with a value of 6 in DialectRevision in SMB2 NEGOTIATE Response. This behavior is deprecated.

<17> Section 2.2.4: Windows Vista SP1 and Windows Server 2008 do not support this dialect revision.

<18> Section 2.2.4: Windows Vista SP1, Windows Server 2008, Windows 7 and Windows Server 2008 R2 do not support this dialect revision.

<19> Section 2.2.4: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 do not support this dialect revision.

<20> Section 2.2.4: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not support the SMB 3.1.1 dialect.

<21> Section 2.2.4: The "SMB 2.???" dialect string is not supported by SMB2 clients and servers in  Windows Vista SP1 and Windows Server 2008.

<22> Section 2.2.4: Windows-based SMB2 servers may set this field to any value.

<23> Section 2.2.4: Windows–based SMB2 servers generate a new ServerGuid each time they are started.

<24> Section 2.2.4: Windows clients do not enforce the MaxTransactSize value.

<25> Section 2.2.5: Windows-based clients always set the Capabilities field to SMB2_GLOBAL_CAP_DFS(0x00000001) and the server will ignore them on receipt.

<26> Section 2.2.5: Windows clients set the Buffer with a token as produced by the NTLM authentication protocol in the case, see [MS-NLMP] section 3.1.5.1.

<27> Section 2.2.6: Windows clients set the Buffer with a token as produced by the NTLM authentication protocol in the case, see [MS-NLMP] section 3.1.5.1.

<28> Section 2.2.9: The Windows SMB 2 Protocol client translates any names of the form \\server\pipe to \\server\IPC$ before sending a request on the network.

<29> Section 2.2.10: SMB2_SHAREFLAG_FORCE_LEVELII_OPLOCK is not supported on Windows Vista SP1 and Windows Server 2008.

<30> Section 2.2.13: Windows-based clients never use exclusive oplocks. Because there are no situations where the client would require an exclusive oplock where it would not also require an SMB2_OPLOCK_LEVEL_BATCH, it always requests an SMB2_OPLOCK_LEVEL_BATCH.

<31> Section 2.2.13: When opening a printer file or a named pipe, Windows-based servers ignore these ShareAccess values.

<32> Section 2.2.13: When opening a printer object, Windows-based servers ignore this value.

<33> Section 2.2.13: When opening a printer object, Windows-based servers ignore this value.

<34> Section 2.2.13: When opening a printer object, Windows-based servers ignore this value.

<35> Section 2.2.13: Windows server implementations reserve all bits that are not specified in the table. If any of the reserved bits are set, STATUS_NOT_SUPPORTED is returned.

<36> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<37> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<38> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<39> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<40> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<41> Section 2.2.13: Windows Vista SP1, Windows Server 2008, Windows 7, Windows 8, and Windows 8.1-based clients will set this bit when it is requested by the application.

<42> Section 2.2.13.1.1: Windows sets this flag to the value passed in by the higher-level application.

<43> Section 2.2.13.1.1: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview do not ignore the SYNCHRONIZE bit, and pass it to the underlying object store. If the caller requests SYNCHRONIZE in the DesiredAccess parameter, but the SYNCHRONIZE access is not granted to the caller for the object being created or opened, the underlying object store fails the request and returns STATUS_ACCESS_DENIED. When SYNCHRONIZE access is granted, the SYNCHRONIZE bit is returned in MaximalAccess field of SMB2_CREATE_QUERY_MAXIMAL_ACCESS_RESPONSE with no other behavior.

<44> Section 2.2.13.1.1: Windows fails the create request with STATUS_ACCESS_DENIED if the caller does not have the SeSecurityPrivilege, as specified in [MS-LSAD] section 3.1.1.2.1.

<45> Section 2.2.13.1.2: Windows sets this flag to the value passed in by the higher-level application.

<46> Section 2.2.13.1.2: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview do not ignore the SYNCHRONIZE bit, and pass it to the underlying object store. If the caller requests SYNCHRONIZE in the DesiredAccess parameter, but the SYNCHRONIZE access is not granted to the caller for the object being created or opened, the underlying object store fails the request and returns STATUS_ACCESS_DENIED. When SYNCHRONIZE access is granted, the SYNCHRONIZE bit is returned in MaximalAccess field of SMB2_CREATE_QUERY_MAXIMAL_ACCESS_RESPONSE (section 2.2.14.2.5) with no other behavior.

<47> Section 2.2.13.1.2: Windows fails the create request with STATUS_ACCESS_DENIED if the caller does not have the SeSecurityPrivilege, as specified in [MS-LSAD] section 3.1.1.2.1.

<48> Section 2.2.13.2: If DataLength is 0, Windows-based clients set this field to any value.

<49> Section 2.2.13.2.8: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview acting as SMB servers support the following combinations of values: 0, READ, READ | WRITE, READ | HANDLE, READ | WRITE | HANDLE.

<50> Section 2.2.13.2.10: Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 Technical Preview support the following combinations of values: 0, READ, READ | WRITE, READ | HANDLE, READ | WRITE | HANDLE. Windows 8, Windows 8.1, and Windows 10 restrict requests accordingly.

<51> Section 2.2.14: Windows-based clients never use exclusive oplocks. Because there are no situations where it would require an exclusive oplock where it would not also require an SMB2_OPLOCK_LEVEL_BATCH, it always requests an SMB2_OPLOCK_LEVEL_BATCH.

<52> Section 2.2.14: Windows-based SMB2 servers always return FILE_OPENED for pipes with successful opens.

<53> Section 2.2.14: Windows-based SMB2 servers may set this field to any value.

<54> Section 2.2.14.2.11: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview set this field to an arbitrary value.

<55> Section 2.2.23.1: Windows-based clients never use exclusive oplocks. Because there are no situations where it would require an exclusive oplock where it would not also require an SMB2_OPLOCK_LEVEL_BATCH, it always requests an SMB2_OPLOCK_LEVEL_BATCH.

<56> Section 2.2.24.1: Windows-based clients never use exclusive oplocks. There are no situations where an exclusive oplock would be used instead of using a SMB2_OPLOCK_LEVEL_BATCH.

<57> Section 2.2.24.2: Windows clients always set the LeaseState in the Lease Break Acknowledgment to be equal to the LeaseState in the Lease Break Notification from the server.

<58> Section 2.2.31: If no input data is required for the FSCTL/IOCTL command being issued, Windows-based clients set this field to any value.

<59> Section 2.2.31: Windows clients set the OutputOffset field equal to the InputOffset field.

<60> Section 2.2.31.1.1: Windows clients set this field to an arbitrary value.

<61> Section 2.2.32: Windows–based SMB2 servers set InputCount to the same value as the value received in the IOCTL request for the following FSCTLs.

  • FSCTL_FIND_FILES_BY_SID

  • FSCTL_GET_RETRIEVAL_POINTERS

  • FSCTL_QUERY_ALLOCATED_RANGES

  • FSCTL_READ_FILE_USN_DATA

  • FSCTL_RECALL_FILE

  • FSCTL_WRITE_USN_CLOSE_RECORD

Windows clients ignore the InputCount field.

<62> Section 2.2.32: Windows–based SMB2 servers set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<63> Section 2.2.32.2: Windows-based SMB2 server will place 2 extra bytes set to zero in the SRV_SNAPSHOT_ARRAY response, if NumberOfSnapShotsReturned is zero.

<64> Section 2.2.32.3: Windows-based servers always send 4 bytes of zero for the Context field.

<65> Section 2.2.32.4.1: Windows–based SMB2 servers and clients do not check SourceFileName. It is ignored.

<66> Section 2.2.33: Windows-based servers do not support resuming an enumeration at a specified FileIndex. The server will ignore this flag.

<67> Section 2.2.33: SMB2 wildcard characters are based on Windows wildcard characters, as described in [MS-FSA] section 2.1.4.4, Algorithm for Determining if a FileName Is in an Expression. For more information on wildcard behavior in Windows, see [FSBO] section 7.

<68> Section 2.2.37: Windows SMB2 servers ignore the FileInfoClass field for quota queries. Windows SMB2 clients set the FileInfoClass field to 0x20 for quota queries.

<69> Section 2.2.37: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<70> Section 2.2.37: Windows clients send a 1-byte buffer of 0 when InputBufferLength is set to 0.

<71> Section 2.2.37.1: Windows clients set this field to 1 for TRUE.

<72> Section 2.2.37.1: Windows clients set this field to 1 for TRUE.

<73> Section 2.2.37.1: Windows-based clients never send a request using the SidBuffer format 2.

<74> Section 2.2.39: Windows servers will fail the request with STATUS_INVALID_PARAMETER if BufferOffset is less than 0x60 or greater than 0xA0.

<75> Section 2.2.41: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview set this field to an arbitrary value.

<76> Section 3.1.3: By default, Windows-based servers set the RequireMessageSigning value to TRUE for domain controllers and FALSE for all other machines.

<77> Section 3.1.4.3: Windows clients and servers do not encrypt the message if the connection is NetBIOS over TCP.

<78> Section 3.2.1.2: Windows clients do not enforce the MaxTransactSize value.

<79> Section 3.2.2.1: The Windows-based client implements this timer with a default value of 60 seconds. The client does not enforce this timer for the following commands:

  • Named Pipe Read

  • Named Pipe Write

  • Directory Change Notifications

  • Blocking byte range lock requests

  • FSCTLs: FSCTL_PIPE_PEEK, FSCTL_PIPE_TRANSCEIVE, FSCTL_PIPE_WAIT

<80> Section 3.2.2.2: The Windows-based clients scan existing connections every 10 seconds and disconnect idle connects that have no open files and that have had no activity for 10 or more seconds.

<81> Section 3.2.2.3: Windows clients set this timer to 600 seconds, except Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 clients, which do not implement this timer.

<82> Section 3.2.3: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview clients set this based on a stored value in the registry.

<83> Section 3.2.4.1.1: A client can selectively sign requests, and the server will sign the corresponding responses. Windows-based clients do not selectively sign requests.

<84> Section 3.2.4.1.2: Windows-based clients require a minimum of 4 credits.

<85> Section 3.2.4.1.2: The Windows-based client will request credits up to a configurable maximum of 128 by default. A Windows-based client sends a CreditRequest value of 0 for an SMB2 NEGOTIATE Request and expects the server to grant at least 1 credit. In subsequent requests, the client will request credits sufficient to maintain its total outstanding limit at the configured maximum.

<86> Section 3.2.4.1.3: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview SMB2 clients will block any newly initiated multi-credit requests that exceed the shortage, but will send out other requests that can be satisfied using the available credits.

<87> Section 3.2.4.1.3: Windows-based clients set the MessageId field to 0, when the AsyncId field is set to an asynchronous identifier of the request.

<88> Section 3.2.4.1.4: Windows-based clients do not send compounded CREATE + READ/WRITE requests when the payload size of the WRITE request or the anticipated response of the READ request is greater than 65536.

<89> Section 3.2.4.1.4: Windows SMB2 Server allows a mix of related and unrelated compound requests in the same transport send. Upon encountering a request with SMB2_FLAGS_RELATED_OPERATIONS not set Windows SMB2 Server treats it as the start of a chain.

<90> Section 3.2.4.1.4: Windows-based clients will align their compounded requests and responses on 8-byte boundaries. They do not disconnect other machines that disobey this rule.

<91> Section 3.2.4.1.4: The Windows-based client does not send unrelated compounded requests.

<92> Section 3.2.4.1.4: Windows-based clients will compound certain related requests to improve performance, by combining a Create with another operation, such as an attribute query.

<93> Section 3.2.4.1.4: Windows-based clients set the SessionId and TreeId fields of subsequent requests with the SessionId and TreeId values of the previous request in the compound chain.

<94> Section 3.2.4.1.4: When the Windows-based client compounds a FileId-bearing operation with an SMB2 CREATE request, the FileId field is set to an indeterminate value, which the server ignores as specified in section 3.3.5.2.7.2.

<95> Section 3.2.4.1.5: Windows 7 and Windows Server 2008 R2 SMB2 clients set CreditCharge to 1 for IOCTL requests.

<96> Section 3.2.4.1.5: Windows 7, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview-based SMB2 clients set the CreditCharge field to 1 if Connection.SupportsMultiCredit is FALSE.

<97> Section 3.2.4.1.7: Windows-based clients choose the Channel with the least value of Channel.Connection.OutstandingRequests.

<98> Section 3.2.4.2: Windows-based clients always set up a new transport connection when establishing a new session to a server.

<99> Section 3.2.4.2: Windows will reuse an existing session if the access is by the same logged-on user and the target server name matches exactly. This means that Windows will establish a new session with the same credentials if the same user is logged on to the client multiple times, or if the user is accessing the server through two different names that resolve to the same server. (NetBIOS and fully qualified domain name, for example.)

<100> Section 3.2.4.2: Windows will establish a new connection for every SMB2 session being created.

<101> Section 3.2.4.2: Windows establishes a new connection for each new session.

<102> Section 3.2.4.2.1: Windows Vista SP1 and Windows Server 2008 clients enumerate all transports, send a Direct TCP connection request, and then, after 500 milliseconds, send connection requests to all other eligible addresses and all other NetBIOS over TCP transports.

Windows 7 and Windows Server 2008 R2 clients enumerate all transports, send a Direct TCP connection request, and then, after 1,000 milliseconds, send connection requests to all other eligible addresses and all other NetBIOS over TCP transports.

Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview clients look up a server entry in ServerList where Server.ServerName matches the ServerName to which the connection is established. If no entry is found, the clients enumerate all transports, send a Direct TCP connection request, and then, after 1,000 milliseconds, send connection requests to all other eligible addresses over Direct TCP and NetBIOS over TCP transports. If an entry is found, the clients send a Direct TCP connection request, and then, after 1,000 milliseconds, enumerate all transports and send connection requests to all Direct TCP addresses.

In each case, the first successful connection is used and all others are closed.

<103> Section 3.2.4.2.2: The Windows-based client will initiate a multi-protocol negotiation unless it has previously negotiated with this server and determined that it implements the SMB 2 Protocol. In the latter case, it will initiate an SMB2-only negotiate.

<104> Section 3.2.4.2.2.1: When a Windows-based client sends the deprecated "SMB 2.001" dialect, a Windows Vista RTM–based server would acknowledge with a value of 6 in DialectRevision in the SMB2 NEGOTIATE Response. This behavior is deprecated.

<105> Section 3.2.4.2.2.2:  Windows 7 without [MSKB-3002286] sets ClientGuid to the global ClientGuid value.

<106> Section 3.2.4.2.2.2: Windows 10 and Windows Server 2016 Technical Preview use 32 bytes of Salt.

<107> Section 3.2.4.2.2.2: Windows 10 and Windows Server 2016 Technical Preview initialize with AES-128-GCM(0x0002) followed by AES-128-CCM(0x0001).

<108> Section 3.2.4.2.3: Windows-based clients implement the first option that is specified.

<109> Section 3.2.4.2.3: All the GSS-API tokens used by Windows SMB2 clients are up to 4Kbytes in size. SMB2 servers always instruct the GSS_API server to expect the GSS_C_FRAGMENT_TO_FIT.

<110> Section 3.2.4.2.3.1: Windows-based clients implement the first option that is specified.

<111> Section 3.2.4.2.3.1: All the GSS-API tokens used by Windows SMB2 clients are up to 4Kbytes in size. SMB2 servers always instruct the GSS_API server to expect the GSS_C_FRAGMENT_TO_FIT.

<112> Section 3.2.4.3: Windows clients set File.LeaseKey to a newly generated GUID as specified in [MS-DTYP] section 2.3.4.2.

<113> Section 3.2.4.3: Windows clients set File.LeaseKey to a newly generated GUID as specified in [MS-DTYP] section 2.3.4.2.

<114> Section 3.2.4.3: Windows-based clients will request a batch oplock for file creates.

<115> Section 3.2.4.3.5: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview clients set this to zero.

<116> Section 3.2.4.3.8: A Windows client application requestsSMB2_LEASE_READ_CACHING and SMB2_LEASE_HANDLE_CACHING when a file is opened for read access. In addition, a Windows client application requests SMB2_LEASE_WRITE_CACHING if the file is being opened for write access.

<117> Section 3.2.4.6: Windows-based clients will try to send multiple read commands at the same time, starting at the lowest offset and working to the highest.

<118> Section 3.2.4.6: Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 Technical Preview default to 4 KB.

<119> Section 3.2.4.7: Windows-based clients will try to send multiple write commands at the same time, starting at the lowest offset and working to the highest.

<120> Section 3.2.4.7: Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 Technical Preview default to 4 KB.

<121> Section 3.2.4.7: Windows-based clients always put the payload at the beginning of the Buffer field and do not insert padding.

<122> Section 3.2.4.8: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<123> Section 3.2.4.9: In a SET_INFO request where FileInfoClass is set to FileRenameInformation, Windows clients append an arbitrary number of padding bytes set to arbitrary values at the end of the Buffer field.

<124> Section 3.2.4.10: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<125> Section 3.2.4.12: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<126> Section 3.2.4.14: Windows-based clients will set StartSidLength and StartSidOffset to any value.

<127> Section 3.2.4.17: The Windows SMB2 server implementation closes and reopens the directory handle in order to "reset" the enumeration state. So any outstanding operations on the directory handle will be failed with a STATUS_FILE_CLOSED error.

<128> Section 3.2.4.20: Windows 7 and Windows Server 2008 R2 SMB2 clients set CreditCharge to 1 for IOCTL requests.

<129> Section 3.2.4.20.1: Windows clients set this field to any value.

<130> Section 3.2.4.20.1: Windows clients set the OutputOffset field to InputOffset.

<131> Section 3.2.4.20.2.1: Windows clients set this field to any value.

<132> Section 3.2.4.20.2.1: Windows clients set this field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<133> Section 3.2.4.20.2.2: Windows applications use FSCTL_SRV_COPYCHUNK if the target file handle has FILE_READ_DATA access. Otherwise, they use the FSCTL_SRV_COPYCHUNK_WRITE.

<134> Section 3.2.4.20.2.2: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<135> Section 3.2.4.20.3: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<136> Section 3.2.4.20.4: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<137> Section 3.2.4.20.5: Windows clients set this field to any value.

<138> Section 3.2.4.20.5: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<139> Section 3.2.4.20.6: Windows-based SMB2 servers pass File System Control requests through to the local object store but do not support I/O Control requests and fail such requests with STATUS_NOT_SUPPORTED.

<140> Section 3.2.4.20.6: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<141> Section 3.2.4.20.7: Windows clients set the OutputOffset field to the sum of the values of the InputOffset and the InputCount fields, rounded up to a multiple of 8 bytes.

<142> Section 3.2.4.20.8: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<143> Section 3.2.4.20.10: Windows clients set this to 64 kilobytes.

<144> Section 3.2.4.20.11: Windows clients set the OutputOffset field to InputOffset.

<145> Section 3.2.4.24: Windows based clients set the MessageId field to 0, when the AsyncId field is set to an asynchronous identifier of the request.

<146> Section 3.2.4.24: Windows-based clients set the SessionId field to TreeConnect.Session.SessionId, and Windows-based servers will ignore the SessionId field.

<147> Section 3.2.5.1: For the following error codes, Windows-based clients will retry the operation up to three times and then retry the operation every 5 seconds until the count of milliseconds specified by Open.ResilientTimeout is exceeded:

  • STATUS_SERVER_UNAVAILABLE

  • STATUS_FILE_NOT_AVAILABLE

  • STATUS_SHARE_UNAVAILABLE

<148> Section 3.2.5.1.1: Windows clients discard the message if it is encrypted and the connection is NetBIOS over TCP.

<149> Section 3.2.5.1.3: Windows-based clients will not disconnect the connection but simply disregard the incorrectly signed response.

<150> Section 3.2.5.1.5: Windows clients extend the Request Expiration Timer for requests being processed asynchronously as follows:

If the registry value ExtendedSessTimeout in HKLM\System\CurrentControlSet\Services\LanmanWorkStation\Parameters\ is set, the clients use the same value. Otherwise, the clients extend the expiration time to four times the value of default session timeout.

Windows Vista SP1, Windows Server 2008, Windows 7 and Windows Server 2008 R2 never enforce a timeout on SMB2 CHANGE_NOTIFY requests, SMB2 LOCK requests without the SMB2_LOCKFLAG_FAIL_IMMEDIATELY flag, SMB2 READ requests on named pipes, SMB2 WRITE requests on named pipes, and the FSCTL_PIPE_PEEK, FSCTL_PIPE_TRANSCEIVE and FSCTL_PIPE_WAIT named pipe FSCTLs.

<151> Section 3.2.5.1.7: Windows-based clients will not disconnect the connection, but will simply fail the request.

<152> Section 3.2.5.1.8: Windows-based SMB 2 Protocol clients do not check the validity of the command in the response.

<153> Section 3.2.5.2: Windows-based clients will not use the MaxTransactSize and will use the ServerGuid to determine if the client and server are the same machine.

<154> Section 3.2.5.5: By default Windows 8 and Windows 8.1 will try to establish alternate channels, if Connection.OutstandingRequests exceeds 8. Windows Server 2012, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview will try to establish alternate channels, if Connection.OutstandingRequests exceeds 1.

<155> Section 3.2.5.5: Windows-based SMB2 clients will choose the interfaces using the following criteria:

  1. Skip the interfaces in NETWORK_INTERFACE_INFO Response where IfIndex is 0.

  2. For each interface returned in NETWORK_INTERFACE_INFO Response, if the interface has both link-local and non-link-local IP addresses, skip the link-local IP address.

  3. If there is one or more multiple link-local addresses (suppose there are Y such interfaces), select local interfaces which only have link-local addresses (suppose there are X such local interfaces).

  4. Build a destination address list, include all server non-link-local addresses and X*Y server link-local addresses.

  5. For each RDMA capable address pair, duplicate the address pair, one for RDMA and one for Direct TCP.

  6. Sort address pairs by which address pair is best suited for connection between client and server.

  7. For each address pair, compute

    • Link speed of the pair = min( link speed of local interface, link speed of remote interface)

    • RSS capable = RSS capable of local interface and RSS capable of remote interface

  8. If there are RDMA capable address pairs, select them.

    • Otherwise if there are RSS capable address pairs, select them.

    • Otherwise select remaining address pairs.

  9. Select the pairs with the highest link speed from the selected address pairs.

  10. Select local/remote address pairs so that all eligible local/remote interfaces are used and the connections are distributed among local and remote interfaces.

  11. The client attempts to establish an alternate channel on each selected interface and address pair. The client will create only a single connection per address pair when the server interface is neither RSS- nor RDMA-capable.

<156> Section 3.2.5.12: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview replay the write operation up to three times or until all channels in the session are disconnected.

<157> Section 3.2.5.14: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview replay the IOCTL operation up to three times or until all of the channels in the session are disconnected.

<158> Section 3.2.5.14: If the OutputCount field in an SMB2 IOCTL Response is 0 and the OutputOffset exceeds the size of the SMB2 response, Windows clients will return STATUS_INVALID_NETWORK_RESPONSE to the application.

<159> Section 3.2.5.14.9: Windows clients enable TCP keepalives to detect broken connections.

<160> Section 3.2.5.18: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview replay the SetInfo operation up to three times or until all of the channels in the session are disconnected.

<161> Section 3.2.5.19.1: Windows-based clients will not request exclusive oplocks.

<162> Section 3.2.5.19.2:  Windows clients do not send a Lease Break Acknowledgement when they have an outstanding SMB2 CREATE Request on the same File.

<163> Section 3.2.6.1: Windows clients use a default time-out of 60 seconds.

<164> Section 3.2.6.1: Windows-based clients return a STATUS_CONNECTION_DISCONNECTED error code to the calling application.

<165> Section 3.2.6.1: The Windows-based clients will disconnect the connection.

<166> Section 3.2.7.1: When the reestablishment of the durable handles fails with a network error, Windows clients retry the reestablishment three times.

<167> Section 3.3.1.1: Windows-based servers will limit the maximum range of sequence numbers. If a client has been granted 10 credits, the server will not allow the difference between the smallest available sequence number and the largest available sequence number to exceed 2*10 = 20. Therefore, if the client has sequence number 10 available and does not send it, the server will stop granting credits as the client nears sequence number 30, and eventually will grant no further credits until the client sends sequence number 10.

<168> Section 3.3.1.2: A Windows-based server will grant some portion of the client request based on available resources and the number of credits the client is currently taking advantage of. A Windows–based server grants credits based on usage but will attempt to enforce fairness if there are insufficient credits.

<169> Section 3.3.1.2: Windows-based SMB2 servers support a configurable minimum credit limit below which the client is unconditionally granted all credits it requests, and a configurable maximum credit limit above which credits are never granted, as follows:

SMB2 server

Default minimum

Default maximum

Windows Vista SP1, Windows 7, Windows 8, Windows 8.1, and Windows 10

128

2048

Windows Server 2008,Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 Technical Preview

512

8192

<170> Section 3.3.1.2: A Windows–based server does not currently scale credits based on quality of service features.

<171> Section 3.3.1.4:  On Windows 7 and Windows Server 2008 R2, a 128-bit ClientLeaseId is generated by an arithmetic combination of LeaseKey and ClientGuid, which is passed to the object store at open/create time. On Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016 Technical Preview, Windows 10, and Windows Server 2016 Technical Preview, the LeaseKey in the request is used as the ClientLeaseId.

<172> Section 3.3.1.4: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview -based SMB2 servers support only the levels described above, and Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview -based SMB2 clients request only those levels.

<173> Section 3.3.1.6: Windows-based servers allow the sharing of both printers and traditional file shares.

<174> Section 3.3.1.6: In Windows, this abstract state element contains the security descriptor for the share.

<175> Section 3.3.1.6: Windows-based SMB2 clients do not cache directory enumeration results.

<176> Section 3.3.1.13: The Windows SMB2 server allocates an I/O request (IRP) structure which it uses to locally request action from the object store. The Request.CancelRequestId is set to the unique address of this structure.

<177> Section 3.3.2.1: This timer has a default value of 35 seconds, but its value could be changed by system policy to any range between 5 seconds and infinite (4,294,967,295 seconds).

<178> Section 3.3.2.2: Windows-based SMB2 servers set this timer to a constant value of 16 minutes.

<179> Section 3.3.2.3: Windows-based servers implement this timer with a constant value of 45 seconds.

<180> Section 3.3.3: Windows-based SMB2 servers set this value to 256.

<181> Section 3.3.3: Windows-based SMB2 servers set this value to 1 MB.

<182> Section 3.3.3: Windows-based SMB2 servers set this value to 16 MB.

<183> Section 3.3.3: Windows servers initialize ServerHashLevel based on a stored value in the registry.

<184> Section 3.3.3: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview SMB2 servers provide a constant maximum resiliency time-out of 300000 milliseconds.

<185> Section 3.3.3: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview, by default, set RejectUnencryptedAccess to TRUE. If the registry value RejectUnencryptedAccess under HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\ is set to zero, RejectUnencryptedAccess is set to FALSE.

<186> Section 3.3.3: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview set IsMultiChannelCapable to TRUE.

<187> Section 3.3.4.1.1: Windows servers always sign the final session setup response when the user is neither anonymous nor guest.

Windows 8, Windows Server 2012, Windows 8.1 without [MSKB-2976995] and Windows Server 2012 R2 without [MSKB-2976995] servers fail to sign responses other than SMB2_NEGOTIATE, SMB2_SESSION_SETUP, and SMB2_TREE_CONNECT when Session.SigningRequired is TRUE, global EncryptData is TRUE, RejectUnencryptedAccess is FALSE and either Connection.Dialect is "2.0.2" or "2.1" or Connection.ClientCapabilities does not include SMB2_GLOBAL_CAP_ENCRYPTION.

<188> Section 3.3.4.1.2: For an asynchronously processed request, Windows servers grant credits on the interim response and do not grant credits on the final response. The interim response grants credits to keep the transaction from stalling in case the client is out of credits.

<189> Section 3.3.4.1.3: The Windows-based server compounds responses for any received compounded operations. Otherwise, it does not compound responses.

<190> Section 3.3.4.1.3: When there are not enough credits to process a subsequent compounded request, Windows SMB2 servers set the NextCommand field to the size of the last SMB2 response message including the SMB2 header.

<191> Section 3.3.4.1.3: Windows-based servers grant all credits in the final response of the compounded chain, and grant 0 credits in all responses other than the final response.

<192> Section 3.3.4.1.3: Windows servers do not calculate the size of the response message; servers depend on the transport to send the response message.

<193> Section 3.3.4.2: Windows-based servers send interim responses for the following operations if they cannot be completed immediately:

  • SMB2_CREATE, if the underlying object store indicates an Oplock/Lease Break Notification or if access/sharing modes are incompatible with another existing open

  • SMB2_CHANGE_NOTIFY

  • Byte Range Lock

  • Named Pipe Read on a blocking named pipe

  • Named Pipe Write on a blocking named pipe

  • Large file write

  • FSCTL_PIPE_TRANSCEIVE

  • FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE, when oplock break happens

  • SMB2 FLUSH on a named pipe

  • FSCTL_GET_DFS_REFERRALS

<194> Section 3.3.4.2: Windows-based servers incorrectly process the FSCTL_PIPE_WAIT request on named pipes synchronously.

<195> Section 3.3.4.2: Windows servers enforce a configurable blocking operation credit, which defaults to 64 on Windows Vista SP1, Windows 7, Windows 8, Windows 8.1, and, Windows 10, and defaults to 512 on Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 Technical Preview.

<196> Section 3.3.4.4: For Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview, STATUS_BUFFER_OVERFLOW will be returned for FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_GET_REPARSE_POINT, along with the ones mentioned in section 3.3.4.4.

<197> Section 3.3.4.6: Windows-based SMB2 servers set Open.OplockTimeout to the current time plus 35000 milliseconds. If Open.IsPersistent is TRUE, Open.OplockTimeout is set to the current time plus 60000 milliseconds.

<198> Section 3.3.4.7: Windows-based SMB2 servers set Lease.LeaseBreakTimeout to the current time plus 35000 milliseconds. If Open.IsPersistent is TRUE, Windows 8 and Windows Server 2012 set Lease.LeaseBreakTimeout to the current time plus 60000 milliseconds. If Open.IsPersistent is TRUE, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview set Lease.LeaseBreakTimeout to the current time plus 180000 milliseconds.

<199> Section 3.3.4.13: Windows Server 2012 and Windows Server 2012 R2 set these bits as appropriate for shared volume configurations.

<200> Section 3.3.4.13: By default, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview set Share.CATimeout to zero.

<201> Section 3.3.4.17: Windows Lease break is described in [MS-FSA] section 2.1.5.17. The Open parameter passed is the Open.Local value from the current close operation, the Type parameter is LEVEL_GRANULAR to indicate a Lease request, and the RequestedOplockLevel parameter is zero.

<202> Section 3.3.4.21: For each supported transport type as listed in section 2.1, the Windows SMB2 server attempts to form an association with the specified device with local calls specific to each supported transport type and rejects the entry if none of the associations succeed.

<203> Section 3.3.4.21: On Windows, ServerName is used only when the transport is NetBIOS over TCP.

<204> Section 3.3.5.1: Possible Windows-specific values for Connection.TransportName are listed in a product behavior note attached to [MS-SRVS] section 2.2.4.96.

<205> Section 3.3.5.2: Windows performs cancellation of in-progress requests via the interface in [MS-FSA] section 2.1.5.19, Server Requests Canceling an Operation, passing Request.CancelRequestId as an input parameter.

<206> Section 3.3.5.2: Windows 7 without [MSKB-2536275], and Windows Server 2008 R2 without [MSKB-2536275] terminate the connection when the size of the request is greater than 64*1024 bytes.

Windows Vista SP1 and Windows Server 2008 on Direct TCP transport disconnect the connection if the size of the message exceeds 128*1024 bytes, and Windows Vista SP1 and Windows Server 2008 on NetBIOS over TCP transport will disconnect the connection if the size of the message exceeds 64*1024 bytes.

<207> Section 3.3.5.2.1: Windows server will discard the message if it is encrypted and the connection is NetBIOS over TCP.

<208> Section 3.3.5.2.1: Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 Technical Preview will accept OriginalMessageSize up to 1028 kilobytes.

<209> Section 3.3.5.2.3: For an SMB2 Write request with an invalid MessageId, Windows 8 and Windows Server 2012 will stop processing the request and any further requests on that connection.

<210> Section 3.3.5.2.4: Windows-based servers will not disconnect the connection due to a mismatched signature.

<211> Section 3.3.5.2.4: Windows-based servers will not disconnect the connection due to an unsigned packet.

<212> Section 3.3.5.2.6: Windows-based servers will disconnect the connection when it processes packets that are smaller than the SMB2 header or packets that contain an invalid SMB2 command. For all other validations, it will not disconnect the connection but simply return the error.

<213> Section 3.3.5.2.7: In Windows Vista and Windows Server 2008, when an operation in a compound request requires asynchronous processing, Windows servers fail them with STATUS_INTERNAL_ERROR except for the following two cases: when a create request in the compound request triggers an oplock break, or when the operation is last in the compound request.

In all SMB2 servers, if a create request in a compound chain is processed asynchronously due to an oplock break, Windows servers send an interim response to the client. If there are one or more conflicting create operations in a compounded request, Windows servers send an oplock break notification for the completed create prior to sending any response, and the level of the broken oplock is not updated in all prior create responses in the compound response.

<214> Section 3.3.5.2.7: Windows-based SMB2 servers allow a mix of related and unrelated compound requests in the same transport send. Upon encountering a request with SMB2_FLAGS_RELATED_OPERATIONS not set, a Windows-based SMB2 server treats it as the start of a chain.

<215> Section 3.3.5.2.7.2: If SMB2_FLAGS_RELATED_OPERATIONS is present in the first request, Windows servers fail all related requests in the compounded chain with error STATUS_INVALID_PARAMETER.

<216> Section 3.3.5.2.7.2: If the previous session expired, Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 servers fail the next request in the compounded chain with STATUS_NETWORK_SESSION_EXPIRED, and the subsequent requests in the compounded chain will be failed with STATUS_INVALID_PARAMETER.

<217> Section 3.3.5.2.9: Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 do not disconnect the connection but continue session verification.

<218> Section 3.3.5.2.9: Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 servers do not fail the request if the SMB2 header of the request has SMB2_FLAGS_SIGNED set in the Flags field and the request is not an SMB2 LOCK request as specified in section 2.2.26.

<219> Section 3.3.5.2.9: Windows servers fail the request with 0x80090302 when the authentication method is GSS-API.

<220> Section 3.3.5.3.1: If the underlying transport is NETBIOS over TCP, Windows servers set MaxTransactSize to 65536. Otherwise, MaxTransactSize is set based on the following table:

Windows version\Connection.Dialect

MaxTransactSize

Windows 7\Windows Server 2008 R2

1048576

Windows 8 without [MSKB-2934016]\Windows Server 2012 without [MSKB-2934016]

1048576

All other SMB2 servers

8388608

<221> Section 3.3.5.3.1: If the underlying transport is NETBIOS over TCP, Windows servers set MaxReadSize to 65536. Otherwise, MaxReadSize is set based on the following table.

Windows version\Connection.Dialect

MaxReadSize

Windows 7\Windows Server 2008 R2

1048576

Windows 8 without [MSKB-2934016]\Windows Server 2012 without [MSKB-2934016]

1048576

All other SMB2 servers

8388608

<222> Section 3.3.5.3.1: If the underlying transport is NETBIOS over TCP, Windows servers set MaxWriteSize to 65536. Otherwise, MaxWriteSize is based on the following table.

Windows version\Connection.Dialect

MaxWriteSize

Windows 7\Windows Server 2008 R2

1048576

Windows 8 without [MSKB-2934016]\Windows Server 2012 without [MSKB-2934016]

1048576

All other SMB2 servers

8388608

<223> Section 3.3.5.3.2: When a Windows-based client sends the deprecated "SMB 2.001" dialect, a Windows Vista RTM-based server would acknowledge with a value of 6 in DialectRevision in the SMB2 NEGOTIATE Response. This behavior is deprecated.

<224> Section 3.3.5.3.2: A Windows Vista RTM–based server sets DialectRevision to 6.

<225> Section 3.3.5.3.2: Windows servers set this to a default value of 65536.

<226> Section 3.3.5.3.2: Windows servers set MaxReadSize to a default value of 65536.

<227> Section 3.3.5.3.2: Windows servers set MaxWriteSize to a default value of 65536.

<228> Section 3.3.5.4: If the underlying transport is NETBIOS over TCP, Windows servers set MaxTransactSize to 65536. Otherwise, MaxTransactSize is set based on the following table.

Windows version\Connection.Dialect

2.0.2

All other SMB2 dialects

Windows Vista SP1\Windows Server 2008

65536

N/A

Windows 7\Windows Server 2008 R2

65536

1048576

Windows 8 without [MSKB-2934016]\Windows Server 2012 without [MSKB-2934016]

65536

1048576

All other SMB2 servers

65536

8388608

<229> Section 3.3.5.4: If the underlying transport is NETBIOS over TCP, Windows servers set MaxReadSize to 65536. Otherwise, MaxReadSize is set based on the following table.

Windows version\Connection.Dialect

2.0.2

All other SMB2 dialects

Windows Vista SP1\Windows Server 2008

65536

N/A

Windows 7\Windows Server 2008 R2

65536

1048576

Windows 8 without [MSKB-2934016]\Windows Server 2012 without [MSKB-2934016]

65536

1048576

All other SMB2 servers

65536

8388608

<230> Section 3.3.5.4: If the underlying transport is NETBIOS over TCP, Windows servers set MaxWriteSize to 65536. Otherwise, MaxWriteSize is set based on the following table.

Windows version\Connection.Dialect

2.0.2

All other SMB2 dialects

Windows Vista SP1\Windows Server 2008

65536

N/A

Windows 7\Windows Server 2008 R2

65536

1048576

Windows 8 without [MSKB-2934016]\Windows Server 2012 without [MSKB-2934016]

65536

1048576

All other SMB2 servers

65536

8388608

<231> Section 3.3.5.4: Windows 10 and Windows Server 2016 Technical Preview use 32 bytes of Salt.

<232> Section 3.3.5.5: Windows 8 and Windows Server 2012 look up the session in GlobalSessionTable using the SessionId from the SMB2 header if the SMB2_SESSION_FLAG_BINDING bit is set in the Flags field of the request. If the session is found, the server fails the request with STATUS_REQUEST_NOT_ACCEPTED. If the session is not found, the server fails the request with STATUS_USER_SESSION_DELETED.

<233> Section 3.3.5.5: Windows Vista SP1 and Windows Server 2008 servers fail the session setup request with STATUS_REQUEST_NOT_ACCEPTED.

<234> Section 3.3.5.5.3: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview will also accept raw Kerberos messages and implicit NTLM messages as part of GSS authentication.

<235> Section 3.3.5.5.3: Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 servers do not fail the request if dialects do not match.

<236> Section 3.3.5.5.3: Windows by default uses the guest account to represent guest users. Alternatively, any user account that is a member of the well-known BUILTIN_GUESTS or DOMAIN_GUESTS group (see [MS-DTYP] section 2.4.2.4) is considered a guest account.

<237> Section 3.3.5.5.3: Windows 7 and Windows Server 2008 R2 remove the current session from GlobalSessionTable and Connection.SessionTable but the SESSION_SETUP request succeeds, if the PreviousSessionId and SessionId values in the SMB2 header of the request are equal and the authentications were for the same user. Further requests using this SessionId will fail with STATUS_USER_SESSION_DELETED.

<238> Section 3.3.5.7: Windows-based SMB2 servers do not set this bit in the ShareFlags field.

<239> Section 3.3.5.7: Windows-based SMB2 servers do not set this bit in the ShareFlags field.

<240> Section 3.3.5.7: Windows Server 2012 and Windows Server 2012 R2 set these two bits based on group policy settings.

<241> Section 3.3.5.7: Windows Vista SP1 and Windows Server 2008 do not support the SMB2_SHAREFLAG_ENABLE_HASH_V1 bit.

<242> Section 3.3.5.7: Windows Server 2012 R2 also verifies whether TreeConnect.Share is asymmetric before setting the SMB2_SHARE_CAP_ASYMMETRIC bit in the SMB2 TREE_CONNECT response.

<243> Section 3.3.5.9: Windows Vista and Windows Server 2008 validate the create requests before session verification as described in the "Create Context Validation" phase in section 3.3.5.9.

<244> Section 3.3.5.9: Windows-based SMB2 servers fail an SMB2 CREATE request with STATUS_ACCESS_DENIED if the file name in the request is one of the following: "LPT1", "LPT2", "LPT3","LPT4", "LPT5", "LPT6", "LPT7", "LPT8", "LPT9", "COM1", "COM2", "COM3", "COM4", "COM5", "COM6", "COM7", "COM8", "COM9", "PRN", "AUX", "NUL", "CON", and "CLOCK$".

<245> Section 3.3.5.9: Windows-based servers ignore DesiredAccess values other than FILE_WRITE_DATA, FILE_APPEND_DATA and GENERIC_WRITE if any one of these values is specified.

<246> Section 3.3.5.9: Windows-based servers fail requests having a CreateDisposition of FILE_OPEN or FILE_OVERWRITE, but ignore values of FILE_SUPERSEDE, FILE_OPEN_IF and FILE_OVERWRITE_IF.

<247> Section 3.3.5.9: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 ignore create contexts having a NameLength greater than 4 and ignore create contexts with a length of 4 that are not specified in section 2.2.13.2.

<248> Section 3.3.5.9:  Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not perform this verification and continue to process the request.

<249> Section 3.3.5.9: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 do not perform this verification.

<250> Section 3.3.5.9: Windows Vista SP1 and Windows Server 2008 do not fail the request if the ImpersonationLevel in the request is not one of the values specified in section 2.2.13.

<251> Section 3.3.5.9: Windows-based SMB2 servers check only for FILE_WRITE_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, and FILE_APPEND_DATA in the DesiredAccess field.

<252> Section 3.3.5.9: Windows Vista SP1 and Windows Server 2008 do not support the SMB2_SHAREFLAG_FORCE_LEVELII_OPLOCK flag and ignore the TreeConnect.Share.ForceLevel2Oplock value.

<253> Section 3.3.5.9: Windows performs the following open/create mappings from SMB2 parameters to the object store as described in [MS-FSA] section 2.1.5.1 Server Requests an Open of a File.

Object Store parameter

SMB2 parameter

Notes

DesiredAccess

DesiredAccess

DesiredFileAttributes

FileAttributes

ShareAccess

ShareAccess

CreateDisposition

CreateDisposition

CreateOptions

CreateOptions

SecurityContext

Session.SecurityContext

SecurityFlags

ImpersonationLevel

SecurityFlags and ImpersonationLevel are not passed to the object store

PathName

PathName

Relative to TreeConnect.Share.LocalPath

RootOpen

TreeConnect.Share

A LocalOpen representing TreeConnect.Share.LocalPath. Windows SMB2 servers maintain such a LocalOpen for each active Share.

IsCaseSensitive

FALSE

Windows-based SMB2 servers always handle path names as case-insensitive

TargetOplockKey

NULL

OplockKey specified only for obtaining Leases

ParentOplockKey

NULL

Oplock Key to identify the owner of an oplock on the parent directory of the file being opened.

Windows performs the following mappings from object store results to SMB2 response.

Object Store result

SMB2 response

Notes

CreateAction

CreateAction

Open

FileId

The FileId to Open mapping is computed and maintained by the server

<254> Section 3.3.5.9: Windows-based servers will receive the data from the local create operation for constructing the error response when a symbolic link is present in the target path name.

<255> Section 3.3.5.9: Windows Oplock acquisition is described in [MS-FSA] section 2.1.5.17. Oplock acquisition is an optional step in open/create processing; the Open parameter passed is the Open.Local result from the open or create operation, and the Type parameter is mapped as follows.

Object Store oplock Type

SMB2 oplock level

LEVEL_BATCH

SMB2_OPLOCK_LEVEL_BATCH

LEVEL_ONE

SMB2_OPLOCK_LEVEL_EXCLUSIVE

LEVEL_TWO

SMB2_OPLOCK_LEVEL_II

The Status code returned indicates whether the requested oplock was granted.

<256> Section 3.3.5.9: Windows obtains CreationTime from the object store FileBasicInformation [MS-FSA] section 2.1.5.11.6 and [MS-FSCC] section 2.4.7.

<257> Section 3.3.5.9: Windows obtains LastAccessTime from the object store FileBasicInformation [MS-FSA] section 2.1.5.11.6 and [MS-FSCC] section 2.4.7.

<258> Section 3.3.5.9: Windows obtains LastWriteTime from the object store FileBasicInformation [MS-FSA] section 2.1.5.11.6 and [MS-FSCC] section 2.4.7.

<259> Section 3.3.5.9: Windows obtains ChangeTime from the object store FileBasicInformation [MS-FSA] section 2.1.5.11.6 and [MS-FSCC] section 2.4.7.

<260> Section 3.3.5.9: Windows obtains AllocationSize from the object store FileStandardInformation [MS-FSA] section 2.1.5.11.27 and [MS-FSCC] section 2.4.38.

<261> Section 3.3.5.9: Windows-based SMB2 servers will set AllocationSize to any value for the named pipe.

<262> Section 3.3.5.9: Windows obtains EndOfFile from the object store FileStandardInformation [MS-FSA] section 2.1.5.11.27 and [MS-FSCC] section 2.4.38.

<263> Section 3.3.5.9: Windows-based SMB2 servers will set EndofFile to any value for the named pipe.

<264> Section 3.3.5.9: Windows obtains FileAttributes from the object store FileBasicInformation [MS-FSA] section 2.1.5.11.6 and [MS-FSCC] section 2.4.7.

<265> Section 3.3.5.9.1: Windows sets extended attributes on a newly created file with the FSCTL_SET_OBJECT_ID_EXTENDED FSCTL [MS-FSA] section 2.1.5.9.32 and [MS-FSCC] section 2.3.63.

<266> Section 3.3.5.9.2: Windows sets security attributes on a newly created file with the Application requests setting of security information [MS-FSA] section 2.1.5.16.

<267> Section 3.3.5.9.2: Windows will ignore security descriptors if the underlying object store does not support them.

<268> Section 3.3.5.9.3: Windows-based servers support this request.

<269> Section 3.3.5.9.3: Windows sets allocation size on a newly created file with the FileAllocationInformation [MS-FSA] section 2.1.5.14.1 and [MS-FSCC] section 2.4.4, after converting bytes to volume cluster size.

<270> Section 3.3.5.9.4: Windows validates that a snapshot with the time stamp provided exists by forming a FileBothDirectoryInformation object store request for the file including the provided @GMT token in the path, as described in [MS-SMB] section 2.2.1.1.1 and [MS-FSA] section 2.1.5.5.3.1.

<271> Section 3.3.5.9.4: Windows opens a file on a snapshot with the time stamp provided by the file including the provided @GMT token in the path, as described in [MS-SMB] section 2.2.1.1.1 and [MS-FSA] section 2.1.5.1.

<272> Section 3.3.5.9.5: Windows computes the MaximalAccess to return by querying the security attributes of the file with [MS-FSA] section 2.1.5.13, and performing an access check against the credentials provided by the request. QueryStatus is set to the Status returned in that operation.

<273> Section 3.3.5.9.6: Windows Vista SP1, Windows 7,Windows Server 2008, and Windows Server 2008 R2 ignore undefined create contexts.

<274> Section 3.3.5.9.7: Windows Vista SP1, Windows Server 2008, Windows 7 and Windows Server 2008 R2 ignore undefined create contexts.

<275> Section 3.3.5.9.7: Windows Vista SP1, Windows Server 2008, Windows 7 and Windows Server 2008 R2 ignore undefined create contexts.

<276> Section 3.3.5.9.7: Windows 8, Windows Server 2012, Windows 8.1 and Windows Server 2012 R2 do not perform lease version verification.

<277> Section 3.3.5.9.7: Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 servers respond with the SMB2_CREATE_DURABLE_HANDLE_RESPONSE create context after a successful reconnect of a durable open.

<278> Section 3.3.5.9.8: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not ignore the SMB2_CREATE_REQUEST_LEASE create context when RequestedOplockLevel is not equal to SMB2_OPLOCK_LEVEL_LEASE.

<279> Section 3.3.5.9.8: On Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, the Lease.ClientLeaseId is passed to the object store when processing continues at open/create time. A new or existing lease is thereby associated with the resulting open.

To acquire or promote the lease as dictated by the SMB2_CREATE_REQUEST_LEASE Create Context, a subsequent object store call is invoked as described in [MS-FSA] section 2.1.5.17. The Open parameter passed is the Open.Local result from the above operation, and the Type parameter is LEVEL_GRANULAR to indicate a Lease request. The RequestedOplockLevel parameter is constructed to include zero or more bits as follows.

Object Store RequestedOplockLevel bit to be set

SMB2 Lease.LeaseState bit requested

READ_CACHING

SMB2_LEASE_READ_CACHING

WRITE_CACHING

SMB2_LEASE_WRITE_CACHING

HANDLE_CACHING

SMB2_LEASE_HANDLE_CACHING

The Status code returned indicates whether the requested lease was granted.

<280> Section 3.3.5.9.10:  If the Timeout value in the request is not zero, Windows 8 and Windows Server 2012 SMB2 servers set Timeout to the Timeout value in the request.

<281> Section 3.3.5.9.10:  If the Timeout value in the request is zero and Share.CATimeout is not zero, Windows 8 and Windows Server 2012 SMB2 servers set Timeout to Share.CATimeout. If the Timeout value in the request is zero and Share.CATimeout is zero, Windows 8 and Windows Server 2012 SMB2 servers set Timeout to 60 seconds.

If the Timeout value in the request is zero, Windows 8.1 and Windows Server 2012 R2 SMB2 servers set Timeout to 180 seconds.

<282> Section 3.3.5.9.10:  Windows 8 and Windows Server 2012 R2 SMB2 servers set Open.DurableOpenTimeout to 60 seconds.

<283> Section 3.3.5.9.11: Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 servers do not ignore the SMB2_CREATE_REQUEST_LEASE_V2 create context when Connection.Dialect is equal to "2.1" or if RequestedOplockLevel is not equal to SMB2_OPLOCK_LEVEL_LEASE.

<284> Section 3.3.5.9.11:  On Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, the Lease.ClientLeaseId and Lease.ParentLeaseKey are passed to the object store in the form of TargetOplockKey and ParentOplockKey. A new or existing lease is thereby associated with the resulting open.

To acquire or promote the lease as dictated by the SMB2_CREATE_REQUEST_LEASE_V2 Create Context, a subsequent object store call is invoked as described in [MS-FSA] section 2.1.5.17 Server Requests an Oplock. The Open parameter passed is the Open result from the above operation, and the Type parameter is LEVEL_GRANULAR to indicate a Lease request. The RequestedOplockLevel field is constructed to include zero or more bits as follows.

Object Store RequestedOplockLevel bit to be set

SMB2 Lease.LeaseState bit requested

READ_CACHING

SMB2_LEASE_READ_CACHING

WRITE_CACHING

SMB2_LEASE_WRITE_CACHING

HANDLE_CACHING

SMB2_LEASE_HANDLE_CACHING

The Status code returned indicates whether the requested lease was granted.

<285> Section 3.3.5.9.12: Windows Server 2012 with [KB2770917] and Windows 8 with [KB2770917] fail the CREATE request with STATUS_INVALID_PARAMETER if the request includes the SMB2_DHANDLE_FLAG_PERSISTENT bit in the Flags field of the SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2 Create Context.

If the Session was established by specifying PreviousSessionId in the SMB2 SESSION_SETUP request, therefore invalidating the previous session, Windows 8.1 and Windows Server 2012 R2 close the durable opens established on the previous session.

<286> Section 3.3.5.9.12: If Open.OplockLevel is equal to SMB2_OPLOCK_LEVEL_BATCH or Open.Lease.LeaseState includes SMB2_LEASE_HANDLE_CACHING, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 continue to process the request.

<287> Section 3.3.5.9.12: Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not perform Lease version verification.

<288> Section 3.3.5.9.12:  Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not perform this verification and continue to process the request.

<289> Section 3.3.5.9.13: Windows SMB3 servers compute the maximal access to return by querying the security attributes of the file with [MS-FSA] section 2.1.5.13, and performing an access check against the credentials provided by the request.

<290> Section 3.3.5.10: Windows Vista, Windows Server 2008 , Windows 7, and Windows Server 2008 R2 validate the open before verifying the session.

<291> Section 3.3.5.10: Windows obtains attributes and end of file from the object store FileBasicInformation [MS-FSA] section 2.1.5.11.6 and [MS-FSCC] section 2.4.7.

<292> Section 3.3.5.11: Windows flushes any cached data to the file with Server Requests Flushing Cached Data [MS-FSA] section 2.1.5.6.

<293> Section 3.3.5.11: If the request target is a named pipe or file, Windows-based servers handle this request asynchronously.

<294> Section 3.3.5.12: Windows 7 and Windows Server 2008 R2 fail the request with STATUS_BUFFER_OVERFLOW if the Length field is greater than Connection.MaxReadSize. Windows Vista SP1 and Windows Server 2008 will fail the request with STATUS_BUFFER_OVERFLOW if the Length field is greater than 524288.

<295> Section 3.3.5.12: Windows reads from a file with Server Requests a Read [MS-FSA] section 2.1.5.2.

Object Store parameter

SMB2 parameter

ByteOffset

ByteOffset

ByteCount

ByteCount

Open

Open.Local

Key

0

Unbuffered

Set to TRUE if SMB2_READFLAG_READ_UNBUFFERED is set in the Flags field of the request, otherwise set to FALSE.

<296> Section 3.3.5.12: Windows SMB2 servers send an interim response to the client and handle the read asynchronously if the read is not finished in 0.5 milliseconds.

<297> Section 3.3.5.12: Windows-based servers handle the following commands asynchronously: SMB2 Create (section 2.2.13) when this create would result in an oplock break, SMB2 IOCTL Request (section 2.2.31) for FSCTL_PIPE_TRANSCEIVE if it blocks for more than 1 millisecond, SMB2 IOCTL Request for FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE (section 2.2.31) when oplock break happens, SMB2 Change_Notify Request (section 2.2.35) if it blocks for more than 0.5 milliseconds, SMB2 Read request (section 2.2.19) for named pipes if it blocks for more than 0.5 milliseconds, SMB2 Write request (section 2.2.21) for named pipes if it blocks for more than 0.5 milliseconds, SMB2 Write Request (section 2.2.21) for large file write, SMB2 lock request (section 2.2.26) if the SMB2_LOCKFLAG_FAIL_IMMEDIATELY flag is not set, and SMB2 FLUSH Request (section 2.2.17) for named pipes.

<298> Section 3.3.5.13: Windows SMB2 servers allow the operation when either FILE_APPEND_DATA or FILE_WRITE_DATA is set in Open.GrantedAccess.

<299> Section 3.3.5.13: Windows 7 and Windows Server 2008 R2 fail the request with STATUS_BUFFER_OVERFLOW instead of STATUS_INVALID_PARAMETER if the Length field is greater than Connection.MaxWriteSize. Windows Vista SP1 and Windows Server 2008 do not validate the Length field in SMB2 Write Request.

<300> Section 3.3.5.13: If the Flags field contains any bit values other than those specified in section 2.2.21, Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 fail the request with STATUS_INVALID_PARAMETER.

<301> Section 3.3.5.13: If the Channel value is not equal to 0x00000000 or 0x00000001, Windows Server 2012 fails the request with STATUS_INVALID_PARAMETER. If the Channel value is not equal to 0x00000000, Windows 8 fails the request with STATUS_INVALID_PARAMETER.

<302> Section 3.3.5.13: Windows writes to a file with Server Requests a Write [MS-FSA] section 2.1.5.3.

Object Store parameter

SMB2 parameter

ByteOffset

ByteOffset

ByteCount

ByteCount

InputBuffer

Buffer

Open

Open.Local

Key

0

Unbuffered

Set to TRUE if SMB2_WRITEFLAG_WRITE_UNBUFFERED is set in the Flags field of the request, otherwise set to FALSE.

<303> Section 3.3.5.13: Windows-based servers handle the following commands asynchronously:

  • SMB2 CREATE Request (section 3.3.5.9) when this create would result in an oplock break.

  • SMB2 IOCTL Request (section 3.3.5.15) for FSCTL_PIPE_TRANSCEIVE if it blocks for more than 1 millisecond. For FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE, when an oplock break happens.

  • SMB2 CHANGE_NOTIFY Request (section 3.3.5.19) if it blocks for more than 0.5 milliseconds.

  • SMB2 READ Request (section 3.3.5.12) for named pipes if it blocks for more than 0.5 milliseconds.

  • SMB2 WRITE Request (section 3.3.5.13) for named pipes if it blocks for more than 0.5 milliseconds.

  • SMB2 WRITE Request (section 3.3.5.13) for large file write.

  • SMB2 LOCK Request (section 3.3.5.14) if the SMB2_LOCKFLAG_FAIL_IMMEDIATELY flag is not set.

  • SMB2 FLUSH Request (section 3.3.5.11) for named pipes.

<304> Section 3.3.5.14: Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 validate the open before verifying the session.

<305> Section 3.3.5.14: Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not verify the LockSequence value in the SMB2 LOCK Request (section 2.2.26) when both Open.IsResilient and Open.IsPersistent are FALSE.

<306> Section 3.3.5.14.1: Windows-based servers ignore this value while processing Unlocks.

<307> Section 3.3.5.14.1: Windows processes unlock with Server Requests unlock of a Byte-Range [MS-FSA] section 2.1.5.8.

Object Store parameter

SMB2 parameter

FileOffset

Offset

Length

Length

Open

Open.Local

LockKey

0

<308> Section 3.3.5.14.2: Windows-based servers check for SMB2_LOCKFLAG_FAIL_IMMEDIATELY only for the first element of the Locks array.

<309> Section 3.3.5.14.2: Refer to [FSBO] for implementation-specific details of how byte range locks can be implemented.

<310> Section 3.3.5.14.2: Windows processes lock with Server Requests a Byte-Range Lock [MS-FSA] section 2.1.5.7.

Object Store parameter

SMB2 parameter

FileOffset

Offset

Length

Length

ExclusiveLock

FALSE if SMB2_LOCKFLAG_SHARED_LOCK set, or TRUE if SMB2_LOCKFLAG_EXCLUSIVE_LOCK set

FailImmediately

TRUE if  SMB2_LOCKFLAG_FAIL_IMMEDIATELY set

Open

Open.Local

LockKey

0

<311> Section 3.3.5.15: Windows Vista SP1 and Windows Server 2008 SMB2 servers fail an IOCTL request with STATUS_INVALID_PARAMETER if [ max(InputCount, MaxInputResponse) + max(OutputCount, MaxOutputResponse) ] is greater than 262144.

<312> Section 3.3.5.15: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 SMB2 servers copy the OutputCount bytes into the output buffer for the following FSCTLs:

  • FSCTL_GET_RETRIEVAL_POINTERS

  • FSCTL_GET_REPARSE_POINT

  • FSCTL_PIPE_TRANSCEIVE

  • FSCTL_PIPE_PEEK

  • FSCTL_DFS_GET_REFERRALS

Windows Vista SP1 and Windows Server 2008 SMB2 servers copy the OutputCount bytes into the output buffer for the following FSCTLs:

  • FSCTL_PIPE_TRANSCEIVE

  • FSCTL_PIPE_PEEK

  • FSCTL_DFS_GET_REFERRALS

All other FSCTL commands will be failed with error STATUS_BUFFER_OVERFLOW through error response specified in section 2.2.2.

<313> Section 3.3.5.15: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview allow only the CtlCode values, as specified in section 2.2.31, and the following CtlCode values, as specified in [MS-FSCC] section 2.3.

FSCTL name

FSCTL function number

FSCTL_CREATE_OR_GET_OBJECT_ID

0x900c0

FSCTL_DELETE_OBJECT_ID

0x900a0

FSCTL_DELETE_REPARSE_POINT

0x900ac

FSCTL_FILESYSTEM_GET_STATISTICS

0x90060

FSCTL_FIND_FILES_BY_SID

0x9008f

FSCTL_GET_COMPRESSION

0x9003c

FSCTL_GET_NTFS_VOLUME_DATA

0x90064

FSCTL_GET_OBJECT_ID

0x9009c

FSCTL_GET_REPARSE_POINT

0x900a8

FSCTL_GET_RETRIEVAL_POINTERS

0x90073

FSCTL_IS_PATHNAME_VALID

0x9002c

FSCTL_LMR_SET_LINK_TRACKING_INFORMATION

0x1400ec

FSCTL_OFFLOAD_READ

0x94264

FSCTL_OFFLOAD_WRITE

0x98268

FSCTL_QUERY_FAT_BPB

0x90058

FSCTL_QUERY_FILE_REGIONS

0x90284

FSCTL_QUERY_ALLOCATED_RANGES

0x940cf

FSCTL_QUERY_ON_DISK_VOLUME_INFO

0x9013c

FSCTL_QUERY_SPARING_INFO

0x90138

FSCTL_READ_FILE_USN_DATA

0x900eb

FSCTL_SET_COMPRESSION

0x9c040

FSCTL_SET_DEFECT_MANAGEMENT

0x98134

FSCTL_SET_OBJECT_ID

0x90098

FSCTL_SET_OBJECT_ID_EXTENDED

0x900bc

FSCTL_SET_REPARSE_POINT

0x900a4

FSCTL_SET_SPARSE

0x900c4

FSCTL_SET_ZERO_DATA

0x980c8

FSCTL_SET_ZERO_ON_DEALLOCATION

0x90194

FSCTL_WRITE_USN_CLOSE_RECORD

0x900ef

Windows 8.1 and Windows Server 2012 R2 allow these additional CtlCode values, as specified in [MS-RSVD].

FSCTL name

FSCTL function number

FSCTL_SVHDX_SYNC_TUNNEL_REQUEST

0x90304

FSCTL_QUERY_SHARED_VIRTUAL_DISK_SUPPORT

0x90300

Windows 10 and Windows Server 2016 Technical Preview allow the additional CtlCode value, as specified in [MS-RSVD].

FSCTL name

FSCTL function number

FSCTL_SVHDX_ASYNC_TUNNEL_REQUEST

0x90364

Windows 10 and Windows Server 2016 Technical Preview allow the additional CtlCode value, as specified in [MS-FSCC].

FSCTL name

FSCTL function number

FSCTL_DUPLICATE_EXTENTS_TO_FILE

0x98344

Windows 10 and Windows Server 2016 Technical Preview allow the additional CtlCode value, as specified in [MS-SQOS].

FSCTL name

FSCTL function number

FSCTL_STORAGE_QOS_CONTROL

0x90350

<314> Section 3.3.5.15: Windows Vista SP1 and Windows Server 2008 servers without [MSKB-978491], and Windows 7 and Windows Server 2008 R2 without Service Pack 1 ignore a FSCTL_SRV_NOTIFY_TRANSACTION request specifying a valid FileId, don't send a response to the client, and reply to a FSCTL_SRV_NOTIFY_TRANSACTION with an invalid or -1 FileId with STATUS_INVALID_PARAMETER.

For the following FSCTLs, Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 return STATUS_FILE_CLOSED instead of STATUS_INVALID_DEVICE_REQUEST:

  • FSCTL_QUERY_NETWORK_INTERFACE_INFO

  • FSCTL_DFS_GET_REFERRALS_EX

  • FSCTL_VALIDATE_NEGOTIATE_INFO

<315> Section 3.3.5.15.1: Windows enumerates previous versions of an existing file by forming a FileBothDirectoryInformation object store request for the file including an @GMT-* wildcard as described in [MS-SMB] section 2.2.1.1.1 and [MS-FSA] section 2.1.5.5.3.1.

<316> Section 3.3.5.15.1: Windows-based SMB2 servers will place 2 extra bytes set to zero in SnapShots array and set SnapShotArraySize to 2, if NumberOfSnapShots is zero.

<317> Section 3.3.5.15.2: A Windows-based DFS server does not return any data to the caller if the buffer supplied to FSCTL_GET_DFS_REFERRALS is too small.

<318> Section 3.3.5.15.3: Windows-based servers return STATUS_INVALID_DEVICE_REQUEST if the FSCTL_PIPE_TRANSCEIVE being executed is not a named pipe share.

<319> Section 3.3.5.15.3: Windows SMB2 servers send an interim response to the client if the read/write attempt is not finished in 1 millisecond.

<320> Section 3.3.5.15.3: Some Windows–based SMB2 servers return the input buffer that was received in the request as part of the response. Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 will not return the input buffer that was received in the request, and the InputCount field is always zero. Windows Vista SP1 and Windows Server 2008 will send back the input buffer based on the InputOffset and InputCount fields indicated in the request.

<321> Section 3.3.5.15.3: Windows–based SMB2 servers set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<322> Section 3.3.5.15.4: Windows-based servers return STATUS_INVALID_DEVICE_REQUEST, if FSCTL_PIPE_PEEK request being executed is not a named pipe share.

<323> Section 3.3.5.15.4: Windows SMB2 servers will set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<324> Section 3.3.5.15.5: Windows servers do not support any additional contexts.

<325> Section 3.3.5.15.5: Windows servers construct the 24-byte blob using Open.DurableFileId and other pieces of information which include the process ID of the caller and a timestamp.

<326> Section 3.3.5.15.6: Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 do not verify byte-range locks on both source and destination files.

<327> Section 3.3.5.15.7: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 servers support the FSCTL_SRV_READ_HASH request.

<328> Section 3.3.5.15.7: When the branch cache feature is available and the file size is less than 65,536 bytes, Windows servers fail the request with STATUS_HASH_NOT_PRESENT.

<329> Section 3.3.5.15.7:  Windows-based servers set the FileDataOffset field to the starting offset from the segment covering the Offset requested in the SRV_READ_HASH request.

<330> Section 3.3.5.15.8: The following FSCTLs are explicitly blocked by Windows-based SMB2 server and not passed through to the object store. They are failed with STATUS_NOT_SUPPORTED.

FSCTL_REQUEST_OPLOCK_LEVEL_1 (0x00090000)

FSCTL_REQUEST_OPLOCK_LEVEL_2 (0x00090004)

FSCTL_REQUEST_BATCH_OPLOCK (0x00090008)

FSCTL_REQUEST_FILTER_OPLOCK (0x0009005C)

FSCTL_OPLOCK_BREAK_ACKNOWLEDGE (0x0009000C)

FSCTL_OPBATCH_ACK_CLOSE_PENDING (0x00090010)

FSCTL_OPLOCK_BREAK_NOTIFY (0x00090014)

FSCTL_MOVE_FILE (0x00090074)

FSCTL_MARK_HANDLE (0x000900FC)

FSCTL_QUERY_RETRIEVAL_POINTERS (0x0009003B)

FSCTL_PIPE_ASSIGN_EVENT (0x00110000)

FSCTL_GET_VOLUME_BITMAP (0x0009006F)

FSCTL_GET_NTFS_FILE_RECORD (0x00090068)

FSCTL_INVALIDATE_VOLUMES (0x00090054)

FSCTL_READ_USN_JOURNAL (0x000900BB)

FSCTL_CREATE_USN_JOURNAL (0x000900E7)

FSCTL_QUERY_USN_JOURNAL (0x000900F4)

FSCTL_DELETE_USN_JOURNAL (0x000900F8)

FSCTL_ENUM_USN_DATA (0x000900B3)

FSCTL_QUERY_DEPENDENT_VOLUME (0x000901F0)

FSCTL_SD_GLOBAL_CHANGE (0x000901F4)

FSCTL_GET_BOOT_AREA_INFO (0x00090230)

FSCTL_GET_RETRIEVAL_POINTER_BASE (0x00090234)

FSCTL_SET_PERSISTENT_VOLUME_STATE (0x00090238)

FSCTL_QUERY_PERSISTENT_VOLUME_STATE (0x0009023C)

FSCTL_REQUEST_OPLOCK (0x00090240)

FSCTL_TXFS_MODIFY_RM (0x00098144)

FSCTL_TXFS_QUERY_RM_INFORMATION (0x00094148)

FSCTL_TXFS_ROLLFORWARD_REDO (0x00098150)

FSCTL_TXFS_ROLLFORWARD_UNDO (0x00098154)

FSCTL_TXFS_START_RM (0x00098158)

FSCTL_TXFS_SHUTDOWN_RM (0x0009815C)

FSCTL_TXFS_READ_BACKUP_INFORMATION (0x00094160)

FSCTL_TXFS_WRITE_BACKUP_INFORMATION (0x00098164)

FSCTL_TXFS_CREATE_SECONDARY_RM (0x00098168)

FSCTL_TXFS_GET_METADATA_INFO (0x0009416C)

FSCTL_TXFS_GET_TRANSACTED_VERSION (0x00094170)

FSCTL_TXFS_SAVEPOINT_INFORMATION (0x00098178)

FSCTL_TXFS_CREATE_MINIVERSION (0x0009817C)

FSCTL_TXFS_TRANSACTION_ACTIVE (0x0009418C)

FSCTL_TXFS_LIST_TRANSACTIONS (0x000941E4)

FSCTL_TXFS_READ_BACKUP_INFORMATION2 (0x000901F8)

FSCTL_TXFS_WRITE_BACKUP_INFORMATION2 (0x00090200)

FSCTL_QUERY_FILE_REGIONS (0x00090284)

FSCTL_IS_CSV_FILE (0x00090248)

FSCTL_IS_FILE_ON_CSV_VOLUME (0x0009025C)

Windows-based SMB2 servers fail FSCTLs whose transfer type is METHOD_NEITHER with error STATUS_NOT_SUPPORTED except the following ones. For more information about FSCTL transfer type, see [MSDN-IoCtlCodes].

FSCTL_PIPE_TRANSCEIVE (0x0011C017)

FSCTL_QUERY_ALLOCATED_RANGES (0x000940CF)

FSCTL_WRITE_USN_CLOSE_RECORD (0x000900EF)

FSCTL_READ_FILE_USN_DATA (0x000900EB)

FSCTL_GET_RETRIEVAL_POINTERS (0x00090073)

FSCTL_FIND_FILES_BY_SID (0x0009008F)

FSCTL_SRV_READ_HASH (0x001441BB)

<331> Section 3.3.5.15.8: Windows performs passthrough FSCTL operations via Server Requests an FsControl Request [MS-FSA] section 2.1.5.9.

<332> Section 3.3.5.15.8: Windows–based SMB2 servers will set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<333> Section 3.3.5.15.9: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 servers process the FSCTL_LMR_REQUEST_RESILIENCY request regardless of the negotiated dialect.

<334> Section 3.3.5.15.9: Windows 7 and Windows Server 2008 R2 servers keep the resilient handle open indefinitely when the requested Timeout value is equal to zero. Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 servers set a constant value of 120 seconds.

<335> Section 3.3.5.15.13: Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 require that the caller is a member of the Administrators group.

<336> Section 3.3.5.16: Windows servers use only the 30 least significant bits of AsyncId to look up a request in Connection.AsyncCommandList.

<337> Section 3.3.5.16: When being handled by an object store, Windows performs cancellation of in-progress requests via the interface in [MS-FSA] section 2.1.5.19, Server Requests Canceling an Operation, passing Request.CancelRequestId as an input parameter. Windows does not attempt to cancel other in-progress requests.

<338> Section 3.3.5.17: Windows Vista SP1, Windows 7, Windows Server 2008, and Windows Server 2008 R2 servers do not disconnect the connection.

<339> Section 3.3.5.18:  Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 fail the request with STATUS_NOT_SUPPORTED.

<340> Section 3.3.5.18: The Windows SMB2 server implementation closes and reopens the directory handle in order to "reset" the enumeration state. So any outstanding operations on the directory handle will be failed with a STATUS_FILE_CLOSED error.

<341> Section 3.3.5.18:  If the length of the received data is less than the size of SMB2 header (0x40) plus size of SMB2 QUERY_DIRECTORY request (0x21), Windows servers fail the request with STATUS_INVALID_PARAMETER. Otherwise, if FileNameLength is 0 and the underlying file system is NTFS, Windows servers fail the request with STATUS_OBJECT_NAME_INVALID.

<342> Section 3.3.5.18: Windows-based servers do not support resuming an enumeration at a specified FileIndex. The server will ignore this flag.

<343> Section 3.3.5.18: Windows performs directory query information requests via the corresponding interfaces in [MS-FSA] section 2.1.5.5.3:

  • FileBothDirectoryInformation: [MS-FSA] section 2.1.5.5.3.1.

  • FileDirectoryInformation: [MS-FSA] section 2.1.5.5.3.2.

  • FileFullDirectoryInformation: [MS-FSA] section 2.1.5.5.3.3.

  • FileIdBothDirectoryInformation: [MS-FSA] section 2.1.5.5.3.4.

  • FileIdFullDirectoryInformation: [MS-FSA] section 2.1.5.5.3.5.

  • FileNamesInformation: [MS-FSA] section 2.1.5.5.3.6.

<344> Section 3.3.5.19: Windows Vista SP1 and Windows Server 2008 limit OutputBufferLength size to 256 KB.

<345> Section 3.3.5.19: Windows-based servers handle the following commands asynchronously: SMB2 Create (section 2.2.13) when this create would result in an oplock break, SMB2 IOCTL Request (section 2.2.31) for FSCTL_PIPE_TRANSCEIVE if it blocks for more than 1 millisecond, SMB2 IOCTL Request for FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE (section 2.2.31) when oplock break happens, SMB2 Change_Notify Request (section 2.2.35) if it blocks for more than 0.5 milliseconds, SMB2 Read Request (section 2.2.19) for named pipes if it blocks for more than 0.5 milliseconds, SMB2 Write Request (section 2.2.21) for named pipes if it blocks for more than 0.5 milliseconds, SMB2 Write Request (section 2.2.21) for large file write, SMB2 lock Request (section 2.2.26) if the SMB2_LOCKFLAG_FAIL_IMMEDIATELY flag is not set, and SMB2 FLUSH Request (section 2.2.17) for named pipes.

<346> Section 3.3.5.19: Windows requests ChangeNotify processing via Server Requests Change Notifications for a Directory in [MS-FSA] section 2.1.5.10. If the SMB2_WATCH_TREE flag is set, the WatchTree boolean is passed as TRUE. ChangeNotify notification is reported as described in [MS-FSA] section 2.1.5.10.1.

<347> Section 3.3.5.20: Windows-based SMB2 servers fail the request with STATUS_INVALID_PARAMETER if OutputBufferLength is greater than 65536.

<348> Section 3.3.5.20.1: Windows-based SMB2 servers fail the following request levels with STATUS_INVALID_INFO_CLASS instead of STATUS_NOT_SUPPORTED: 1, 2, 3, 10, 11, 12, 13, 19, 20, 27, 31, 36, 37, 38, 39, 40, 50.

<349> Section 3.3.5.20.1: Windows-based SMB2 servers fail the following request levels with STATUS_NOT_SUPPORTED instead of STATUS_INVALID_INFO_CLASS: 41, 43, 47, 49, 51, and 53. Windows-based SMB2 servers fail requests of level 52 with STATUS_INFO_LENGTH_MISMATCH.

<350> Section 3.3.5.20.1: Windows-based SMB2 servers will set CurrentByteOffset to any value.

<351> Section 3.3.5.20.1: Windows performs SMB2 GET_INFO SMB2_0_INFO_FILE processing as specified in the subsection of [MS-FSA] section 2.2.37, corresponding to the requested FILE_INFORMATION_CLASS value of the FileInfoClass request field, as listed in section 2.2.37. If the information class is FileAllInformation, Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 return an absolute path to the file name as part of FileNameInformation.

<352> Section 3.3.5.20.2: Windows performs SMB2 GET_INFO SMB2_0_INFO_FILESYSTEM processing via the subsection of [MS-FSA] section 2.1.5.11 corresponding to the requested FS_INFORMATION_CLASS value of the FileInfoClass request field, as listed in section 2.2.37.

<353> Section 3.3.5.20.2: SetFsInfo calls to Windows servers fail with STATUS_ACCESS_DENIED because Windows servers do not allow setting volume information over the network.

<354> Section 3.3.5.20.3: Windows performs SMB2 GET_INFO SMB2_0_INFO_SECURITY processing via Server Requests a Query of Security Information ([MS-FSA] section 2.1.5.13).

<355> Section 3.3.5.20.4: Windows-based servers do support quotas, if configured.

<356> Section 3.3.5.20.4: Windows performs SMB2 GET_INFO SMB2_0_INFO_QUOTA processing via Server Requests a Query of Quota Information ([MS-FSA] section 2.1.5.20).

<357> Section 3.3.5.21.1: Windows-based SMB2 servers fail the following request levels with STATUS_NOT_SUPPORTED instead of STATUS_INVALID_INFO_CLASS: 30, 41, 42, 43.

<358> Section 3.3.5.21.1: Windows performs SMB2 SET_INFO SMB2_0_INFO_FILE processing via the subsection of [MS-FSA] section 2.1.5.14 corresponding to the requested FILE_INFORMATION_CLASS value of the FileInfoClass request field, as listed in section 2.2.37.

<359> Section 3.3.5.21.2: Windows performs SMB2 SET_INFO SMB2_0_INFO_FILESYSTEM processing via the subsection of [MS-FSA] section 2.1.5.15 corresponding to the requested FS_INFORMATION_CLASS value of the FileInfoClass request field, as listed in section 2.2.37.

<360> Section 3.3.5.21.3: If the underlying object store does not support object security based on Access Control Lists (as specified in [MS-DTYP] section 2.4.5), it returns STATUS_SUCCESS.

<361> Section 3.3.5.21.3: Windows performs SMB2 SET_INFO SMB2_0_INFO_SECURITY processing via Server Requests Setting of Security Information [MS-FSA] section 2.1.5.16.

<362> Section 3.3.5.21.4: Windows servers do support quotas, if configured.

<363> Section 3.3.5.21.4: Windows performs SMB2 SET_INFO SMB2_0_INFO_QUOTA processing via Server Requests Setting of Quota Information ([MS-FSA] section 2.1.5.21).

<364> Section 3.3.5.22.1: Windows-based servers complete the oplock break indication request with the object store by providing the following SMB2 parameters as input parameters, as specified [MS-FSA] section 2.1.5.18:

Object Store parameter

SMB2 parameter

Open

Open.LocalOpen

Type

SMB2_OPLOCK_LEVEL_NONE

<365> Section 3.3.5.22.1: Windows-based servers complete the oplock break indication request with the object store by providing the following SMB2 parameters as input parameters, as specified [MS-FSA] section 2.1.5.18:

Object Store parameter

SMB2 parameter

Open

Open.LocalOpen

Type

SMB2_OPLOCK_LEVEL_NONE

<366> Section 3.3.5.22.1: Windows-based servers complete the oplock break indication request with the object store by providing the following SMB2 parameters as input parameters, as specified [MS-FSA] section 2.1.5.18:

Object Store parameter

SMB2 parameter

Open

Open.LocalOpen

Type

SMB2_OPLOCK_LEVEL_NONE

<367> Section 3.3.5.22.1: If multiple conflicting Opens occur before an Oplock Acknowledgment for the first oplock break is received, that change the server oplock state to a level that is lower than the pending notification, the server fails the Oplock Acknowledgment with STATUS_REQUEST_NOT_ACCEPTED. Windows-based servers complete the oplock break indication request with the object store by providing the following SMB2 parameters as input parameters, as specified in [MS-FSA] section 2.1.5.18:

Object Store parameter

SMB2 parameter

Open

Open.LocalOpen

Type

OplockLevel

<368> Section 3.3.6.3: Windows servers use a constant time-out value of 45 seconds.

<369> Section 3.3.7.1: Windows performs cancellation of in-progress requests via the interface in [MS-FSA] section 2.1.5.19, Server Requests Canceling an Operation, passing Request.CancelRequestId as an input parameter.

<370> Section 3.3.7.1: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 servers will not reset ResilientOpenScavengerExpiryTime.

<371> Section 3.3.7.1: Windows servers set this value to 16 minutes.

<372> Section 3.3.7.1: Windows performs cancellation of in-progress requests via the interface in [MS-FSA] section 2.1.5.19, Server Requests Canceling an Operation, passing Request.CancelRequestId as an input parameter.

Show:
© 2015 Microsoft