To define SMB Signing Disabled Policy.

Instead of making changes to the Default Domain Policy to disable SMB signing, create a new Group Policy Object with the appropriate policy settings.

At the server, open Start, All Programs, Administrator Tools.

Open Group Policy Management.

Expand the forest.

Expand Domains.

Select the local domain. The group policy objects will display in the right-hand pane along with the Default Domain Policy.

Right-click the domain icon (domainname.local) in the console tree and select Create and Link a GPO Here.

Enter "SMB Signing Disabled" (without the quotations marks) for the GPO Name and click OK.

Right-click on the new GPO in the right-hand pane and select Edit to open the Group Policy Object Editor.

Under Computer Configuration, expand Windows Settings.

Expand Security Settings.

Expand Local Policies.

Select Security Options.

In the right-hand pane, scroll down to Microsoft network server: Digitally sign communications (always) and double-click on the policy object.

Select the Disabled radio button and make sure the checkbox is enabled for Define this policy setting.

Click OK.

Close the Group Policy Object Editor.

Right-click on the SMB Signing Disabled policy object and select Enforced. In the Linked Group Policy Objects window, the SMB Signing Disabled object should show Yes under both Enforced and Link Enabled.

Move the SMB Signing Disabled policy just above the Default Domain Policy in the window. The SMB Signing Disabled policy object should be number 5 in the list and the Default Domain Policy should be number 6 for a default SBS installation.

Open a command prompt window on the server.

Type "gpupdate /force" (without the quotation marks) and press Enter.

When the policy update completes, close the command prompt window.

SMB 2.0 was introduced in Windows Vista and Windows Server 2008. SMB 2.0 is designed for the needs of the next generation of file servers. Windows Server 2008 and Windows Vista support both SMB 1.0 and SMB 2.0 in order to preserve backward compatibility.

Some of the enhancements in SMB 2.0, include:

Sending multiple SMB commands in the same packet which reduces the number of packets sent between a client and server
Larger buffer sizes
Increased scalability, including an increase in the number of concurrent open file handles on the server and the number of shares that a server can share out
Support for Durable Handles that can withstand short network problems
Support of Symbolic Links
Testing done with copying large files between Windows Vista and Windows Server 2008, and then Vista to Windows 2003, have shown that by using SMB 2.0 the file copying was, in averege, 2 times faster than with older operating systems.

However, while SMB 2.0 seems to do a good job if BOTH client and server OSs support it, in some cases it will slow things down. The reson for this is that the version of SMB used for file sharing is determined during the SMB session negotiation. If both the client and server support SMB 2.0, then SMB 2.0 is selected during the initial negotiation. However, if they don't both support it, SMB 1.0 will be used to in order to preserve backwards compatibility.

The SMB protocol version to be used for file operations is decided during the negotiation phase. During the negotiation phase, a Windows Vista client advertises to the server that it can understand the new SMB 2.0 protocol. If the server (Windows Server 2008 or otherwise) understands SMB 2.0, then SMB 2.0 is chosen for subsequent communication. Otherwise the client and server use SMB 1.0.

When using the terms "client" and "server" in case of file and print sharing, it does not necessarily mean that a client-type OS such as Vista "always" connects to a server-type Os such as Windows Server 2008. Sometimes, a Vista computer will connect to another Vista computer, and in that case, the computer that is "serving" the shares is considered to be the "server".

Here's how SMB is used when related to SMB versions: