Delivering win10 v1511 via WSUS 4 - how to?

I just replied to you in another question (you weren't the OP though) and the short answer is yes, I've succeeded in doing this and didn't do anything apart from what you have already listed. That patch is important, but beyond that it all tends to work. I think you'll have to resort to logs, although maybe someone else will pop in with a common misconfiguration I may not have seen or am have managed to forget....

One thing that might have bitten you. If you tried to deploy the win10 upgrade *before* applying 3095113,  you may have a bad download on the client. The transfer from server to client doesn't work right because file was processed before the patch was applied. To fix this:

On the server:
under IIS Admin->WSUS Administration->Content-> Click on "Mime Types"-> Add

File Mame Extention:  = .esd
MIME type:     application/octet-stream

On server and client:
Clear the SoftwareDistribution Download Cache under the Windows Dir and clear out the hidden $WINDOWS.~BT

That mime type fix was needed to download it to the client, indeed. It will never arrive at the client if you don't do that. The patch was installed before the wsus server was even downloading v1511.
Retrying the process now on 2 VMs (second, clean environment).

In case you got bit by this:

http://blogs.technet.com/b/wsus/archive/2016/01/30/quot-help-i-synched-upgrades-too-soon-quot.aspx

Again, it doesn't work.
Clean 2012 r2 with that patch installed before detecting and downloading the 1511 Win10 Pro update (retail). Clean win10 10240 client, client detects it from wsus, client cannot download it->Mimetype-fix ->download succeeds but installation fails right after download completion.

So no progress here. Logfileentry goes

*  START  *  Installing updates CallerId = UpdateOrchestrator
2016.02.02 02:46:09.7866561 800   4640  Agent           Updates to install = 1
2016.02.02 02:46:09.7887876 800   4640  Agent             Title = Upgrade to Windows 10 Pro, version 1511, 10586 - en-us, Retail
2016.02.02 02:46:09.7887928 800   4640  Agent             UpdateId = A62D6FE6-56C1-4701-870C-CAA1FA1B575D.201
2016.02.02 02:46:09.7887932 800   4640  Agent               Bundles 1 updates:
2016.02.02 02:46:09.7887957 800   4640  Agent                 5ACDB345-B2AB-4577-A845-A47025368F8C.201
2016.02.02 02:46:10.0333236 800   2260  Agent           WU client calls back to install call {D8BFE4A6-E262-480C-AA83-E7642991F437} with code Call progress and error 0
2016.02.02 02:46:10.0689085 800   4640  DownloadManager Preparing update for install, updateId = {5ACDB345-B2AB-4577-A845-A47025368F8C}.201.
2016.02.02 02:46:10.0694212 3568  4068  Handler         * START *   Windows Setup Install
2016.02.02 02:46:10.0694218 3568  4068  Handler         Updates to install = 1
2016.02.02 02:46:10.0742572 3568  4068  Handler         Starting Windows Setup with command line = C:\Windows\SoftwareDistribution\Download\fb62e6359af678adf6e3286f2af394f3\WindowsUpdateBox.exe" /ClassId 79da1d7b-444e-4209-add8-14b35e12d9de /ReportId {5ACDB345-B2AB-4577-A845-A47025368F8C}.201 "
2016.02.02 02:46:10.0742587 3568  4068  Handler         HandlerSecsInADay = 86400.
2016.02.02 02:46:10.0742593 3568  4068  Handler         Registering WinSetup COM server as CLSID {79DA1D7B-444E-4209-ADD8-14B35E12D9DE} and APPID {B0262106-E469-4253-AFDE-6797F12AED5A}
2016.02.02 02:46:10.0758615 3568  4068  Handler         Successfully registered WinSetup COM server as CLSID {79DA1D7B-444E-4209-ADD8-14B35E12D9DE}
2016.02.02 02:46:11.9153883 3568  3776  Handler         Requested file 10586.0.151029-1700.th2_release_CLIENTPRO_RET_x64fre_en-us.esd has no decrypt information
2016.02.02 02:46:12.0786571 3568  4068  Handler         Installer completed. Process return code = 0x8007007E, result = 0x8007007E, callback pending = False
2016.02.02 02:46:12.0797333 3568  4068  Handler         Exit code = 0x8007007E
2016.02.02 02:46:12.0797356 3568  4068  Handler         * END *   Windows Setup Install

Select allOpen in new window

No idea how that would work anywhere else. Please note the difference to win8.1 and 7, where it indeed started the installation and ordered a restart but never completed.

Any idea?

I read from others that they had the same problem after they redetected updates. The second revision of the 1511 update was buggy, while the first one worked. It seems, I cannot obtain the first one anymore.

As a policy, I don't use clients for testing, and for my labs all o have access to is MSDN or VL, not retail and English (u.s.) at that, but I'll build up a new clean lab and retest this upcoming weekend to see if I can reproduce that failure and then open a bug with MS. Anecdotally though, that error about no decrypt info would imply an issue with the WU client opening and processing the .esd file. That is consistent with corruot metadata in the WSUS database which can be fixed with the last link I posted. If I can reproduce the failure, I'll also test that as a potential fix. But again, I won't be able to test retail. Only VL.

Fine.

Did you read this https://social.technet.microsoft.com/Forums/windowsserver/en-US/0aee1e1c-c6e9-4efd-9ceb-e81d65d9f436/wsus-fails-to-download-windows-10-upgrade-files?forum=winserverwsus ?
Very different results is what people get. And the one at the end had never synced before applying the patch - just like me. I wonder what would corrupt the metadata. I will also try his fix now.

Madness continues.
The same WSUS that can update 10240 to 1511 cannot upgrade win8.1. The WSUS reports that the update is needed by the client but the client doesn't see it. Interestingly, when I use wuinstall.exe (3rd-party command line update installer), the update is seen and downloaded, but after installing for 20 minutes, it says it fails. Tried that on several 8.1.
I don't think I'll continue this route but instead script install those upgrades from an extracted ISO, that works flawless.

It seems MS hasn't provided a stable way to do this. Since for security reasons, the upgraded machines may not be unattended (people could press shift f10 during the upgrade and get a command prompt with system rights and compromise their own computers) anyway, we dropped the idea of using WSUS completely. Instead, we use startup scripts triggering \\server\share\setup.exe /auto upgrade