whelkman

I worked around this issue by pulling SP3 from the HF folder then manually integrating it against SOURCE: WindowsXP-KB936929-SP3-x86-ENU.exe /integrate:c:\hfslip\SOURCE I subsequently ran HFSLIP as normal plus WMP11 Slipstreamer, DriverPacks, and nLite. The image built, burned, and installed as I expected.

I had a problem with read-only in the past, but there must have been some intermediate warning prompting me to fix it. Now I remove the gray check mark on the HFSLIP directory after copying source. Interestingly, SOURCESS somehow gets a gray read-only check all on its own. TXTSETUP.SIF is not marked as such. In fact, from what I can tell, only the folders themselves have the check; I can't locate a single-read only file.

After slipstreaming a Dell SP1a source with HFSLIP 1.7.8 and TommyP's set, I discovered I could not integrate Media Player with the WMP 11 Slipstreamer. While diagnosing the problem on the WMP Slipstreamer forum, we discovered that apparently TXTSETUP.SIF was not updated along with the Service Pack; pretty much all references within were to SP1. I inserted a previously created HP OEM CD that was updated from SP2 -> SP3 via HFSLIP, and its TXTSETUP.SLF looked correct. Therefore, either I'm doing something wrong, or HFSLIP isn't a fan of this particular Dell version. I tried the procedure several times, and I completely obliterated the existing folder structure before my final attempt. HFSLIP otherwise runs normally. It takes as long as it should to complete and doesn't output any errors that I can see. nLite recognizes the HFSLIP output as SP3, but I'm betting the image wouldn't install were I to burn to CD. Thanks for any suggestions. I attached HFSLIP.LOG in case it is of use. Referenced WMP 11 Slipstreamer thread: http://www.boooggy.org/forum/viewtopic.php?f=12&t=83 HFSLIP.zip

As reported elsewhere, the culprit appears to be KB945432, a "security" patch for Office 2003 SP2/SP3. Sources indicate that uninstalling the patch resolves the issue. Alternatively, our organization has thus far met with success by changing Entourage's attachment default to MIME.

Pengo, Thank you for your diagnosis; you saved us significant work. Information for others who may find this thread: The problem is not totally consistent. Picture and Fax viewer works normally on my workstation (with administrative access), but JPEGs sent from our Entourage-using department fail everywhere else tested (with no administrative access). Additionally, it seems some JPEGs work and others fail; I don't have enough data for further diagnosis. With one particular JPEG, Windows 2000 could not display it in IE6 SP1+patches or Imaging but could with Microsoft Office Picture Manager 2003 with SP3+patches applied. Other JPEGs fail everywhere. I do not have a suitable explanation as to why this has happened. A process that has been in place for years has suddenly broken. My best theory is that either Microsoft has recently changed their JPEG rendering library or Outlook's attachment behavior. On affected computers, the issue is shared between 2000 and XP and shared, at least, between IE6 SP1, IE 7, Firefox 2, Imaging (2000), Picture and Fax Viewer (XP), and Paint. We did not test behavior with IE8, Firefox 3, or Windows Vista. Since I believe several programs in that list have independent JPEG rendering libraries, it would appear to be a new flaw in Outlook's attachment behavior.