• Unidentified Windows Update process

    An interesting observation from Noel Carboni:

    UPDATE Noel notes: It turns out ctldl.windowsupdate.com is a legitimate security check:

    https://technet.microsoft.com/en-us/library/dn265983.aspx

    Why Explorer did it is still a bit of a mystery, and it’s not from Classic Shell as it turns out I had the Classic Shell auto-update check already disabled on the Win 7 system.

    Perhaps the expiration of a certificate invoked this behavior on all systems.

    Another tiny piece in a very big puzzle…

    In the past day I’ve observed my Windows 7, 8.1, and 10 systems all doing something uncommon:

    My firewall blocked all these systems from communicating withctldl.windowsupdate.com.  Specifically, it’s Explorer.exe doing the trying.  Normally I do not see these different systems all do something similar like this at nearly the same time, and Explorer.exe only VERY rarely communicates online.  Curious, eh?

    Know that I have everything set as manual as possible on all three of these systems.  Beyond the WU settings, I have Windows Update completely disabled and of course the firewall in place to block comms that are not explicitly allowed (and without reconfiguration, which I do when requesting updates, Windows Updates are not allowed).

    Explorer itself is not normally in the habit of communicating online much at all, which makes these observations stand out.

    These are excerpted from my DNS server logs, coincident in time with thewindowsupdate.com checks.  The other DNS resolutions for the Windows 7, 8.1, and 10 systems around the same times as the ctldl.windowsupdate.comchecks are listed in respective order.

    DualServer20160419.log:[19-Apr-16 17:55:59] Client 192.168.2.44, crl.microsoft.com A resolved Locally to 23.14.84.171

    DualServer20160419.log:[19-Apr-16 17:55:59] Client 192.168.2.44, ctldl.windowsupdate.com A resolved Locally to 96.16.98.112

    DualServer20160419.log:[19-Apr-16 23:41:06] Client 192.168.2.32, crl.usertrust.com A resolved from Forwarding Server as 178.255.83.2

    DualServer20160419.log:[19-Apr-16 23:41:07] Client 192.168.2.32, ctldl.windowsupdate.com A resolved Locally to 96.16.98.112

    DualServer20160420.log:[20-Apr-16 08:31:49] Client 192.168.2.26, ctldl.windowsupdate.com A resolved Locally to 96.16.98.112

    DualServer20160420.log:[20-Apr-16 08:31:49] Client 192.168.2.26, ocsp.startssl.com A resolved Locally to 23.14.84.171

    DualServer20160420.log:[20-Apr-16 08:31:49] Client 192.168.2.26, www.classicshell.net A resolved from Forwarding Server as 184.168.173.1

    I don’t think this is triggered by Classic Shell itself, which is installed on all three systems, since only one of the them actually checked classicshell.net, and it may just coincidence just because those were times the systems were logged-in.

    I am imagining some kind of internal update process that’s occasionally kicked off inside Explorer itself.  I’ll be asking on the Classic Shell forum about this.