In short
SMB over QUIC lets Windows clients reach SMB file shares over an encrypted QUIC connection instead of exposing traditional SMB on TCP 445 to the internet. On Windows Server 2025, SMB over QUIC is available in Standard and Datacenter editions. The default deployment path uses UDP 443 with TLS 1.3 and a certificate whose name matches the server FQDN.
Raff Technologies tested the full workflow on Windows Server 2025 using a public DNS name, a Let's Encrypt certificate, SMB certificate mapping, and a remote Windows client. This refresh keeps that test evidence but updates the 2026 guidance around pricing, certificate tooling, renewal, and client compatibility.
SMB over QUIC is useful when you need remote SMB without exposing TCP 445
Traditional SMB over the public internet is a poor fit because TCP 445 is commonly blocked and should not be broadly exposed. SMB over QUIC changes the transport: the SMB session runs through QUIC over UDP, with TLS 1.3 protecting the connection.
Common use cases include:
- remote employees mounting a Windows file share without a separate VPN tunnel;
- branch offices that need a shared UNC path over the internet;
- MSP-managed file servers for distributed client teams;
- contractors who need controlled access to specific shares.
SMB over QUIC does not replace identity, permissions, endpoint management, backups, or good credential hygiene. It changes the transport, not the authorization model.
Windows Server 2025 changed the SMB over QUIC edition requirements
Older Server 2022 guidance is easy to misread because SMB over QUIC was associated with Azure Edition. On Windows Server 2025, Microsoft makes SMB over QUIC available in Standard and Datacenter editions as well.
That makes the feature practical on hosted Windows Server 2025 VMs outside Azure.
What you'll need
For the workflow in this guide:
- Windows Server 2025 Standard or Datacenter;
- local administrator access;
- the File Server role;
- a public DNS name such as
files.example.com; - a TLS certificate that matches that FQDN;
- inbound UDP 443 for SMB over QUIC;
- a supported SMB over QUIC client;
- strong user credentials and appropriate share/NTFS permissions.
If you use Let's Encrypt HTTP-01 for certificate issuance or renewal, you also need inbound TCP 80 reachable during validation. If you use DNS-01, TCP 80 is not required for certificate validation.
Tested on Raff
The original lab test was performed on:
| Item | Value |
|---|---|
| Provider | Raff Technologies |
| OS | Windows Server 2025 Standard Evaluation |
| Build | 26100 |
| VM size used in lab | 4 vCPU / 8 GB RAM / 120 GB NVMe |
| Region | us-east |
| Validation FQDN | quic-test.raffusercloud.com |
| ACME client used in lab | win-acme 2.2.9.1701 |
| Certificate validation | HTTP-01 self-hosting |
| Test date | 2026-05-23 |
| Tester | Serdar Tekin |
The lab verified File Server installation, UDP 443 firewall access, certificate issuance, SMB certificate mapping, share creation, remote client access, and transport verification with QuicConnectionCount=1 and TcpConnectionCount=0.
The Evaluation image shown in screenshots was used for documentation testing. It is not the production licensing recommendation for Raff customers.
Step 1 — Install the File Server role
Open PowerShell as Administrator:
Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools
Verify:
Get-WindowsFeature -Name FS-FileServer
Then inspect the SMB server configuration:
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, EnableSMBQUIC, RestrictNamedPipeAccessViaQuic
On Server 2025, SMB1 should remain disabled. SMB over QUIC support is built into the current SMB server stack; you do not install a separate QUIC role.
Create a test folder if you need one:
New-Item -Path "C:\QuicShare" -ItemType Directory -Force
Step 2 — Open UDP 443 for SMB over QUIC
The standard SMB over QUIC deployment uses UDP 443, not TCP 443.
New-NetFirewallRule -DisplayName "SMB over QUIC (UDP 443)" ` -Direction Inbound ` -Protocol UDP ` -LocalPort 443 ` -Action Allow
Verify:
Get-NetFirewallRule -DisplayName "SMB over QUIC (UDP 443)" | Format-List DisplayName, Enabled, Direction, Action
Microsoft recommends using SMB over QUIC instead of exposing TCP 445 to the internet. Keep TCP 445 restricted to the networks that genuinely require classic SMB access.
Step 3 — Obtain a certificate for the file-server FQDN
SMB over QUIC requires a certificate that matches the name clients use to connect.
The original Raff lab used win-acme 2.2.9.1701 and Let's Encrypt. That tested workflow remains valid for existing win-acme deployments, but the win-acme project has since been succeeded by simple-acme, maintained by the same project maintainer. For a new long-lived deployment in 2026, evaluate simple-acme before standardizing on the older win-acme client.
The certificate must:
- contain the file-server FQDN in the Subject Alternative Name;
- be trusted by the client;
- include a private key on the server;
- remain valid for the lifetime of the SMB certificate mapping.
If you use HTTP-01, make sure the DNS name resolves to the server and TCP 80 is reachable during validation. Wildcard certificates require DNS-01.

The lab stored the certificate in Cert:\LocalMachine\My and confirmed that it had a private key.
Check your certificate:
Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter -Descending | Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey
HasPrivateKey must be True for the server certificate you map to SMB.
Step 4 — Map the certificate to SMB over QUIC
Once the certificate is installed, map it to the exact FQDN used by clients.
Example:
New-SmbServerCertificateMapping ` -Name "files.example.com" ` -Thumbprint "YOUR_CERTIFICATE_THUMBPRINT" ` -StoreName "My" ` -Type QUIC ` -Flags None
Verify:
Get-SmbServerCertificateMapping | Format-List Name, Thumbprint, StoreName, Type, Flags
The mapping should show the expected name and Type : QUIC.
Step 5 — Create the SMB share and permissions
Create a share only after defining both SMB share permissions and NTFS permissions appropriate for the users who need access.
Example test share:
New-SmbShare ` -Name "QuicShare" ` -Path "C:\QuicShare" ` -FullAccess "CONTOSO\FileUsers"
For workgroup systems, use a scoped local user instead of a broad group. For domain-joined systems, prefer domain identities and groups.
Remember that effective access is the intersection of share permissions and NTFS permissions.
Step 6 — Connect from a supported Windows client
From a supported Windows client, map the share using QUIC transport.
net use Z: \\files.example.com\QuicShare /TRANSPORT:QUIC
If credentials are required:
net use Z: \\files.example.com\QuicShare /TRANSPORT:QUIC /USER:CONTOSO\username
Avoid embedding plaintext production passwords directly in commands or scripts.
Microsoft has expanded SMB over QUIC client support over time, so verify the current edition and build requirements for the client fleet you actually manage rather than relying on an old 2022-era compatibility chart.
Step 7 — Verify that the connection is really using QUIC
A successful mapped drive is not enough. Verify transport.
Get-SmbMultichannelConnection -ServerName files.example.com | Format-List *
In the Raff lab, the proof output included:
QuicConnectionCount : 1 TcpConnectionCount : 0 Selected : True

That confirms the client is using SMB over QUIC rather than classic SMB over TCP.
Certificate renewal needs an SMB mapping check
Certificate renewal deserves special attention because SMB over QUIC depends on the certificate mapping remaining valid after renewal.
If your ACME client replaces the leaf certificate with a new certificate and thumbprint, verify whether the SMB certificate mapping was updated as part of your renewal workflow.
Check the current mapping:
Get-SmbServerCertificateMapping | Format-List Name, Thumbprint, StoreName, Type
Then compare it with the newest certificate for the FQDN:
Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotBefore -Descending | Select-Object -First 10 Subject, Thumbprint, NotBefore, NotAfter
Do not assume that successful ACME renewal automatically guarantees the SMB mapping now points at the newest thumbprint. Build a post-renewal verification step into your operational process.
If you still use win-acme, also verify its scheduled task and renewal list:
.\wacs.exe --list Get-ScheduledTask | Where-Object TaskName -like "*win-acme*"
For new deployments, review simple-acme's current renewal and scripting options before implementing the equivalent automation.
Common errors
SMB over QUIC does not connect
First verify DNS and UDP 443. TCP-based Test-NetConnection -Port 443 does not prove UDP 443 is reachable, so use firewall logs, packet capture, or another UDP-aware diagnostic if needed.
The certificate name does not match
Clients must connect using a name covered by the certificate. Connecting by raw IP address usually fails certificate validation unless the certificate was specifically issued for that identity, which public ACME certificates generally are not.
The certificate has no private key
Check:
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, HasPrivateKey
Use a certificate entry with HasPrivateKey : True.
Authentication fails
Separate transport problems from account problems. Review the server Security log for failed logons and verify username format, password, account state, share permissions, and NTFS permissions.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddMinutes(-10)} -MaxEvents 10
Renewal succeeded but QUIC stopped working later
Compare the active SMB certificate mapping with the currently valid certificate thumbprint. If the ACME client issued a replacement certificate, the SMB mapping may need to be refreshed depending on how your automation is built.
SMB over QUIC should not be treated as a complete security architecture
SMB over QUIC protects the network transport, but production deployments still need:
- strong identity and credential policies;
- least-privilege SMB and NTFS permissions;
- supported Windows builds;
- endpoint security;
- tested backups;
- monitoring and failed-logon review;
- a certificate renewal process;
- a documented offboarding process for remote users.
Avoid treating "no VPN needed" as "no other security controls needed."
Raff sizing should follow workload, not user-count shortcuts
The original version of this guide mapped fixed Raff plans to statements such as "up to 50 active users." We removed that because SMB file-server sizing depends heavily on file size, concurrent I/O, antivirus scanning, application behavior, sync patterns, and storage capacity.
Current Raff Windows VM examples are:
| Plan | Compute | With Windows Server Standard SPLA |
|---|---|---|
| 2 vCPU / 4 GB / 80 GB | $22.99/mo | $37.99/mo |
| 4 vCPU / 8 GB / 120 GB | $40.99/mo | $55.99/mo |
| 8 vCPU / 16 GB / 180 GB | $76.99/mo | $91.99/mo |
Windows Server Standard licensing through Raff SPLA is currently $15 per instance per month. Extra volumes are $0.08/GB-month, snapshots/backups are $0.06/GB-month, and VM traffic is 3 Gbps unmetered with no VM egress fees.
For a file server, size based on concurrent activity, storage requirements, backup strategy, and observed disk/network utilization rather than employee count alone.
