Protocol7

Hi all I'm trying to add Services For Macintosh from Windows Server 2000 to XP SP3. I believe I've found all the required files (a lot were not listed in the file and print service .inf files) and can get Print Services to install just fine from Add/Remove optional components. However, I can't get File Services to fully install. It appears to get quite far but ultimately ends up with the error: "Could not install the File Services for Macintosh component because a file or registry entry is missing". Is there any way I can find out what this file or entry is? I can't seem to find it in any logs and Event Viewer has no clues either. Turns out I was missing a couple of files after all. Process Monitor to the rescue.

Thanks jaclaz Hacked bootsector seems the most likely candidate. I saw something about replacing the string msdos5.0 with cmdcons but I couldn't figure out what file I had to hexedit to get this. It sounded like I had to build the bootsector out of another file like spcmdcon.sys (?). There's so many overlapping methods on these threads... It might work, I dunno. The other options (grub etc) are too much hassle for what I'm trying to achieve. Plus I still have to be able to call the recovery console from CDShell. Yeah that was one of the main threads I found last night. But I'm not really concerned with the catch 22 problem. I've only ever had one xp machine with an admin password set and in that case I just blanked the pass.

Hi jaclaz Sorry I could have been a bit clearer. I posted that after a long long day of trail-and-erroring stuff I was adding to my bootdisk. I have a multiboot disc with BartPE and some other floppy image based utils that I boot using CDShell. I added the recovery console using a pebuilder plugin I found online (I think it was cdob's). It loads fine from CDShell (and thanks to another post from cdob it also uses the driverpacks mass storage drivers for increased support). But it goes to the welcome to setup screen where I have to press R to get to the recovery console. It's only one keypress, but it would be nice to skip it as the other choices are no use. From reading around, it seemed it was possible to do this by adding a WINNT.SIF to the recovery console folder with some settings, but I tried a few variations and none worked. A hacked bootloader seems another possibility but most threads I've read go off in other tangents (usb sticks etc). All I want is to boot straight to the console, not any of the other hacks. And if it involves anything more than adding/editing a file then I'll stick to pressing R

What commands should I have in the WINNT.SIF if I want to skip straight to the recovery console on a multi-boot cd I've made? I've tried what's in jaclaz's above (though I wasn't able to set the path for OriSrc as the cd drive letter can change) but the best I could get was an error saying the installation files couldn't be found. I'm afraid I'll wear a hole in my hard disk with the amount of failed isos I've built trying to get this working so if anyone can put me out of my misery that would be great.

Thanks for the help kof94. It works a treat. I know CDShell probably isn't the best solution these days, but it's what I used to build my initial multiboot disc and I have everything else working fine with it. In time I'll switch over to isolinux but for now I didn't feel like it for the sake of one program. Is there any way to update the isolinux.csm file that cdshell uses? I was trying some stuff out initially (pasting a newer isolinux module into isolinux.csm in a hex editor) but I'm not sure I got it all right. I remember getting something about an image checksum error.

I'll be building a new multi-xp/repair disc soon now that SP3 is as good as here. So I'd also like to add some newer repair tools. I really like Parted Magic and would like to have it as a menu option but can't figure out how the hell to get it working with CDShell. I know there's an isolinux option you can use from CDShell (and this would be the only util using it) but I've tried placing the iso-extracted files in a few different places and just can't get the program to run when called from CDShell. Can anyone who knows their way around cdshell and isolinux help me out here?

Actually, I'd be interested in the Dell and HP ones too. Any chance of a 2003 section on oembios.net?

Out of curiosity, how many 2003 oembios sets are there? And do any of the sets on oembios.net work for 2003?

Thanks for the help guys. I had a brainwave and it's worked The trick was to add the [unattended] section with ProvideDefault after textmode setup was complete. That way it was left untouched. I was already injecting a product key into the $winnt$.inf file at T-39 via oemscan, so I injected the [unattended] entry using the presetup.cmd file that the driverpacks mass storage setup had added. This runs after the first reboot before gui setup begins. At T-39 I think it's too late because when I tried adding it to the oemscan cmd file it didn't work. This is what I added to presetup.cmd: @ECHO OFF for %%i in (C: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:) do if exist %%i\WIN51 set CDROM=%%i %CDROM%\OEM\NirCmd.exe inisetval %SystemRoot%\SYSTEM32\$WINNT$.INF "Unattended" "UnattendMode" "~qProvideDefault~q" %CDROM%\OEM\NirCmd.exe inisetval %SystemRoot%\SYSTEM32\$WINNT$.INF "Unattended" "OemSkipEula" "~qYes~q"

Thanks FreeStyler. I drew a blank with DefaultHide, but did get it to show with ProvideDefault. The problem with having to use an [unattended] section is that I lose the repair functionality as it jumps straight to the partitioning step in textmode setup. I'd rather keep that and lose regional setup if I had to choose. I guess there's no way to keep both.

I've searched through the forum here and most people are trying to skip this as part of an unattended setup. I want my setup almost fully attended, but because I'm using DetachedProgram to run something at T39, it skips the Regional & Language screen and goes straight to the User Information one. Here's my winnt.sif: [Data] MSDosInitiated=0 UnattendedInstall=Yes [GuiUnattended] DetachedProgram=".\system32\cmd.exe" Arguments="/Q /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (FOR %J IN (%IOEM) DO (IF EXIST %J (start /min /D%J NirCmd.exe exec hide oemscan.cmd)))" The closest I could find to what I was trying to do was here but it didn't work. I think the UnattendedInstall=Yes is necessary for the DetachedProgram section to work, so is there any way to over-ride it's skipping of the Regional settings?

Thanks for the reply FreeStyler. I figured it out in the end. The code was actually fine. The problem was that I had the winnt.sif in the wrong folder. Wrong: X:\2eho X:\home_oem\i386\winnt.sif Right: X:\2eho\winnt.sif X:\home_oem\i386 That's what I get for not reading up more on multiboot basics The disc is working fine from the oemscan point of view. I just have trouble with the driverpacks.net mass storage pack because some controllers have the same hardware id for both raid and sata controllers and by default it seems to load the raid driver. Gave me trouble when I tried it out on a Asus A8V Deluxe board with the Promise 376 controller set as sata. But I think they might be making progress in this area.

Nvm. After some belated rtfm-ing I got it working. Phew.

I'm having a hell of a time getting this to work. I have a nice working setup for a regular xp cd that calls oemscan at T39. But when I try to use the same files/code in a multi-boot disc it just won't work. The only real differences are that the i386 folder is now nested in a folder rather than being at the root of the disc, and there's an extra folder created containing what appears to be the textmode files. Old way: X:\i386\winnt.sif New way: X:\2eho (created by the "Create_MultiBoot_Folders_And_Files.exe" tool) X:\hoem\i386\winnt.sif winnt.sif: [Data] MSDosInitiated=0 UnattendedInstall=Yes [GuiUnattended] DetachedProgram=".\system32\cmd.exe" Arguments="/Q /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (FOR %J IN (%ISLP) DO (IF EXIST %J (start /min /D%J NirCmd.exe exec hide homescan.cmd)))" NirCmd and homescan.cmd are in a folder called SLP in the root of the disc. homescan.cmd calls oemscan which resides in the 2eho folder. All of this works perfectly in a single-boot cd. My winnt.sif shouldn't be affected by paths (as you can see) so why on earth has this stopped working? I've spent the last 3 days trying dozens of solutions and nothing has worked. Can anyone with some multiboot experience help me out here? Thanks!

[uPDATE] Well, I figured out that I didn't need to have the mass storage pack selected in the base program, just the textmode checkbox at the bottom. Now the drivers are slipstreamed into the i386 folder and there no more $OEM$ folder or Unattended section written into the winnt.sif. I didn't want them available as PnP drivers anyway, only for the textmode part. So in theory I should have been able to go back to my old winnt.sif. Except that it still doesn't work. Now, the only difference from before is that the i386 folder isn't on the root of the cd, but nested in a folder: Old way = X:\i386 New way = X:\HOME_OEM\i386 But I can't see how this would affect the code as the cdrom detection code seems solid. So why is it still not executing DetachedProgram at T39? --------------------------- Hi everyone. I'm trying to build a multi-XP dvd that I can use for installing retail and oem versions of home, pro and mce. Before this, I used individual cds with oemscan integrated and they worked great. But I'm having trouble with this multi one. I'm integrating the mass storage driverpack using the driverpacks base program and I think this is what is messing things up. Basically, my old method of calling oemscan from winnt.sif isn't working anymore. Here's my old, working winnt.sif: [Data] MSDosInitiated=0 UnattendedInstall=Yes [GuiUnattended] DetachedProgram=".\system32\cmd.exe" Arguments="/Q /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (FOR %J IN (%IOEM) DO (IF EXIST %J (start /min /D%J NirCmd.exe exec hide oemscan.cmd)))" And this is what I have after the driverpacks have been integrated: [Data] UnattendedInstall=Yes MsDosInitiated=No [Unattended] OemPnpDriversPath="D\D\M\3\1;D\D\M\3\1\O;;D\D\M\3\3;D\D\M\A\1;D\D\M\A\2;D\D\M\A\3;D\D\M\A\4;" (there's a lot more here but it's throwing the tables out of shape so I've trimmed it) OemPreinstall=Yes DriverSigningPolicy=Ignore NonDriverSigningPolicy=Ignore [GuiUnattended] DetachedProgram=".\system32\cmd.exe" Arguments="/Q /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (FOR %J IN (%I2EHO) DO (IF EXIST %J (start /min /D%J NirCmd.exe exec hide oemscan.cmd)))" [GUIRunOnce] command9="%SystemDrive%\DPsFnshr.exe" And for completion, here's the oemscan.cmd file that is supposed to be called (only the path has been changed from OEM to 2EHO) @ECHO OFF for %%i in (C: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:) do if exist %%i\WIN51 set CDROM=%%i %CDROM%\2EHO\OEMSCAN.EXE > "%SystemRoot%\Temp\oemscan.log" exit I've tidied up the new winnt.sif a little compared to how it looked after the driverpacks code was injected. Can anyone please explain why the code in GuiUnattended isn't being called anymore? Is it because of the new Unattended section? If so, is there any workaround? And finally, is the driverpacks finisher in GUIRunOnce needed at all for mass storage drivers? Thanks for any light you can shed on this!