This is a discussion of AFS, or Azure File Sync,
which is an Azure service that you can use to do many things.
You can centralize your local file shares into a hybrid
storage solution using Azure Files.
Azure Files is one of the four services in Azure Storage,
a general purpose storage account.
We could summarize Azure Files in a very succinct way by
saying cloud hosted SMB and NFS file shares.
AFS, or Azure File Sync,
gives us multi‑site access and synchronization and that
multi‑site access and sync happens, this is really important,
note this well, with no changes required to your client application,
so your drive mappings, your work folders,
your Windows 10, Windows 11 work folders,
all of that local access, even your DFS,
your distributed file system topology on‑premises,
you don't have to change anything.
Azure File Sync just overlays your existing file share architecture.
It's really cool.
And you'll see also, we've got cloud backup,
so therefore, we have business continuity/disaster recovery features.
You can save space,
disk space on your local file servers by turning on cloud tiering
where your less frequently accessed files will go up to the cloud and
be removed from your local file servers,
although those file names, of course, will appear in directory listings,
and then you've got a convenient mechanism for cloud backup.
So I like to describe the Azure File Service and Azure Storage as a
Swiss Army knife because it's so multi‑functional,
and I've always been a fan of Azure File Sync as some really
clever engineering that carries on that tradition of Swiss Army
knife metaphor or multi‑function.
Here is a diagram I created and lucid chart to help you
understand the use case and the high‑level Azure File Sync
architecture a little bit better, also to get you on board with vocabulary.
So step one is creating an instance in your Azure subscription
of what's called a Storage Sync Service.
Now your business may need only one of these because
you can have multiple sync groups, and a sync group consists of two components.
You've got a cloud endpoint,
which is going to be a single file share in a storage account,
and then on‑prem,
you have your server endpoints and the way you register your
on‑premises file servers is simply installing a small agent.
Now the agent is Windows only, unfortunately,
but it does communicate network wide only on TCP for principally,
I should say TCP 443.
In the real world,
you always want to double check the docs to see if
there is any port requirements, but the main one is TCP 443.
Note that we're not having to expose TCP 445,
the server message block port, to the world.
No, no, no, you don't have to do that.
It's just going to be HTTPS encrypted TLS‑based communications
between the server endpoints and those cloud endpoints.
You can have only one cloud endpoint per sync group,
but you can have as many server endpoints as you want and that gives you,
again, some of that redundancy and possibly the ability to move away from DFS.
You know, DFS and DFS replication carry with them their own history and baggage.
You might find that a migration to Azure File Sync makes a lot more sense,
and you know, something else that's so cool about AFS,
let's say that in our London office there on the right side of the slide,
that server‑london file server goes offline,
it has a catastrophic hardware problem.
We can literally just install the Azure File Sync agent
on another member server in London, connect it up into the sync group,
and once the data is synced,
that machine takes over those file shares for the original machine.
You might have to do some DNS updating depending,
but it's literally that easy and the cloud backup and the cloud tiering,
all of that is transparent. Let's get into the demo, and we've got a lot to do.