Everything, Everything

There are many things I like about Server 2016 (and Server 2012 R2), but the removal of the Remote Desktop Configuration Manager MMC snap-in that was really useful in Server 2008 (which used to run this web server for several years) makes it a lot more difficult to configure a different certificate for the RDP listener. Instead of a few clicks in a GUI you now have to find the SHA1 hash and use the command line (although you can do it by adding a registry key, but WMI is easier in my opinion).

I went with Method 1, Using Windows Management Instrumentation (WMI) script, to configure the use of my certificate on my shiny new VM running Server 2016. After identifying the SHA1 hash of the certificate, the following command can be used on newer versions of Windows including Server 2016 to replace the default self-signed certificate:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"

Not that you'll see the certificate, as I've locked down access to RDP to a handful of trusted IP addresses.

EDIT: Just a quick note in case that other page disappears. The thumbprint is the "Thumbprint" entry when viewing the certificate in IE, or the "Certificate Hash" when viewed in IIS Manager. Make sure to remove the invisible character at the start of the thumbprint, if one's there, and remove all of the spaces between the pair of characters.

Or more specifically, a DDoS attack coming from compromised IP cameras took out Dyn, which is used by Twitter, Spotify, Reddit and many others for DNS. The devices appear to be part of a Mirai-based botnet, which is formed of compromised Internet of Things (IoT) devices.

This explains why Twitter wasn't accessible for a while yesterday, but there were some knock-on effects too. This web site of mine will periodically check Twitter for my latest tweets so they can be displayed on the homepage. Because Twitter was having trouble with their DNS provider, my home page would wait 10 seconds before giving up, which meant a 10 second delay before my web page would be displayed. In theory my site should fall back to a cached copy of my tweets that I store locally in a database (partly for this reason, partly to keep things quick, and partly to limit the bandwidth I use with Twitter). Unfortunately, when the connection failed (as my server couldn't resolve Twitter's domain because of the attack against Dyn) my code threw an exception and I hadn't handled the exception properly (or more specifically, at all). This meant the rest of the page content didn't load, which would result in invalid HTML5 output as I hadn't closed a few tags (e.g. body and html), plus most of the content would be missing. I now handle the exception properly, and if it fails to resolve (after 4 seconds now, as 10 seconds felt like forever) the rest of the page should return properly. I've done some testing and I'm pretty confident all is well now, but hopefully Twitter's DNS won't fail again so I might be fixing a problem that will never happen again.

Stuart Ashen is fundraising for Stand Up To Cancer. Donate to @ashens's JustGiving page: https://t.co/91IGqrccH9

Can't decide if I should try and buy the new Pixel phone or stick with my current one. Only the XL is really an imp… https://t.co/6PEX1nHcdm