Reinout Segers

Although it is fairly expensive, Azure Files in combination with Azure File Sync is a perfect solution for a home NAS. It offers scalable and reliable cloudbased storage with instant on-premises access by caching the most recent files on a traditional fileserver through a process called cloud tiering. This means it can use most of the Windows Fileserver features, such as DFS, ACL and other FSRM services.

Evidently, it is not quite meant for home use, but instead suits the needs in particular for midmarket businesses. These companies tend to have a few hundred gigabytes to a handful of terabytes of storage. However, this exponentially grows once high availability, offsite backups and disaster recovery are required.

Azure File Sync is currently in preview, which means the price is low and support is limited: a no-go area for production environments. I won't go into further details about what Azure File Sync actually can do for your business. It reminds of Azure's StorSimple, but far less expensive. Head over to Petri.com for an excellent article.

Thus, I can't use it yet for my clients, but my home environment is a perfect business case: it is a full-fletched Microsoft-based hybrid cloud environment. My fileshare is slightly larger than 1 terabyte on a parity volume spanning three physical disks. No backup 😇 and lousy performance (I got these "special" NAS harddrives, yay?).

Enter Azure Files with File Sync. I created a new PowerShell DSC configuration file, which built a new fileserver on-premises, attached a simple volume and set up DFS. I migrated the data and boom, done. Peace of cake.

The data synchronized with the Azure storage account as it should and it seemed to work nice and well. The volume on my fileshare was 150GB of NVMe SSD storage and I configured File Sync to leave 40GB of free space. New files were instantly synchronized and older files were tiered almost immediately to Azure, adhering the 40GB free space threshold.

Soon things stopped working. Tiered files would throw an error trying to open them: "the file cannot be accessed by the system". Time to surf to the troubleshooting section on support site. It took some digging and found this sentence: "In order to respond to tiering/recall requests, the Azure File Sync file system filter must be loaded". The Filter Manager Control Program (fltmc.exe) indeed reported that StorageSyncGuard.sys was loaded, but StorageSync.sys wasn't loaded.

PS C:\> fltmc
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
DfsDriver                               1       405000         0
storqosflt                              0       244000         0
wcifs                                   0       189900         0
StorageSyncGuard                        2       180465         0
FileCrypt                               0       141100         0
...

The StorageSync was registered though:

PS C:\> fltmc filters

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
StorageSyncGuard                        2       180465         0
StorageSync                             2       180460         0
...

Loading the driver manually gave no error: fltmc load StorageSync . Retrieving tiered files now worked again 🎉

So what caused the driver to not load automatically after a reboot? After sifting through the eventlog (the File Sync eventlog provider wasn't much help), it found these events in this order:

There we have it! The MiniFilter Drivers are loaded well before the iSCSI disks are initiated. This means that the iSCSI disk is not available when the driver is being attached to the volume, resulting in the immediate unloading of the driver.

I guess that leaves us with three solutions:

1. Use persistently bound volumes
2. Use PowerShell DSC to ensure the status of the driver
3. Change the MiniFilter Driver startup type from SERVICE_SYSTEM_START to SERVICE_AUTO_START in StorageSync.inf (not a good idea I suppose 😉)

Just some notes to end the story with, because there is still some space left:

• Media streaming is supported: instantly play media files without having to download it first
• Tier files to the cloud, transparently to the end user
• Easy disaster recovery: just built a new fileserver: files are instantly available
• Use fast storage on-premises, acting as a cache
• Beware of the costs: iops and outgoing bandwidth may suprise you
• Thorougly test your anti-virus: scanning offline files is not a good idea in this case
• Inventorize other software that scans fileshares, such as your media server (😏) or the Azure Information Protection Scanner
• Traditional backup solutions won't work: it will download all tiered files from Azure
• Do not forget to create a backup and disaster recovery plan. Use Azure Backup and Snapshots. I assume the snapshop function will be integrated into the context menu of file explorer.