Windows Server 2012 R2 introduced a new version of SMB. Technically it’s SMB 3.02, but we continue to call it just SMB3. The main changes are described at http://technet.microsoft.com/en-us/library/hh831474.aspx. With this new release, we made a few changes in SMB PowerShell to support the new scenarios and features. This includes a few new cmdlets and some changes to existing cmdlets, with extra care not break any of your existing scripts. This blog post outlines 7 set of changes related to SMB PowerShell in Windows Server 2012 R2.

1) Simpler setting of ACL for the folder behind a share

In Windows Server 2012, the SMB share has a property that facilitates applying the share ACL to the file system folder used by the share. Here’s the syntax:

• (Get-SmbShare –Name <ShareName> ).PresetPathACL | Set-Acl

In Windows Server 2012 R2, we have improved this scenario by providing a proper cmdlet to apply the share ACL to the file system used by the share. Here’s the new syntax:

• Set-SmbPathAcl –Name ShareName

Note1 : The Windows Server 2012 syntax continues to work with Windows Server 2012 R2, but the new syntax is much simpler and therefore recommended.

Note 2: There is known issue with Windows Server 2012 R2 Preview that causes this new cmdlet to fail when using non-Unicode languages. As a workaround, you can use the old syntax.

2) Scale-Out Rebalancing (per-share redirection)

Per-share redirection is the new default behavior for the new SMB Clients (Windows 8.1 or Windows Server 2012 R2), when connecting to a Scale-Out clusters that use a storage system that does not support Direct I/O from all nodes, if running Windows Server 2012 R2. The common scenario here is a Scale-Out File Server backed by Mirrored Storage Spaces.

Here are the changes in SMB PowerShell to support SMB Scale-Out per-share redirection:

• New “Redirected” Boolean property to Get-SmbConnection to indicate that per-share redirection is being used.
• Get-SmbWitnessClient now includes a “ShareName” property, since witness can track connections per share, not only per server. 
• Get-SmbWitnessClient now includes a “Flags” property, which will show “Share” when doing per-share redirection

3) Other SMB Witness Changes

While the overall functionality of the SMB Witness is largely unchanged in Windows Server 2012 R2 (aside from per-share redirection), we have put some effort in improving the SMB PowerShell cmdlets associated with it. Here are the changes:

• The Move-SmbWitnessClient cmdlet can be referred to now simply as Move-SmbClient, This is simply a new alias that better describes what the cmdlet actually does.
• The default view for Get-SmbWitnessClient was improved. Here’s the new list of items shown: 

Client Computer   Witness Node  File Server   Network Name  Share Name  Client State    
Name              Name             Node Name
----------------- ------------- ------------- ------------  ----------  ------------    
JOSE-V            JOSE-A1       JOSE-A2       JOSE-F        VMS4        RequestedNoti...
JOSE-V            JOSE-A1       JOSE-A2       JOSE-F        VMS3        RequestedNoti...
JOSE-V            JOSE-A1       JOSE-A3       JOSE-F        VMS1        RequestedNoti...
JOSE-V            JOSE-A1       JOSE-A3       JOSE-F        VMS2        RequestedNoti...
JOSE-V            JOSE-A2       JOSE-A1       JOSE-F        VMS6        RequestedNoti...
JOSE-V            JOSE-A2       JOSE-A1       JOSE-F        VMS5        RequestedNoti...

• There is a new “NetworkName” parameter in Move-SmbClient.  If a NetworkName is specified, then only those will be moved. 

Windows Server 2012 syntax for Move-SmbWitnessClient:

• Move-SmbWitnessClient -ClientName X -DestinationNode Y

Windows Server 2012 R2 syntax:

• Move-SmbClient -ClientName X -DestinationNode Y [ -NetworkName Z ]

Note 1: If the –NetworkName is omitted in the Move-SmbClient cmdlet, all client connections will be moved to the destination.

Note 2: When using per-share redirection, the SMB client will always move to the file server node that owns the volume behind the file share. Using Move-SmbClient (or Move-SmbWitnessClient) in that situation has no effect.

4) SMB Bandwidth Limits

Starting with Windows Server 2012 R2, administrators can set a bandwidth limit for one or more categories by using simple PowerShell cmdlets. They can also query the limit for each category.  

There are 3 categories of traffic that can be limited:

• VirtualMachine: Hyper-V over SMB traffic. This limit can only be applied on Hyper-V hosts. 
• LiveMigration: Hyper-V Live Migration over SMB traffic. This limit can only be applied on Hyper-V hosts. 
• Default: All other types of SMB traffic. This limit can be applied on any SMB client.

A category limit is an absolute value expressed in bytes per second.  For example, a category limit of 500MB means the total throughput for this category should not exceed 500 megabytes per second.

The PowerShell cmdlets used to manage SMB Bandwidth Limits are:

• Get-SmbBandwidthLimit [ –Category {Default/VirtualMachine/LiveMigration} ]
• Set-SmbBandwidthLimit –Category {Default/VirtualMachine/LiveMigration} –BytesPerSecond x 
• Remove-SmbBandwidthLimit –Category {Default/ VirtualMachine/LiveMigration}

Note 1: Before you can use Bandwidth Limits, the feature needs to be enabled. For that, you should use:

• Add-WindowsFeature FS-SMBBW

Note 2: A new SMB Performance counter set with an instance per category becomes available after you install the feature.  The performance counters in for this set will use the same counters used today for the SMB Client Shares counter.

Note 3: PowerShell allows us to specify units like KB, MB, GB after the number of bytes when specifying the BytesPerSecond parameter.

Note 4: The Set-SmbBandwidthLimit cmdlet won’t accept a BytesPerSecond parameter smaller than 1MB (1048576).

5) SMB Multi-instance

SMB Multi-instance is a new feature in Windows Server 2012 R2 that separates regular SMB traffic from CSV-related inter-node SMB traffic in distinct  SMB instances. This is designed to improve isolation between the two types of traffic in improve the reliability of the SMB servers. Information related to this new CSV-only instance in Windows Server 2012 R2 is hidden in all PowerShell cmdlets.

However, there are the changes in SMB PowerShell so an Administrator can view information related to the hidden CSV instance:

• The –IncludeHidden option in Get-SmbConnection and Get-SmbMultichannelConnection will show the connections associated with the hidden CSV instance. 
• There is now an InstanceName property in the full output of Get-SmbConnection, Get-SmbMultichannelConnection, Get-SmbSession and Get-SmbOpenFile. It shows either “Default” or “CSV” (only shows if using the –IncludeHidden option).

Note: There is really little use in inspecting the information on the hidden CSV instance, except if you’re troubleshooting CSV inter-node communications.

6) SMB Delegation

When you configure Hyper-V over SMB and you manage your Hyper-V hosts remotely using Hyper-V Manager, you will might run into access denied messages. This is because you’re using your credentials from the remote machine running Hyper-V Manager in the Hyper-V host to access a third machine (the file server). This is what we call a “double-hop”, and it’s not allowed by default for security reasons.The main problem with the scenario is that an intruder that compromises one computer in your environment could then connect to other systems in your environments without the need to provide a username and password. One way to work around this issue is to connect directly to the Hyper-V host and providing your credentials at that time, avoiding the double-hop.

You can also address this by configuring Constrained Delegation for SMB shares, which is a process that involves changing properties in Active Directory. The security risk is reduced here because a potential intruder double-hop would be limited to that specific use case (using SMB shares on the specified servers). The constrained delegation process was greatly simplified in Windows Server 2012 when the the Active Directory team introduced resource-based Kerberos constrained delegation, as explained at http://technet.microsoft.com/library/hh831747.aspx. However, even with  this new resource-based constrained delegation, there are still quite a few steps to enable it.

For Hyper-V over SMB in Windows Server 2012, we provided TechNet and blog-based guidance on how to automate constrained delegation. In Windows Server 2012 R2, SMB has a new set of cmdlets to simplify the configuration of resource-based constrained Delegation in SMB scenarios. Here are the new cmdlets introduced:

• Get-SmbDelegation –SmbServer X
• Enable-SmbDelegation –SmbServer X –SmbClient Y 
• Disable-SmbDelegation –SmbServer X [–SmbClient Y] [-Force]

Note 1: For the Disable-SmbDelegation cmdlet, if no client is specified, delegation will be removed for all clients.

Note 2: These 3 new SMB cmdlets do rely on Active Directory PowerShell to perform their actions. For this reason, you need to install the Active Directory cmdlets before using the SMB delegation cmdlets. To install the Active Directory cmdlets, use:

• Install-WindowsFeature RSAT-AD-PowerShell

Note 3: Because these cmdlets only work with the new resource-based delegation, the Active Directory forest must be in “Windows Server 2012” functional level. To check the Active Directory Forest Functional level, use:

• Get-ADForest

Note 4: Virtual Machine Manager uses a different method to remote into the Hyper-V host. For VMM, constrained delegation is not required for management of Hyper-V of SMB.

7) Disable SMB1

SMB1 now can be completely disabled, so that the components are not even loaded. For scenarios where SMB1 is not required, this means less resource utilization, less need for patching and improved security.

To disable SMB1 completely, use the following PowerShell cmdlet:

• Remove-WindowsFeature FS-SMB1

You can re-enable it by using:

• Add-WindowsFeature FS-SMB1

Note 1: A reboot is required after this feature is enabled or disabled.

Note 2: For information worker scenarios, if you have Windows XP clients, you absolutely still need SMB1, since that is the only SMB version supported by Windows XP. Windows Vista and Windows 7 do not need SMB1 since they support SMB2. Windows 8 and Windows 8.1 do not need SMB1, since they support both SMB2 and SMB3.

Note 3: For classic server scenarios, if you have Windows Server 2003 or Windows Server 2003 R2 servers, you absolutely still need SMB1, since that is the only SMB version supported by them. Windows Server 2008 and Windows Server 2008 R2 do not need SMB1 since they support SMB2. Windows Server 2012 and Windows Server 2012 R2 do not need SMB1, since they support both SMB2 and SMB3.