Are you Using these Windows Server Storage Features? You Should.

Save to My DOJO

Are you Using these Windows Server Storage Features? You Should.

Table of contents

Storage technologies are always changing and evolving while at the same time bringing immense benefit to our datacenters. We have come a long way from IDE spinning rust drives, iSCSI/FC protocols, and FAT32/NTFS. We have observed disk options grow in choice, capacity, and speed. We witnessed ethernet become a first-class storage protocol beyond iSCSI, and we were around to see file systems emerge and mature.

In this article, we’ll briefly talk about 2 such technologies, and leave you with some resources to learn more, including a webinar focused on modern-day storage technologies.

Let’s start with ReFS.

What is ReFS?

The ReFS file system was introduced in Windows Server 2012 and has evolved since then in terms of reliability and capabilities. Apart from scalability, ReFS offers some other capabilities that are very interesting for backup workloads.

NOTE: Want to know how ReFS stacks up to NTFS?

The block cloning capabilities of ReFS are convenient when it comes to synthetic operations in backups (depending on your backup vendor). Merging files, deleting old restore points, or creating full synthetic backups becomes lighting fast as you perform metadata operations instead of copying the data. That’s because ReFS can reference the existing blocks of data already on disk to create new files as needed.

The magic of block cloning: storing 30TB worth of data and consuming only 12TB

Figure 1: The magic of block cloning: storing 30TB worth of data and consuming only 12TB (image by Didier Van Hoye)

Next to incredible speed gains, the block cloning capabilities save space on disk. Instead of using copies of existing files to create a synthetic full, ReFS mainly needs to reference existing file data blocks. Those capacity savings add up.

ReFS - Block cloning and Integrity Streams

Figure 2: ReFS – Block cloning and Integrity Streams (image by Didier Van Hoye)

Finally, next to speed and space efficiencies, we can detect data corruption due to bit rot. For this, you need to turn on data integrity streams. While it does impact performance somewhat, ReFS offers the potential of auto repairing bit rot or file data block corruption. For this, you need to leverage a redundant implementation of storage spaces. That can be stand-alone storage spaces with mirroring or Storage Spaces Direct with mirroring. That allows ReFS to grab the needed file bock copies it needs to replace the corrupt ones detected via data integrity streams. All that happens transparently to the workload.

How Does Altaro Leverage These Features?

While Altaro Supports conducting backups from ReFS volumes, and restoring to ReFS volumes, we handle the block deduplication (inline), storage efficiencies, and auto-repair within our own software in order to provide a unified experience whether you are leveraging ReFS for your backup storage or older file system such as NTFS.

More information on Altaro VM Backup requirements and features can be found here.

SMB over QUIC

SMB over QUIC is new in Windows Server 2022 Azure Edition. Essentially it allows us to access SMB file shares over HTTPS/443. While that might sound scary, let me elaborate a bit on the reasons, benefits, and how this might be safer and easier than a VPN in certain use cases.

Next to TCP and RDMA, we now have QUIC for use with SMB

Figure 3: Next to TCP and RDMA, we now have QUIC for use with SMB (image by Didier Van Hoye)

The use case for SMB over QUIC

Microsoft offers SMB over the internet already with Azure File Shares over port 445. Now port 445 is more often than not blocked for ingoing and outgoing traffic at the edge firewalls. For a good reason, but it does mean that some handy and legitimate scenarios do not work. It also means that we need a VPN to access file shares from a client outside the corporate network. That introduces some extra complexity, maintenance and adds to the workload support workers have to handle. All that for something that is second nature to people, accessing a file share. Likewise, we need a VPN or Express Route to access Azure File Shares.

SMB over QUIC address these challenges. By allowing secure access to file shares over HTTPS/443, SMB over QUIC eliminates a lot of complexity and removes the game stopping factor that firewalls and ISPs most block port 445, which is often beyond your control. It also makes the process of accessing a file share identical no matter where a user is. Whether in the office, on the road, or at home, it remains the same experience without them needing a VPN connection. Azure File Shares will also support SMB over QUIC and solve that challenge.

QUIC requires TLS 1.3, and Windows Server 2022 supports this and has it enabled by default.

Without a line of sight to a domain controller, authentication will happen over NTLMv2. Therefore, to avoid introducing NTLMv2 dependent workloads, you can and should implement one or more KDC proxy servers. These will handle the Kerberos authentication for you when you have no connectivity to a domain controller.

The Kerberos Key Distribution Center Proxy Protocol

Here’s the gist of the challenges a KDC proxy solves. A Kerberos requires client connectivity to a Key Distribution Center (KDC) server to authenticate. In practice, that means a domain controller. Now, what if that is not possible? When you are outside of the corporate network and don’t have a VPN connection, what can you do? That is where the Kerberos Key Distribution Center Proxy Protocol (KKDCP) provides a solution. It allows clients to use a KKDCP server to obtain Kerberos service tickets securely.

 

Overview of the KDC proxy service

Figure 4: Overview of the KDC proxy service (image by Didier Van Hoye)

The Kerberos client must be configured with the KDC servers (GPO/registry), and when the standard ways of authenticating fail, it becomes a KKDCP client that sends Kerberos messages using HTTPS to the KKDCP server.

The KKDCP server locates a KDC (domain controller) for the request and sends the request to the KDC on behalf of a KKDCP client. From the KDC’s perspective, nothing is different; it receives Kerberos messages and is otherwise not involved in the KKDCP. When the KKDCP server gets the response from the KDC, it sends the Kerberos message over HTTPS back to the KKDCP client.

When accessing file share on the corporate network, by default, this will happens over TCP/445. The negotiation for TCP/445 starts before SMB over QUIC does, and as such, this wins typically. However, that will not work outside the corporate network because TCP/445 is blocked, and SMB over QUIC will kick in. When the client has no line of sight to domain controller fails. When you have configured that client with one or more KDC proxies, those come into play when all else fails, and Kerberos authentication is handled for you by a KDC proxy.

Note that you need to configure the KDC proxy to know about the trusted SAN certificate SMB over QUIC uses. That implies that you must have an internet reachable CRL/OCSP for this certificate. There are many more details to this, but the good news is that Windows Admin Center makes it super easy to set up SMB over QUIC for file shares and configure a KDC Proxy.

Critique about QUIC

When QUIC, in general, was first introduced, many security people and vendors got into a frenzy proclaiming this reduces security because firewalls and other security appliances could not handle QUIC and became blind. Now that should have been addressed by any vendor and turned into a sales pitch. Many of the other objections hold equally true for TLS 1.3 in general or for different ways of accessing file shares. While security is essential, the industry does love its drama and spectacle over new technologies. But change affects us all, and even the security industry has to adapt.

Would you Like to Learn More?

On August 11 we’re hosting a webinar that covers everything here plus lots more Windows Server Storage goodness. As always, we’ll be presenting it live twice on the day to enable as many people to join as possible and ask your questions. Session one is at 14:00 CEST, 08:00 EDT, and 05:00 PDT. Session 2 is at 19:00 CEST, 13:00 EDT, and 10:00 PDT. I (Didier Van Hoye) will be presenting the event with long-time Altaro webinar host Andy Syrewicze.

You can register to watch it live (before August 11) or on-demand at Altaro Webinar: Unlock your Storage Potential with these Powerful Built-in Windows Server Features.

Windows Server Storage webinar

Save my Seat

That title gives us a vast scope, and we will cover many subjects, so get ready for a whirlwind journey through storage devices, protocols, technologies, file systems, and more. Finally, we’ll glance over what Microsoft did with all these over the years to arrive at where we are today in the era of Windows Server 2022.

HDD, SSD, NVMe, PMEM …. SCSI, IDE, SATA, SAS, … iSCSI, FC, FCoE, NVMeOF, NVMeoFC, SMB 3, …, FAT, FAT32, NTFS, ReFS, NFS … , welcome to only tiny acronym soup in the IT world! Add to that local, shared, and software-defined storage, and that’s what we’ll be touching on in this webinar. See you there!

Threat Monitor
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published. Required fields are marked *

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.