I've used this a few times to put games on exchangeable media. Installers don't like it if you pick an SD card as an install target, but they don't care if C:\Games\Whatever is actually an NTFS mount point that goes unpopulated as soon as I disconnect the memory card. This trick has the downside of confusing installers that try to check free space, though.
For permanently mounted drives, I'd pick symbolic links over mount points because this lets you do file system maintenance and such much easier on a per-drive level. You can still keep everything under C:\ and treat it like a weird / on Unix, but it you need to defragment your backup hard drive you won't need to beat the partition manager into submission to make the defragment button show up for your mounted path.
Don't have to use PowerShell either, it's been available for ages through Disk Management. Right-click on a partition -> Change Drive Letter and Path -> Add -> Mount in following empty NCTS folder.
NTFS mount points can be very handy for engineering around software that doesn't allow you to customize paths. I can choose VM disks with different performance or replication policies and stitch them together like I would on a *nix OS. It's very handy and only in rare occasions have I had applications "notice" it and balk.
Symlinks also work on NTFS, though mount points have the advantage of not having a canonical path that might be unintentionally resolved and persisted.
Only for NTFS (both source and dest) though, no exFAT shared drives under a folder mount or what have you. I think the same is actually true of ReFS for some reason.
When you create/format the partition in the GUI tools it'll actually ask if you want to assign a drive letter or mount as a path as well.
Many programs (Steam did, last time I checked) will look up the parent disk's free space when you do that and might refuse to install if that space is too small (even if target dir have enough)
Indeed, and if you only have a single drive letter, that drive is always the active one, and so you can just write paths starting with the backslash: \Windows\System32 etc.
It's even available in the regular UI, open "computer management" go to the disk section and many of the 'magic' things about drives in windows world are just UI toggles
Back when Windows 2000 was the new thing, I used to put "Program Files" on another disk with this. Starting programs became faster too, as things loaded both from the OS drive and the drive where the programs were installed.
Unbound unfortunately has some a pair of issues ([1][2]) that in some situations (adblocking, source address based dns selection) can make it a less than optimal match for some use-cases.
"Some users of our service (NextDNS), discovered this issue since edgekey.net has been added to some anti-tracker blocklists, resulting in the blocking of large sites like apple.com, airbnb.com, ebay.com when used with unbound."
As Pi-Hole is a modified dnsmasq, NextDNS may be a modified unbound
For HTTP I use a localhost-bound TLS forward proxy that has the DNS data in memory; I gather the DNS data in bulk from various sources using various methods; there are no remote DNS queries when I make HTTP requests
Unbound is overkill for how I use DNS on the local network
Psst! NSD isn't a "resolver" at all. Traditional DNS terminology is tricky to use (given that what is covered by "resolver" in the RFCs does not match how most people see the system as divided up) but something that does not do the resolving part at all is definitely not a resolver.
Amazon/AWS Registrar. They're a reseller for Gandi, but of course everything is managed through AWS and the pricing is at-cost instead of the rip-off that Gandi is now.
Orchestrate the renewal with Ansible - renew on the "master" server remotely but pull the new key material to your orchestrator and then push them to your server fleet. That's what I do. It's not "clean" or "ideal" to my tastes, but it works.
It also occurred to me that there's nothing(?) preventing you from concurrently having n valid certificates for a particular hostname, so you could just enroll distinct certificates for each host. Provided the validation could be handled somehow.
The other option would maybe be doing DNS-based validation from a single orchestrator and then pushing that result onto the entire fleet.
DNS-based (hostname) allowlisting is just starting to hit the market (see: Microsoft's "Zero Trust DNS" [1]) and this would kill that. Even traditional proxy-based access control is neutered by this and the nice thing about that is that it can be done without TLS interception.
If you're left with only path-based rules you're back to TLS interception if you want to control network access.
The caveat with this is that it will fail the check on subsequent version upgrades too and will refuse to upgrade.
Non-Enterprise editions are only supported for 2 years so your 25H2 (or whatever it is) installation will go sour in 2027.
reply