Is Offloaded Data Transfers (ODX) working?

Offloaded Data Transfers (ODX) is a new data transfer strategy that makes advancements in moving files.  Only storage devices that comply with the SPC4 and SBC3 specifications will work with this feature.  With this feature, copying files from one server to another is much quicker.  This feature is only available in Windows 8/2012 and above as both the source and the destination.
This is how it works at very high level:

• A user copies or moves a file by using Windows Explorer, a command line interface, or as part of a virtual machine migration.
• Windows Server 2012/2012R2 automatically translates this transfer request into an ODX (if supported by the storage array) and it receives a token that represents the data.
• The token is copied between the source server and destination server.
• The token is delivered to the storage array.
• The storage array internally performs the copy or move and provides status information to the user.

Below is a picture representation of what it looks like.  The top box is the way we are used to seeing it.  If you copy a file from one machine to another, the entire file is copied over the network.  In the bottom box, you see that the token is passed between the machines and the data is transferred on the storage.  This makes copying files tremendously faster, especially if these files are in the gigabytes.

For more information on Offloaded Data Transfers, please refer to

Windows Offloaded Data Transfers Overview

Many Windows installations have additional filter drivers loaded on the Storage stack.  This could be antivirus, backup agents, encryption agents, etc.  So you will need to determine if the installed filter drivers support ODX.  As a quick note, if the filter driver supports ODX, but the storage does not (or vice versa), then ODX will not be used.
We have filter manager supported features (SprtFtrs) which will tell if filter drivers support ODX.  We can use the FLTMC command, as shown below, to list filter drivers and their supported features.  For example:
X:\> fltmc instances
Filter      Volume Name    Altitude   Instance Name  Frame  SprtFtrs
----------  -------------  ---------  -------------  -----  --------
FileInfo    C:             45000      FileInfo       0      00000003
FileInfo    I:             45000      FileInfo       0      00000003
FileInfo    D:             45000      FileInfo       0      00000003 <-it and="" both="" offload="" read="" span="" supports="" write="">
FileInfo    K:             45000      FileInfo       0      00000003
FileInfo    \Device\Mup    45000      FileInfo       0      00000003
You can also see the Supported Features available for a filter driver in the registry:

HKLM\system\CurrentControlset\services\

The SupportedFeatures registry value contains an entry. If it is 3 as in the above FLTMC output, is supports ODX.
Now that we have determined that ODX is supported by the required components, is it actually working?  You can see the ODX commands FSCTL_OFFLOAD_WRITE and FSCTL_OFFLOAD_READ captured in a Process Monitor trace when it is working.  When ODX is working, we see the following in Process Monitor.

In case a target fails the Offload, it does not support ODX, or does not recognize the token, it can give a STATUS_INVALID_TOKEN and/or STATUS_INVALID_DEVICE_REQUEST as the result.

Other reasons why it might not work :
1)    Something above Storage stack such as encryption or File system driver (Encryption filter, etc.) can cause it to fail.
2)    Even though two disks/volumes might support offload they might be incompatible. This has to be established by involving the Storage Vendors.
It is not a recommendation, but for informational purposes, you can disable ODX functionality in the registry if so desired.  You can do this  with a PowerShell command:

Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" -Value 1

Or, you can edit the registry directly.  The value of 1 (false) means that it is disabled while the value of 0 (true) means it is enabled.  When this change is made, you will need to reboot the system for it to take effect.
One last thing to mention is that you should always keep current on hotfixes.  This is especially true if you are running Failover Clustering.  Below are the recommended hotfixes you should be running on Clusters, which include fixes for ODX.

Recommended hotfixes and updates for Windows Server 2012-based failover clusters
Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters