Has anyone else used the 32 bit x86 Windows 8.1U1 to map to a Windows 2012 R2 with Set-SmbServerConfiguration EncryptData $True and Set-SmbServerConfiguration RejectUnencryptedAccess $False ?

I have full success with 64 bit X64 Windows 8.1U1 client.  No problems.

As soon as I try NET USE X: \\SERVERNAME.DOMAIN.EXT\SHARENAME the 32 bit client hangs for many minutes before finally mapping the drive.  Any attempt to access the share hangs Explorer or the computer for many more minutes.  So slow it is almost impossible to use the machine.

If I set on the server:

Set-SmbServerConfiguration EncryptData $False

The NET USE works fast and access is fast.

Or, if I turn off SMB2/3 on client, NET USE works fast and access is fast, like this:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled

This is on a freshly installed 8.1U1, no GP, no apps or fully configured with apps and GP.  Every 32 bit OS machine, including varied Sony and Dell hardware, VM's on HyperV Server, etc.  Behaves the same against several 2012 and 2012 R2 servers, although they are all similar in setup.

Thanks!

Windows 8.0 GA x86 32 bit also does this to a SMB 3 encrypted share also.  Unusably slow.  Disabling SMB3 on client makes it work full speed again. 

Something is very odd with the 32 bit SMB 3 encrypted client in Windows 8.x. 

• Edited by Shangrila1 Tuesday, August 19, 2014 7:50 PM

Hi,

Since you set the RejectUnencryptedAccess to $true, clients that do not support SMB 3.0 are allowed unencrypted access the file shares. It seem that the client is unencrypted access the file shares after you disableSMB3 on client which will make it work full speed again. 

Best Regards,

M

I have the same issue  - I already thought, I am the only one, because I did not find any information about this issue until now.

The setup: Domain controller/file server Win 2012 R2, freshly installed Win 8.1 clients 64 bit and 32 bit.

64 bit clients work fine, 32 bit clients show the described issue.

I also created a file share with the data encryption option disabled and this share with clear text data transfer can be accessed fine by 32 bit clients as well. At least as long as no share with enabled data encryption was accessed before - I go into that further below.

Overall it seems the 32 bit implementation is buggy when it comes to handling encrypted SMB3.

I monitored the communication with Wireshark and witnessed some interesting behavior which might help to understand the problem:

1. Protocoll negation works fine. SMB 3.02 is agreed on.
2. Tree Connect Request Tree: \\servername\share-with-enc-on results in sucessful Tree Connect Resonse
3. Client sends one Encrypted SMB3 package and immediately receives one encrypted SMB3 package from the server as responds.
4. And this is where it stops. Normally, the client should continue with sending the next Encrypted SMB3 package, but this does not happen.

Once in this state, it is also not possible to access the share without encryption (e.g. \\servername\share-with-enc-off) anymore. So I initially thought, the client is dead. But with some experimentation and looking at the network traffic I found out a few things:

• I you use a different name or the IP to access the server, it works fine. E.g. \\serveralias1\share-with-enc-off. Until you try to access \\serveralias1\share-with-enc-on - then you have the same issue as described above.
• Looking at the network traffic, it seems - once the client is stuck - it sends some requests to access \\servername\share-with-enc-off encrypted and in clear text at the same time. At least I think it is, because it is a little random and also encrypted, but usually with a Tree Connect Request an encrypted request goes out with the same ack number. The server happily answers both.
  Before the client goes haywire, it does not send any encrypted requests when accessing \servername\share-with-enc-off
• But looking at the network traffic, I also saw, that the stuck communication regarding listing the directory contents of \\servername\share-with-enc-on continued after about 20 minutes and completed successfully. I was then able to see the share content in Windows Explorer on the 32 bit client. But if you initiate another request (e.g. by going one folder deeper) you are in for another waiting period. I did not test, if 20 minutes are constant or the time differs.
• What I also saw in the network traffic, once the communication got unstuck is, that it finished very quickly, exchanging several encrypted packages doing that. So the theory of old hardware just being slow on the encryption/decryption part seems not to be the cause.

Disabling encryption is acceptable in my environment, so I will do that on the server side in the share options as a workaround. But it would be nice to get a fix for that.

Kind Regards,
Martin

• Edited by Martin.Stangl Saturday, September 06, 2014 1:20 PM Added PS

Yes, it is still broken for me as of a few weeks ago...

I use GP or whatever means to shut off SMBV2 and SMBV3 on 32 Win 8.x

I did see some stuff in MS15-11 released today mentioning SMB V1 and had me a bit worried, but it looks as near as I can tell that if the client has the patch we are ok, but if I apply the GP to up the security for MS15-11, I may have non-functioning Win 8.x 32 bit machines if I have them forced to SMBV1 only.  We shall see.  Reference: https://support.microsoft.com/kb/3000483