Start with the user's file operation and identify where its time is spent. A large sequential copy, opening thousands of small files and saving a document over SMB exercise different paths. Increasing network bandwidth helps only when the original operation is constrained by that bandwidth.
This guide uses two disposable Windows VMs and synthetic files on a dedicated share. It contains no measured customer results. Commands are read-only inspection examples; workload execution and configuration changes require an approved lab.
1. Map the complete operation
Record client VM, server VM, active host placement, guest NICs, port groups, physical uplinks and the datastore backing the share. Also identify the client's source/destination disk. A copy can be limited by that disk before it exercises the server.
Choose three separate tests: one large-file transfer, many small-file opens, and a representative application save/read-back. Define dataset size, directory count, concurrency, direction and expected content. Use a manifest of synthetic filenames and checksums held outside the test destination.
Record security requirements before benchmarking. Signing, encryption, access controls and endpoint protection are part of the required service. Do not turn them off to obtain a result for a different security configuration. Microsoft's SMB tuning guidance: https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/smb-file-server describes protocol and workload considerations; its registry options are not a default tuning checklist.
2. Confirm the negotiated connection
Open the approved lab share from the client first, then inspect connections in that same user context:
Get-Help Get-SmbConnection -Full
Get-SmbConnection -ServerName 'files-lab.example.invalid' |
Select-Object ServerName, ShareName, Dialect, NumOpens
Replace the fictional name with the allocated lab server. An empty result may mean no active connection under that identity, a different resolved server name, or insufficient visibility. It does not prove SMB is disabled. Inspect the live connection rather than inferring the negotiated dialect from the installed operating system. Get-SmbConnection reference: https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbconnection
Record the connection's signing/encryption properties using the supported tools for the installed build. The public reference currently defaults to a newer Windows Server view, so confirm local help before relying on a property or parameter. Do not export entire connection objects to a public report because identities and paths may be included.
3. Verify Multichannel and RSS separately
SMB Multichannel can create multiple transport connections, including on a single RSS-capable adapter. Receive Side Scaling distributes receive processing across CPUs. Multiple connections do not necessarily mean multiple independent physical paths. Multichannel architecture and requirements: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/manage-smb-multichannel
During the transfer, run:
Get-SmbMultichannelConnection -ServerName 'files-lab.example.invalid' -IncludeNotSelected |
Select-Object ServerName, Selected, ClientInterfaceIndex,
ServerInterfaceIndex, ClientRSSCapable, ClientRdmaCapable
Get-NetAdapterRss -Name '*'
Compare selected and rejected interface pairs. Map the interface indices back to the design, and inspect RSS on both Windows endpoints. A capability flag is not proof that traffic used that feature. Multichannel command: https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbmultichannelconnection?view=windowsserver2022-ps and RSS command: https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterrss document these observations.
For virtual NICs, distinguish guest-visible capabilities from physical networking. Do not assume a fast displayed VMXNET3 link provides RDMA or guarantees that a single flow can use all host uplinks. This article uses SMB over TCP and does not configure SMB Direct.
4. Collect measurements across the same interval
In Windows Performance Monitor, select available SMB Client Shares counters on the client and SMB Server Shares counters on the server. Add per-core CPU, disk latency/throughput, available memory and the relevant network-interface throughput. Counter names and availability depend on release and language.
In vCenter, record both VMs' CPU Ready, storage latency and network activity during the same UTC window. Record whether the machines share a host; a same-host path may avoid the physical switches and is a different network experiment.
Bound collection to the workload interval and retain failures. Convert units explicitly: disk counters reported in seconds need conversion before comparison with millisecond charts. Compare per-share or per-disk observations where possible; a server-wide average can hide the affected share.
Use the following worksheet:
| Pattern | Next measurement | Likely misleading shortcut |
|---|---|---|
| One guest core is busy, storage quiet | RSS state, connection count and CPU Ready | Add storage capacity |
| Large copies fast, small-file opens slow | Metadata operations, authentication, filters and latency | Quote only sequential throughput |
| Server storage latency rises with demand | VM-to-datastore map and backend load | Add another guest NIC |
| Client disk saturates | Client local-read/write comparison | Blame the file server |
| First observed access slower than repeats | Cache state and application startup work | Call every repeat a new tuning result |
These are investigation hypotheses, not diagnoses established by this article.
5. Run controlled comparisons
Use a fixed input set and process the same work at the same concurrency. Separate warm-up from measured runs. Label initial access as first observed unless a controlled cold state was actually established. Do not flush production caches or reboot a shared file server for a benchmark.
If measurements implicate networking, compare one approved lab networking change with the original configuration, then repeat the original configuration. If they implicate storage, keep the SMB path constant while comparing the appropriate storage candidate. Retain original driver and policy details before changes.
Run the application save/read-back as well as the synthetic copy. Verify content checksums and successful reopen after the client closes the file. A cached completion may not represent the same durability boundary as the application's normal save, so document what each test observes.
Use repeated runs to report a median, a sensible tail percentile and failure count. Record sample size. Do not remove failed operations from the timing story or claim a high-percentile service target from a handful of samples.
6. Validate availability without confusing it with speed
If redundant paths are part of the design, plan an isolated path-loss drill with the network owner. Identify exactly which guest and physical path is removed and which remains. Do not disconnect the host's sole management or storage uplink.
Measure whether the application preserves correct reads/writes and how long recovery takes. A transfer surviving one guest NIC change does not demonstrate survival of a host, switch or storage-array failure. Record those as separate untested failure domains.
The RSS reference also redirects to the Windows Server 2025 documentation view; the exact 2022 URL could not be reopened during source checking. Match Get-NetAdapterRss and its properties against the installed Windows Server 2022 help before using the example.
Acceptance and rollback
A candidate passes when application results remain correct, response improves repeatably under comparable work, required security remains enabled and host/storage headroom is acceptable. Throughput gained by increasing concurrency beyond the real workload is a different capacity result.
Restore the one changed lab setting if the candidate fails, recreate the relevant client connection where required, and repeat the baseline. Do not disconnect every user's SMB session as cleanup. Preserve evidence and remove only the identified synthetic files under the reviewed cleanup plan.
Related topics: Windows application timing, vSphere networking and controlled DiskSpd experiments.
Learning notes
- More SMB connections do not automatically create independent network paths.
- Small-file latency and large-file bandwidth are different requirements.
- The client, server and hypervisor must be measured during the same operation.
Sources and review status
See the source ledger, author self-check and series index. Independent review and lab validation remain pending.