Microsoft Update & WGA issues

[Tomalak]

Hello all,

Returning to hfslip after some time and going back from 2.0 to the current 1.7.8 beta (version 'm' of June 6th), I experience some trouble now - or maybe I'm just too tired . Anyway, maybe you can help me with the things I apparently did wrong... I haven't found time yet to read through all the threads of the previous weeks and months to see whether there are some tips hidden in them (hfslip.org is vastly outdated).

Most of the patches I included have been integrated perfectly (at least the security relevant ones, still have to check the optional ones), but some failed and I don't know why:

1) Although all necessary cab files (as mentioned e.g. in the thread with the updates) are put into the HFCABS directory, I have to install Microsoft Update when first visiting the update site. For some reason the muweb_site.cab (together with muauth.cab and mucatalogwebcontrol.cab) is not considered.

2) MU also complains about missing WGA and wants to perform a KB892130 install first before I can do the update check. I've excluded the respective file as I have a legitcheckcontrol.cab (with a more recent version of the dll) in the HFCABS folder. I'm pretty sure this worked in the past - has this changed? Do I indeed have to include both?

3) KB905474 (WGA Notification) is also reported as missing although the appropriate file "WindowsXP-KB905474-DEU-x86.exe" is in he HF directory. After the first attempt failed, I renamed the file to end with "-standalone" as I found this name in the hfslip source, but this didn't change anything. I know this is not an essential update, but nevertheless it bothers me that it shows up in MU. That's why I wanted to have it included, and as far as I can remember this also worked some months ago without problems.

Nothing special regarding my setup, but if required I can still provide the logfile of course.

After these issues have been resolved, I'll probably soon come back with more questions regarding some optional updates. But as these are more "for fun" than really required to be slipstreamed, I'll open a separate thread for them if necessary.

Thanks for you help!

Tomalak

[Tomalak]

[updates]

* 2009/10/11: Items 10 and 12 resolved, solution added below.

* 2009/10/13: Item 07 obsolete. Other topics that changed during the last days (due to new hfslip versions available) will be updated in the post below soon.

* 2009/10/14: Item 11 solved, instructions added how to handle that. Now obsolete items 7, 10 and 12 greyed out.

[/updates]

Hello all,

Answering myself... As announced above, I did some more tests with current hfslip and the mandatory security patches as well as several optional updates. The goal was to have MU/WU completely satisfied at the end (which I did not accomplish, read on for the details). Here are my findings, in the hope that they might be of help for some of you.

Good news first:

1) In general most updates get treated correctly. Even those who do not really contain files and are mostly designed to change registry settings are processed correctly. This includes the time zone updates (most recent one: KB970653 (v3)) and the ActiveX killbits updates (most recent one: KB973525, showing a "0 files" message during the hfslip run which is okay). So just include them in HF, nothing special to consider here.

Then there are, for the interested amongst you, some general notes on a few particular updates:

2) KB892130 did not pose a problem, including it in HF gave no complaint afterwards from MU/WU. The file contained ('legitcheckcontrol.dll' in version 1.7.69.2) is outdated so theoretically this update is not required, however for some reason it has be included...

3) 'legitcheckcontrol.cab' is not required in HFCABS. The version available here is 1.9.9.1 whereas the most recent one is 1.9.40.0 (this comes with KB905474, see also below the section with problematic updates).

4) KB967715 (autorun correction) contains only an outdated file ('shell32.dll' version 6.0.2900.5622) which is replaced by KB971029 ('shell32.dll' version 6.0.2900.5853), but it is still required as it sets an important registry setting for the autorun feature to be actually disabled. Thus omitting it from the HF folder results in an appropriate entry in MU/WU - just include both updates and everything is fine.

5) Renaming the file 'SmartCard_XP_x86.exe' of optional update KB952013, available here to 'WindowsXP-KB952013-x86-xxx.exe' is enough to make it work in HF.

6) On the contrary this does not hold true for file 'IMAPI_XP_SRV2003_x86.exe' of optional update KB952011, also available here. Renaming it to 'WindowsXP-KB952011-x86-xxx.exe' and putting it to HF has no effect: there is a "0 files" message during the hfslip run, and afterwards the three files 'cdrom.sys', 'imapi2.dll' and 'imapi2fs.dll' still all have version 5.1.2600.5593 (at least if KB932716 (v2) is included which is the case for me).

So I put this update to HFSVCPACK_SW1 (there you can also store it with its non-standard original name). Now the following happens: 'imapi2.dll' and 'imapi2fs.dll' (directory 'system32\drivers') are updated to version 6.0.6001.18164, and 'cdrom.sys' is still the one mentioned above from KB932716. But in directory 'system32\dllcache' you'll find 'cdrom.sys' in the very old version 5.1.2600.3126 (SP3 comes with 5.1.2600.5512!). No difference if put to HFGUIRUNONCE, so this does not matter.

It's up to you whether you want to have this included. Anyway, it's a very strange update, with two files being current ones with high version numbers, and on the other side one file being completely outdated. Maybe just Microsoft knows the purpose of this (although I seriously doubt that).

tommyp, is it possible to deal with this exception in hfslip?

7) If you want to include KB958911 (more stable version of 'gdiplus.dll'), do _not_ put it into HF! This results in a critical error, see attached image, and will abort the installation. Putting it in HFSVCPACK_SW1 is fine.

tommyp, any chance to have a look on this? This is not really important, I know, but it may to indicate a flaw within hfslip.

Update 2009/10/13: Irrelevant now. Most recent 'gdiplus.dll', version 5.2.6001.22319, is now contained in KB958869 (MS09-062). Attachment with screenshot has been removed.

8) If you include KB968389 and want it to be effective, do no forget to include the appropriate registry file in HFSVCPACK (mentioned and available here under item 5). This is not set by the update itself (another Microsoft caprice, by the way)!

9) The strange 'tweakui.exe' issue, described as item 2 here is still valid. I have to use the escape key to skip the message, but the file is present later on. This one really puzzles me, but I guess I just have to live with the fact that I have to press one additional key during the textmode copy phase for no apparent reason...

And finally there are some really problematic updates where I'd like to see a solution. There are workarounds for them, but they fill up the list of installed software, and I do not consider that as "clean"):

10) MU still does not work when running it the first time in a new installation, for some reason I have to do that manually. This is the same issue as described in my initial post above as item no 1. If even included a newer 'muauth.cab' (will mention that in the respective sticky thread as well so MuppetHunter can update his link), but to no avail.

tommyp, is it possible to investigate? This worked in the past, but for some reason MU is nowdays again quite touchy. I think others described this as well, but I cannot find the appropriate thread now.

Update 2009/10/11: Problem solved by using updated 'muweb_site.cab' (see list maintained by Mupper Hunter). No other corrections necessary.

11) Even more annyoing (in my eyes): the stubborn update KB905474 (German version, don't know the direct URL of the English one). I know, many consider WGA notifications as unnecessary and will avoid it, but for completeness' sake I want to have it included. As I own a legitimate Windows version I do not have a problem including it. But it refuses to cooperate...

Putting the original file in HF or HFSVCPCK_SW1 was useless. After analyzing the update I discovered it has an unusual format - you can extract it and then you get a file called 'wganotifypackageinner.exe' which is the actual update in the standard format. I renamed it accordingly (also described by fz500 here) and tried it both in HF and in HFSVCPACK_SW1, but again without success.

In HFGUIRUNONCE it works of course, but it's ugly. And tricking Windows to consider it as installed with this registry file by Acheron is a hack only.

tommyp, again my plea to have a look on that and to fix it if possible. I know I'm nasty

Update 2009/10/14: More or less solved now. Procedure to integrate KB905474 properly (with some drawbacks, see below):

1. Download the Microsoft package for KB905474 for your language, the German one is deep linked above. Could be identified by just searching for it in case this information has already been published for your language, or by having a look at "WindowsUpdate.log" after KB905474 has been installed once via MU/WU. Maybe some friendly folks here could provide the download locations for other languages also?
   
2. As already described above: extract this package and get the file "wganotifypackageinner.exe" from it. This is the actual update, in the usual format with standard structure which is expected by hfslip.
   
3. Rename that to "WindowsXP-KB905474-x86-<LANG>.exe" and put it to HF. Thereby all contained files ("wgatray.exe", "wgalogon.dll" and, most important, the current version 1.9.40.0 of "legitcheckcontrol.dll") can be found at the correct locations in your installation after Windows setup.
   
4. Put the attached registry file to HFSVCPACK. This one entry makes MU/WU believe you have KB905474 installed properly and it won't complain any longer.
   

That's it. Note that this may not be totally the same as putting the patch to HFGUIRUNONCE in the first place which apparently does more, e.g.

• adding some more registry entries, some of them visible from Acherons post
  
• storing "wganotify.cat" in Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}, don't know how important that is
  

But it is sufficient to have the most recent "legitcheckcontrol.dll" in your system, enabling WGA protected downloads from MU/WU, and at the same time keeping MU/WU silent. What more do we want?

12) Last issue: MSI installer 4.5 (KB942288) won't integrate.

When put to HF, exactly nothing happens, after Windows installation still version 3.1 is present in the system.

When put to HFSVCPACK_SW1 only some of the files are updated to version 4.5.6001.22159 (namely 'msiexec.exe', 'msimsg.dll' and 'msimsg.dll.mui') while others remain in version 3.1.4001.5512 ('msi.dll', 'msihnd.dll' and 'msisip.dll'). This results in a broken installer, so do _not_ do that!

With HFGUIRUNONCE it works, but again this is the possibility I dislike (although the registry file mentioned by Lions here is then not necessary).

Anyway, if you additionally include the optional KB958655 (v2) which contains an improved 'msi.dll', you have to put it also in HFGUIRUNONCE instead of HF or HFSVCPACK_SW1 as long as the problem above is not solved. Otherwise - I've tried it B) - you'll understandably run in all kind of problems with this mixed up installer, e.g. broken GUI elements in IE8, as some components are not installed cleanly during Windows setup...

tommyp, last question today : solving this would be really nice. Any intention to tackle it in near future? I'll try to support and test as far as my time permits...

Update 2009/10/11: To be solved as follows

1. Extract the update 'WindowsXP-KB942288-v3-x86.exe' to some temporary folder (parameter "/X:<PATH>") and get the file 'msimsg.dll.<YOURLANGUAGE>.mui' from sub directory 'SP3QFE'. Rename it to 'msimsg.dll.mui' (no language!) and put it to 'HFEXPERT\WIN\system32\mui\<LANGUAGECODE>' (list of valid language codes). Get rid of the tempory folder again, the other files are not needed.
   
2. Put 'WindowsXP-KB942288-v3-x86.exe' to HF as usually.
   
3. Remove the string '942288' from the definition of variable 'DefExcHF' in hfslip. This is valid as of version 1.7.9_beta_m (2009/06/06), line to be modified is 1473.
   
4. Optionally put update KB958655(v2) into HF as well.
   
5. Run hfslip. No issues experienced, should result in a working MSI installer 4.5 including display of help box.
   

Update 2009/10/14: Solved with hfslip version 'o' (beta 20091012a) which implements the steps above.

Wow, long post. Let's finish here for now.

Kind regards,

Tomalak

WindowsXP_KB905474_x86.reg

Edited October 14, 2009 by Tomalak

[tommyp]

Don't count on updates at the moment. Typically spare time is spent away from the computer, and yes, real life is far better than sitting in front of a machine coding for free.

Item 6 - This is an optional update. Typically optional updates aren't required. However, usually sys files are part of cab files. You can probably try choosing repacking of the cabs when running the program.

Item 7 - The link you provide says "This is a Customer Preview Release. At the conclusion of this preview phase, the final version of the update will be released via Windows Update" in the overview of the download. Because it's a preview, and non-mandated hotfix, you'll be on your own playing with microsoft alphaware. Once the article/download is mature enough to warrant a "critical" status, then we'll play things by ear and/or fix the script. I do not see the point of making hfslip work for microsoft alphaware at this point in time. In my opinion, just because microsoft offers a software, does not automatically mean it is functional and you are mandated to have it installed.

Item 9 - do you have modifype in the hftools directory?

Item 10 - I do not use windowsupdate & I haven't used it in many years. There are commandline alternates that provide the same info in a fraction of the amount of time. Please post what registry fixes and/or file fixes should be in place for MU to work.

Item 11 - Usually when unpacking troublesome hotfixes, the binaries are renamed to something else when installed into the OS. You can try using a program that examines what files are replaced and what registry additions are put in place when a program is installed. From there, you can see what files are replaced. I don't have the program name handy, but will post the program name it if you are interested in troubleshooting.

edit - the free software is called Installrite. You can see what files are swapped/replaced and what registry entries are created/removed. From the sounds of things, it sounds like the non-essential msft bloatware needs hardcoded fixes.

Edited September 30, 2009 by tommyp

[Muppet Hunter]

@ Tomalak

Does putting MSI 4.5 in HF with Lions' regfile not work for you?

[Tomalak]

Hello tommyp,

Don't count on updates at the moment. Typically spare time is spent away from the computer, and yes, real life is far better than sitting in front of a machine coding for free.

Okay, that's fine - you've set the right priorities.

Item 6 - This is an optional update. Typically optional updates aren't required. However, usually sys files are part of cab files. You can probably try choosing repacking of the cabs when running the program.

I don't fully understand that - what should I repack (in which cab? It's an ordinary update executable), and when (which program you mean, the hfslip run)? Anyway, I don' think it's a real issue as the outdated file is only in the system32\dllcache directory.

Item 7 - [...] Once the article/download is mature enough to warrant a "critical" status, then we'll play things by ear and/or fix the script. I do not see the point of making hfslip work for microsoft alphaware at this point in time. In my opinion, just because microsoft offers a software, does not automatically mean it is functional and you are mandated to have it installed.

You're right. I usually follow very close the recommendations from the Patch-Info site, and it's included in the list of recommended updates there. But as there is the HFSVCPACK_SW1 workaround, this is not really a problem.

Item 9 - do you have modifype in the hftools directory?

Yes, I do, and it works fine for some other files (notepad replacement etc.) It's just that one file that refuses to cooperate. Strange, but let's forget it...

Item 10 - I do not use windowsupdate & I haven't used it in many years. There are commandline alternates that provide the same info in a fraction of the amount of time. Please post what registry fixes and/or file fixes should be in place for MU to work.

Phew, no idea. I just know that it worked in the past (but my last installation has been some time ago, and was based on hfslip 2.0), and now it doesn't. So I assumed that something has been broken in the recent betas.

Probably have to do some before/after analysis on a fresh installation when I find the time. Or do others here have an idea on what's going wrong?

Item 11 - Usually when unpacking troublesome hotfixes, the binaries are renamed to something else when installed into the OS. You can try using a program that examines what files are replaced and what registry additions are put in place when a program is installed. From there, you can see what files are replaced. I don't have the program name handy, but will post the program name it if you are interested in troubleshooting.

Same here. Looks like a standard update (once the inner package has been extracted as described), but it's not dealt with correctly. When I find the time (probably not before December) I will do a before/after comparison and inform you about changed files and registry entries.

Any remarks on item 12 (see also my answer below on Mupper Hunters question)?

Thanks a lot, kind regards,

Tomalak

[Tomalak]

@ Tomalak

Does putting MSI 4.5 in HF with Lions' regfile not work for you?

No, it does not. To be sure that this is not the result of some side effects, I even tried with no updates at all (just KB942288 in HF, the reg file in HFSVCPACK and wbemoc.cab in HFCABS as this is mandatory for SP3). Same result... File WindowsXP-KB942288-v3-x86.exe has also been re-downloaded just in case it was broken (which it was not, for comparison: MD5 is 448447e0ba4560cd558eddb5f5b0809e and SHA-1 is 86e1cc622dbf4979717b8f76ad73220cdb70400b).

Seems that hfslip does not even consider that update. Have a look at the attached log - I don't see it becoming extracted or any of the files being slipstreamed at the end.

Am I the only one having this problem? Are there any others out there at all that still use XP and hfslip?

Thanks for ideas,

Tomalak

hfslip_1.7.9_beta_m_Output.txt

HFSLIP.LOG.txt

[tommyp]

I extracted and checked out the msi v4.5 installer earlier this week. It's packed with every imaginable language! HFSLIP does not support this (neither does Nlite IIRC). Slipstreaming this is possible, but would be lots of work with no reward. I'd say that one possibility is to manually extract it, chose your language, rename the binaries and use the hfexpert directory option. Installation *could* fail though. I think that the windows xp setup routines kinda sorta needs the right msi binaries, but I could be wrong. I haven't tested the hfexpert msi method, but you are free to try it out.

Getting back to the item #6. When I say repack, I mean to chose packing option A, B or C (i.e. do not create an SPX.CAB file). A typical SYS driver is located inside drivers.cab. So, after chosing options A, B or C, the newer driver will be put into the driver.cab file.

As far as the WU goes, MSFT changes their mind on what registry info is present on the host OS for WU to work. I could have sworn that the CAB files or some hotfix added the necessary registry info into the install disk. If something needs to be hardcoded, I can add it in. Or perhaps it's just an outdated hotfix? I can't quite say what the answer is. I do know that msft likes to keep several versions of the same filename on their downloads available where only one of the files is the latest. Go figure. It could be as simple as a hyperlink pointing to an old version of an update on the hotfix page.

If you want to try something fun, search for a filename on the MSFT website. You'd be surprised at the lack of info you find. I especially like it when the pop up thing shows up asking if it likes the info shown. I've found that to properly search microsoft, you have to use google. Bantering off. lol

[Tomalak]

Hello all,

Made some progress... Here's a short update (well, not so short, have to give the story as it was some work to figure it out).

I extracted and checked out the msi v4.5 installer earlier this week. It's packed with every imaginable language! HFSLIP does not support this (neither does Nlite IIRC). Slipstreaming this is possible, but would be lots of work with no reward. I'd say that one possibility is to manually extract it, chose your language, rename the binaries and use the hfexpert directory option. Installation *could* fail though. I think that the windows xp setup routines kinda sorta needs the right msi binaries, but I could be wrong. I haven't tested the hfexpert msi method, but you are free to try it out.

Seemed a little bit too much work for me, and in this case all the details for the registry from the inf files etc. would not be considered. So I started by repacking the hotfix to a new package, putting just the correct files in it (for German language in this case) and rearranging the file and directory structure so it looks like any ordinary hotfix. Finally had a replacement executable, an "improved update". Only to find out, one hour later, that running the file with the "/Q /X:<Path>" flags does exactly the same anyway: it removes other languages and leaves you with something hfslip should be able to work with... Still didn't work, file was not used

And finally I found out why: KB942288 is simply blocked by hfslip itself! Didn't think of that possibility before, had no deep look on the code - and no one told me So after deleting the culprit, the six characters "942288" from the variable DefExcHF (line 1473), everything worked. KB942288 was slipstreamed, and I had a working MSI installer 4.5 after the setup of Windows. That also explains why it had worked before, but then stopped suddenly (at least for me, seems I'm currently the only one working with most recent hfslip beta): somewhen this update was added to the list of excluded patches...

But there's one subtlely: with my approach the file "msimsg.dll.<LANGUAGE>.mui" is not dealt with properly, so if you run 'msiexec.exe' afterwards, you get an empty help window as no translation is available. This can be resolved by putting the mentioned file, renamed to "msimsg.dll.mui" (no language identifier!), to the directory "Windows\system32\mui\<LANGUAGECODE>". <LANGUAGECODE> is 0407 for German, you may have to adapt that accordingly (a list of codes is easy to find).

Et voilà, first problem solved! Will add it to my post above as well so the solution is easy to find.

As far as the WU goes, MSFT changes their mind on what registry info is present on the host OS for WU to work. I could have sworn that the CAB files or some hotfix added the necessary registry info into the install disk. If something needs to be hardcoded, I can add it in. Or perhaps it's just an outdated hotfix? I can't quite say what the answer is. [...]

Well, I now can . No hardcoding necessary, it was indeed an outdated file. Took me quite an effort to investigate, but finally I discovered that the "muweb_site.cab" was not up to date. Got the most recent one (new URL, will post that in the main update thread), put it in HFCABS, and no complaint by WU anymore...

Et voilà, second problem solved!

Will tackle the remaining ones another time, enough for today. Hope that helps so far,

Tomalak

[tommyp]

Most excellent contribution. Thanks for the inputs. I think I have a way to automate this. The prob I have to deal with is that the installer is not expandable via a commandline when the host OS is 2000.

Edit - New beta is posted that hopefully slipstreams the 4.5 installer. It will ONLY work on an XP host machine that is slipstreaming XP.

Edited October 12, 2009 by tommyp

[Tomalak]

Hello,

I found out how to satisfy MU/WU so that it considers KB905474 (item 11) as installed and does not report it as missing when searching for updates. It's one single registry entry that has to be added (not all that are listed by Acheron here are really necessary).

Please see my updated post above for details. I think most of the 'open topics' I stumpled upon when returning to hfslip are solved now. Great!

Regards,

Tomalak

Update: Sorry, seems that MSFN currently ruins the URLs of links to other posts even though I entered them correctly...

Edited October 14, 2009 by Tomalak