Various problems with installing updates

[Preyr]

0) MSSE, WMF, WD, WLE were installed successfully.
1) The installation of service pack is reported as "failed" but it is indeed installed (DoUpdate detects SP1, it is listed in "Installed updates" and mentioned in the system information).
2) Only VCPP 2012 x86 and x64 got installed.
3) There were only 29 installed updates (most probably the prerequisites for what got installed).
4) I ran "../../cmd/InstallOSUpdate.cmd *" from "w61-x64/glb" and it installed a whole lot of updates before I interrupted it. I also installed several VC redists without issues.


What I discovered thus far:
1) SetSystemEnvVars.cmd does not contain any "CPP_xxxx_xxx" variables.
2) ListInstalledUpdateIds.vbs lists installed updates correctly (I checked the .txt file which it creates)
3) ListMissingUpdateIds.vbs does not create "MissingUpdates.txt" at all (I inserted the "pause" command in DoUpdate.cmd right after

Code: Select all

%CSCRIPT_PATH% //Nologo //B //E:vbs ListMissingUpdateIds.vbs %LIST_MODE_IDS%

)
I removed "/B" option right now and I saw this in CMD output:

Code: Select all

H:\upds\wsusoffline\client\cmd\ListMissingUpdateIds.vbs(17, 1) (null): The digital signature of the object did not verify.

Attaching the log, the client folder with truncated updates, the determined system options : http://filebin.net/dug3g1fz3e

[Preyr]

LMAO

http://www.davidegrayson.com/signing/
>SHA-1 phase-out
> The article Windows Enforcement of Authenticode Code Signing and Timestamping from Microsoft describes how SHA-1 will stop being supported in various ways in Windows 7. On 2016-01-01, those versions of Windows will stop trusting code that was signed with a SHA-1 code-signing certificate and a timestamp of 2016-01-01 or later. On 2017-01-01, SHA-1 will be restricted further, but the article uses confusing language and it is hard to tell exactly what they are talking about. Also, once SHA-1 preimage attacks are possible, Microsoft will restrict its use even further. To avoid these problems, it might be best to start using SHA-2 for everything, including the file digest, main certificate, timestamp digest, and timestamp certificate.


Yeah, that must be it. The wsusscn2.cab is indeed signed with SHA-1 even though it was downloaded long after 01.01.2016. So, what should I do for it to pass?

Still cannot get a clue about why CPP absence is not detected.

[aker]

1) Fresh installation of Windows or with integrated SP? [assuming, you are using Windows 7 x64]
2) wsusou will just UPDATE C++, not install it. You may install it using the executables inside .\client\cpp
3) Did DoUpdate.cmd say "Nothing to do" or did it tell you to reboot the system and recall the update afterwards?
4) manually calling "InstallOSUpdate.cmd" might result in unintended behaviour and won't get any support here. It sounds like it tried to install all updates inside your repo, ignoring, if required or not.

Problem with wsusscn2.cab's signature: try installing http://download.windowsupdate.com/msdow ... otsupd.exe

[boco]

wsusscn2.cab is dual-signed, once with SHA1 and once with SHA256 (SHA2). If you see only the SHA1 signature then you are missing important Windows Updates.

KB3033929 and maybe KB2763674

[Preyr]

I now checked the log and I see that WSUSOU installed something new upon every launch until I ran "InstallOSUpdate *". It did not say to recall it during last runs it so I thought that something was wrong.

1) No integrated SP (SP0 detected upon the first start)/
2) Oh, did not think about it. There are several products which might be installed: WLE, WD, MSSE, why not give user an option of installing VC++ libs too?
3) DoUpdate said to reboot and recall once or twice, but no more after that, I rebooted and recalled it on my own.
4) I am not expecting any support on blind install, I just said that many updates installed without problems. I checked the InstallOSUpdate.cmd before running it, it can do no harm because it only calls standard Windows tools for installing. Windows won't accept the incompatible or already installed update, it won't try to reinstall the update as well.

wsusscn2.cab is dual-signed, once with SHA1 and once with SHA256 (SHA2). If you see only the SHA1 signature then you are missing important Windows Updates.

Yes, this might be the case.

Interesting thing: I cannot find any mention of "3033929" in "client" folder (searching file contents). So: it seems that WSUSOU would never install any dynamic updates because it will never preinstall the KB3033929 which is required for wsusscn2.cab timestamped after 01.01.2016 to be loaded. I may confirm it after I roll back my Windows installation just to be sure.

[WSUSUpdateAdmin]

Hi.

[...]So: it seems that WSUSOU would never install any dynamic updates because it will never preinstall the KB3033929 which is required for wsusscn2.cab timestamped after 01.01.2016 to be loaded.[...]

May I ask where you got this information from?
I can neither find it on https://support.microsoft.com/en-us/kb/926464 nor on https://support.microsoft.com/en-us/kb/3033929.

Regards,
T. Wittrock

[boco]

@Admin:
From site https://www.globalsign.com/en/blog/micr ... ng-policy/

Windows 7 and later platforms will stop accepting SHA-1 Code Signing Certificates after January 1 st , 2016. Software developers may need to use both SHA-1 and SHA-2 certificates depending on the target platforms.

https://social.technet.microsoft.com/wi ... in_General

[Preyr]

Now I am not sure in that failure of verification was caused by SHA-1 deprecation. Let me speculate: it looks like SHA-1 deprecation was introduced by some update and Windows 7 won't invalidate SHA-1 signatures just because of timestamp more recent than 31.12.2015. I will retry installing updates without KB3033929 sometime later.

In my specific case the failure seems to be caused by the wsusscn2.cab integrity itself - both signatures (SHA256 revealed after KB3033929) appear invalid, yet both signatures of some downloaded updates which I checked are OK. I redownloaded wsusscn2 (relaunched the collection tool) it and updates install just fine now.

BUT: judging by the logs I can say that the file which I used before SHOULD work.

download.log:

08.02.2016 8:47:46,53 - Info: Verified digital file signatures of Windows Update Agent installation and catalog files

hashes-wsus.txt (calculated at the download time):

%%%% HASHDEEP-1.0
%%%% size,md5,sha1,sha256,filename
## Invoked from: C:\Users\LIL\Desktop\4save\updates\wsusoffline\client\md
## C:\Users\LIL\Desktop\4save\updates\wsusoffline\client\md> ..\bin\hashdeep64.exe -c md5,sha1,sha256 -l -r ..\wsus
##
7749976,b46c93117c07626bebc7af83a7562034,fc0ee3a9af88ef2237aac450bc94b2fc08af79f5,d500a5b5945fafc6a52fb54b7169b62c6c1137e1694184ff2eff790aa1394ece,..\wsus\WindowsUpdateAgent30-x64.exe
6776168,f723820b8656e82958fa7ed854a7eefe,50186ec913a4896a92d72e5e5384693bf3a71182,b2512e0c2786f72ed41559580261c782a13fb5ea7fe23878873f83ecaeeec25f,..\wsus\WindowsUpdateAgent30-x86.exe
154503008,8dbcf49b8743df29d854870c08ab9ebe,d4d2aff053328b3fff8ead3e5c2e2af31ba96698,a8fd301e9d558e4cc93ffec3af78aec128b6625be2370f5940f69187258edca6,..\wsus\wsusscn2.cab

hashdeep64 output (manual recalculation):

h:\upds\wsusoffline\client\bin>hashdeep64.exe -c md5,sha1,sha256 %temp%\wsusscn2.cab
%%%% HASHDEEP-1.0
%%%% size,md5,sha1,sha256,filename
## Invoked from: h:\upds\wsusoffline\client\bin
## h:\upds\wsusoffline\client\bin> hashdeep64.exe -c md5,sha1,sha256 C:\Users\ani\AppData\Local\Temp\wsusscn2.cab
##
154503008,8dbcf49b8743df29d854870c08ab9ebe,d4d2aff053328b3fff8ead3e5c2e2af31ba96698,a8fd301e9d558e4cc93ffec3af78aec128b6625be2370f5940f69187258edca6,C:\Users\ani\AppData\Local\Temp\wsusscn2.cab

So: WSUSOU checked the digital signature and it did verify (according to the logs).

Yet, the sigcheck output:

c:\users\lil\appdata\local\temp\w\wsusscn2.cab:
Verified: The digital signature of the object did not verify.
File date: 8:51 08.02.2016
Publisher: n/a
Company: n/a
Description: n/a
Product: n/a
Prod version: n/a
File version: n/a
MachineType: n/a

Or, the CSV output:

"c:\users\lil\appdata\local\temp\w\wsusscn2.cab","The digital signature of the object did not verify.","8:51 08.02.2016","n/a","n/a","n/a","n/a","n/a","n/a","n/a"

NOW, the quote from DownloadUpdates.cmd:

Code: Select all

...............
if "%VERIFY_DL%"=="1" (
  if not exist ..\bin\sigcheck.exe goto NoSigCheck
  echo Verifying digital file signatures of Windows Update Agent installation and catalog files...
  ..\bin\sigcheck.exe %SIGCHK_COPT% -s ..\client\wsus >"%TEMP%\sigcheck-wsus.txt"
  for /F "tokens=1 delims=," %%i in ('%SystemRoot%\System32\findstr.exe /I "Unsigned" "%TEMP%\sigcheck-wsus.txt"') do (
    del %%i
    echo Warning: Deleted unsigned file %%i.
    echo %DATE% %TIME% - Warning: Deleted unsigned file %%i>>%DOWNLOAD_LOGFILE%
    echo File signature verification failure >"%TEMP%\sigerror-wsus.txt"
  )
  if exist "%TEMP%\sigcheck-wsus.txt" del "%TEMP%\sigcheck-wsus.txt"
  if exist "%TEMP%\sigerror-wsus.txt" (
    if exist ..\client\md\hashes-wsus.txt del ..\client\md\hashes-wsus.txt
    del "%TEMP%\sigerror-wsus.txt"
    goto SignatureError
  )
  echo %DATE% %TIME% - Info: Verified digital file signatures of Windows Update Agent installation and catalog files>>%DOWNLOAD_LOGFILE%
...........

WSUSOU does not check the verification of the cabs, it just checks whether they are signed or not. It would be nice if WSUSOU checked not just the presence of signature but the "Verified" status.

[Preyr]

Will it change?

[aker]

You'll have to wait for WSUSUpdateAdmin to read this topic.