In this demonstration, I'm going to show you how to use AFS.
We're going to deploy and configure the service,
and then we're going to carry on this discussion into the next module.
You're looking at the desktop of a Windows Server 2022 machine named
localdc1. And if I use universal naming convention,
or UNC syntax, in other words double backslash hostname,
we can see I have a shared folder called scripts that
contains a bunch of PowerShell scripts.
This is the test case for AFS.
We're going to synchronize this scripts shared folder up into AFS.
Now again, if you're thinking wait a minute now.
I'm already confused, Tim. Hang on because you know with a shared
folder you have your typical shared folder permissions and NTFS
permissions to govern authorization.
And then when we shift context to the storage account,
I've created a storage account called contosofiles001.
There is Azure Active Directory authentication and authorization,
and there's‑‑‑ Well, there's other methods too,
but still don't get confused.
Don't overthink it.
With AFS, you're going to still have those resources accessed 100% locally,
so your NTFS file security and your shared folder
permissions will be what's important.
Now, in my contosofiles001 storage account,
I better create a matching file share,
which I'll do right now for that scripts directory.
Let's click Create, File share, or + File share.
I'm going to give it the same name, scripts.
I'll leave the tier and everything at the default.
So let's click Create to build that share,
and now we're ready to create our instance of the Storage Sync Service.
Now let's head on over there. Again, I've already created one.
The soufflé is already baked and ready to come out of the oven.
But if I go to the create screen, we can just look at the workflow.
It's pretty simple.
You just have your traditional Azure resource metadata,
subscription, resource, group, name, and region.
You can either use the public internet endpoint, or you could use private link.
This would constrain the Azure File Sync Service to a virtual network,
and you'd communicate with it using private IP addresses.
Then we have taxonomic tags as we normally do,
so no big surprises from that standpoint.
So I've already created the Sync Service.
Next, we'll come into its properties,
and you can see I've already created one sync group called,
appropriately enough, syncgroup1.
Well, just to demonstrate the one‑to‑many relationship,
I mentioned that the typical pattern I see is that a
business will have one Storage Sync Service,
and then you'll deploy sync groups.
And again, the topologies here can go all sorts of different ways.
You might want to create a sync group for each shared folder,
for each server, each location.
There's many possible ways that you can do that separation.
I'm just going to do a simple one‑to‑one here.
I'm going to create a sync group called
nashville‑scripts because I'm in Nashville,
and this is the scripts folder.
Sponsorship subscription is right.
We have to choose our storage account and file share.
We have our contosofiles.
Now notice here that there is a region dependency here.
These are the storage accounts in the selected
subscription and location East US.
That's the location of my Storage Sync Service.
So let's bring that in, and then we have to specify an existing file share.
If I were an engineer at Microsoft, I would have to create new link here,
but I'm not.
I'll select the scripts and then click Create.
So that creates two things, the sink group,
and it also creates the cloud endpoint.
So let's go into nashville‑scripts.
And eventually, it looks like the job status has been accepted,
and it's provisioning right now.
We have our one and only one Azure file share here,
and then we can get to work on the next to last step of the deployment,
and that is bringing in server endpoint.
So why don't we, while this is provisioning, go ahead and add a server endpoint.
However, this button you'll see is going to dead end us.
This interface assumes that you've already registered a server.
And, of course, we haven't registered the local server yet.
So, what I want to do is come out of this dialog,
come down to Registered servers,
and there is a download link right up here for the Azure File Sync agent.
Now, of course,
we could download that by browsing to this page at the
Microsoft Download Center ourselves.
That's all this link in the Azure portal is after
all is a hyperlink to this page.
Let me click Download to bring it down.
It looks like we have several different versions,
one per operating system version.
We've got Server 2022, which is what I want,
2019, 2012R2, and 2016, about 55 MB MSI package.
Let's bring this down.
This is just a standard MSI package, so let's launch the wizard.
Accept the license agreement.
We're going to install the Storage Sync Agent.
I'll leave the default path there.
Click Next.
I'm not using a proxy, so again I'll click Next.
A nice convenience I've seen as a trend with these Azure agents is that you can
integrate their update into Microsoft Update, which is a super useful thing to
do because I know in the past, I've had occasions,
particularly with the Log Analytics agent,
of it falling out of date quite a bit because I and my
colleagues forget frankly to verify that the log agent
version is the most recent one.
So I'm going to do that integration.
We can optionally schedule an automatic update and a window for that.
We can do data collection and then lastly install.
Because this process doesn't require anything like authentication to Azure,
it seems to me you could take that MSI and deploy it automatically,
even with something lightweight like Group Policy‑based software installation.
We'll find it's at first run of the Storage Sync Agent that we
hook in and become a member of a sync group.
All right, let's click Finish, and the Azure File Sync client starts up.
We can always get to it from the Start menu here if you need it in the future.
Click OK, and we're going to sign into not gov cloud or a sovereign cloud,
but the public cloud.
I'm not a cloud service provider.
Sign in.
We get our standard sign‑in flow here.
I'll sign in with my administrative credentials.
I'll answer this MFA request.
All right, here's where I can patch into my Storage Sync Service.
Let me choose my subscription,
my resource group, and lastly, the Storage Sync Service. We'll click Register.
Great. Registration was successful.
Let me close out of here. And I have a PowerShell session running
here, and you can see if I do a get‑service, the name of the Storage
Sync agent window service, the short name is FileSyncSvc Just wanted
to let you know that. We'll also want to make a note of the local path
to our shared folder.
In my case, it looks like it's C:\shares\script. And again,
Azure File Sync allows you to share an entire volume, but Microsoft
recommends that you use a discrete shared folder instead.
Let's come back to the portal where we left off. Let's go to Sync groups,
and let's head on over to nashville‑scripts. And now we will, in fact,
click the Add server endpoint button because now we have our registered
server right here, localdc1.contososolocal.int, and then we have our path.
Again, when I first saw this,
I was a little surprised because it wanted a local path
and not a UNC path. But there you go.
We're going to get into some of these other options in the next module.
So for now, I'm just going to click Create and wait for this job to complete.
Ultimately, our server endpoint shows with a green check for health, and
we'll begin to see these metric displays down here that will eventually
show files synced and bytes synced data over time.
And as you'd expect,
I think, if we head on over to the contosofiles001 storage account,
File shares blade, and investigate our scripts share, we see
that those files have, in fact, been synchronized from our local file share into the cloud.