Based on the experiences of the other people who have already replied on this thread (including a clean install and re-update that failed again!), we don’t think performing a RESTORE and re-running Windows Update would result in any different outcome.

After installing the 12/12/2017 Quality update on 4 different PC’s, we believe the installation problems are being caused by different versions of the Windows Update Client software.  Please read the following carefully to see why we have reached this conclusion.

PC BUILD NUMBERS BEFORE AND AFTER 12/12/2017 QUALITY UPDATES

We have 4 Windows 10 PC’s.  Two of them installed the Fall Creators update (V1709) on 11/14/17, and the other two installed the Fall Creators Update on 12/9/17.  The V1709 Build number was NOT the same between these two groups.  The two PC’s that had the later Build of V1709 did NOT report the installation error on the 12/12/2017 Quality Update, and they appear to be functioning normally.

Build Status Before and After 12/12/2017 Quality update:

Computers A and B – Version 1709 Build 16299.64 (Installed 11/14/2017) updated to Build 16299.125, but reported an installation error code of 0x80070643 on the KB4054517 Cumulative Update.

Computers C and D – Version 1709 Build 16299.98 (Installed 12/9/2017) updated to Build 16299.125 without any installation errors reported on any of the 12/12/17 Quality updates.

Note that even for the two PC’s reporting error code 0x80070643, they ALL now display the SAME Build number (16299.125) after the 12/12/2017 Quality update.

DIFFERENCES IN QUALITY UPDATE PROCESSES BASED ON PREVIOUS BUILD NUMBER

During the 12/12/2017 Quality Updates, we observed VERY significant differences in the update sequence and messaging, depending on the pre-update Build number.  This leads us to believe that the Windows Update software being used was different for Build 16299.64 versus 16299.98.

Here are some of the major differences we observed between the “.64” updates and the “.98” updates:

DIFFERENCES IN UPDATE PROCESS

The “.98” updates followed the “normal” progression we’ve observed over the last two years for cumulative updates – namely after pressing “Restart Now”, it works on updates through 30%, does a Restart, works on updates 30-100%, then displays lock screen.

The “.64” updates followed a much different sequence and displayed a host of messages that were new to us.  They worked on updates through 30%, then did a Restart, then displayed messages like “Stage 1 of 2 – Working on Features”, “Stage 1 of 2 – Getting Windows Ready”, “Stage 2 of 2 – Setting Up Updates”, and “Stage 2 of 2 – Working on Updates” and then did ANOTHER Restart and worked on updates from 30-100%.

Once the “.64” PC’s displayed the lock screen, our first entry of the password was ignored, and we saw circling dots on top of our lock screen picture.  On both “.64” PC’s we had to enter the password a second time before the Desktop was displayed.

The “.64” PC’s required that the Flash Player patch KB4053577 be installed during the Restart, but the “.98” PC’s were able to successfully install that patch BEFORE the Restart.

NETWORK DISPLAY ISSUES AFTER THE QUALITY UPDATE

Immediately after the updates, the two “.98” PC’s (now on “.125”) could see all 4 computers and our router’s READYSHARE when displaying “Network” in File Explorer.  But the two “.64” PC’s didn’t display any LAN PC’s in File Explorer -> Network.

Even though File Explorer -> Network was not displaying other PC’s correctly on two of the PC’s, ALL of our PC’s COULD actually access each other after the updates.

NOTE:  After we did some manual file accesses between PC’s on our network, one of the two “.64” PC’s eventually DID start displaying all of the PC’s on our LAN Network.  We noticed that it now had a Windows Service running called “Net.Pipe Listening Adaptor”, but that same service is NOT running on the “.64” PC that still doesn’t display all the other PC’s on the LAN in File Explorer -> Network.  We have not tried starting this “Net.Pipe Listening Adaptor” service on that PC, but we’d be willing to try that!

CONCLUSIONS

We think that V1709 Build 16299.125 has essentially been installed on all 4 PC’s  and they are functioning fairly normally.  But perhaps some .NET module may NOT have been installed or started up quite properly on the “.64” PC’s, resulting in the 0x80070643 error code.

Based on the experiences of the other people who have already replied on this thread, we don’t think performing a RESTORE and re-running Windows Update would result in any different outcome.