Problems slipstreaming modified disk management files; software RAID

[xpman]

I have some problems concerning the slipstreaming of the XP Pro RAID modifications.

I use the guide according to this link

http://www.tomshardware.com/2004/11/19/usi..._raid_5_happen/

Modifying the files and inserting them manually into the system works fine.

I have now tried two different ways of integrating the files on the CD:

1. Replacing the original files on the disc.

a. I used makecab to create

dmboot.sy_

dmconfig.dl_

dmadmin.ex_

b. Then I replace them in the I386 folder.

c. Then, during textmode setup, I get an error message: "The file dmadmin.exe was not copied correctly". In addition the file is claimed not to be a "valid Windows XP system image" (see attached screenshot for details). The other two files do not create a problem.

2. Putting the files into $OEM$\$$\system32 and $OEM$\$$\system32\drivers (just like in the live system)

In this case, the original files are still there after the installation completes. I had thought that the contents of the system32 folder was copied during textmode setup before the oem folder was processed. This behavior suggests the contrary.

Searching the forums for "dmadmin" didn't reveal anything regarding this. I still hope anybody has any idea what this could be or how it is solved.

It seems to be that there are some basic issues with file replacement and copying behind this which I don't know about.

Edited August 26, 2007 by xpman

[xpman]

All my attempts in the meantime to solve this failed so far.

Does anybody maybe have a hint regarding the replacement of such files in general? I have a similar problem with termserv.dll.

[xpman]

1. Help came when I was looking at how to disable WFP, which lead me to this post:

http://unattended.msfn.org/unattended.xp/view/web/64/

After applying

modifype dmadmin.exe-a

and then compressing the file as before

makecab dmadmin.exe dmadmin.ex_

The installation went through perfectly. So it was just a checksum problem. Interestingly, none of the guides I read mentioned this. But then they only described how to replace the files in a live system. I guess that Windows doesn't check the checksum then.

2. What I am unsure about now is

a. which files to require such modifications.

b. if I can do any damage applying modifype.exe to the "wrong" file, i.e. one that doesn't need it. Does the exe check this?

3. I then tried to disable WFP with a modified sfc_os.dl_ and the hive modification so WFP would be disabled at T12 already. Copying the RAID files in a script worked then (I verified that the files were overwritten), but after the first reboot they were gone again.

The reason for doing it this my is to keep the modifications to the original medium at a minimum and the allow the replacement of files besides sfc_os.dll at a minimum. The fact that I got no WFP message box when copying the files over at T12 suggest to me that WFP was indeed disabled. But why are the files gone after a reboot, then?

[xpman]

I've had some more time to deal with the problem:

a. I use hivesft.inf to import both SFCDisable and SFCSetting with 0xffffff9d (I use both for testing).

b. I modified the two bytes in sfc_os and also replaced SFCDisable by SFCSetting.

I found the following:

At T-12:

1. The modified sfc_os.dll is installed properly.

2. The registry settings from hivesft.inf are correctly imported.

3. The copying operation for the disk management files succeeds (just as for termsrv.dll)

Now somewhere after T-12 and before T-9 the following happens:

4. SFCDisable is reset to 0; this, according to some other posting, is normal, and it doesn't appear to be influenced by the modified sfc_os.dll. Still, it shouldn't matter because sfc_os.dll should look at SFCSetting anyway.

5. The modified disk management files have been replaced by the original ones.

Whenever I try to replace the files again after that (from a cmd that I leave open), the files fully disappear in system32 for a few seconds and then the original ones appear again.

All I find in the forums concerns overwriting system files either after the first real boot or right on the installation medium. In the latter case WFP shouldn't matter anyway. I'd prefer having a choice at T-12, though, especially because termsrv.dll cannot be replaced as easily once Windows is fully up and running (at least not without another reboot).

Any clues?