Solved.
I haven't heard back from Microsoft Support since sending them my log files, but I got some time to take a look myself. Here's a relevant snippet:
+++++++++++ PT: Synchronizing server updates +++++++++++
+ ServiceId = {9482F4B4-E343-43B6-B170-9A65BC822C77}, Server URL = https://www.update.microsoft.com/v6/ClientWebService/client.asmx
Timeout for accelerated install is already set
WARNING: Cached cookie has expired or new PID is available
WARNING: PTWarn: Anonymous plug-in skipped for WU
Triggering accelerated install by calling UpdateNow
No installable updates are available
WARNING: Send failed with hr = 80072efe.
WARNING: SendRequest failed with hr = 80072efe. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
WARNING: WinHttp: SendRequestUsingProxy failed for <http://download.windowsupdate.com/msdownload/update/common/2009/06/2803268_2cf7737e73bd31ae709b14a95c8d2ecb7eccfbf3.cab>. error 0x80072efe
WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072efe
WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072efe
WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072efe
Note the failure to download http://download.windowsupdate.com/msdownload/update/common/2009/06/2803268_2cf7737e73bd31ae709b14a95c8d2ecb7eccfbf3.cab.
I tried to download this CAB file from a browser, which didn't work. I then tried wget (in cygwin) which didn't work and reported "Connection reset by peer". I also had the same problem downloading the CAB file from Linux machines on my home network, so it was not an issue with the Windows machines themselves.
To cut a long story short, I finally tracked down the problem to my router, which is running DD-WRT.
Apparently I must have enabled the "Filter ActiveX" option about a month ago and forgotten that I'd done so.
Given the security problems with ActiveX, this sounds like a sensible option to activate, but upon reading the help... not so much!
Filter ActiveX
Blocks HTTP requests containing a URL ending in ".ocx" or ".cab".
Yes... that would certainly cause problems! Unticking this and applying the settings to the router has cured the problem on both of my Windows machines, as you'd expect.
Thanks everyone for your help & suggestions, hope this is of use to someone else.
RDP 8.1 (latest version) attempts to do DPI-scaling redirection (match the DPI on the server side with the DPI on the client side). This only works if the session that is started on the server side is a new session. Why? Unfortunately, DWM (window manager) and explorer can not change the DPI dynamically (it requires a logout).
So, the "solution" that you can try is to log in, open CMD, run logout, wait until it logs you out and then attempt an MSTSC connection again. This should give you a new session and once MSTSC connects to the machine, it will "remote" the DPI settings, thus making things look normal.
There are cons to this:
- you lose your existing session
- it takes time to do this
- when you will login locally to the server, everything will be tiny :) (because the DPI settings persist - so you will have to login again :( )
Best Answer
See How do I reset Windows Update components?
The page may pop up a generic 'Fix General Problems' in front of that page. If so, run that first, then this one. I've known it take 2 attempts before it works.