InTheWayBoy

Rock on man, thanx for the post...was starting to think it was a dumb question It sounds like even with the 'issues' you have it should be perfect for us. The driver.cab isn't an issue so much if I understand it...I could either merge everything back into an unofficial driver.cab and drvindex.inf, or I can keep the original driver.cab and drvindex.inf, but add a custom spx.cab? In regards to the nlite issues, I don't really use that so I'm not worried about it. But I am concerned about the process...to be clear, should I: 1. HFSLIP the source, then make the RIS image from the source 2. Make the RIS image from a standard source, then HFSLIP the RIS image And yeah, I've never found a MassStorage integrator that actually worked for me...best to do it by hand. If I do that, it requires editing the TXTSETUP.SIF file...should I wait to do that until after I HFSLIP it? Sorry for all the questions...I'm sure some of these would be answered if I just did this...that's what the long weekend if for eh?

Yeah...lets say you have a RIS server setup that has a few images. Your dir structure should look like this: Notice how the structure is laid out...so if you wanted to permanently remove the XPSP2 image, just delete the folder: \\RisServer\reminstall\setup\english\images\XPSP2 Now if you notice, each image has an i386 folder, and in that folder is a templates folder. In that resides the *.sif that is associated with that image. You can have more than one for each image, which would result in more menu options. If you have one image with two *.sif files, then you will get a menu with two choices when you boot to RIS. If you want to remove one of those choices, then you can manually remove the *.sif fromt the templates folder.

You got it about right...RIS usually scans the RIS Share for *.sif, so if you remove the image folder you also remove the *.sif associated with it. The only other addition I can suggst is to restart the Remote Install service just to make sure...and you might want to 'Verify" the server too, which never seems to do much but it might help.

Unless it was customized, your D: should have a folder called "Documents and Settings". In that folder there should be a few other folders, one for each user. Inside each users folder is another set of folders...there should be an "Application Data" folder, with other folders inside it. Inside that should be all your files for Firefox...I can't remember if they still use "Mozilla" or "Firefox", but look for either of those and in there should be your Firefox profile. If you already have Firefox installed on the new C:, then you should be able to just move the bookmarks.html file to the profile and then it should show right up. You might need to close and open Firefox if it's already running. To avoid this in the future either manually redirect Firefox to save it's profile info to a more accessable folder, or there are several plugins that will backup your profile to a different location...FTP is the most common method.

Yeah, do what he said, that way we can narrow down which chipset yours is and see if we can get the M$ stack to support it.

Well if the M$ stack doesn't recognize your adapter then as far as I know you are S.O.L. You can only pick which stack if you have two stacks that recognize your adapter...so in your case, since the bluesoleil is the only one that works then that is pretty much what you are stuck with. Sometimes you can hack in support to the other stacks, but I haven't seen anyone attempt to hack in support for other adapters to the M$ stack. There might be a chance you could do that, but you would need to find certain PNP id's from the bluesoleil driver INF's. You could then insert those id's into the M$ bluetooth driver INF and see if it works...but I doubt it. If you could post the adapters manufacturer, model, and any other specific info about the device that might help...and possibly the INF file for the driver too.

It should ask to install it when the desktop first loads...if it doesn't, just run R2AUTO.EXE from the root of CD2. Now since this is a trial it may not be that way...do you have a folder "CMPNENTS" anywhere in the trial? Because that is where all the new goodies are...same way they do Media Center and TabletPC's. If you don't have that then you either don't get that with the trial or they are doing it some other way.

I've seen HFSLIP around, but never really looked into until recently. I think I like the idea, but I was wondering if anyone has used this on a RIS image. As I understand it various files get compressed and uncompressed or even left out entirely when you make a RIS image from a source. This can cause a ton of problems, and I'm wondering if HFSLIP will fall prey to that as well? To give an example, it may be file.ex_ (Compressed) in the source, but in the RIS image it's file.exe (Uncompressed)...so any scripts that reference file.ex_ won't fly. Or, could I run HFSLIP on the RIS image after it's been created...but still similar issues with file names occur. We use RIS exclusively, so I don't want to waste too much time on this if it is a known issue. I tried searching this sub-forum for RIS but came up with nothing. Still, it's got a lot of good base knowledge so I think I may tinker with it...thanx in advance!

I've been playing with Bluetooth a lot lately...your problem isn't uncommon. All Bluetooth devices need a 'stack' to operate...think of it as a super driver. Anywho, since XP SP2 M$ has included their own stack, but it's very limited because it tries to be universal. Most Bluetooth adapters still rely on their own stack, especially big OEM's like Logitech and Toshiba, who in turn license it out to companies like Dell, HP, and Belkin. From what I've seen you have four major Windows stacks: 1. M$ Stack 2. WidComm 3. Toshiba 4. BlueSoleil Problem is all the three commercial products use their own form of licensing the stack. And of course each version only supports specific adapters. This causes tons of issues when installing or upgrading the stack. You usually have to just stick with the latest official stack the the manufacturer suggests. That sucks cause most of the time the only version availible through the manufacturer is the one that ships with the unit. You can hack and patch the licensing of the stacks, there is a lot of info on google about that...but that's illegal of course. Plus, results aren't always that great when hacking the stack. The whole point of this long post is to explain that you are basically stuck using one or the other...if the M$ stack works with your device then you can hang with that, or you can install the stack that came with your adapter but you'll have to disable the M$ stack. You probably want to stick with the stack that came with it if you want the most features. To give an example, when I use the M$ stack with a particular adapter I can't use a headset as an audio device. But, if I use the stack that came with the device then I can use it as an audio device...sounds comes out the speaker, and I can recored through the mic on the headset. It's sweet! Not great sound quality, but it is perfect for Skype. And if you are going to stay with the manufacturers stack, you should disable the M$ stack so it doesn't get in the way: http://support.microsoft.com/?id=840635

While there is no standard/official way to do it, you can switch certain HAL's if you are crafty enough. I personally don't bother with it, but I have seen several solutions. The most common one I've seen is to somehow have a script that manually replaces the HAL.DLL with the correct version. How does it determine the correct version? Well most examples I've seen run from a menu of sorts (.BAT, AutoIT, etc) and you must select the appropriate HAL. I also seem to recall someone using WMI for this, but that would require the use of something like BartPE or WinPE to run the script from. In the end, it seems like it's just easier to not worry about it. Since I never did it I don't have any of the scripts, but I'm sure someone here does. Or you could just create your own. I think the key is that you have to replace it as early as possible, and it has to be in the same class...either all ACPI or all Non-ACPI. Since you say you want all ACPI then you should be good to go. I recommend changing the driver to the most universal HAL (ACPI PC) before imaging...then afterwards you can impliment a method to change it to it's proper HAL. And here is another thread I posted to that dealt with the same issue: http://www.msfn.org/board/index.php?showtopic=57508 Try searching the forum, there is bound to be several other posts like this one, and one may have your answer. Good luck!

You could disable write-protect, edit, save, then re-enable...or you could right-click on my computer, properties, advanced, startup and recovery settings, and then there is an edit button that will open boot.ini in a temporary editable mode.

You could use the ".\" to inform the script to start in the same place as the script...so for your script it would be something like this: cls @echo off Title Coping Files to uesrprofile and Shortcuts to Desktop MODE CON COLS=80 LINES=30 color 4f xcopy /y ".\LessonMaterial\TrainingData\Shortcuts\*.*" "%userprofile%\desktop" xcopy /e /k /i /c /r /y ".\LessonMaterial" "%userprofile%\Personal\" ECHO Shutting down computer in 5 seconds Shutdown -s /f /t 5 /c "One step to gooooooooo............" That's assuming that both the script and the LessonMaterial folder are in the root of the drive...or parallel to each other. Remember, this uses the place the script runs from as it's base, so if it's running from the local temp dir then it's not gonna do you any good. But if you are running the script straight from the drive then it should work. Couple this with the autorun idea mentioned earlier and those 30 will fly by.

Nevermind...didn't read it fully

You should never go from Trial to Production like that...backup, format, and reload with the new official software. Trial software, even the ones as good as M$ OS, are never reliable when upgraded to the full version. Some may argue otherwise, but from experience your best bet is to reload. You could try doing an in-place upgrade, but I don't know if that will work between different versions of 2003.

Well if they are old, then you might not be able to boot from a USB device...if that's the case then you are S.O.L. If it can boot to a USB device, you're still not out of the woods yet. As far as I know, you can't start the install directly from the device. But, you could try booting to BartPE from the USB drive and then initiating the setup from within BartPE. I've been trying to do something similar for a while, but my situation is a little different...the only bootable device I have is an SD card, and with the way Toshiba makes it bootable it's not very possible for me to get anywhere. If you need help booting BartPE, you should look at the official forums: 911cd.net/forums They have several ways of booting BartPE off a USB device. You'll probably need to test and refine it a lot. In truth, if you can swing it you should try doing what ColdFusion recommended...network install. Hell, if you have a RIS server setup you probably won't have to carry a boot disk if the computers are PXE capable!

They are made so you don't lose any info during a reinstall...lots of important stuff hides in there, so it's better to leave the previous files be and just create new profiles. The best way to avoid it is to not do a half-a** reinstall. A full reload is the only option in my opinion...partly because of this issue. In the end this rarely hurts anything, because most of the info in the original folders isn't linked to the new install...but it does make for a very untiddy folder. Also, certain scritps or applications that don't use variables might run into issues with this, so it's best to just try and avoid it at all costs. As for a tip, if you must reload without formatting, I generally boot into BartPE and move all the original files and folders into a 'backup' folder. It's nothing special, but by moving them out of the root of the drive you don't get problems like this thread. Then after the reload you can root through the dir for files before erasing them. Of course if you had a virus then this process isn't recommended, as the virus would still be on the drive during a reload.

Yuck...stay away from SiS in the future. They work, but they are never any good and you run into lots of problems like this one As for your issue at hand, you should check out the device drivers sub-forum: http://www.msfn.org/board/index.php?showforum=88 If you can't find a specific fix in there, then you may want to look at changing the routine in which you load the SATA drivers. The DriverPack may help you out too if you are interested. Doing a quick search for SISRaid.INF (Part of your drivers included in the post) you get this: http://www.msfn.org/board/index.php?act=Se...=%2Bsisraid.inf Good Luck!

I vote for Unstoppable Copier: http://www.roadkil.net/unstopcp.html

There is a thread on the BartPE forums about booting a real XP from a USB device: http://www.911cd.net/forums//index.php?showtopic=14181 Of course it's not official and I don't know if it would apply to 2003. But it's a start! Otherwise you're pretty much out of luck other than the WinPE option previously mentioned.

Well, here's the situation...we just got in five new TabletPC's, the Toshiba M200 to be exact. They are the more mobile flavor of TabletPC's that Toshiba offers, and as such they don't come with an optical drive. Of course, you can spend a chunk of change and buy their official external DVD drive, but we don't need them. The units come with a Restore DVD that is nothing more than a large Ghost image (Which is password protected and supposedly encrypted) and the install files for all the extra crap Toshiba loads on the unit. I've already worked past not having a regular install source for the TabletPC OS, and have succesfully constructed a RIS image that works great over LAN. But I really want to find a way to do a 'local' restore at the unit, in case the network isn't availible or the NIC is bad. The units have an SD reader built in, and Toshiba has managed to make it bootable. At first blush this looks to solve all the problems, but after much frustration it doesn't...it makes it even worse! Allow me to explain...Toshiba includes two utilities that relate to the SD. One is a format utility, the other a boot utility. The format utility looks to format the SD as a FAT16X, with some odd partition tables. I don't have the info handy, but I did record the info. The boot utility transfers a bootable floppy disk or disk image to the SD. When it does this the end result is an oddly named floppy image, $TOSFD00.VFD. After some investigation there isn't much to it other than the specific name...I just create a disk image using WinImage or VFD and then rename it to the previously mentioned file. Because of this funky scheme, I can't figure out how to load an XP setup process natively. I know I could do it via DOS and WINNT.EXE, but that is slow. My first thought was to try and load BartPE, after which I could initiate the setup process via WINNT32.EXE. But because the way the SD boots it's not very easy. Let me explain some things I've found/tried: 1. When using the Toshiba tools to format and setup the boot for SD, I can boot to a DOS prompt. The floppy image is A:, and the rest of the SD is C:. This makes me think I could accomplish a lot, since I could just use the floppy image to load and then run everything from the rest of the SD as C:. If you format the SD using other methods (HPFormat, HEX Format, etc) then you won't get access to the rest of the SD after boot. I think it has something to do with how the partition tables are setup when using the Toshiba utility. 2. It's impossible to boot to a USB drive, it's not even offered in the boot menu. And Toshiba is very restrictive with their BIOS config. 3. I've tried using apps like Gujin, GRUB4DOS, SmartBootManager, and XOSL...and many will load and work, but I can't figure out how to get it to load anything useful. For instance, it will let me load the XP that is currently running from the HD, but I can't configure them to boot to a boot loader that resides as a file on the SD card. 4. I've tried to just forget the Toshiba utilities, but without them nothing is bootable. I've tried several methods of booting BartPE from a USB drive. And they work on other systems, but as I mentioned the units can't boot from a USB drive. I then tried to use the SD as the USB drive, and successfully completed the steps as I did when using a normal USB drive. But nothing worked...I think it's because the process will only work by loading that specific $TOSFD00.VFD, like it's hard coded into the BIOS or something. So given all that, I know what I need...I need some way to hold the install files on the SD, and then have a floppy image configured to boot and then 'chainload' the XP setup process from a file. I can't use partition boot sectors, because the way the process goes if it's anything other than Toshiba's proprietary mix then I can't access the rest of the SD. It's so simple yet far too frustrating to do on my own...I need some help. Been trying this for so long I think I'm cross-eyed So maybe some of ya'll will have a simple solution for me. If you are suggesting an application, please try and include some kinda of example for the syntax. A lot of the applications I tried to use say they can do what I want them to, but trial and error never got me far. And as an aside, since this is based on SD, there would be the time when the SD card would die from usage right? And with all this type of file access it may go quicker...any input or personal experience? Thanx in advance, I'll be happy to provide any information and try all valid suggestions. Thanx again!

I think any bootdisk made since Win98 has LFN support. If not, there has to be tools for it, but I'm not aware of one. For command history and auto-complete I've always used DOSKEY, which you can just slip into your AUTOEXEC.BAT or any other script.

You need to keep the same $OEM$ structure as a CD based install...if your info is correct you have the Drivers folder in the same place as your I386 and $OEM$ folders. That's not right, and most definantly your problem. You should have something like this: RIS_IMAGE\I386 \$OEM$\$1\Drivers\VGA \Chipset \$$\System32 Detailed a little better here: http://unattended.msfn.org/unattended.xp/view/web/18/ Otherwise things look okay as far as you winnt.sif goes. You have all the drivers expanded in their respective folders I assume. EDIT: I see that the formatting of posts might have skewed your dir list, so you may already have it correct.

Well you could try and construct some kinda BAT menu that you could use to enter in the CDKey...but you would have to have a way to load the setup process after that, so you can't do a native install, would have to do it from DOS as far as I can see. Or, to keep it running native, you could construct a BartPE/WinPE distro that would boot, wait for CDKey, then run setup. Of course, that would require a fair amount of investment of time, but it's about all I can think of. And don't discount what I mentioned earlier...different CDKey's won't work, OEM vs. RETAIL. Also, a quick FYI...the M$ activation line is touch tone sensitive, so you don't even have to speak into it for the long part. Saves me tons of time and errors, never have to talk to anyone.

Why not just do a fresh load...since you would always have to install it new in any scenario, why not just export the info from AD and Exchange, install SBS on the new server, setup, then import the AD and Exchange info. You can export AD: http://www.microsoft.com/technet/prodtechn...o/bulkstep.mspx http://www.computerperformance.co.uk/Logon...SVDE_Export.htm http://www.myitforum.com/articles/12/view.asp?id=8499 You can export GPO by using the newish GPMC. As for Exchange, I still have yet to spend more than an hour or two with it, so I can't speak of any tactics. But I'm sure it's possible, a quick google should set you straight. Or some other smarty will post an idea for the Exchange issue. Also, I've never used SBS so some of those links may not apply to it since it seems like it's just different enough to matter. Also, I would take this as an opportunity to document the new install, so when something like this happens in the future you can ensure better reliability. Because what would happen if you didn't have a chance to have a functioning server, only a backup...good luck!

NM