Good day, Cloud Gurus, and welcome back,
and congratulations on making it to the end of this section.
I hope the knowledge you've gained in this section
will serve you well both now and into the future.
Let's recap some of the key takeaways from the lessons
in this section.
At the start of this section,
we spoke about disks and how you can initialize them
either as GPT or NBR, and these days,
you're going to want to use GPT whenever possible.
And then we spoke about how you can format the disk
to create a volume either using NTFS or ReFS.
And Microsoft requires NTFS for boot volumes,
and they recommend ReFS whenever possible for data volumes.
But there are some limitations,
including compatibility
with a range of Windows Server features,
like File Server Resource Manager, Distributed File System,
and Data Deduplication on 2016 server or earlier.
And then we spoke about how you can use storage bases
to improve the resiliency of the storage within your server
by using multiple directly attached disks,
and then configuring those disks in a storage pool.
And then you can create virtual disks
by pooling them together
and then create volumes using those virtual disks.
And then we spoke about sharing data out using file shares,
starting with a folder on a file server
and then configuring a shared folder.
And when you create a file share,
you'll need to provide a share name
and you can end that share name
with a $ sign character
to hide the share name from users browsing the server.
You can also configure share permissions
but often these are not used to actually assign access.
So you can generally grant broad access
using share permissions,
and then you can use NTFS permissions
to control access both locally
and when data is accessed via the share.
NTFS permissions, sometimes called Windows ACLs,
are more granular than share permissions
and can be inherited
or have inheritance broken to better control access.
What's important to remember about NTFS permissions
is that deny overrides allow,
so deny permission should be used sparingly.
And then we took a look at File Server Resource Manager
and how you can use the various features
of File Server Resource Manager
to provide advanced file management capabilities,
including quotas to ensure users don't use too much space
on a given folder or volume,
and remembering that only FSRM quotas
can be applied to our folder.
The older NTFS quotas, which no one really uses these days,
are volume-level only.
We also took a look at how you can prevent users
from saving unwanted data to a server using file screens.
And file screens are based on the file extension.
And finally, we also took a look at
how you can use the file classification infrastructure
to ensure files are handled appropriately
based on how they're classified.
And then we explored how you can distribute
and replicate data using Windows Server.
We first explored the file-level Distributed File System,
or DFS, where we took a look at replication,
which can be used to replicate a folder between servers.
It's important to remember that DFS replication can be done
in one direction or in both directions.
And it can be done either in a hub and spoke
or full mesh topology.
We also explored how you can make this replicated data
accessible using a DFS namespace, and you can configure one
or more namespace targets for redundancy.
And these name spaces can be highly available
with domain-based name spaces, using Active Directory,
or stand alone without Active Directory.
And then we took a look at how you can replicate volumes
between Windows file servers at the block-level
in one direction only using storage replica.
We learned that storage replica can be asynchronous,
which is useful for higher latency networks
like between your on-premises environment and the cloud,
or synchronous replication
within the site or between Azure availability zones.
We also learned those key terms, like RTO,
which is the amount of time a service takes
to recover from failure.
And RPO, which is the point in time
the servers will revert to after a failure,
meaning how much data will be lost when a failure occurs.
And we learned that synchronous replication
with Storage Replica provides a zero RPO or no data loss.
We also took a look at how you can optimize
the capacity of your servers using deduplication.
We learned that you could use it with either NTFS or ReFS,
but you need to be running Windows server 2019 or later
to use ReFS.
We also learned that you can use DFS with dedup
on one or more of the servers in the DFS replication group,
but with block-level replication like Storage Replica,
you need to have deduplication enabled
on both the servers in the replication partnership.
We also learned that deduplication messes with things
like Windows Search,
so you might get incomplete search results,
and we learned some of the warnings
about using ROBOCOPY with dedup.
We also learned about the optimization task
and that it runs offline by default every hour
but you can run it manually if required,
and we learned about the garbage collection task
that cleans up the chunk store,
and you can run that task manually if you want to,
otherwise it'll run once per week by default.
We also briefly covered off the integrity scrubbing task
that is used to deal with chunk store corruption.
And then, finally, in this section,
we covered off BranchCache
and its newfound role as a performance
and bandwidth optimization tool in hybrid environments.
We also learned that BranchCache is ideal for data types
that are accessed by multiple clients at the site.
And these include things like software distribution
and operating system updates.
We also took a look at the 2 modes of BranchCache,
which are hosted cache,
which allows a server at the branch office
to optionally pre-cache data at branch offices
allowing even the first client
to have fast access to the data.
Or distributed mode, which uses other clients
at the branch site to speed up access to data
with the first client being slower
than all of the subsequent clients.
All right, that wraps up this section.
I hope you found something useful,
and I hope this prepares you
for what's ahead as an Azure hybrid administrator.
Thanks for being with me,
and I'll see you in the next section.