Cannot get SMB Multichannel to work (Win 8.1 <-> 10)

[Marsh]

I found this powershell script from the Internet.

Powershell to set private network, I add this line in my build / config / deploy OS PS script

Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private

 

[MrFlppy]

First feedback after an unsuccessful test with fresh setups of Win 8.1 on each system
I'll list everything I've done on both systems:

- Create setup USB thumb drive of 8.1 Pro x64 with Microsoft's Media Creation Tool

- Unplug all ethernet cables

- Install 8.1

- Install motherboard chipset drivers (latest WHQL package) -> reboot

- Install graphics drivers (latest WHQL package) -> reboot

- NO ethernet drivers installed manually

- Configure each ethernet adapter: Disable IPv6, IPv4: Manual IP address (192.168.1.10, 192.168.1.11), Managed switch's IPv4 address set as gateway, DNS empty

- Reboot

- Plug ethernet cable back in, wait for prompt "Yes, search for devices etc.", network shows up as private network

- Plug in additional ethernet cable

- Reboot

- Create folder C:\Share, enable share for everyone

- Reboot

- Each share shows up on the other system immediately but during a large file copy test again only one ethernet adapter on each PC is actually used

I don't get it

 

[RobertFontaine]

I211/I217-V Windows 10 LACP teaming fails

 

[MrFlppy]

Thanks for trying to help but these teaming issues affect Windows 10 (current test setup consists of two 8.1 machines) and SMBMC isn't the same as teaming. You can combine SMBMC with teaming but in general these are two different features.

 

[Hirn]

@MrFlppy I freshly installed Win8.1 on my PC2, followed your steps on how you setup your network and noticed something very strange.

Robocopy from Win10 to Win8.1:

Worked as expected right out of the box. The Win10 PC is only connected with one NIC, so it uses both NICs 50% on the Win8.1 side.

Then I accessed a Win10 share from the Win8.1 PC and copied a file:

And it only used ONE NIC.

Then I disabled the NIC that Win8.1 used, enabled it again, tried the same copy again:

And it used both NICs as it should...

Did some more testing and my verdict is:
- If I access a share on Win10 from Win8.1 right after booting (waited 15min to have all services up and whatever Win8.1 does): It only uses ONE NIC.
- If I disable one NIC (doesnt matter which one) after booting, access the Win10 share in Win Explorer, enable the second NIC again and then copy a file: It uses both NICs.
- If I use robocopy on Win8.1 to transfer a file after booting (without disabling a NIC): it uses both NICs. [Edit Correction: often fails, too.]
If I then use the Windows Explorer to copy a file after I used robocopy, it uses both NICs, too, without having to first disable/enable one.

- From Win10 to Win8.1 via robocopy or Explorer always uses SMBMC.


Thats how it looks like on Win8.1 if SMBMC is working (copy via Win Explorer from a Win10 share after a robocopy).

This behaviour is very strange, but it is consistant every time I boot the Win8.1 PC. And so far I don't have an explanation for this.
I have around a dozen PCs running SMBMC on customers sites, all Win8.1 (now all Win10) to Server2012R2 and I've never seen this happening. Neither with Win10 <-> Win10.

 

[MrFlppy]

I just ordered an 8.1 retail licence (only got OEMs so far) that should have some Microsoft installation support included, I'll try to get them to release a step-by step check-list that is really complete so that we don't have to guess WHY something is behaving the way it is.

I'll bring Win 10 1607 setups into the mix tomorrow (same procedure as explained above with 8.1), maybe I can recreate your findings.

Or do you spot any obvious potential missteps during my instalation sequence?

 

[Hirn]

I don't think there is anything wrong with your steps. It works with Win10, just not with Win8.1.

Did some more testing on 8.1. Correction to my earlier post:
- A few times SMBMC works with robocopy right after the start. but often it fails, too.

- Putting in a DNS Server or adding the hostnames to hosts file doens't change anything.
- Using full ProSet drivers instead of default MS drivers makes no difference.

- If I disable one of the NICs after Windows booted, and re-enable it, robocopy and Win Explorer always use SMBMC.
Must be some flaw in Win8.1 in the way the networks are registered at boot.

Like @cesmith9999 my guess is, that this doens't happen in domain environments, as I've never seen this behaviour. All 8.1 PCs I had configured for SMBMC were in a domain. Just makes no sense to me why.

 

[MrFlppy]

Next I'll try to mix it up with Win 10 on one of the systems to replicate your setup, maybe the disabling and reenabling of one ethernet adapter on the 8.1 system will work then, too.

 

[MrFlppy]

Update #2 regarding fresh installs of 8.1 and 10:

Proper SMBMC is still not working, also tried Hirn's tip of de- and reactivating a NIC on a system.

However that led to an interesting discovery:

PC1 has two 1 GbE connections (PC1-Eth1 and PC1-Eth2), running 10 Pro 1607

PC2 has two 1 GbE connections (PC2-Eth1 and PC2-Eth2), running 8.1 Pro

Now I start a file transfer via explorer on PC2, copying a large file from PC1. In the Task Manager I see that only PC2-Eth1 is active at 113 MB/s. While the transfer is still running I go to the network connections settings and deactivate PC2-Eth1. The transfer process doesn't cancel or halt, it immediately switches to the previously idling PC2-Eth2 and goes on with 113 MB/s.

Re-activating PC2-Eth1 does not have any effect, meaning the transfer process continues using only PC2-Eth2 at 113 MB/s. But I can again deactivate PC2-Eth2 and the transfer process goes back to PC2-Eth1.

I checked the transfered file (copy and original), both checksums are identical.

Seems to be something like pseudo-SMBMC :-/

 

[MrFlppy]

I think I just got mind-fuqqed:

I211/I217-V Windows 10 LACP teaming fails

Quote from the Intel Wired Community Windows 10 No Teaming Thread:

"There are no native LBFO capabilities on Win10. Microsoft does not support client SKU network teaming.

It was a defect in Windows 10 build 10240 that “New-NetLbfoTeam” wasn’t completely blocked on client SKUs. This was an unintentional bug, not a change in the SKU matrix. All our documentation continued to say that NIC Teaming is exclusively a feature for Server SKUs.

While the powershell cmdlet didn’t outright fail on client, LBFO was in a broken and unsupported state, since the client SKU does not ship the mslbfoprovider.sys kernel driver. That kernel driver contains all the load balancing and failover logic, as well as the LACP state machine. Without that driver, you might get the appearance of a team, but it wouldn’t really do actual teaming logic. We never tested NIC Teaming in a configuration where this kernel driver was missing.

In the 10586 update (“Fall update”) that was released a few months later, “New-NetLbfoTeam” was correctly blocked again.

In the 14393 update (“Anniversary update”), we continued blocking it, but improved the error message.

The bottom line is that customers should NOT attempt to create teams on client SKU. It is NOT supported on client SKU, and never has been. Classic NIC Teaming continues to be supported in Windows Server 2016.

Adam Rudell | Windows Networking Beta | Microsoft Corporation"

This somehow leads me to believe that working SMBMC (with increased transfer speed during a single file copy process) is more or less a "bug" and maxing out a single NIC but being able to switch the NIC during the copy process without cancelling it is the indended functioning under a non-Server Windows Edition.