@scottalanmiller my problem with Certs on Windows, in general, is that you almost always have to copy it around to multiple servers to make everything work well, and that jsut defeats the purpose of LE.
Based on what is on the site, Microsoft has an intrinsic trust with LE's root store. I should be able to set up a RD Session Host with a LE certificate for publishing and there should be no untrusted publisher for RemoteApps or Session Host desktops once the certificate's thumbprint is published via Group Policy?
One would hope that they would. LE is like the standard in SSL Certs. It's from the EFF, way more trustworthy than other cert authorities, IMHO.
Snag: Valid for 90 days. In larger RDS farm settings this would be a bear to manage. That means the need for an automated process.
It is expected to be automated. SSL Cert updates should not be intrusive. All of the tools for LE SSL Certs are designed around the idea that you will automate them and never need to worry about them again. It's about being less of a snag, not more of one.
Got it thanks. Looks like a bit of a learning curve then. 🙂
It's not bad. I find learning the LE pieces easier than learning to do it the old fashioned way 🙂 And with LE it is "learn once and ignore", rather than "learn once, forget, do again in a year or two all over again."
My grand idea is that checkpoints would be used before installing Windows updates or some upgrade to an application. You take the checkpoint, apply the update, and if everything breaks, you apply the checkpoint. If nothing breaks, then you delete the checkpoint.
I'm curious how this would be handled with a SQL Server VM or Redis VM. You'd update your VM, transactions start happening, then things break causing you to have to apply the checkpoint. Any transactions that were done would be lost, which upon further thinking probably doesn't matter, since you probably couldn't trust any data put into the database while the stuff was in the process of breaking.
You have to make sure you don’t have transactions coming in. Simple as that. Anything is a headache waiting to happen.
Makes sense. When I do maintenance on these normally, I stop IIS once downtime’s been announced, then do my work. So I’d just take the checkpoints at that point. I imagine once stuffs back up and I confirm things aren’t broken, Hyper-V just handles merging the avhdx file in such a way that SQL Server, etc is none the wiser. Or is there significant risk of stuff breaking if it’s running while that merge process takes place?
No real risk. Just performance loss.
And never enought to matter to any SMB workload I have ever had to deal with.
OMG, nevermind. Figured that out too. Was a combination of a missing default path and the same .NET CLR pool version as before. It's a subfolder and needs its CLR version set, too. Argh. All is well now.