All right, good deal.
So we're all set with that.
Let's click Close, and now we can return to the Azure portal.
All right,
so now we're back in the portal. Let's refresh our view, and my win2019
box is online, and registered, and all set to plug in.
So let's now go over to Sync groups. And actually, before we do
that, we want to make sure that we have a file share ready. I
almost forgot that little detail.
So let's head over to Azure Storage, and I'm going to pick on my
timstorage001 storage account. We're going to come down under File
shares, and I'm going to create a file share here called az801. Now,
of course, that's kind of a ridiculous name in the real world, but
just go with it. I want to make sure I can remember it is basically
why I'm doing that.
So there is our cloud‑based file share here in Azure Storage. Good to go.
So let's come back to Storage Sync Services, ps‑storage‑sync, Sync groups,
Sync group, and I'm going to call this scripts‑win2019. The storage account,
let's browse to that right now, timstorage001,
and then notice the reason why I wanted to make sure to go back and
create that file share is that there is not an option to create
one. It has to already be in existence.
So we'll click Create to create that sync group. It's in the East US as
well, and let's now go into the properties there, and we'll see it takes a
little while for the one and only one cloud endpoint. Now the topologies
that you can choose for Azure File Sync,
it depends really. In other words,
because we can have multiple server endpoints, we can bring in multiple
paths. But notice that those local file share paths are going to
resolve or be dumped into a single file share.
So if you want to do a one‑to‑one mapping between local
file shares and Azure file shares,
you're going to have to create multiple sync groups.
Otherwise,
if you don't care, if you want to consolidate those local
files into a single cloud endpoint, you can do that as well,
totally up to you.
So let's now go to, well, first of all,
let me show you what happens, what options we have here.
Basically, it's Properties and Delete for our cloud
endpoint. Let's just take a quick look.
So it looks like there's just a lot of metadata going on in the
Resource ID. Not much you can do other than refresh and delete.
Let's add a server endpoint in now, and we've registered our server,
so we can choose it from the list.
Now this takes a little bit of getting used to. The
path needs to be a local path, not a universal naming convention path.
So I'm going to want to come into my C drive, and I'm
going to use scripts as my example here.
So I'm going to copy that path.
Of course, I could just type it, but I'm going to paste it in.
We're not using Azure Data Box, so I'll ignore that.
And then for Cloud Tiering, Disable or Enable. Now I have a faint
recollection that cloud tiering doesn't work if your file share is on
your C drive. We'll see if that happens.
Okay,
let's see. Here it is right here, actually. This is an
exam alert point in real life as well.
You may be trying to create a server endpoint using the system volume.
Notice that cloud tiering does not work. Nuts! So I'm going to have to
disable that. But you should know from an exam perspective, if you do
enable cloud tiering that you're going to have to make sure that your
local file paths are not on your C drive.
And then also in addition to enabling tiering,
you can specify here the percentage of volume free space via a policy.
And this determines the aggressiveness of the tiering.
In other words,
20 is the default. That says make sure that you're
reserving, or Azure File Sync,
make sure that you're reserving at least 20% of free space on that volume.
So the higher you make this percentage,
the more free space you'll have locally, but the more aggressive the tiering
will be, you see? And we also can specify a date policy, only cache files that
were accessed or modified within a certain number of days. So these are our
controls to adjust that level of aggressiveness, all right? Let's see, for
initial sync, this determines how gentle you want that initial upload to be.
Merge the content of the server path with the content in the Azure file share.
Files with the same name and path will lead to conflicts, or we can
authoritatively overwrite any conflicted files in the Azure file share. I'm
going to choose Merge, and then we have download. Now you might wonder, if
you're doing cloud tiering, that means that you're going to be able to enumerate
files locally, but the file may not actually be available locally.
So that means the first time the file is requested, it
will need to be recalled from the server.
So here, you're adjusting how that is going to happen when you're
doing cloud tiered. Download the namespace first,
then recall the file content as much as will fit, or download the
namespace, file content will be recalled when accessed. That option would
only be applicable if you are, in fact, using tiering,
which I cannot do in this case.
Let me click Create. And that's really, believe it or not, all there is to
it. Largely, it's just self‑running and self‑maintaining.
So once that server endpoint is provisioned,
there's going to be that initial sync, and then from now on,
you've just got that synchronization taking place based on the
properties that you've set. And again,
all you can do from the server endpoint from a configuration standpoint is
get back to your properties and delete the endpoint. So you can see here
there's some metrics charts that we can look at.
Let me step back out of that full‑screen view and go back to the sync group.
But just by way of quick glance,
the two metric views you have are the number of
files synced and then the volume,
the bytes synced. It will take a little while for this to kick in,
but eventually, we'll be able to monitor it. After about 10 minutes
or so, we see the data showing up here, so it looks like 18 uploads, 1 download,
so we can just follow that, and we can make alerts, etc, etc. There you have it.