This is the complicated part about offline files in Windows. It is not a mere synchronization utility and is not meant to be one. It allows for the user to access the same \\server\share UNC path even when there is no network connection and to do this it uses a combination of components that exist in both the kernel and user mode parts of the operating system. The integration between the SMB mini-redirector and the offline files component is huge so if a fileserver is somehow not accessible over the SMB protocol, the offline files component will disable the whole namespace that starts with \\server.

This tight integration and marking of fileservers as offline and not parts of the path offline may in some cases be unideal, such as in the case of using a DFS path and making a part of this path available offline. Suppose that you have a \\domain\dfsroot\publicshare\user01 path that resides on a domain-based DFS path. Addding to this, suppose also that the user accesses other parts of this DFS path without making it available offline. The problem arises when Offline files decides that the above path becomes unaccessible. At this point, any path that starts with \\domain will be marked as offline. If the user then tries to access some other dfs root and another folder that resides on that root, he won't be able to do that, such as \\domain\dfsroot02\someotherfolder will also be offline.

To overcome this situation we need to understand how the redirector, mrxsmb.sys handles server objects. Suppose that you establish a file share connection to a fileserver using the following in a row:

a. \\fileserverNetBIOSName\Share

b. \\IPAddressOfServer\Share

c. \\FQDNofFileServer\Share

All these 3 different references to the same file server will have their own server object created, called an SRV_OPEN in the redir terminology. Essentially these will behave like 3 different connections to the same fileserver. If at this moment let's say that you are accessing the dfs path \\domain\dfsroot\publicshare\user01 and the fileserver that hosts this folder goes offline. Immediately after this all parts of the \\domain will be inaccessible.

To overcome this limitation, you can create a CNAME record for the domain name and configure your clients to access this path when accessing DFS. So instead accessing \\domain\dfsroot\publicshare\user01 you can create a cname such that users can connect to \\CNAMEforDomain\dfsroot\publicshare\user01 . With this configuration even if a single fileserver in that path goes down, offline folder and the redirector will mark the bogus \\CNAMEforDomain path as offline and you will still have access to the original domain and all hosted domain based root under this domain through \\domain.

One thing to note is when you create a CNAME and immediately try to access the path you may get a "Duplicate name exists on the network" error back. This occurrs because by default the SMB file server in Windows does not allow connections to a different name than the registered name on the machine. So you can't - by default - access a file server named FILESERVER by CNAMEFILESERVER. There is a key that can be used to disable this security check and it is called DisableStrictNameChecking, when set to one, the above workaround for DFS / Offline files integration will work without any issues. DisableStrictNameChecking is a parameter of the LanManServer and you can check "Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name", https://support.microsoft.com/kb/281308. The hotfix mentioned in this article is meant for Windows 2000 and you do not need to install this hotfix on Windows Server 2003, the key can be configured directly.

• TCP Chimney offload
• Receive Side Scaling (RSS)
• Network Direct Memory Access (NetDMA)

Modern networked servers that run on the latest hardware like the PCIe bus and the associated new MSI interrupt technologies will take advantage of technologies like the RSS and NetDMA. TCP Chimney offloading helps with reassembly of TCP streams and offloads all TCP related computation to the NIC on-board processor thereby reducing the workload on the CPU and RSS will enable better handling and load distribution of incoming NIC interrupts in multiprocessor systems.

The details of these technologies are covered in a number of places in this white paper and KB912222, "The Microsoft Windows Server 2003 Scalable Networking Pack release" and KB936594, "You may experience network-related problems after you install Windows Server 2003 SP2 or the Scalable Networking Pack on a Windows Server 2003-based computer".

As this is a framework that is built to integrate a software function that to be offloaded to hardware, tight integration with the NIC hardware and associated drivers are there. Due the complexity and nature of this integration, and partly due to the fact that the above mentioned 3 technology frameworks being fairly new, with certain deployments we have faced issues where the workaround moving forward was to disable this feature on that server. Is it a concern to disable these features?

Not really, for most of the deployments out there this technology is not required.  Most servers will not see any performance benefit at all by deploying this technology. Let's say that you have a very busy file server with a NIC that is %80 utilized at all times. If on this server you don't see the processor utilization around the same numbers, then you'll probably not see any difference in performance after applying this pack on that server. The main benefit will be with servers that have multiple processors, huge number of files to serve that have multiple network cards and are serving couple gigs bps. These servers will benefit from RSS in utilizing all processors in processing the MSI interrupts and distributing them equally among all processors, by offloading the TCP work to the NIC and they will perform much better when the load is more than a regular networked server.

In summary it would be safe to say that when you have issues with the scalable networking pack, either due the problem described in 936594 or because you have an incompatibility with the network hardware, it is advisable to contact Microsoft PSS and in the meantime remove the features enabled by this pack. It is important to monitor a server's network and processor performance before going forward to enable this feature set on a server, as described above there are only certain scenarios coupled with a high load on CPU usage in a system where this will be useful.

In a very fast network connection and during the transfer of a long enough data stream, tcp sequence numbers can wrap and cause the receiving system under certain conditions to reset the connection(some references give figures of this happening in 34 seconds on a 1 Gbps link).

Sequence numbers are a way to mark the offset in data to the receiving end, letting them know which part of the data they have received. the current tcp implementation uses 32 bit unsigned integers for sequence numbers. during such a transfer as described above, the receiving end could receive data that seems to be already received and may decide to discard this.

RFC 1323 has come up with a solution and calls this Protection against Wrapped Sequence Numbers or PAWS in short. PAWS is implemented in Windows and allows for the use of the TCP Timestamping option in addition to the sequence number to make sure that even when a seemingly wrapped sequence number is received, the timestamp of the packet that has been received is also checked to make sure that it is actually a new packet and not a part that we are re-receiving.

so as we are checking the timestamp now as well as the sequence number, there are other things to consider. what about clock synchronization on the sender and the receiver? PAWS does not rely on any sort of time sync between the sender and the receiver. what basically happens is, when a packet is received that contains a timestamp, we take that and save it as TS.Recent as referenced in RFC 1323, the current timestamp for that sender. as we receive more packets, the timestamp is increased accordingly and is based on what we receive as a timestamp of that packet from the sender.

Timestamps are ever increasing and that also is an important characteristic of the checks that PAWS does. if we receive a packet that has an older timestamp we decide that this packet cannot be received and in the end passed to the user and as it is an old packet, it will be discarded. an attacker could actually use this to reset a connection on the server: if you send the server a packet with a good sequence number and a much later timestamp in the future, you will invalidate all packets that should actually be received from the original sender. Microsoft released https://www.microsoft.com/technet/security/advisory/899480.mspx to address this and actually all systems running XP SP2 and 2003 Srv SP1 are protected against this. the issue was first addressed in the MS05-019, however that advisory does not contain references to this issue.

To read more on this see RFC 1323 and the KB article from Microsoft where we give details as to how this is implemented in Windows.

RFC 1323 - TCP Extensions for High Performance, https://www.faqs.org/rfcs/rfc1323.html

Description of Windows 2000 and Windows Server 2003 TCP Features, https://support.microsoft.com/kb/224829

Make sure to put in a comment with any questions you may have. Happy networking!

I've used a very simple application on both clients to demonstrate a simple concept, an application locking a file and not sharing. the code that runs on both client machines is below:

HANDLE hFile;
printf("press Enter to create file handle..\n");
getchar();

hFile = CreateFile(L"\\\\192.168.1.100\\share\\foo.bar",
  GENERIC_READ | GENERIC_WRITE,
  0,
  NULL,
  OPEN_EXISTING,
  FILE_ATTRIBUTE_NORMAL,
  NULL);
 
  printf("CreateFile returns with %d\n", GetLastError());
 
printf("file created.. press Enter to exit..\n");
getchar();

return 0;

the noteworthy thing here is parameter 3, by providing this with a 0 im telling the OS that I'd like that file to be opened but I will not share it with anyone. If I get access to it, it's mine only..

32 17.535497 192.168.1.200 192.168.1.100 SMB SMB:C; Tree Connect Andx, Path = \\192.168.1.100\SHARE, Service = ?????

33 17.535969 192.168.1.100 192.168.1.200 SMB SMB:R; Tree Connect Andx, Service = A:

34 17.536613 192.168.1.200 192.168.1.100 SMB SMB:C; Nt Create Andx, FileName = \foo.bar

.....(below is part of packet 34, how the createfile is sent over the network to the fileserver by smb..)

    - ShareAccess ShareAccess: 0x00000000
      Read:   (...............................0) Read NOT Allowed
      Write:  (..............................0.) Write NOT Allowed
      Delete: (.............................0..) Delete NOT Allowed
      Rsvd:   (00000000000000000000000000000...) Reserved(Must be zero)

....
 
35 17.536838 192.168.1.100 192.168.1.200 SMB SMB:R; Nt Create Andx, FID = 0x4007 (\foo.bar@#34)

then the client at 192.168.1.250 tries to access the same file..

63 28.574906 192.168.1.250 192.168.1.100 SMB SMB:C; Tree Connect Andx, Path = \\192.168.1.100\SHARE, Service = ?????

the same application is being used so the same share access settings are sent to the server. now the server checks with the previous lock owner...

66 28.575674 192.168.1.100 192.168.1.200 SMB SMB:C; Locking Andx, FID = 0x4007 (\foo.bar@#34)

67 28.576314 192.168.1.200 192.168.1.100 SMB SMB:C; Locking Andx, FID = 0x4007 (\foo.bar@#34)

it's basically asking the previous owner of the lock if it can release it gracefully. the client says no

71 29.573853 192.168.1.100 192.168.1.250 SMB SMB:R; Nt Create Andx - NT Status: System - Error, Code = (67) STATUS_SHARING_VIOLATION

the second machine receives a STATUS_SHARING_VIOLATION and the file cannot be opened. This is what happens when oplocks are enabled. now check below. this new trace is from an instance where both clients are not using oplocks. you can do this on 2K and later by adding a new dword OplocksDisabled under services\mrxsmb..

25 2.766744 192.168.1.200 192.168.1.100 SMB SMB:C; Tree Connect Andx, Path = \\192.168.1.100\SHARE, Service = ?????

....
64 15.419357 192.168.1.250 192.168.1.100 SMB SMB:C; Nt Create Andx, FileName = \foo.bar

66 16.419300 192.168.1.100 192.168.1.250 SMB SMB:R; Nt Create Andx - NT Status: System - Error, Code = (67) STATUS_SHARING_VIOLATION

the server responds immediately after it receives the request to create a handle on the file. this file is open as share nothing by a previous client and that client has not requested any oplocks on the file. the server in the first instance where oplocks are in effect, asks the client first because it thinks the client may release it, and it doesnt want the first client to lose any data in any scenario because the first client may be opportunistically caching local in memory information and we do not want to mess around with data integrity.

the second instance where oplocks are not there, the server responds to the second opener immediately as it knows the first client is not caching anything and uses the open file object on the server side and information on this object to immediately deny the second open request.

4    26.359326        192.168.1.6    192.168.1.8    NTLMSSP    NTLMSSP:NTLM NEGOTIATE MESSAGE

5    26.650751        192.168.1.8    192.168.1.6    NTLMSSP    NTLMSSP:NTLM CHALLENGE MESSAGE

6    26.835188        192.168.1.6    192.168.1.8    NTLMSSP    NTLMSSP:NTLM AUTHENTICATE MESSAGE, Domain: GTSC-B7A3A93C1A, User: administrator, Workstation: GTSC-B7A3A93C1A

7    28.531328        192.168.1.8    192.168.1.6    SMB    SMB:R; Session Setup Andx

The next thing in the SMB comm with the file server will the setting up of the user session. The SMB command used for this is Session Setup AndX. The 4 packets above shows this to us. Windows clients will use NTLM or Kerberos, preferrably Kerboros in most instances. This trace shows the use of NTLM as the authentication SSP, security support provider, it was chosen by the client as the file server's IP was used rather than the server name. That's the default behaviour.

Frame:

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-03-FF-66-C3-39],SourceAddress:[00-03-FF-60-C3-39]

+ Ipv4: Src = 192.168.1.6, Dest = 192.168.1.8, Next Protocol = TCP, Packet ID = 3002, Total IP Length = 246

+ Tcp: Flags=...AP..., SrcPort=1240, DstPort=Microsoft-DS(445), Len=206, Seq=2987748740 - 2987748946, Ack=4142961914, Win=65446

+ Nbtss: SESSION MESSAGE, Length =202

- Smb: C; Session Setup Andx

AsciiString Protocol: SMB

UINT8 Command: Session Setup Andx 115(0x73)

+ UINT32 NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS

+ SMBHeader: Command, TID: 0x0000, PID: 0xFEFF, UID: 0x0000, MID: 0x0040

+ SMBRequestSessionSetupAndXNTLMESS CSessionSetupAndXNTLMESS:

- NtlmSSP: NTLM NEGOTIATE MESSAGE

AsciiStringTerm Signature: NTLMSSP

UINT32 MessageType: Negotiate Message (0x00000001)

- NtlmsspNegotiateMessage:

+ NtlmsspNegotiateFlags NegotiateFlags: 0xE2088297 (NTLM v2128-bit encryption, Always Sign)

- NtlmsspString WorkstationDomainHeader: Length: 0, Offset: 0

UINT16 Length: 0 (0x0)

UINT16 MaximumLength: 0 (0x0)

UINT32 BufferOffset: 0 (0x0)

- NtlmsspString WorkstationNameHeader: Length: 0, Offset: 0

UINT16 Length: 0 (0x0)

UINT16 MaximumLength: 0 (0x0)

UINT32 BufferOffset: 0 (0x0)

- NtlmsspVersion Version: Windows 5.1 Build 10250 NTLMSSPv15

UINT8 ProductMajorVersion: 5 (0x5)

UINT8 ProductMinorVersion: 1 (0x1)

UINT16 ProductBuild: 10250 (0x280A)

UINT24 Reserved: 0 (0x0)

UINT8 NTLMRevisionCurrent: 15 (0xF)

netmon will show you the additional information provided in the first request from the client as you see in this screenshot. The most important part in this message in addition to the Session Setup SMB, will be the NTLM's negotiate flags. This determines things such as the level of encyrption supported, and methods that will be used for authentication. This is a 32 bit field and each bit is responsible for carrying another option.

The next the client does is a connection to the "srvsvc" named pipe on the file server.

8    28.531626        192.168.1.6    192.168.1.8    SMB    SMB:C; Tree Connect Andx, Path = \\192.168.1.8\IPC$, Service = ?????

9    28.560590        192.168.1.8    192.168.1.6    SMB    SMB:R; Tree Connect Andx, Service = IPC

10    52.876400        192.168.1.6    192.168.1.8    SMB    SMB:C; Nt Create Andx, FileName = \srvsvc

11    54.153964        192.168.1.8    192.168.1.6    SMB    SMB:R; Nt Create Andx, FID = 0x4000

12    54.182335        192.168.1.6    192.168.1.8    MSRPC    MSRPC:Warning:

13    54.237065        192.168.1.8    192.168.1.6    SMB    SMB:R; Write Andx, FID = 0x0000, 72 bytes

14    54.255979        192.168.1.6    192.168.1.8    SMB    SMB:C; Read Andx, FID = 0x4000, 1024 bytes at Offset 0

15    54.320003        192.168.1.8    192.168.1.6    MSRPC    MSRPC:Warning:

16    54.320226        192.168.1.6    192.168.1.8    MSRPC    MSRPC:Warning:

17    54.701699        192.168.1.8    192.168.1.6    MSRPC    MSRPC:Warning:

18    54.701932        192.168.1.6    192.168.1.8    SMB    SMB:C; Close, FID = 0x4000

19    54.702385        192.168.1.8    192.168.1.6    SMB    SMB:R; Close, FID = 0x0000

20    54.755524        192.168.1.6    192.168.1.8    SMB    SMB:C; Nt Create Andx, FileName = \srvsvc

21    54.756530        192.168.1.8    192.168.1.6    SMB    SMB:R; Nt Create Andx, FID = 0x4001

22    54.756704        192.168.1.6    192.168.1.8    MSRPC    MSRPC:Warning:

23    54.757058        192.168.1.8    192.168.1.6    SMB    SMB:R; Write Andx, FID = 0x0000, 72 bytes

24    54.757181        192.168.1.6    192.168.1.8    SMB    SMB:C; Read Andx, FID = 0x4001, 1024 bytes at Offset 0

25    54.757448        192.168.1.8    192.168.1.6    MSRPC    MSRPC:Warning:

26    54.757543        192.168.1.6    192.168.1.8    MSRPC    MSRPC:Warning:

27    54.800388        192.168.1.8    192.168.1.6    MSRPC    MSRPC:Warning:

28    54.800546        192.168.1.6    192.168.1.8    SMB    SMB:C; Close, FID = 0x4001

29    54.801091        192.168.1.8    192.168.1.6    SMB    SMB:R; Close, FID = 0x0000

This connection is required to send queries on the file share and get more information on the share.

Then the client checks to see if it's connecting to a DFS namespace:

34    68.715121        192.168.1.6    192.168.1.8    SMB    SMB:C; Tree Connect Andx, Path = \\192.168.1.8\IPC$, Service = ?????

35    68.715612        192.168.1.8    192.168.1.6    SMB    SMB:R; Tree Connect Andx, Service = IPC

36    68.715780        192.168.1.6    192.168.1.8    DFS    DFS:Get DFS Referral Request, FileName: \192.168.1.8\c$, MaxReferralLevel: 3

37    68.812676        192.168.1.8    192.168.1.6    SMB    SMB:R; Transact2, Open2 - NT Status: System - Error, Code = (14) STATUS_NO_SUCH_DEVICE

STATUS_NO_SUCH_DEVICE from the fileserver means that the share is not a Dfs namespace and that the client should connect directly to this share..

After this has been done the communication will continue with the client doing the actual tree connect to the share name directly this time. In the attached trace from the earlier post you will see that the client queries for the files with Trans2 requests and then at the end closes the tree connection with a tree disconnect, and before that also closing the file with a Close SMB. The last in the comm will be Logoff SMB to logoff the user from the file server.

in this post I've attached a simple network trace that you can check together with its analysis of the first 2 frames. I will continue analyzing this trace with multiple posts. at the first sight, trace analysis applications seem simple, applications like Microsoft Network Monitor or Wireshark (these are 2 best out there and all other seem to lack the extensibility and the vast support for the protocols that these 2 have). they will parse the packets from the trace file into fields and their associated values in a readable format. while this may be sufficient with simple cases, most of the the time, one who wants to analyze the situation over the network needs to have extensive protocol information in order to be able to find a root cause, the reason why a specific operation over the network fails.

this trace will include a very generic xp client accessing a 2003 file server, both at SP2, mapping a drive, listing files and outputting contents of a file in that share and then disconnecting. I'll try to give as much detail as possible.

     24 24.641698   192.168.1.6           192.168.1.8           SMB      Negotiate Protocol Request
     28 25.797167   192.168.1.8           192.168.1.6           SMB      Negotiate Protocol Response

the very first that happens before the above 2 packets will actually be the transport connection. the client, here 192.168.1.6, will initiate a 3 way handshake with 192.168.1.8. by default Windows clients will try to establish a connection over 139 and 445 simultaneously. while these can be controlled, if you don't choose to do so, the first port that the client receives a syn,ack from will be the one used for the comms. for your reference 139 is the netbios session protocol port and 445 is direct hosted smb.

after this is successful, next thing will be negotiate protocol request. this is the very first in an smb communication. client will send a list of dialects it supports:

SMB (Server Message Block Protocol)
    SMB Header
        Server Component: SMB
        [Response in: 28]
        SMB Command: Negotiate Protocol (0x72)
        NT Status: STATUS_SUCCESS (0x00000000)
        Flags: 0x18
            0... .... = Request/Response: Message is a request to the server
            .0.. .... = Notify: Notify client only on open
            ..0. .... = Oplocks: OpLock not requested/granted
            ...1 .... = Canonicalized Pathnames: Pathnames are canonicalized
            .... 1... = Case Sensitivity: Path names are caseless
            .... ..0. = Receive Buffer Posted: Receive buffer has not been posted
            .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported
        Flags2: 0xc853
            1... .... .... .... = Unicode Strings: Strings are Unicode
            .1.. .... .... .... = Error Code Type: Error codes are NT error codes
            ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
            ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
            .... 1... .... .... = Extended Security Negotiation: Extended security negotiation is supported
            .... .... .1.. .... = Long Names Used: Path names in request are long file names
            .... .... .... .0.. = Security Signatures: Security signatures are not supported
            .... .... .... ..1. = Extended Attributes: Extended attributes are supported
            .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response
        Process ID High: 0
        Signature: 0000000000000000
        Reserved: 0000
        Tree ID: 0
        Process ID: 65279
        User ID: 0
        Multiplex ID: 0
    Negotiate Protocol Request (0x72)
        Word Count (WCT): 0
        Byte Count (BCC): 98
        Requested Dialects
            Dialect: PC NETWORK PROGRAM 1.0
                Buffer Format: Dialect (2)
                Name: PC NETWORK PROGRAM 1.0
            Dialect: LANMAN1.0
                Buffer Format: Dialect (2)
                Name: LANMAN1.0
            Dialect: Windows for Workgroups 3.1a
                Buffer Format: Dialect (2)
                Name: Windows for Workgroups 3.1a
            Dialect: LM1.2X002
                Buffer Format: Dialect (2)
                Name: LM1.2X002
            Dialect: LANMAN2.1
                Buffer Format: Dialect (2)
                Name: LANMAN2.1
            Dialect: NT LM 0.12
                Buffer Format: Dialect (2)
                Name: NT LM 0.12

the server will respond back with:

 Negotiate Protocol Response (0x72)
        Word Count (WCT): 17
        Dialect Index: 5, greater than LANMAN2.1
        Security Mode: 0x03
            .... ...1 = Mode: USER security mode
            .... ..1. = Password: ENCRYPTED password. Use challenge/response
            .... .0.. = Signatures: Security signatures NOT enabled
            .... 0... = Sig Req: Security signatures NOT required
        Max Mpx Count: 50
        Max VCs: 1
        Max Buffer Size: 4356
        Max Raw Buffer: 65536
        Session Key: 0x00000000
        Capabilities: 0x8001f3fd
            .... .... .... .... .... .... .... ...1 = Raw Mode: Read Raw and Write Raw are supported
            .... .... .... .... .... .... .... ..0. = MPX Mode: Read Mpx and Write Mpx are not supported
            .... .... .... .... .... .... .... .1.. = Unicode: Unicode strings are supported
            .... .... .... .... .... .... .... 1... = Large Files: Large files are supported
            .... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are supported
            .... .... .... .... .... .... ..1. .... = RPC Remote APIs: RPC remote APIs are supported
            .... .... .... .... .... .... .1.. .... = NT Status Codes: NT status codes are supported
            .... .... .... .... .... .... 1... .... = Level 2 Oplocks: Level 2 oplocks are supported
            .... .... .... .... .... ...1 .... .... = Lock and Read: Lock and Read is supported
            .... .... .... .... .... ..1. .... .... = NT Find: NT Find is supported
            .... .... .... .... ...1 .... .... .... = Dfs: Dfs is supported
            .... .... .... .... ..1. .... .... .... = Infolevel Passthru: NT information level request passthrough is supported
            .... .... .... .... .1.. .... .... .... = Large ReadX: Large Read andX is supported
            .... .... .... .... 1... .... .... .... = Large WriteX: Large Write andX is supported
            .... .... 0... .... .... .... .... .... = UNIX: UNIX extensions are not supported
            .... ..0. .... .... .... .... .... .... = Reserved: Reserved
            ..0. .... .... .... .... .... .... .... = Bulk Transfer: Bulk Read and Bulk Write are not supported
            .0.. .... .... .... .... .... .... .... = Compressed Data: Compressed data transfer is not supported
            1... .... .... .... .... .... .... .... = Extended Security: Extended security exchanges are supported
        System Time: Dec  9, 2007 15:00:34.908906400
        Server Time Zone: -120 min from UTC
        Key Length: 0
        Byte Count (BCC): 16
        Server GUID: 4900C30A3474AB418E7207FA3774EC7E
        Security Blob: <MISSING>

with this negotiate protocol response back from the server, the dialect to be used can be seen. in this case it is greater than lanman2.1 and will be:

            Dialect: NT LM 0.12
                Buffer Format: Dialect (2)
                Name: NT LM 0.12

the other important part in this response is the capabilities part. this tells you what options and features of smb is supported on the file server. this is maybe the first thing to check as for example in an oplock problem, will tell you if the server support oplocks and a bunc of other things.

the next thing will be obvious, user authentication. that will be in another post, until then happy networking..

smb.cap

 file copy as simple as it may seem by selecting a bunch and right clicking to choose Copy in explorer is a complex operation in the background for the operating system. the multilayered approach in handling IO requests within kernel mode, needs some understanding of the IO architecture of Windows to tackle these types of issues. most of the time you will find that 3rd party filter drivers, misbehaving user mode applications are a cause and when stripped of these additional layers of complexity you will see that most of the time Windows to Windows file copy is efficient.

isolation and the reproducibility of such an issue is important so as to find the component that is indeed slow. is copying the same file without Antivirus in place still slow, is it your specific application that is slow, do you see the same results when copying the file over the command prompt, or better yet can the issue be reproduced when the system is booted into Safe Mode with Networking(will abbreviate to SMN mode)? in SMN any 3rd party networking or other AV and similar filter drivers will be disabled. in Windows drivers interact with each other and for any given IO request there may be multiple drivers interacting within a driver stack to fullfill the request. SNM will help you get these additional 3rd party components out of the picture thereby help isolate the root component of the cause.

once you are certain the issue is reproduced reliably in SNM, you need to make sure if the server side is consistent in this sense as well. can you reproduce the same issue with another file server? if the answer is no, then the server will need investigating. slow responses for file requests over a network file server, might mean that the server is having local performance issues and it might just be hitting its own limits in terms of servicing a specific number of requests at a time.

this would require looking at a performance log collected for a day or two and then analyzing this log to see trends in memory, disk, network and processor usage. I'll try to address other aspect of file access performance in coming posts, until then happy SMBing.