Here's a pre-alpha release of HFSLIP 2.0. Use at your own risk.

Suggestion: run it in a blank folder so the subfolders are created, read the changelog, populate the folders as necessary and run it again.

If you used a pre-alpha of HFSLIP 2.0 older than 80507a on Windows Server 2003 and you had it slipstream the DX9 extras, please check in the custom "DX9plus" cab package in the HF folder that there are no microsoft*.dll files in it. If there are, delete the cab package.

Main package:
hfslip-2.0.0pa_80630a.zip

Extras for HFCABS (download directly into HFCABS):
wbemoc.cab (required fix for problem with XPSP3; please remove previous HFSLIP32_POST_WBEMOC fix from HFTOOLS)
ieaccess.cab (a clean version of an updated ieaccess.inf for IE7 and IE8; to be used with HFSLIP 2.0 80515b or higher)

Plugins for HFTOOLS (extract into HFTOOLS):
HFSLIP32_PRE_WSearch40_v1.zip (Windows Search 4.0 plugin for HFSLIP 2.0 80608a or newer; put exe for XP or Srv2K3 in HF)
HFSLIP32_PRE_SWFlash9_v1.zip (SWFlash 9.0.124.0 plugin for HFSLIP 2.0)
HFSLIP32_PRE_TZ4_v2.zip (time zone plugin without tzchange.exe for HFSLIP 2.0)
HFSLIP32_PRE_TZ4_tzchange_v2.zip (time zone plugin with tzchange.exe for HFSLIP 2.0; XPSP2, XPSP3 & 2K3SP2)

Known issues:
- on Windows 2000, the DX9 redist is extracted every time; this is because HFSLIP doesn't yet create a custom cab package for the DX9 core for that OS
- HFCLEANUP is broken (this folder is not blocked, so rename it if you're using it for reducer files)
- Windows XP MCE 2005 is broken
- MPlayer.exe (WMP9), wmfdist.exe, wmfdist95.exe and KB891122 are not processed
- old HFSLIP_PRE* and HFSLIP_POST* plugins don't work; they need to be upgraded to support the new HFSLIP code
- *.EXT files are ignored; they will be replaced by plugins

IEACCESS.INF with IE7 and IE8:
To avoid potential issues, HFSLIP 2.0 will now always write an updated ieaccess.inf file in ANSI. In addition to this, for languages where a certain string in this file contains special characters, that string is rewritten in English so you will at least get a readable text.
ieaccess.inf is the installation file that Windows calls when you want to add or remove access to Internet Explorer when in the Add/Remove Windows Components dialog. The string that may contain special characters in certain languages concerns the tip you see when you highlight "Internet Explorer" in that dialog, so it's not really an issue. But if you prefer to have it clean, please use the ieaccess.cab package; if present in the HFCABS folder, HFSLIP 2.0 will use it instead of modifying ieaccess.inf by itself.

New "DX9CORE=FULL" setting in HFANSWER.INI:
On Server 2003, this tells HFSLIP that you want the DX9 core to be updated; if this variable is not set (or not present), only the DX9 extras are processed.
On Windows XP, this variable has no effect.
On Windows 2000, this has no effect yet.

New "UserFolder=" setting in HFANSWER.INI:
HFSLIP 2.0 places all HFSVCPACK, HFSVCPACK_SW1, HFFIRSTLOGON, HFFIRSTLOGON_SW1 and HFEXPERT\AUTOIT files except HFSVCPACK\*.cmd and HFSVCPACK_SW1\*.exe files into a folder in the root of the new source. By default, this new folder in the root of the new source is named $HFSLIP but you can change that with the UserFolder variable in HFANSWER.INI. For example: UserFolder=MyFiles. Any spaces are stripped out automatically (eg, "My Files" becomes MyFiles).


Changes marked in this color are changes relative to the HFSLIP 2.0 test releases, not HFSLIP 1.x. They will be removed overtime to avoid confusion.

Changes 80630a:
- fixed a problem with the way CMD files in HFSVCPACK are handled

Changes 80620a:
- testing workaround for copy error with napprov.mof (and napschem.mof) in network-based installs
- new source language detection method based on mfc42*.dl_

Changes 80612a:
- cumulative ActiveX KillBits are force-added by HFSLIP so it isn't needed to include the current hotfixes (KB948881 or KB950760); to override this behavior, specify NoKillBits=YES in HFANSWER.INI
- [2K3] GdiDetectionTool registry hack is no longer added (because it isn't needed)

Changes 80611a:
- added support for KB951376 for Windows XP (Windows Update wants to see bthport.sys in system32\drivers but it's not installed by Windows setup by default)
- added support for new XAPOFX binary in June 2008 DirectX9 Redist
- added support for Windows Installer 4.5 for XPSP2, XPSP3 and 2K3SP2 (requires recent 7za.exe in HFTOOLS)
- handling of Windows Installer 4.5 now requires 7za.exe in HFTOOLS no matter what the host OS is to bypass corrupt localized CAT files

Changes 80608a:
- allowed "%ProgramFiles%\Windows Desktop Search" as destination folder at T-28 for plugins
- blocking WindowsSearch*.exe updates so they aren't processed automatically
- names of new binaries slipstreamed by HFSLIP are shown in HFSLIP.LOG (this replaces the old getnewfiles plugin)

Changes 80605a:
- testing solution provided by Acheron to delete the temporary HFSLIP folder used during Windows setup

Changes 80520a:
- every extra file (HFSVCPACK, etc.) is no longer copied to hard disk first, but installed directly from the source (thanks to 7yler)

Changes 80519a:
- the "INSTALLRC" variable is no longer ignored, but its value should now be "YES" if you want the Recovery Console installed at T-13 (INSTALLRC=YES)

Changes 80515a:
- [IE7/IE8] an updated ieaccess.inf is now always written in ANSI instead of in Unicode to avoid potential issues with other programs (see "IEACCESS.INF with IE7 and IE8" above)

Changes 80507a:
- got rid of HFSLPGUI.INF (was used for post-logon installs)
- qmgr.dll from the BITS update needs to be in both the system32 and the system32\BITS folder; instead of duplicating the file, it is now just copied from system32 to system32\BITS at T-13
- [Win2K] added support for sp4supporttools.exe if placed in HF (needed to work around the mess with netdiag.exe)
- [Win2K] mqrperf.dll is not slipstreamed for Professional (eg, KB937894)
- [Win2K] if MDAC 2.8 SP1 is slipstreamed, only MDAC281*.exe updates are handled; otherwise, only MDAC253*.exe updates are handled
- [Win2K] if IE6 is slipstreamed, updates for IE5 and OE5 are blocked; otherwise, updates for IE6 and OE6 are blocked

Changes 80501a:
- HFEXPERT\AUTOIT files are placed in the SOURCESS\<UserFolder> folder like SVCPACK and 1st logon installs

Changes 80430a:
- added support for new XAudio2*.dll binary in March 2008 DirectX9 redist
- custom cab packages are created in the HF folder for the DX9 core and the DX9 extras (if applicable) which will be used instead the next time HFSLIP is run; if a newer redist is included, only the updates are processed and a new cab package is created for the DX9 extras
- introducing "DX9CORE=FULL" setting in HFANSWER.INI (see above for details)

Changes 80428a:
- removed support for XP SP1, 2K3 Gold and 2K3 SP1; an HFSLIP version specifically meant for XP SP1 will be released later
- removed support for Windows Media Player 10
- removed support for IE7 SVCPACK and GUILOGON modes
- removed support for HF\BASIC; put these files in HF
- KB898461 (Package Installer) and KB898543 (WMP11 slipstreaming fix) are only processed if the OS is XP SP2; they must be in the HF folder, not in HF\NOREG
- enhanced slipstreaming of WMP11 into Windows XP
- fixed (and allowed) slipstreaming of IE7 into Windows Server 2003
- introducing slipstreaming of IE8 beta 1 into both Windows XP and Windows Server 2003 (IE8 is slow to start the first time)
- slipstreaming WMP11 for WinXP into Server 2003 is possible, but Microsoft Update will be much slower and won't display any updates that might exist for it; also, updates for WMP11 cannot be manually installed on Server 2003 (you'll have to make a new source and install Windows again each time)
- new binaries collected from updates are slipstreamed faster into the new source
- the HFSLIP folder path can now safely contain spaces; the short path name (8.3 standard) is used wherever necessary
- in AUTORUN mode, it is no longer necessary to seperately set the COMPMEM and MULTICAB variables; just set DRIVERCOMP as usual
- HFGUIRUNONCE folder is now named HFFIRSTLOGON
- introducing new HFFIRSTLOGON_SW1 folder for Type 1 hotfixes and *.MSI files that need to be installed at first GUI logon
- HFSVCPACK_SW2, HFFIRSTLOGON and HFFIRSTLOGON_SW1 folders are not created automatically
- introducing new folder in the root of the SOURCESS folder for most SVCPACK and 1st logon installs

Some neat changes in the 2.0 series, Tomcat76. Thanks for all your hard work!

Hello Tomcat76,

First of all: thanks for your continuing support, development and all the effort put into hfslip! It's really appreciated!

Found the time today to test the new hfslip version (2.0.0pa_80508a), together with a Windows XP Professional SP3 (integrating the service pack was done before, not by hfslip). It worked almost perfect, except two minor issues I experienced - and these may not even be related to hfslip at all:

1) After the installation, Windows Update (and the MBSA) complained about a missing patch, KB941569 (MS07-068). I don't understand that because according to Microsoft's own list of fixes included in SP3 (KB946480) this patch should be already in there. Maybe this is a result of integrating WMP11?

2) During the textmode phase of the setup, the copy routine gave a message like "tweakui.exe copied erroneously" (or similar, was a German message for me). I included 'tweakui.exe' in HFEXPERT\WIN\system32, together with a reg file 'tweakui.reg' in HFSVCPACK - this has always worked with hfslip 1.x in combination with SP2. The strange thing is that the file was not skipped - it was present in Windows later on, and I could use it as expected, no problems. Just this strange error at installation time that I simply had to ignore...

Please find the corresponding log file attached. I have no idea where these two issues come from: the new hfslip version, the new SP3, or something completely different... Thanks!

Kind regards,
Tomalak

KB941569 is sort of a cumulative update in that it contains different versions of the same binaries. SP3 obviously doesn't contain the WMP11 versions.

I don't know. It could be that the file isn't 100% compatible with SP3, or that modifype needs to be run on it. Do you have the same problem when updating XPSP3 using HFSLIP 1.7.6rc7?

Yep, my bad, haven't seen that. I will include it in my next test install.

Any idea when you will find the time to update the patch list on your homepage for SP3 as it is final now? I figured out most of the necessary updates myself (and, well, reading other lists ), but these obviously didn't catch KB941569 yet. WU/MU and MBSA are satisfied now (with all the patches included in the logfile I posted), but I'm not sure whether I still miss something. What about the updates for MSXML2 (KB887606) and MSXML4 (KB941833) - are they still necessary? I could only find references to MSXML3 in the changelog (= list of included patches, KB946480) for SP3...


Tested all combinations today: hfslip 1.7.6 (rc7) and hfslip 2.0 (pa8), with SP2 and SP3. The error always occurs, it's apparently not connected to SP3 or hfslip at all - I'm pretty sure it was not there during my last installation, but this took place some months ago, perhaps I changed something else in the meantime...
Anyway, as this is only a minor annoyance and not a real problem - as explained everything works after the Windows setup is finished - it's not necessary to analyze this further, as long as no one else experiences the problem, and in a more serious way.

Thanks a lot!

Tomalak

Will HFSLIP 2.0 still support the feature to install the Recovery Console for Windows XP? I tried this under XP SP2 using HFSLIP 1.7.6 but during setup I get some prompts (connecting to check for updates )

I'll post some screens later. I just post it here since I assume HFSLIP 1.x won't get updated anymore.

HFSLIP 2.0 is still a very long way to go, so 1.x is still being updated.

HFSLIP 1.x has the Recovery Console installed from a CMD file at T-13. The method only works for CD-based installs because I never found a way to poll for UNC paths simultaneously. It also requires the user to enter a multiboot path (if applicable) at the beginning of the HFSLIP run. Since I have eliminated all other needs for the multiboot path in HFSLIP 2.0, I decided to drop this feature in HFSLIP 2.0 until a better solution is found -- one which works for network-based installs too. If need be, I'll have it copy all files that are necessary to install the Recovery Console to hard disk (into the temporary %WINDIR%\HFSLIP folder) but then I first need to find out which files are needed.

If you have any issues with how the Recovery Console is being installed with HFSLIP 1.x, please start a new thread.

For the Recovery Console you could try this


Then your not dependant on a path.

You need to make sure i386\WINNTUPG exists, and contains the following 4 files:

CFGMGR32.DLL
NETMAP.INF
NETUPGRD.DLL
SETUPAPI.DLL

It should work at T-13 but havn't tested.

I'll be dxxxxx...

Do you happen to know whether "SourcePath" really is the PATH to the installation source, or that it's just the drive letter in every circumstance?

I'm asking this because in the case of a multiboot CD with D:\PRO\i386 and D:\ADV\i386 the path to the source would strictly speaking be "D:\PRO" or "D:\ADV" and not "D:\".

Corrent, "SourcePath" is the full path to installation source.

I've been using Mutliboot and it does point to the folder not the root. So for D:\PRO\i386 or D:\ADV\i386, "SourcePath" would be D:\PRO or D:\ADV.

At work we use Network installs and "SourcePath" points to the UNC Path.

Here's another Script I use if i what to copy SourceFile to the local drive.

Thanks for this. It's a really valuable tip, so you got yourself a spot in the hall of fame...

Every additional file is now installed directly from the source, except when it's determined at T-13 that there are spaces in the path to the source, in which case silent executables from HFSVCPACK and HFFIRSTLOGON are first copied to the hard disk and installed from there. This is because of a limitation with the START command; it appears it can't handle quotes if they follow it immediately.

Glad to be able to help in some small way.

I've gained a lot from looking at the HFSLIP scripts, with alot more still to learn. So very happy that i can contribute something.


I've had problems with START in the past were the following happerns:

START /WAIT "%~dp0SETUP.EXE" <-- does not work correctly
START "Install" /WAIT "%~dp0SETUP.EXE" <-- Works fine

Is it possible that START "%~dp0SETUP.EXE" is seeing "%~dp0SETUP.EXE" as the "title"

Therefore START "HFSLIP" "%~dp0SETUP.EXE" may work ...

Keep up the great work.

Heh... And start /? would've given me the same answer. That'll teach me...

Standalone executables are now installed like this: START/WAIT "" "%SRCPATH%<Userfolder>\filename.exe"

Seems to work just fine. Thanks again...

Just wanted to say thank you so much TC, for incorporating that 'install directly from source' feature

It's very much appreciated, mate


CU, Martin.

You should really thank 7yler for this...

Hi Tomcat, you didn't mention you updated the .NET Builder tool! Thank you very much. Will test it soon.

Other patches I have applied are removing all START/WAIT commands from the svcpack hfslip.cmd. In a batch file all commands are processed one after another. This has no side effects!

I have changed the recovery console install command to use the settings as specified in winnt.sif. In that file I specify that dynamic updates are disabled.



At line 533 I have replaced the REPLACE script with a script to not copy any hidden or system files or directories starting with a dot (UNIX equivalent of hidden file) to the CD.:

This allows me to use HFSLIP directly in subversion (I know I should use export )



I have also added a custom file RunHidden.exe to my CD to hide the SVCPACK hfslip.cmd. This file is placed in the SVCPACK directory (line 3766)



Runhidden is my own AutoIt written script that simply changes also working directory to the correct folder:



P.S. Can I switch to HFSLIP 2.0 now? Or is it still Alpha?

HFSLIP 2.0 is still pre-alpha, but I don't intend to make big changes to HFSLIP 1.x anymore.

Testing plugin for Windows Search 4.0 for Windows XP and for Windows Server 2003.

The plugin is to be extracted into the HFTOOLS folder and the exe goes in HF.
Make sure to use HFSLIP 2.0 build 80508a or newer.

Hello,

During some test installations I repeatedly received an error message at the beginning of the text mode copy phase (immediately after formatting the hard disk), see attached screenshot.

After a long and tedious testing phase with several hfslip runs I finally identified the culprit: KB942288 (Windows Installer 4.5), named "WindowsXP-KB942288-v3-x86.exe". Removing just this file from the HF folder makes the installation work again... I'm not sure whether this is a problem of hfslip 2.0.0pa only (tried 80608a, 80605a and xxx) - can someone reproduce the issue with hfslip 1.7.7? I'm not in the mood of running more tests now and already reorganized all my files to support versions 2.x only

Is it possible to support that specific update, Tomcat76, e.g. by another HFTOOLS plugin? And, note to my self: never test the most recent non-standard updates from MS if you don't want to go down the road of desperation

Kind regards,
Tomalak

What's "xxx"?

Windows Installer 4.5 is not supported by HFSLIP 1.x or HFSLIP 2.0 older than 80605a so you won't notice the problem there.

I'll look into it. I have an idea of the cause, but I must admit I didn't expect it. I only tested WI 4.5 with an English Windows XP source. I'll try with other languages now.

I tried a new installation test and i had the same problem Tomalak have. I also put the Installer 4.5 (WindowsXP-KB942288-v3-x86.exe) into HF directory. I was trying 80605a... Is this problem fixed in 80608a?

I'm using Windows XP Italian. I assume that the Installer is multilanguage, as I don't see any "ITA" nor "ENG" nor anything else in the filename... Is it true?

The problem is that I was making use of destination folder ID's that apparantly only exist for English XP/2K3 sources. The next version will fix this.

But there's an additional problem. I tested it on a German Windows XP source and it appears the German security catalog file for this update is fubar; you'll get three errors reported in setuperr.log. To work around this, I will have to enforce the use of 7za.exe for Windows XP and Server 2003 host OS's as well in order to get the English CAT file in every circumstance. This is namely a special hotfix that contains INFs and CAT files for all languages Windows XP was released in, but normal extraction will only extract the INF and the CAT in the language of the host OS; eg, if the host OS is German, normal extraction will cause only the German INF and CAT file to be extracted. I can only get the English CAT file for non-English host OS's by using 7za.exe.

Also, by adding support for Windows Installer 4.5 I broke the handling of Windows Installer 3.1 for Windows 2000. In the mean time, you can get around this by placing 7za.exe in the HFTOOLS folder.

Problems should be fixed now with the latest test version.

I really enjoy using HFSLIP to create an XPCD. However to build such an CD costs about 20 minutes on my system. There is some time lost on copying everything from SOURCE to SOURCESS directory and after that some more time is waisted copying everything to the ISO.
I have two harddrives in my system, so I would like for example to have processed C:\HFSLIP\SOURCE to D:\SOURCESS and then copy the ISO back to C:\HFSLIP. This should really speed things up, since reading and writing to the same disc is very slow.

Can you add this feature to the HFSLIP answer file?

"Changes 80612a:
- cumulative ActiveX KillBits are force-added by HFSLIP so it isn't needed to include the current hotfixes (KB948881 or KB950760); to override this behavior, specify NoKillBits=YES in HFANSWER.INI"

Is there a way to add this into hfslip 2.x?

I made a Testinstall XPSP3 german without IE7 and WMP x, only current Hofixes by hfslip 2.0.0pa build 80611a and added drivers by nlite.
Works great.
btw, i don´t include installer 4.5, MS update don´t ask for or offer it.

Tested yesterday, and the problem in text mode setup is vanished.
But in installed Windows, I still had an issue with Installer 4.5. The problem seems to be identical to the one I described here, but I used HFSLIP 2.0 80611a this time.
I even put 7za.exe in HFTOOLS... What did I do wrong?

PS I wanted to post the log, but I don't have it anymore...

I did a quick test changing the SOURCESS location to my second harddrive. When normally the HFSLIP process takes about 20 minutes to slipstream and create a CD iso, now it was reduced to 15 minutes. A 25% decrease of processing time on my system.
If you can also move location of WORK and TEMP to different drives HFSLIP processing should go even quicker.

@Smiley89
Do you still have the SOURCESS folder? If so, ZIP TXTSETUP.SIF and HFSLIPOC.INF from SOURCESS\I386 together and put the ZIP file online (either here or elsewhere).

@Acheron
I need to discuss that with TommyP.

Unforunately, I don't have them anymore. I can reproduce them easily though, so I'll post them later.

Here it is.
I also included HFSLIP.LOG.

Smiley89--

Everything seems to be in place for the Windows Installer 4.5 update. I could only spot a few unnecessary hotfixes but it's not certain that those are the culprit.

WindowsXP-KB949269-x86-ITA.exe [Windows XP doesn't have ADAM]
WindowsXP-KB951978-x86-ITA.exe [only for XPSP3 with IE6 - manual installation is blocked if IE7 is detected]

You could also remove WindowsXP-KB944043-v3-x86-ITA.exe and WindowsXP-KB951830-x86-ITA.exe but I don't see anything out of the ordinary with those so try removing only the other two first.

Tried again without KB949269 and KB951978. Apparently, nothing changed: Installer service still doesn't show up. I'll try removing also the other 2 updates.

To further prevent flashing cmd windows the following can be altered:



into



Also any "cscript" commands to run vbscripts can be changed into "wscript /B".

@Acheron
Well, you know... Those are the commands that are used by Microsoft in the hotfixes. If those are altered, I want to be sure that they still work.
Also, the second command is no longer triggered from HFSLIP.CMD but from HFSLIPOC.INF in HFSLIP 2.0 so the syntax you propose may need to be changed again.

@Smiley89
I don't really know what else could be the problem. I can't duplicate it with an English or a Dutch source.

Maybe it's the wrong 7za.exe command-line tool? I downloaded the latest version from the official website.

Yes, that's the reason I post these commands here, so they can be tested. cscript and wscript are using the same engine to process vbscripts. the /B command prevents displaying any messages to the user.

If you want each hotfix processed the Microsoft way you should just stick with using the official /Integrate method. Is that what you want???

UPDATE

I found the last cmd window caused by the User Profile Hive Cleanup tool, not by HFSLIP.

Hi,

I have a list of files only support /Q for silence installation.
However, there is no HFSVCPACK_SW2 folder after I double click the HFSLIP 2.0..
Where should I put those files?

How about for cleartype.exe that supports /S only? where should I put that file?

Thanks.

Ok, I've found something that might be helpful.
I tried to slipstream Installer 4.5 with the /integrate switch on a clean SP3 source. I didn't integrate anything else.
Then I tested the resulting ISO on VirtualBox as usual...
And the result is the same! Installer service doesn't show up on the services list.
So the problem it's probably related to the hotfix, not to HFSLIP.

Hope this helps.

One thing I love about HFSLIP is the HIVEINSTALL support. I searched the net about inf commands and there is a lot of information available. I found even this to create custom shortcuts. No need for any batch files. Maybe also hfslip.cmd can be changed into inf format

ctpooon--

You can create the HFSVCPACK_SW2 folder manually. It just isn't created automatically by HFSLIP 2.0 to keep things tidy.

There isn't any provision for executables that only support the /S switch.

Hi TC,

While testing out HFSLIP v2.0 I notced something strange.
The .CMD file I have in the HFSVCPACK folder didn't work.
After looking into it abit more, I found that the .CMD file was on the 'Root' of the partition I was using HFSILP v2.0 on [D:\].
It had no extension and was called 'SVCPACK'

I'm doing another test now, to see if it happens again.


---Edit---
Yep, same thing again.
This time I had a good look at what was going on.
It seems as though the error happens while copying the .CMD file.
Instead of being copied the the '\Sourcess\i386\svcpack' folder it gets copied to the '\' folder and renamed SVCPACK.

Its entry in the 'svcpack.inf' is there and it works great if I copy the .CMD to the '\Sourcess\i386\svcpack' folder by hand.

Maybe a 'Typo' in the script

Thanks. This should be fixed now.

Me again! (Edited from earlier to clarify and with more testing results)

80630a, during gui-mode copy, can't find file RSOP.MOF

With only IE7 and required, like so:


Only one missing file: RSOP.MOF

Compressed version is, of course, in i386. (Verified it's not actually in the $NT.whatever.LS? by interrupting the install after it gave the error).
It is, however, listed in TXTSETUP:



I will follow up with my original set of selected patches and missing files.

P.S. I've been using the low-compression "SPX" option, as that seems much faster than the "DRIVER.CAB" option. Any chance that could make a difference?

From your previous replies I just realized network-based installs aren't really supported, or aren't first priority, so double thanks.
(Hmm, I wonder if my boss would approve a donation to you guys?)

Followup:

Going back to my original batch of updates, it's the following that are missing, in the order they are asked for (just a couple seconds after "installing networking":

rsop.mof
wscenter.mof
rsop.mtl

As an aside - since my most pressing need for this is just to get a basic image built to be re-deployed, is there any reason I can't provide these files manually and get on with my life? (Or does problem of these missing files point to there being some other, hidden issues?)

So, though I verfied that said files are there on the HD before the reboot from textmode, burning same files to a CD (well, technically an .iso, as this was a VM for the latest round of testing) and pointing the installer to those worked!?! I wonder if the files are getting deleted on the restart, or perhaps it's a wierd permissions/ownership issue?

Hello TC76,

The Windows Search 4.0 plugin is not working for me. After installation of Windows I can call the search window and the new GUI shows up, but it doesn't find files and instead only says that the "indexing is not working properly" (or something like that, and only have the German version). Indeed the indexing service is set to start mode "manual" and not running. But starting it manually, or setting the service to "automatic", or trying a re-boot inbetween, didn't bring any change.
If necessary I can post a screenshot. What other information would be useful for debugging this, which logfile do you want to see?

And am I the only one with this problem, was someone able to successfully slipstream Windows Search 4.0? Any help appreciated, thanks!

Kind regards,
Tomalak