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:
|09:43:24.916||Microsoft-Windows-FilterManager||6||File System Filter 'StorageSyncGuard' (10.0, 2058-07-01T03:59:24.000000000Z) has successfully loaded and registered with Filter Manager.|
|09:43:24.925||Microsoft-Windows-FilterManager||6||File System Filter 'StorageSync' (10.0, 1990-07-20T01:55:08.000000000Z) has successfully loaded and registered with Filter Manager.|
|09:43:24.926||Microsoft-Windows-FilterManager||1||File System Filter 'StorageSync' (Version 10.0, 1990-07-20T01:55:08.000000000Z) unloaded successfully.|
|09:43:33.201||Service Control Manager||7036||The MSiSCSI service entered the running state.|
|09:43:33.373||Service Control Manager||7026||The following boot-start or system-start driver(s) did not load: StorageSync|
|09:43:33.482||Service Control Manager||7036||The FileSyncSvc service entered the running state.|
|09:43:33.497||Microsoft-FileSync-Agent||1000||Storage Sync Agent (FileSyncSvc) service started.|
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:
Just some notes to end the story with, because there is still some space left: