xpboy24

hi Trip, I took a look at WES 7 and was able to make it so that all writes went to RAM. But I still can't multiboot off of it. I'm currently using iSCSI booting of WES 7, but when I bring a 2nd machine online with identical hardware, it BSODs with 0xc0000034. I shutdown the other machine and reboot 2nd machine and it boots fine. I think it still somehow locks all the files and prevents them from being accessed by another computer. Is there anything i can change to prevent that from happening?

hi Steve, thanks for the reply What I'm ultimately trying to accomplish is a diskless one-to-many boot scenario that does NOT replicate the master image. All clients diskless boot from the "read-only" master, and things like IP addresses and computer name are stored in RAM to be wiped. I don't mind if a unique copy needs to be retained, but it still has to be diskless and without too much management overhead. The issue with iSCSI that i've run into is the simple fact that given an ~300 client deployment, LUN management is going to be an ultimate nightmare. Differencing VHD boot can solve this, but then there has to be a way to make a specific client boot to a specific BCD store all within the gPXE sanboot sequence. So my best hope was a fully volatile environment. The clients will not have a lot of write activity or changes; most likely the only "change" will be some minor configurations such as dhcp IP and registry to launch a single app. Given they'll be in a workgroup, I'm not too worried about name or SID conflicts at this time. So it's not for RAM cache performance as it is more of trying to accomplish a true one-to-many scenario.

Hi everyone, I have an unusual method I'm trying to figure out on how to boot Windows 7 and I hope you can help me Setup : Hard Drive that has a full Windows 7 installation already on that's pre-configured with specific settings (BASE) Required Result : Boot the BASE Win 7, but make it so that all requested files are loaded into RAM and stay there. Basically I'm trying to OS Stream Win 7, but into RAM so that any and all changes made stay in RAM and the Hard Drive is used as nothing more than a read-only file repository containing all of the necessary files. These changes should be visible while the PC is on, but should reset when it is turned off (Volatile). I've tried iSCSI boot, VHD Boot, and iSCSI VHD Boot, but none of them make it volatile (all changes are written directly back to the Hard Drive). I've also tried setting the permissions on the vhd file to read only, but apparently that has absolutely no effect when the OS boots into it. I've read up on possibly WIM booting Win 7 directly, but from what I understand WIM booting is not a stream boot, but a full RAM boot. This means I'll most likely need a HUGE amount of RAM to get it to work. One thing I thought of that MIGHT work is to use VHD differencing boot so that the parent stays the same and all changes are made to the differencing only; but in order for this to work, I would require some kind of script that would be able to automatically create the differencing vhds (not too difficult), but then be able to boot into that VHD WITHOUT restarting the PC. It would have to be some sort of weird Win PE situation that is able to immediately initiate a boot without a restart... There are OS Streaming products from companies like Citrix and HP that sort of does what I want, but I'm currently looking for an Open Source or MS Built-in method to accomplish what those products do. I personally don't require the amount of control and fine tuning those offer. Has anyone been able to successfully accomplish a deployment such as the one I've described? Thanks

that's great to hear MadBoy. Enjoy your vacation!! =D

Yup. If I use New method no drivers get installed, which is why I prefer Old. But using Old as long as there are NO fnhw windows up, the driver installation will continue on successfully. This becomes a problem in the initial and occasionally when I forget to add a driver for an unknown device or the wrong driver and the fnhw pops up again and thus stops the entire process midstream until I cancel out again. Of course if i'm running it on auto, I might not be paying attention all the time (perhaps initially for testing, but I've occasionally run into some models that are same model # but have 1 different part which causes a redetect), and thus fails. I've found a workaround which seems to revolve around fnhw's need to use windows update initially. Your program, for me, used to never go beyond the fnhw and I never understood why truthfully (which also meant I never really understood the need for the fnhw section in your xml code either). If I disable "Use windows update for drivers" to never, then your program runs through the fnhw next-next-finish routine. I made a script that currently disables windows update driver check via registry and then re-enables it after driver installation. Is there a way so that Cancel is the first option used? If you say it interferes with the installation, is there a way to so that it chooses the "dont' use" option and then clicks next? I think the problem might be that there's no "default" option that gets automatically highlighted in the initial fnhw use windows update screen.

Hey MadBoy, I'd just like to say that I personally love your program. I've been looking for something like this for quite some time and fond yours to be the easiest to use (not requiring a huge script). My only problem with it revolves around the Found New Hardware Wizard. I use the OLD method cuz I could never really get the New method to work and Old does what I want it to do. I'm running this on english XP machines. My problem is that the Found New Hardware Wizard stops the program from proceeding on automatic (which is the biggest reason I love this). I have to manually cancel out of all fnhw windows and then the program will continue on as it should. Once those windows are gone the program works beautifully. I have all the settings set to what it says on the first page, but is there a way to force all the fnhw closed/push cancel? If this feature could be implemented somehow it would be complete!