1.4.3 Issues

[PVU]

For the most part, my recent installs worked out with 1.4.3. However, on two Win2K installs, I produced the following errors:

1. WU asked for Windows2000-KB917008-x86-ENU.EXE
   
2. dotnet11sp1.exe - not found/not installed
   
3. vbrun60sp6.exe - - not found/not installed
   

The KB917008 was a bit of a mystery as it was the only HF item flagged by WU. I don't think the file is corrupt - I got the same result on 2 different computer installs with 2 distinct filesets.

The files in the HFSVCPACK folder were weird in that DOSHERE.INF and tweakui.exe installed, but the other 2 did not. The dotnet11sp1 is from RyanVM.

See the attached HFSLIP.LOG. In the i386/SVCPACK folder of the ISO/disk created with WinISO, there are "~" abbreviations. For instance: DOTNET~1.EXE, VBRUN6~1.EXE and some others. Is that normal?

The source folder contains normal files. Only the WinISO created ISO/disk contains the abbreviated files. However, the KB917008.CAT file in the ISO (disk) I386\SVCPACK was not abbreviated.

[The attached HFSLIP.LOG was modified only to remove notes I made at the end of the log to note failures]

HFSLIP.7z

[Tomcat76]

1. WU asked for Windows2000-KB917008-x86-ENU.EXE
   

Are you installing the MUI CD? This hotfix was a pain to code in. It contains many files that surpass the 8.3 file naming standard.

In the i386/SVCPACK folder of the ISO/disk created with WinISO, there are "~" abbreviations. For instance: DOTNET~1.EXE, VBRUN6~1.EXE and some others. Is that normal?

The source folder contains normal files. Only the WinISO created ISO/disk contains the abbreviated files. However, the KB917008.CAT file in the ISO (disk) I386\SVCPACK was not abbreviated.

That's most surely the problem. The original filenames are hardcoded into HFSLIP.CMD so if they are renamed by whatever tool you use to create the ISO, they will not be found anymore during installation. I suppose KB917008.CAT is not renamed because it follows the 8.3 file naming standard.

I have switched to UltraISO a long time ago but I'm sure WinISO should have a setting to disable automatic file renaming.

[PVU]

1. WU asked for Windows2000-KB917008-x86-ENU.EXE
   

Are you installing the MUI CD? This hotfix was a pain to code in. It contains many files that surpass the 8.3 file naming standard.

I'm not sure what MUI CD is, but from what I just googled (language changing/setting tool), I pretty sure the answer is "no".

In the i386/SVCPACK folder of the ISO/disk created with WinISO, there are "~" abbreviations. For instance: DOTNET~1.EXE, VBRUN6~1.EXE and some others. Is that normal?

The source folder contains normal files. Only the WinISO created ISO/disk contains the abbreviated files. However, the KB917008.CAT file in the ISO (disk) I386\SVCPACK was not abbreviated.

That's most surely the problem. The original filenames are hardcoded into HFSLIP.CMD so if they are renamed by whatever tool you use to create the ISO, they will not be found anymore during installation. I suppose KB917008.CAT is not renamed because it follows the 8.3 file naming standard.

I have switched to UltraISO a long time ago but I'm sure WinISO should have a setting to disable automatic file renaming.

Okay, that explains why IE has been acting a little off (and it seemed as if WU was struggling also).

Here is a list of the SVCPACK renames:

• DOTNET~1.EXE should be dotnet11sp1.exe
  KB8324~1.CAT should be KB832414_Win2K.cat
  KB8938~1.CAT should be kb893803v2_w2k.cat
  KB9054~1.CAT should be kb905414.cat
  KB9236~1.CAT should be KB923689.cat
  KB9280~1.CAT should be KB928090-IE6SP1-20070125.120000.cat
  KB9299~1.CAT should be kb929969-ie6sp1-20061220.120000.cat
  MSDRMC~1.MSI should be msdrmclient.msi
  MSXML2~1.CAT should be msxml2-kb887606-enu.cat
  RMCLIE~1.MSI should be rmclientbackcompat.msi
  VBRUN6~1.EXE should be vbrun60sp6.exe
  

I'm not using VM. Do you think I could simply manually reinstall those hotfixes again, or do you think the entire install is suspect - would you start over?

WinISO allows you to rename individual items, but I can't see that you can apply a global-type setting. I'm a little lazy (too ), so I'll check out Ultra ISO, but this might be a good time to just go with the HFSLIP ISO burning sollution.

Thanks

[Tomcat76]

I wouldn't trust that installation (source) too much. Files may have been renamed in other places as well.

[PVU]

TC, I used UltraISO (should have saved the HFSLIP ISO because it created an ISO without issue). I'm still running into the same problem, but not to the same extent. dotnet11sp1.exe was renamed DOTNET11.EXE (did not install), vbrun60sp6.exe was renamed VBRUN60S.EXE, Media Player 9 was not installed, and I'm still getting the KB917008 WU issue.

In UltraISO, do you need to uncheck "Recompile ISO when Saving Directly" under Config?

The renaming was not as severe, but there were some instances. There were no "~" renames - I should have checked it before the install. My next shot is to burn the HFSLIP ISO.

[johndoe74]

you can instead use nlite to create the ISO. that's what I do after hfslip has completed its magic. that combo works perfectly for me

[PVU]

Postscript:

Not really sure what happened with WinISO or UltraISO, but they were the problem. With the UltraISO try, I was working off a re-compiled ISO image originally created by WinISO, and that could have been a problem.

At the very least, I'd leave WinISO in the bag.

The HFSLIP ISO image creation option worked flawlessly. Everything in SVCPACK installed without issue, and I had no KB917008 issue this time around. WU crapped out on me the first 2 times, but that's probably WU's issue.

john, I was headed there next...

TC, thanks.

I should re-name (hahaha!) this topic, "Trouble with ISO Software"

[Tomcat76]

Which problem specifically? WU getting stuck?

Sometimes (not always) it is necessary to start IE, close it, then start it again in order for WU to work properly the first time.

Also, you need to wait until the site loads completely before clicking the button to start the check. Failure to do so may result in the following issues:

- WU doesn't check your system

- closing IE takes longer than expected

- you need to log off & log back in (or reboot) to have WU working again

The latter doesn't apply to IE7 in my experience (only IE6 and below).

These are general problems that are not related to HFSLIP.