White Paper
EMC VNX Series: Introduction to SMB 3.0
Support
Abstract
This white paper introduces the Server Message Block (SMB) 3.0
support available on the EMC® VNX™ and the advantages gained
over the previous SMB versions. A VNX system can be
implemented in a Microsoft® Windows® environment (with
Microsoft Windows 8 and Windows Server 2012) to leverage the
enhancements in the SMB 3.0 protocol.
March 2015
Copyright © 2015 EMC Corporation. All Rights Reserved.
EMC believes the information in this publication is accurate as
of its publication date. The information is subject to change
without notice.
The information in this publication is provided “as is.” EMC
Corporation makes no representations or warranties of any kind
with respect to the information in this publication, and
specifically disclaims implied warranties of merchantability or
fitness for a particular purpose.
Use, copying, and distribution of any EMC software described in
this publication requires an applicable software license.
For the most up-to-date listing of EMC product names, see EMC
Corporation Trademarks on EMC.com.
VMware is a registered trademark of VMware, Inc. in the United
States and/or other jurisdictions. All other trademarks used
herein are the property of their respective owners.
Part Number H11427.5
EMC VNX Series: Introduction to SMB 3.0 Support
2
Table of Contents
Executive summary.................................................................................................. 4
Audience ............................................................................................................................ 5
Terminology ............................................................................................................ 5
Concepts................................................................................................................. 6
SMB version and negotiation.............................................................................................. 6
SMB 3.0 on VNX ...................................................................................................... 6
Continuous Availability (CA)..................................................................................... 7
Server failover .................................................................................................................... 7
Client failover ..................................................................................................................... 9
Enabling Continuous Availability ...................................................................................... 11
Multichannel ......................................................................................................... 11
Directory Lease...................................................................................................... 12
Offload Copy ......................................................................................................... 14
BranchCache V2 .................................................................................................... 16
SMB Encryption ..................................................................................................... 16
Encryption settings ........................................................................................................... 17
Encryption keys ................................................................................................................ 18
Enabling encryption.......................................................................................................... 18
Remote Volume Shadow Copy Service ................................................................... 19
Large IO ................................................................................................................ 21
Conclusion ............................................................................................................ 21
References ............................................................................................................ 21
EMC VNX Series: Introduction to SMB 3.0 Support
3
Executive summary
EMC VNX has incorporated the Server Message Block (SMB) protocol as an open
standard for network file service. SMB is a file access protocol designed for the
internet and is based on the Common Internet File System (CIFS) protocol that the
Microsoft Windows operating system uses for distributing file sharing, printing, and
communication services from a server over a network. SMB 3.0 is supported with
Microsoft Windows 8 and Microsoft Windows Server 2012 systems and has
significant improvements over the previous SMB versions.
For VNX File Operating Environment (OE) version 7.1.65 and later, the SMB 3.0
protocol is supported on VNX. VNX supports SMB 1.0, SMB 2.x, and SMB 3.0 protocol
communications between client and server. VNX supports SMB 3.0 enhancements
that include:

Continuous Availability (CA) – Continuous Availability enables applications to be
less impacted during a Data Mover or cluster failover. With CA enabled on a share,
if the failover period does not exceed the application timeout, application access
to all open files that were present prior to the failover is re-established and the
failover is transparent to end users.

Multichannel - Multiple TCP connections can now be associated with a single SMB
3.0 session and a client application can use several connections to transfer I/O on
a CIFS share. This optimizes bandwidth and enables failover and load balancing
with multiple NICs.

Directory Lease – SMB 2 introduced a directory cache that allowed clients to
cache a directory listing to save network bandwidth but would not see new
updates. SMB 3 introduces a directory lease and the client is now automatically
aware of changes made in a cached directory.

Offload Copy - Copying data within the same Data Mover can now be offloaded to
the storage, which reduces the workload on the client and network.

SMB Encryption - Provides secure access to the on CIFS shares, protects data on
untrusted networks, and provides end-to-end encryption of data in- flight.

Remote Volume Shadow Copy Service (RVSS) – With RVSS, point-in-time
snapshots can be taken across multiple CIFS shares, providing improved
performance in backup and restore.
Organizations with geographically dispersed sites must uphold data availability
without sacrificing security. Furthermore, performance implications need to be
considered, especially when operations are distributed among remote sites.
Administrators responsible for managing a Windows environment in their company
can leverage VNX support for SMB 3.0 in their IT infrastructure implementations to
alleviate these concerns.
EMC VNX Series: Introduction to SMB 3.0 Support
4
Audience
This white paper is intended for EMC customers, partners, and employees who want
to understand the SMB 3.0 protocol support of VNX. Readers of this document should
be familiar with VNX CIFS shares and Windows Operating System.
For additional information about VNX CIFS shares, refer to Configuring and Managing
CIFS on VNX on EMC Online Support.
Terminology

BranchCache – A WAN optimization protocol which enables content from file
servers on a wide area network (WAN) to be cached on computers at a local
branch office.

CIFS Server – A logical server that uses the CIFS protocol to transfer files. A Data
Mover can host many instances of a CIFS server. Each instance is referred to as a
CIFS server.

Common Internet File System (CIFS) – A file-sharing protocol based on Microsoft
Server Message Block (SMB). It enables users to share file systems over the
Internet and intranets.

Data Mover (DM) – In VNX for File, a cabinet component that is running its own
operating system that retrieves data from a storage device and makes it available
to a network client. This is also referred to as a blade.

Shadow Copy – Point-in-time copy created through Microsoft Volume Shadow
Copy Service (VSS). VSS identifies each shadow copy by a 16-byte GUID (Globally
Unique Identifier).

Share – Directory on a file system or that is made available to CIFS users on the
network. Also, the process of making a file system, directory, or service available
to CIFS users on the network.

Storage Processor (SP) – Storage processor on VNX for Block. On VNX for Block, a
circuit board with memory modules and control logic that manages the system I/O
between the hosts’ Fibre Channel adapter and the disk modules.

Unisphere™ – A web-based management environment for creating storage
resources, configuring and scheduling protection for stored data, and managing
and monitoring other storage operations.

Volume Shadow Copy Service (VSS) – A Windows service and architecture that
coordinates various components to create consistent point-in-time copies of data
called shadow copies.
EMC VNX Series: Introduction to SMB 3.0 Support
5
Concepts
SMB version and negotiation
The SMB protocol follows the client-server model; the protocol level is negotiated by
the client request and server response when establishing a new SMB connection.

CIFS – Windows NT 4.0

SMB 1.0 – Windows 2000, Windows XP, Windows Server 2003, and Windows
Server 2003 R2

SMB 2.0 – Windows Vista (SP1 or later) and Windows Server 2008

SMB 2.1 – Windows 7and Windows Server 2008 R2

SMB 3.0 – Windows 8 and Windows Server 2012

SMB 3.02 – Windows 8.1 and Windows Server 2012 R2
Before establishing a session between the client and server, a common SMB dialect
must be negotiated. As shown in Table 1, the common dialect depends on the SMB
version supported by both the client and DM.
Table 1
SMB dialect used between Client and DM
Client / DM
SMB 3.0
SMB 2.1
SMB 2.0
SMB 3.02
SMB 3.0
SMB 2.1
SMB 2.0
SMB 3.0
SMB 3.0
SMB 2.1
SMB 2.0
SMB 2.1
SMB 2.1
SMB 2.1
SMB 2.0
SMB 2.0
SMB 2.0
SMB 2.0
SMB 2.0
SMB 1.0
SMB 1.0
SMB 1.0
SMB 1.0
Note: SMB 3.0 leverages the SMB 2 protocol and the same SMB 2 packet formats are
utilized by SMB 3.0. SMB 3.0 was originally known as SMB 2.2.
For more information on SMB 2.x versions and negotiations, refer to the Microsoft TechNet
Website at http://technet.microsoft.com.
SMB 3.0 on VNX
Beginning with VNX File Operating Environment (OE) version 7.1.65, the SMB 3.0
protocol is now enabled by default on VNX. Note that VNX uses SMB 3.0 when
negotiating with SMB 3.02 clients. To check if SMB 3.0 is enabled on your DM, use
the server_cifs command to check the Max Protocol as shown in Figure 1.
EMC VNX Series: Introduction to SMB 3.0 Support
6
Figure 1
Check SMB 3.0
If SMB 3.0 is not enabled on your DM, you can enable it using the server_cifs command as
shown in Figure 2.
Figure 2
Enable SMB 3.0
Continuous Availability (CA)
In a client or CIFS server failure, the Continuous Availability (CA) feature allows
Windows-based clients to persistently access CIFS shares without the loss of the
session state. You can leverage this feature when planning with storage availability in
mind for business-critical applications such as Microsoft SQL Server, IIS, and Hyper-V.
Server failover
For a CIFS server to recover client content in a Data Mover failover, persistent handles
are introduced in SMB 3.0. When CA is enabled on a share, persistent handles enable
a CIFS server to save specific metadata associated to an open file handle on disk.
When a Data Mover failover occurs, the new primary Data Mover reads the metadata
from disk before starting the CIFS service. The client will re-establish its session to the
Data Mover and attempt to re-open its files and the Data Mover will return the
persistent handle to the client. The end result is no impact to the application
accessing the open files, if the failover time does not exceed the application timeout.
It is important to note that whether CA works in a Data Mover failover or failback
situation is dependent on the timeout of the application. As long as the Data Mover
failover or failback period does not exceed the timeout of the application, the
application can remain online.
EMC VNX Series: Introduction to SMB 3.0 Support
7
Figure 3
Server Continuous Availability
Figure 3 shows the sequence of events for a Data Mover failover with CA enabled:
1. The client requests a persistent handle by opening a file with associated
leases and locks on a CIFS share.
2. The CIFS server saves the open state and persistent handle on disk.
3. The primary Data Mover is failed over to the standby Data Mover.
4. The Data Mover reads and restores the persistent open state from the disk
before starting the CIFS service.
5. Using the persistent handle, the client re-establishes the connection to the
same CIFS server and recovers the same context associated with the open file
as before the failover occurred.
CA enables SMB clients to transparently reconnect to the peer Data Mover without
affecting clients accessing files on the shares.
EMC VNX Series: Introduction to SMB 3.0 Support
8
A persistent open requires the metadata of the file be committed to the back-end
storage before a request is completed, which includes:

All file data

All namespaces changes

Security descriptor

File size

File dos attributes

File timestamps on explicit setInfo or create
If a failover of a Data Mover occurs, the server will preserve the state of the persistent
handle. This means that any new open state conflicting with the share mode or new
range lock requests will be denied. Furthermore, any new open state involving a lease
break will be suspended.
Before enabling the CA feature, keep in mind that:

With CA enabled, you can achieve a transparent server failover for
implementations where the failover time is no longer than the application
timeout. In such implementations, hosts can continue to access a CIFS
resource without the loss of a CIFS session state following a failover event

Enabling CA will make all I/O going to that share be performed in synchronous
or write-through mode. Performance may be affected and the impact will be
similar to enabling the uncached mount option on a file system

CA is designed for applications, such as Microsoft Hyper-V or SQL Server,
where the file open/close operations are limited. It is not recommended to use
CA in scenarios where the impact of storing the open states is not negligible
such as Home Directory implementations
Client failover
A common approach to mitigate data unavailability at the client level is to configure
Windows clients in a cluster.
In the previous SMB 2.x implementation, the problem with this scenario was that the
server kept the handles of the clients with associated locks. Since the peer cluster
node (to which the application had failed over) is not the same as the original node, a
conflict occurred when the application tried to re-open the file and set the same
locks. The server did not realize that this was the same application trying to re-open
its file.
To address this issue, SMB 3.0 introduces the concept of an instance ID. The instance
ID is a 16-byte unique identifier assigned by the application, such as SQL Server
2012, on a file handle and is maintained for the lifetime of the handle. Using this, the
application will not conflict with the session established prior to the failover because
it can now be identified by the instance ID. The assumptions are that Windows Server
EMC VNX Series: Introduction to SMB 3.0 Support
9
2012 cluster logic ensures the same instance ID is not used by multiple applications
at the same time, and only a single instance of an application can be running at any
time.
Figure 4
Client Continuous Availability
Figure 4 describes the basic sequence of events when a node in a Windows cluster
fails over:
1. The application opens a file on the CIFS share and sets locks.
2. Node 1 fails and the Windows cluster moves the application from node 1 to
node 2.
3. The application re-opens its content on the CIFS share from node 2.
Applications accessing the data stored on the CIFS share are not interrupted.
EMC VNX Series: Introduction to SMB 3.0 Support
10
Enabling Continuous Availability
The Continuous Availability (CA) feature is disabled by default. To enable CA, the file
system must first be mounted with the smbca mount option as shown in Figure 5
Enabling CA on the file system. This is a CLI only procedure.
Figure 5
Enabling CA on the file system
Then the CIFS share must be exported with the type=CA option as shown in Figure 6.
This is a CLI only procedure.
Figure 6
Enabling CA on a CIFS share
Multichannel
SMB 3.0 introduces Multichannel where multiple TCP connections can be associated
with a single SMB session. A restriction in the previous versions of SMB was that only
one TCP connection could be established per SMB session. Now, if one TCP
connection is broken, the user session can continue using the remaining, active TCP
connections. The connection to the CIFS server on the Data Mover remains
established until the last TCP connection is terminated.
Multichannel provides several benefits, including:

Increased bandwidth

Transparent network interface failover

Load balancing
When establishing the SMB session, the CIFS server must send the response on the
same TCP connection the request arrived on. Once the session has been established,
the client sends a request to retrieve the list of interfaces available from the DM and
uses the best interface available for I/O. If multiple interfaces are available, the client
will open new connections on an as-needed basis. For example, when the pending
I/O queue begins growing, the client will open additional connections to improve
bandwidth.
If the network interface controller (NIC) supports Receive Side Scaling (RSS), multiple
TCP connections can be opened on the same NIC and be load balanced across
multiple CPU cores. Multiple RSS NICs can be used to support multiple TCP
EMC VNX Series: Introduction to SMB 3.0 Support
11
connections on each NIC for a single SMB session. You can run the netstat
command on a client to check the number of open TCP connections.
As shown in Figure 7, there are two TCP connections on two NICs associated with the
SMB session.
Figure 7
Multiple TCP connections
Directory Lease
In SMB 2.0, Microsoft developed a directory content cache that resided on the client.
This increased performance by reducing the amount of directory list requests
transmitted over the network. However, a disadvantage of this feature is that when a
client modifies files or folders, clients with a cached listing would not be aware of the
changes even when the directory listing is refreshed by the user.
SMB 3.0 improves the directory content cache with the concept of a directory lease.
By setting a lease on a directory, the Windows client is automatically aware of a
content change made in an open directory. If the content is created, modified, or
deleted in the directory, the directory lease is broken. The next directory list request
will be serviced by the CIFS server, instead of from the directory cache, with the latest
changes.
EMC VNX Series: Introduction to SMB 3.0 Support
12
There are three types of leases:

Read-caching lease (R) enables a client to cache reads, and can be granted to
multiple clients

Write-caching lease (W) enables a client to cache writes

A handle-caching lease (H) enables a client to cache open handles, and can be
granted to multiple clients
Client B
Client A
Figure 8
Directory Lease
Figure 8 describes the sequence of events when a directory lease is broken:
1. Client A opens a directory and caches the listing.
2. Client B changes a file or folder in the same directory. By making this change,
the directory lease is broken.
3. Client A is notified that its cached directory content is no longer up-to-date,
and sends a query to update that directory.
EMC VNX Series: Introduction to SMB 3.0 Support
13
Offload Copy
SPB
SPA
Command
2
7
Data
Data Mover 3
Data Mover 2
8
1
Client
Figure 9
Pre-SMB 3.0 data copy
Figure 9 shows the sequence of events required for a pre-SMB 3.0 copy:
1. The client requests data to be copied.
2. The Data Mover requests data from the Storage Processor.
3. The Storage Processor sends data to the Data Mover.
4. The Data Mover sends data to the client over the network.
5. The client sends back the same data to the Data Mover over the network.
6. The Data Mover sends back the same data to the Storage Processor to be
written.
7. The Storage Processor acknowledges the Data Mover.
8. The Data Mover acknowledges the client.
EMC VNX Series: Introduction to SMB 3.0 Support
14
Transferring data to the client and back results in wasted resources and adds
additional overhead.
Offload copy is designed to improve efficiency by allowing the Data Mover to do the
copy instead of sending data to the host and back again. It is a token-based copy
method where a 512-byte token is used to represent up to 256MB of actual data.
SPB
SPA
Command
4
Data
Token
Data Mover 3
Data Mover 2
1
2
5
3
Figure 10 Offload Copy
Figure 10 describes the sequence of events for an Offload Copy:
1. The client submits a copy request for a file.
2. The Data Mover builds a token and sends it to the client.
3. The client uses the token to generate the write request.
4. The Data Mover performs the copy.
5. The Data Mover acknowledges the client.
EMC VNX Series: Introduction to SMB 3.0 Support
15
The main benefit of Offload Copy is the elimination of reading and writing data across
the network. The host CPU usage and network bandwidth required is reduced.
Offload copy is only used for files that are greater than 512 KB as the token overhead
would make it impractical for smaller files. Note that if the data that is represented by
the token is modified, the token is invalidated and an error is returned. The client
then reverts back to the old copy method using a standard read and write.
BranchCache V2
BranchCache is a Microsoft feature that was originally introduced in the Windows 7
and Windows Server 2008 R2 operating systems. It is designed to optimize wide area
network (WAN) bandwidth when one or more remote branch offices need to connect
to the main office to retrieve data. This had several disadvantages including poor
application responsiveness, high WAN link utilization, and WAN bandwidth is
expensive.
When BranchCache is enabled, it creates a cache of the content from the DM, locally
within a branch office. A client from the same network can request the file and
download it from the local cache, instead of downloading it from the wide area
network. BranchCache optimizes the local link utilization and the responsiveness of
applications, and reduces the WAN bandwidth consumption.
When a file is requested from the DM in the main office, a hash of the file is sent to
the client instead of the file itself. The hash, known as the signature, is much smaller
than the file itself and the client uses it to search the branch office for the file. If a
match is found at the branch office, the client will retrieve the file using the LAN. If no
match is found, the client retrieves the file through the WAN and caches it for other
clients at the branch.
An update to BranchCache was released in Windows 8 and Windows Server 2012
called BranchCache V2. In the original BranchCache, files were divided into 32 MB
segments and each segment was divided into 65KB blocks. Each block was hashed
using SHA256 to generate the signature. In BranchCache V2, a simpler format was
introduced to increase the likelihood of finding signature matches. The concept of
blocks has been dropped. Files are divided into segments and each segment is
hashed using SHA256 to generate the signature. VNX uses a fixed segment size of
128KB.
SMB Encryption
SMB encryption provides secure access to data over untrusted networks by providing
end-to-end encryption between the client and VNX. It does not require specialized
hardware, IPSec, or WAN accelerators. Scenarios where SMB encryption can be
utilized include Remote Office Branch Office (ROBO) over WAN networks and
application workloads over unsecured networks.
EMC VNX Series: Introduction to SMB 3.0 Support
16
Encryption at the share-level is enabled on the particular share, and encryption is
enforced when that share is accessed. Optionally, encryption can be enforced at the
system-level (where encryption is set in the registry of the CIFS server), and all share
access would require encryption. There is no configuration needed at the client-level.
SMB encryption is not the same as Data at Rest Encryption (DARE) and will not encrypt
data on disk. SMB encryption only encrypts data during transmission over the
network. Once the data arrives at the destination, it is decrypted before it is saved to
disk.
Encryption settings
To support the SMB 3.0 protocol, VNX has two new values added to the registry of the
CIFS server: EncryptData and RejectUnencryptedAccess.
Setting the EncryptData value enables encryption on all shares on the CIFS server. By
default, the EncryptData value is disabled.
Setting the RejectUnencryptedAccess value prevents clients that do not support
encryption from establishing a session to the share. Instead, the client receives an
ACCESS_DENIED message after the failed attempt. Disabling the
RejectUnencryptedAccess value gives pre-SMB 3.0 clients the ability to access
encrypted shares. By default, the RejectUnencryptedAccess value is enabled.
To configure these parameters on the registry of the CIFS server, do the following
steps:
1. Open the Registry Editor (regedit.exe) on a computer.
2. Select File > Connect Network Registry.
3. Type the hostname or IP Address of the CIFS server and click Check Names.
When the server is recognized, click OK to close the window.
4. You can edit the parameters under
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Pa
rameters as shown in Figure 11.
EMC VNX Series: Introduction to SMB 3.0 Support
17
Figure 11 Location of SMB Encryption values in the Registry
On VNX, encryption can also be enabled at the share-level by using the
type=Encrypted export option. Once encryption is enabled, the SMB payload is
encrypted only when an encrypted share is accessed.
You can also use the RejectUnencryptedAccess value with the type=Encrypted
export option to control the behavior when a pre-SMB 3.0 client attempts to access it.
Encryption keys
Incoming and outgoing traffic are encrypted using two different secret keys. Both are
computed once the user is authenticated successfully. The encryption and decryption
16-byte keys are generated using the KDF algorithm in Counter Mode.
SMB messages on the network are encrypted between the client and server using the
AES128-CCM cryptographic algorithm, as described in RFC4309 and RFC3610.
The format of the encrypted messages consists of an SMB 2 TRANSFORM_HEADER
header followed by the payload. Any SMB 2 message can be encrypted, except SMB
2_NEGOTIATE and SMB 2_SESSION_SETUP.
Enabling encryption
To enable encryption on a share, export it with the type=Encrypted export option
as shown in Figure 12. This is a CLI only procedure.
EMC VNX Series: Introduction to SMB 3.0 Support
18
Figure 12 Enabling Encryption on a Share
It is important to note that there is a performance impact associated with enabling
encryption. Data is encrypted at either the client or VNX before it is sent across the
network and decrypted at the destination as it is received. CPU resources are required
on both client and VNX for these operations.
Remote Volume Shadow Copy Service
Volume Shadow Copy Service (VSS) infrastructure enables file systems to be backed
up while applications continue to write to these volumes and enables creation of
snapshots (called shadow copies for Microsoft VSS). Prior to SMB 3.0, VSS could only
create and manage snapshots of data stored on local volumes. With Windows Server
2012, Microsoft has extended this feature with Remote Volume Shadow Copy Service
(RVSS).
RVSS supports application backup across multiple file servers and shares. Backup
applications that are VSS-aware can now perform snapshots of server applications
that store data on the VNX CIFS shares. Hyper-V has the ability to store virtual
machine files on CIFS shares. RVSS can be leveraged to take point-in time copies of
the contents of the share. The application can create a writeable snap to leverage
RVSS and then perform a resynchronize operation before the backup is started.
Figure 13 shows a simple deployment of a single Hyper-V server utilizing VNX to store
virtual machines and user data.
EMC VNX Series: Introduction to SMB 3.0 Support
19
Data Mover 3
Data Mover 2
Marketing
Share
Marketing VM
Sales
Share
Sales VM
Figure 13 Backup Hyper-V VMs on CIFS shares
Two Hyper-V CIFS shares are provisioned on VNX: one for the Marketing team and the
other for the Sales team. Each member of these teams has an assigned virtual
machine and accesses files via their group’s respective shares.
The Marketing VM stores the virtual machine files on the Marketing share whereas
Sales VM stores the virtual machine files on both the Marketing and Sales shares.
When the backup application performs a snapshot of Marketing VM, VNX takes a
snapshot of the Marketing file system. A snapshot of the Sales file system is not
taken since only the Marketing share is used by the Marketing VM. The snapshot data
can then be made available to the backup application to perform a backup of the
data. When a snapshot of Sales VM is taken, both the Marketing and Sales file
systems are included in the snapshot taken by VNX.
EMC VNX Series: Introduction to SMB 3.0 Support
20
Large IO
The SMB 3.0 protocol, by default, enables large IO sizes for reads and writes. The
maximum I/O size is now 1 MB, which improves performance for large data copies by
limiting the number of SMB commands on the network.
Conclusion
Data availability, performance, and security are factors that you must consider in your
organization’s IT infrastructure. This is especially important when organizations have
remote offices across different regions of the world. You can utilize the VNX support
of the SMB 3.0 protocol, along with Microsoft Windows 8 and Windows Server 2012,
to address some common concerns.
Continuous Availability and Multichannel are features that maintain data availability
in a failure at the client, server, or network level. Offload Copy enables efficient data
consolidation or migration of content stored on CIFS shares. BranchCache V2
optimizes the local link utilization and the responsiveness of applications, and
reduces the WAN bandwidth consumption.
In terms of security, SMB Encryption enforces protection when data is exchanged
between Windows clients and VNX over untrusted networks, and enables
administrators to decide which Windows clients are granted access to this data.
Leveraging RVSS, point-in-time snapshots of the CIFS shares can be taken across
multiple shares and provide improved performance for backup and restore.
References

Configuring and Managing CIFS on VNX

Configuring BranchCache on VNX

Microsoft TechNet at http://technet.microsoft.com
EMC VNX Series: Introduction to SMB 3.0 Support
21