How can we improve Azure Storage?

Enable immediate sync after changes on the Azure file share for Azure File Sync

When I make a change on my server endpoint (Windows File Server), Azure File Sync initiates a sync session very quickly after file save, however for changes on the cloud endpoint (Azure file share), I have to wait at least 24 hours to have changes get synced down to my server endpoints.

Please invest in features to initiate a sync session immediately after changes are made cloud-side, or at least increase the interval of sync from the Azure file share.

1,108 votes
Vote
Sign in
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Prabath Anuradha shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for your feedback! As you mentioned, we initiate a change detection job once every 24 hours to enumerate the Azure file share and scan for changes. This is required for the Azure file share because Azure Files currently lacks a change notification mechanism like Windows Server has (we watching the USN journal on Windows Server to automatically initiate sync sessions on the server after changes are made).

Long term, we would like to build a change notification mechanism directly into Azure Files. Shorter term, we could use your feedback to understand how painful the once every 24 hours change detection is for you. Please vote and/or leave comments on this item to let us know we should invest in work to make the change detection job run more frequently/faster.

Thanks,

Will Gries
Program Manager, Azure Files

67 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Adrian Fletcher commented  ·   ·  Flag as inappropriate

    Any updates on this? Hopefully even a remote timeline for introduction? We've got some active and some future projects that would depend on this feature allowing a sync interval of at least an hour, preferably less.

    Adrian

  • Juan Acosta commented  ·   ·  Flag as inappropriate

    In our case, it is a useless feature without being able to update the files on the local endpoint real time.

  • Adrian Fletcher commented  ·   ·  Flag as inappropriate

    Use case here, we have a marketing department using Azure File Share to work on fairly large files, both from home (directly connected) and in the office (via Azure File Sync). At the moment, changes done at home take too long to be detected and and synced down to the office 'synced' file share.

    Would greatly appreciate if changes were pushed down much faster (somewhere around less than an hour would be OK in our case).

  • Anonymous commented  ·   ·  Flag as inappropriate

    Use case: we maintain a fleet of vessels, and want to be able to publish document updates out to the fleet using the Microsoft Flow connector to the Azure Storage file share as a trigger. Comms to the vessels will vary, and a vessel might be in range when a change is made, but out of range when the detection job runs, and remain out-of-sync until the vessel is back in comms range again. There would then be a delayed update.

    Ideally, we would prefer to be in a position to offer on-demand updates to the fleet, but this would require a mechanism which triggers a change immediately upon an update completing.

  • Gene G commented  ·   ·  Flag as inappropriate

    Got this all configured, then found this post. Please, we need immediate sync with Azure file change.
    I also went this route since SMB/port 445 blocked by my ISP.

  • Phillip Chen commented  ·   ·  Flag as inappropriate

    Just started looking into Azure File Sync and was curious about the 24 hour sync from Azure to the server endpoints, it would be a blocker if we can't even "trigger" the syncs or at least sync at a more frequent schedule.

  • Robert Glynn commented  ·   ·  Flag as inappropriate

    13 months since this issue was reported (at least here). This is a major issue that is really quite unacceptable that it even existed on production release. 24 hour sync schedule prevents the common use case of locally handling files created on a remote service. My team has to either implement our own sync process or change vendors. If we weren't already so far along in our process, vendor change would be a no-brainer.

  • Anonymous commented  ·   ·  Flag as inappropriate

    If you aren't going to allow some work around for the direct connection via port 445 which is blocked by most small business ISPs then this, a modifiable schedule, or manual trigger HAS to be implemented. Users having to wait a day to do any work to these shared files is ridiculous.

  • xradas commented  ·   ·  Flag as inappropriate

    This whole product is a massive sham, really informative errors and useless documentation. I hate having to speak to people who don't give one, constantly opening and closing tickets because of MS stupid "scoping" when logging a call, just never get to the bottom of anything.

  • Pete commented  ·   ·  Flag as inappropriate

    Not a solution but a work around is, mapping to the Azure file share from the server, look at previous versions, and copy out of previous version to the endpoint (not to the azure file share), these will then be replicated around post haste.

  • Hadriel Tzuk commented  ·   ·  Flag as inappropriate

    @Eric - My use case was that the "Endpoint" didn't sync immediately the change to Azure Storage Account until i upgraded the Agent to 4.1.0.0

  • Eric Mucci commented  ·   ·  Flag as inappropriate

    @Hadriel - When a file is changed directly in the Azure Share (via SMB, Storage Explorer, Azure Restore, etc) the change can take up to 24 hours to sync down to the Server Endpoint. This behavior has not changed with the update to the Sync agent. To be clear, any changes done to the Server Endpoint always synced "immediately" to the Azure Share and to other registered Server Endpoints. The fix in 4.x is related to cloud tiering - in some scenarios files on the Server Endpoint could take up to 24 hours be tiered (ie not stored on the Server Endpoint). This thread is about improving the Cloud --> Server Endpoint sync time, NOT the syncing between Server Endpoints.

  • Hadriel Tzuk commented  ·   ·  Flag as inappropriate

    Guys,

    I can truly confirm that after uninstalling my old FileSync Agent and installed the 4.1.0.0 Agent the FileSync sampling intervals for sampling the folders around 5 seconds. so yes it works.

  • Ramonito commented  ·   ·  Flag as inappropriate

    It's almost a year now and still no action from Microsoft. This feature is the only way for us to migrate TB sized data to Azure and make it available on-premise using FS with GB sized disk.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Can someone confirm this is in 4.1.0.0? I'm not seeing faster change detection from share changes back to server

← Previous 1 3 4

Feedback and Knowledge Base