Windows Updates

[billtodd]

Interestingly, when I manually applied the updates that I thought might be significant only the WMP 6.4 updates created compressed uninstall folders in \WINNT, which might suggest that the WMP 9 and DX9 updates actually were correctly applied by HFSLIP but simply not recognized by Windows Update as having been applied until I reapplied them individually. But the root certificates update failed to be recognized by WU even after I had applied it manually (behavior which I've encountered before): only asking WU to apply it made it recognizable the next time WU ran, though I suppose it's possible that the version which I downloaded using the link in the September list on 10/7 might have been superseded in the interim.

For what it may be worth. Thanks again: this sure beats applying the whole post-Update-Rollup-1 (or even just the post-usp5.1) bunch manually to multiple systems, especially given that I like to know exactly what's on them rather than just give WU its head and let it apply everything.

- bill

Edited October 15, 2009 by billtodd

[tommyp]

Is it possible that some of the newest updates didn't include whatever it takes for Windows Update to recognize that they've been applied? 954155, 968816, 973540, 971633, and 952069 are listed as missing despite the fact that I included them in my \HF input to HFSLIP.

The (optional) root certificates update (also included) came up missing as well. Is this expected behavior (I think I've seen that happen after I manually installed that update)?

Several WMP 6.4 updates are listed as missing despite the fact that I slipstreamed in WMP9. I realize that I can probably just ignore them (unless somehow WMP 6.4 is still lurking in my system somewhere and creating a latent vulnerability if I leave it defenseless), but is this expected behavior from HFSLIP (I tried to search this topic for '6.4' but for some reason just kept getting sent to the main forum page)?

I tend just to ignore updates to things like Remote Desktop Connection, Message Queue, and Active Directory that I never plan to use (or even install), which sometimes leads to strangeness (e.g., 937894 listed as missing but not the more recent 951071 which replaced it or the even more recent 971032 which replaced that). Should this be any cause for concern?

Pure curiosity question: 926122 is listed as missing - a server update which I really wouldn't expect my ancient ThinkPad 570E would require. I remember seeing that pop up missing on one other desktop system once, and never on any others: anyone have any idea why?

Thanks for any insights,

- bill

Bill - thanks for pointing this out. I had a little "operator error" when making my 2k updates earlier this week. You identified the 926122 error. The update will be posted shortly.

The WMP updates are a little strange. Please tell me - are you slipstreaming WMP9? Or are you just slipstreaming the WMP9 codecs? This will help me try to tailor the script so it picks and chooses the right binaries. I just want to iron out the MSI stuff before I start tackling this prob. I'd rather do one fix at a time as my coding skills are rusty.

[jvidal]

Hi, everyone.

BTW, The XP list is outdated, IE8-KB972260 was replaced by IE8-KB974455.

And several others...

bye!

[billtodd]

Yup - I'm slipstreaming WMP9 (MPSetup.exe is included in \HF for the run). In addition to the 4 WMP-related updates that I had slipstreamed but which WU thought were missing (954155, 968816, 973540, and 952069) and the WMP 6.4-related updates that I had not included at all, 3 other WMP-related updates that I did include seem to have been recognized by WU as being there (975025, 969878, and 911564 - plus of course MPSetup.exe itself) - perhaps the result of the inconsistent naming practices that you mentioned.

WU also thought that the DX9 update (971633) which I had included in \HF along with directx_9c_redist.exe was missing. The root certificates update as well, but another post here seems to suggest that a new version of that may have appeared since I captured the one from the September list (since I already had it in \HF this possibility didn't cross my mind when I was updating the \HF contents for October or even when I re-applied the same update manually after WU listed it as missing - duh).

As I mentioned those 4 slipstreamed but unrecognized WMP updates plus the one for DX9 did not generate compressed uninstall folders in \WINNT when I applied them individually after WU thought they were missing - just in case that helps diagnose what's happening.

As for 926122, I'm pretty sure that WU has identified this (apparently server-only) update as missing on only the ThinkPad 570E plus one of the many desktop systems that I've installed Win2K on. Wonder what triggers that.

Just out of curiosity, if I remove *all* WMP9-related material (including MPSetup.exe) and all the WMP 6.4 updates from \HF, then after having installed the slipstreamed system use Add/Remove Windows Components to remove WMP (if indeed that option is available with WMP 6.4/WMP 7.1), then install MPSetup.exe and all the WMP9-related updates, should that exorcise all traces of WMP 6.4/WMP 7.1 from my system? (The list preamble states that "Windows 2000 comes with WMP 7", so it's not clear why 6.4 is there at all.) I'm not sufficiently into paring fat from the system to explore the nLite possibilities, but for some reason find this particular redundancy vaguely annoying.

From my point of view given that there are so few WMP updates that need to be applied just leaving them out of the list and letting us apply them after installation (as is required with other products such as .NET) would be reasonable if figuring out what to do with each one individually is a recurring problem. In any event, thanks for your continuing efforts.

- bill

P.S. Yet another random question:

After installing the system there's an HFSLIP entry in Add/Remove Programs. Is this just an artifact of the installation which can be removed?

P.P.S. 891122 appears to be a DRM 'enhancement' that some might consider to be junk (I didn't include it in \HF), even if it happens to contain useful codecs as well. Microsoft's WMP codec installation packages can be downloaded from http://www.microsoft.com/windows/windowsme...ecdownload.aspx

Edited October 16, 2009 by billtodd

[tommyp]

Holy run on sentences! lol!! If you feel like troubleshooting windows malware player hotfixes, here what you can do. Install a program called installrite on a clean install. Check things with WU (do the custom) to see what hotfixes are not applied correctly. Do not let WU install the fixes. Next, exit out of WU. Run installrite, do a snapshot, install the problem hotfix and then compare what files/registry has changed. Sometimes a binary may be swapped or addes somewhere else. Sometimes, WU wants to see the same file in multiple locations, esp with windows malware player binaries. The locations would be sys32 and PF\WMP. Personally, I don't particularly care for WMP. All you really need is codecs and any media player. WMP is garbage. There's plent of others that a far superior. Both winxp and w2k come with wmp6. 2k has wmp7 which would only be installed if said so on your winnt.sif file. xpsp3 has wmp9 (?) that is only installed if said so on the winnt.sif file. By SS WMP9 on 2k, the winnt.sif file will install wmp9 instead of 7. I'm not too sure how to answer your install this and uninstall that and what is left over. I guess you can try it out and see what happens.

As far as the DX9 hotfix goes, make sure you are using the DX9 hotfix. The file is named Windows2000-DirectX9-KB971633-x86-ENU.exe. Note that it says directx9 in the filename. If you have the wrong file there, then obviously WU will report an error.

[billtodd]

I suspect that if you consult a grammarian you will find that my sentences, while perhaps too long for some tastes, do not qualify as run-on.

I don't use WMP but my wife and daughter do, so I keep it up to date for them. It might be best just to leave its updates completely out of the list (save possibly for MPSetup.exe) rather than just let the chips fall where they may: while I won't presume to speak for anyone else as I said that works fine for me (I'll let you know how removing the old WMP before installing WMP9 works out).

Windows2000-DirectX9-KB971633-x86-ENU.exe was indeed what I had in \HF.

You may have missed my last edit (P.P.S.) above regarding 891122 and applicable codecs. I've tried removing HFSLIP with Add/Remove Programs and will see how that goes.

- bill

[tommyp]

I didn't forget to address the 891122. Look 4 or 5 posts up. Please keep in mind that I was running some beta tests on the MSI installer and wanted that resolved before I started addressing WMP probs ane WMP codec probs. I did mention a test you can run to help troubleshoot and provide a list of what should be replaced that isn't replaced. Once I know that, I can automate things. If not, when I get some free time, I'll have to run various cases of WMP and VMs to see what's happening for myself.

[billtodd]

Are you by any chance confusing 891122 with 926122 (which you indeed did mention a few posts up)?

As for the details of what's happening with WMP hotfixes, I had no idea that incorporating them involved so much manual detective work (let alone whatever it may take to transform the results of that detective work into a working HFSLIP install). Given how easy it is just to install them after the HFSLIP installation is complete, and the likelihood that every new WMP hotfix will create a new puzzle to solve, and the fact that most new WMP hotfixes simply replace previous ones (hence would not add to the post-install update effort), just leaving them out of the HFSLIP list strikes me as by far the most reasonable approach.

In that regard I hope that it's now clear (if it wasn't before) that I haven't been trying to rush you to incorporate any such changes (nor the DX9 change if that's similar in nature): I've only been trying to give as much information about what happened as I could glean to give anyone who might be affected a heads-up and help if/when you decide whether to tackle this issue (plus asked a few random questions that you might know the answer to off the top of your head - again, I wasn't requesting that they be researched).

- bill

[billtodd]

Well, 'removing' WMP6 in Add/Remove Programs after a non-WMP9 installation doesn't do squat in terms of removing anything: it just hides it - and not all that well, since Windows Update still lists its related patches as missing (thanks for introducing me to InstallRite, by the way). And after installing WMP9 and all its relevant updates those WMP6-related updates are still listed as missing, so there's apparently nothing to be gained by not installing WMP9 with HFSLIP. Whether all the related updates - including those for WMP6 - should also be included in the slipstream is more debatable: Windows Update doesn't recognize that they've been installed and if you want to keep WU quiet they must be installed later manually, but since doing this doesn't generate compressed uninstall folders in \WINNT there's a bit less cleanup afterward. I'm leaning toward doing everything but the actual WMP9 installation afterward, if for no other reason than that it's about as easy and doesn't leave any disturbing questions about what is actually happening.

Incidentally, 891122 doesn't show up as a missing update (critical or otherwise) when WM9Codecs9x.exe and the other WMP-related updates are installed. And removing HFSLIP from Add/Remove Programs after the installation didn't cause any obvious problems.

- bill

[tommyp]

I'm coming down the home stretch with W2K WMP hotfixes and a new beta that addresses them. Turns out that most of the media type updates are codec related. Give me a little bit more and I should have things resolved. Today I've run the script and tested the resultant iso 10 times and my PC is tired, and so am I.

On a sidenote, the current rootsupdate can be downloaded from here:

http://www.microsoft.com/downloads/details...49-a00e01e22f17

I think the next round of roots updates should be here: http://support.microsoft.com/kb/931125

I'm not 100% sure, but I think that running this inf file will kill 958470 from showing up with WU in W2k.

[Version]
signature="$Windows NT$"
ClassGUID={00000000-0000-0000-0000-000000000000}
SetupClass=Base
LayoutFile=layout.inf

[DestinationDirs]

[DefaultInstall]
AddReg	= add.reg
DelReg	= delreg


[Add.reg]
	HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%SP_SHORT_TITLE%","DisplayIcon",0x00020000, "%windir%\System32\msiexec.exe"
	HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon","BufferPolicyReads",0x10001,1
	HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{7584c670-2274-4efb-b00b-d6aaba6d3850}"
	HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{7584c670-2274-4efb-b00b-d6aaba6d3850}","Compatibility Flags",0x00010001,0x400
	HKLM,"SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{7584c670-2274-4efb-b00b-d6aaba6d3850}","AlternateCLSID",0x00000002,"{6A6F4B83-45C5-4ca9-BDD9-0D81C12295E4}"
	HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{9059f30f-4eb1-4bd2-9fdc-36f43a218f4a}"
	HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{9059f30f-4eb1-4bd2-9fdc-36f43a218f4a}","Compatibility Flags",0x00010001,0x400
	HKLM,"SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{9059f30f-4eb1-4bd2-9fdc-36f43a218f4a}","AlternateCLSID",0x00000002,"{971127BB-259F-48c2-BD75-5F97A3331551}"
	HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{4EDCB26C-D24C-4e72-AF07-B576699AC0DE}"
	HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{4EDCB26C-D24C-4e72-AF07-B576699AC0DE}","Compatibility Flags",0x00010001,0x400
	HKLM,"SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{4EDCB26C-D24C-4e72-AF07-B576699AC0DE}","AlternateCLSID",0x00000002,"{54CE37E0-9834-41ae-9896-4DAB69DC022B}"



[Strings]

ServicePackSourceFiles  = "Windows 2000 Hotfix Source Files"
SP_SHORT_TITLE		  ="KB958470"
SP_TITLE				= "Windows 2000 Hotfix - KB958470"
SERVICE_PACK_NUMBER	 =5
SP_TITLE_NEW			= "Security Update for Windows 2000 (KB958470)"

I'm not sure why the lines have line breaks, anyone know how to turn off the line wraps?

[billtodd]

Just a couple more oddities observed while running the current release (1.7.8):

The second entry in svcpack.log is

x86GetSourceArchitecture: Invalid handle for file: E:\OSKITWin2KReinstallKit\HFSLIP\SP\i386\mp\dosnet.inf

Does that sound OK?

At one point during the procedure (I didn't find this in either log file) a message to the effect that a valid iso9660 .iso image could not be produced apparently because some support file controlling use of Joliet (I think) extensions was not found appears on the screen. The .iso can still produce a bootable and usable installation disk (WinMerge validates that its data content matches the SOURCESS source) but ISOburner produced a disk on which ISObuster couldn't checksum a couple of the last sectors (could just have been a defective disk) and while InfraRecorder produced a disk that ISObuster could checksum the checksum didn't match that of the input .iso file, which leaves me wondering whether some additional .iso-creation file is missing (beyond bbie.exe, cygwin1.dll, and mkisofs.exe, which are there).

FWIW,

- bill

[tommyp]

Sorry, but I'm not too sure of svcpack.log. Is that file on the installed OS or in some folder on the install disk? I'll assume for now that you installed windows and the E drive is your CD. Looking at E:\OSKITWin2KReinstallKit\HFSLIP\SP\i386\mp\dosnet.inf doesn't quite make sense. Typically there isn't an "MP" folder, or at least I've never seen an MP folder. Dosnet.inf should be in the i386 folder.

The files I have in my hftools follow. If I rename zcdimage.exe to cdimage.exe, then cdimage is used to create the image. Both methods make the same file, so I always have an option to use either. cdimage take precedence for making ISOs, but if it's not there, it uses mkisofs.

bbie.exe

bbie.lic

boot.bin

boot.img

cmdow.exe

EXTRACT.EXE

HFANSWER.INI

mkisofs.exe

mkisofs.txt

modifype.exe

MSICabExtract.exe

MSICabExtract.txt

Reg.exe

ZCDIMAGE.EXE

FWIW, my hfanswer.ini has this:

FORCECDIMAGE=

CDIMGSW=-h -j1 -m

MKISSW=-relaxed-filenames -d -D -N -J -no-emul-boot -no-iso-translate -boot-load-size 4

[billtodd]

Sorry, but I'm not too sure of svcpack.log. Is that file on the installed OS or in some folder on the install disk?

svcpack.log is generated by HFSLIP in its main directory (\HFSLIP in my case) when HFSLIP is run. Its first line is

Service Pack started with following command line: -u -n -o -q -s:"E:\OSKITWin2KReinstallKit\HFSLIP\SOURCE\"

I'll assume for now that you installed windows and the E drive is your CD.

In this case the E: drive is the one containing the HFSLIP directory structure set up by hfslip-1.7.8.cmd which it then uses to generate a slipstreamed installation.

Looking at E:\OSKITWin2KReinstallKit\HFSLIP\SP\i386\mp\dosnet.inf doesn't quite make sense. Typically there isn't an "MP" folder, or at least I've never seen an MP folder. Dosnet.inf should be in the i386 folder.

Beats me: it's HFSLIP that's apparently looking for it during its processing. Didn't find the string '\mp\dosnet' with a quick search of the .cmd file, but the apparent error notation in svcpack.log seems to suggest that it wanted this and didn't find it.

The files I have in my hftools follow. If I rename zcdimage.exe to cdimage.exe, then cdimage is used to create the image. Both methods make the same file, so I always have an option to use either. cdimage take precedence for making ISOs, but if it's not there, it uses mkisofs.

bbie.exe

bbie.lic

boot.bin

boot.img

cmdow.exe

EXTRACT.EXE

HFANSWER.INI

mkisofs.exe

mkisofs.txt

modifype.exe

MSICabExtract.exe

MSICabExtract.txt

Reg.exe

ZCDIMAGE.EXE

All I have in \HFTOOLS are the three files that I placed there (bbie.exe, cygwin1.dll, and mkisofs.exe) plus the BOOT.BIN file that the installation places there - which I think is everything that the instructions at http://www.hfslip.org/ told me to place there.

FWIW, my hfanswer.ini has this:

FORCECDIMAGE=

CDIMGSW=-h -j1 -m

MKISSW=-relaxed-filenames -d -D -N -J -no-emul-boot -no-iso-translate -boot-load-size 4

Your instructions at http://www.hfslip.org/ under the 'Extras' heading say that all those are the default values (in which case I shouldn't need to have that answer file to cause them to be used, should I?).

Incidentally (there always seems to be one more question to ask) I just noticed that generating the installation seems to have added three .cabs to \HFCABS (_IE6_HFSLIP.CAB, _IE6b_HFSLIP.CAB, and _OE6_HFSLIP.CAB) - but not updated them (at least according to their modification dates) since the first slipstreamed installation that I generated. I understood that the \SOURCE directory had to be cleared and repopulated for each run - is this also true of \HFCABS (and any others)?

- bill

[tommyp]

Those _*.cabs are created to speed things up if slipstreaming ie6 on a 2k source. The files inside them won't update because the ie6 cabs weren't updated. There's no need to clear them, unless you want to (hfslip will just recreate them). There's no need to delete anything in hfcabs, hf, hfsvcpack* or any other folders. However, you should delete obsolete files obviously. You do not need to clear the source folder either. The script will clear and recreate the sourcess folder on each run. One little pet peeve I have with 2k vs xp is that when copying files from a cd to a hard drive, on a 2k box the files have a read only file attribute. This does not happen with xp. It would be beneficial to clear the read only attribute to the 2k source files.

It sounds like you using a pre-sp4 source. If you are, just include the SP4 and hfslip will slipstream the source directly with sp4. This is OK. There's no need to delete source after slipstreaming sp4. This will save time too. As far as the svcpack.log and mp\dosnet.inf files go, it could be an artifact of microsoft's sp4 slipstreaming routine. I can't say exactly though. I haven't slipstreamed a pre-sp4 source in many years.

[billtodd]

Our Win2K systems date back to 2001, when SP1 was what the distribution disks came with. A quick check with WinMerge suggests that what's happening to the \SOURCE directory is that SP4 is being slipstreamed into it, before all the other updates get slipstreamed into \SOURCESS. As long as that won't confuse HFSLIP when it gets run again with W2KSP4_EN.EXE still in \HF even though \SOURCE already has the SP4 updates it's understandable why \SOURCE doesn't have to be refreshed each time - one less step in the process (two less if HFSLIP also cleans out \SOURCESS before reusing it).

Whatever errors may or may not be occurring don't seem to have compromised the result, which installs and runs just fine. Thanks again for helping me understand things a bit better.

- bill