36 replies to this topic

[Sha0]

Hello everyone,

I've been messing around trying to see if I can boot Windows XP in full mode (not setup-mode or /MININT mode) entirely over the network. I've done it a million times with Windows XP PE (via BartPE). It's such an interesting process, the XP boot process...

• The computer PXE-boots
• A DHCP address is obtained from my Cygwin DHCPD
• My DHCP server recommends STARTROM.N12 as a boot file
• The computer downloads STARTROM.N12 from my Cygwin TFTPD
• STARTROM.N12 runs and downloads NTLDR via TFTP
• This is where we branch in different directions for BartPE and full XP, based on NTLDR. I am only discussing full XP in this post
• The Windows XP Embedded NTLDR runs and downloads BOOT.INI via TFTP and gives the boot menu:

[boot loader]

timeout=30

default=ramdisk(0)\WINDOWS



[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional from Hard Disk" /fastdetect /sos /bootlog

ramdisk(0)\WINDOWS="ramdisk(0)\windows from net(0) HALAACPI" /fastdetect /rdpath=net(0)\foo.sdi /rdimageoffset=36352 /sos /bootlog /hal=halaacpi.dll

ramdisk(0)\windows="ramdisk(0)\windows from net(0) HALACPI" /fastdetect /rdpath=net(0)\foo.sdi /rdimageoffset=36352 /sos /bootlog /hal=halacpi.dll

net(0)\windows="net(0)\windows" /fastdetect /sos /bootlog

• If we choose one of the ramdisk boots, NTLDR downloads FOO.SDI as a ramdisk, then starts loading the OS from it
• If we choose the net(0)\windows option:
• NTLDR starts loading the OS via TFTP!
  --- START OF GUESSWORK ---
• When it's time to make the switch away from BIOS routines, the Kernel checks the ARC path which we were loaded from
  (You can use Sysinternals' [now Microsoft's] WinObj to see that ARC paths are shortcuts to filesystems)
• The Kernel doesn't see a net(0) shortcut pointing to any filesystem
  --- END OF GUESSWORK ---
• The Kernel displays a Blue Screen of Death with STOP 7B

Although it's guesswork, I think I might have learned something about the boot process that I never knew before... I always thought UNMOUNTABLE_BOOT_VOLUME had to do with not having a device (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}) with a MatchingDeviceID of "gendisk" and not having a device (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE, for example) with a ComptabileIDs including "GenDisk". Now I don't think so. Now I think this is what happens:

• As .SYS files are being loaded (as seen with /SOS), each one has an initialization routine which is called
• Microsoft's RAMDISK.SYS recognizes an available ramdisk loaded by NTLDR and associates that memory with a volume (like \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750})
• RAMDISK.SYS then creates a shortcut from ramdisk(0) to the volume, as can bee seen with WinObj
• When the Kernel decides to switch from using BIOS routines, it checks the ARC path
• The Kernel sees the shortcut from the ARC path of "ramdisk(0)" to "\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}", so it uses the NTFS filesystem all the way through the MS Ramdisk Controller to access the volume

I could be wrong; it could be NTLDR who makes the ramdisk(0) ARC shortcut. Whatever.

If this is all true, and all you need is an ARC shortcut to your boot volume, perhaps someone could write a small .SYS file who will be loaded at boot time and make the "net(0)" shortcut point to "\Device\LanmanRedirector\Registry_stored_fileserver\Registry_stored_fileshare". Then maybe at the big switch, we wouldn't get a blue screen!

The point of all of this is to run full XP over the network, without using a ramdisk. Let me know what you think.

[was_jaclaz]

You have some interesting points raised.

Coincidentally, in this period I am trying to do some experiments with the innards of Recovery Console, and some points appear to be "common".

As a matter of fact, in both SETUPLDR.BIN and NTLDR there is VERY near to the text ramdisk(0) the text net(0) but if you look at the text of error messages further on, some messages:

RDMTFTPTIMEOUT =

RDMTFTPADDR =

Downloading Ramdisk using MTFTP.

ArcOpen(%s) failed:

(bolding is of course mine)

Since usually error messages are in the same order of the sequence of operations that may fail, it appears that the net(0)/TFTP "calls" the Ramdisk, so my guess is that some serious modifications to NTLDR itself are needed...

It is also well possible that one might nees a "less picky" NTDETECT.COM, like the modified Dietmar's one...

Though with MS guys you never know, a few lines below there is this error message:

Sorry, wasn't talking to you!

Here are screenshots of Recovery Console MAP and MAP ARC commands when booted directly and through RAMdisk:
 RC_direct.bmp   151.9KB   1854 downloads
 RC_ramdisk.bmp   151.9KB   1549 downloads

That confirm that even in the "lower level" Recovery Console, Ramdisk(0) creates an ARCPATH to "\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}"

jaclaz

[Sha0]

Er, um, would you mind sharing how you booted CMDCONS on a ramdisk? Thanks.

By the way, my CMDCONS shows RAMDISK.SY_ in there, so it still could be NTLDR (or OSLOADER.EXE, SETUPLDR.EXE, SETUPLDR.BIN, CMLDR, etc.) loads the ramdisk, but RAMDISK.SYS handles filesystem calls to the volume once the switch from BIOS routines are made. Then again, my CMDCONS' SETUPREG.HIV doesn't have ramdisk as a service.

Thanks for the awesome reply.

[windrv]

more simplified and superior approach and less headache:

http://windrv.net/vi...18&extra=page=1

[was_jaclaz]

Er, um, would you mind sharing how you booted CMDCONS on a ramdisk? Thanks.

Yes, sure, I am putting together a complete howto, you'll have to wait a few days.

Briefly, it all began here:
http://www.boot-land...?...ic=2692&hl=

I first created a Recovery Console only .iso:
http://www.boot-land...sole-t2254.html

modifying slightly the batch to stop execution before making the .iso to give me time to put in the source directory the Server 2003 SP1 RAMDISK.SY_ instead of the XP SP2 one.

Then I made a bootsector invoking SETUPLDR.BIN:
http://www.boot-land...?showtopic=2362

Then I put a copy of the .iso and of the bootsector together with a NTLDR, SETUPLDR.BIN and NTDETECT.COM, a BOOT.INI with this line:

C:\SETUPLDR.BS="XP Setup Ramdisk through sector"

and a WINNT.SIF as follows:

[SetupData]
BootDevice = "ramdisk(0)"
BootPath = "\I386\"
OsLoadOptions = "/noguiboot /fastdetect /rdexportascd /rdpath=XPRC.ISO"

Lately I went a bit further:
http://www.boot-land...?...c=2362&st=7

I still have to try a ramdisk(0) setup for the latter, and I am experimenting with various (semi-random) ideas, including getting rid of all the non-normally-needed drivers....

Then again, my CMDCONS' SETUPREG.HIV doesn't have ramdisk as a service.

Just a guess, mind you, but would it be possible that the only difference between XPSP2 and SERVER 2003 SP1 files is the need for an entry in SETUPREG.HIV or, for the latter, the lack of this need?
Bilou_gateux reported that it is possible to use RAMDISK.SY_ from XP SP2 by adding some keys in the Registry and/or adding ramdisk.inf, but cannot say if it would work with SETUPREG.HIV:
http://www.911cd.net...o...19056&st=44

Also, see if you can find some sense in my blah blah here:
http://www.boot-land...?...c=1441&st=3


jaclaz

[Sha0]

Hey windrv, thanks for the reply, but I am actually trying to avoid purchasing a product like Ardence or NeoWare or DisklessAngel. Unless you are saying that map --mem and map --hook fool Windows even past the switch from using BIOS routines to using XP drivers to continue the boot process...? The big idea for me is to load full XP entirely over the network, without (permanently) using a ramdisk. If I have 256 MB RAM, I want full XP over the network to have access to 256 MB RAM.

Hey jaclaz, I totally forgot about /RDEXPORTASCD. I'll give that a try for some fun! I had read those other articles, it's all quite interesting stuff. I think I would like to find out some more about Dietmar's NTBOOTDD.SYS...

[windrv]

Hey windrv, thanks for the reply, but I am actually trying to avoid purchasing a product like Ardence or NeoWare or DisklessAngel. Unless you are saying that map --mem and map --hook fool Windows even past the switch from using BIOS routines to using XP drivers to continue the boot process...? The big idea for me is to load full XP entirely over the network, without (permanently) using a ramdisk. If I have 256 MB RAM, I want full XP over the network to have access to 256 MB RAM.

Hey jaclaz, I totally forgot about /RDEXPORTASCD. I'll give that a try for some fun! I had read those other articles, it's all quite interesting stuff. I think I would like to find out some more about Dietmar's NTBOOTDD.SYS...

Are you actually trying to roll out or introduce such a free product for us?

At present, I think such free product exists for Linux. So if you want to run diskless workstation over network fileserver for free, then try Linux not Windows.

[MedEvil]

The big idea for me is to load full XP entirely over the network, without (permanently) using a ramdisk. If I have 256 MB RAM, I want full XP over the network to have access to 256 MB RAM.

Wouldn't such an OS be terribly slow?

[Sha0]

Hey windrv,
Driver programming has always been something I have avoided. I don't have access to the MS DDK, just the open source alternatives available on the 'net. I have only just recently compiled Sysinternals' NATIVE.EXE NT "native-mode" exectuable, something like Autochk.exe or the PartitionMagic stuff you see when PM is busy changing things after a reboot.
I might try to get into it. I love skeleton projects of things. I'm going to keep investigating. If I figure it out, it'll definitely be open source since there are already such things for sale.

Hey MedEvil,
Actually I am looking at this for a large organization who plans on using Citrix anyway, where pretty well all processing will be happening centrally, so no, I don't think the OS would be terribly slow.
Another scenario where I would want the OS running entirely over the network is just for utilitarian purposes. Somebody's computer keeps BlueScreening, I tell my DHCP server to tell them to boot from the network instead of the local hard drive. They boot a standard image for their PC model, then they can access their files on the C: just to get them off, or I can remote control the PC and manually load the registry hives from the C: to get rid of the driver (maybe a virus) causing the problem. Or maybe I just re-image the C: remotely. I have found that a network-booted XP PE (like BartPE) is very handy for this sort of thing, but still limited. I'd rather have a real XP running. Then I can sell the idea to management and we can have absolute central control of every PC in the organization, as long as they're set to PXE-boot in BIOS.

I am thinking that I need to write a .SYS driver who makes an ArcName shortcut from net(0) to \Device\LanmanRedirector. This is what a network-booted BartPE has. An important thing I've noticed while messing around is that if the booted image has conflicting network adapters on top of the built-in setup network adapter, NDIS.SYS will cause a BlueScreen.

I am thinking that if I want the OS to run over the network wirelessly, a full-blown .SYS driver would have to be coded. As I mentioned in an ImDisk post, I envision the driver as something like an IDE or SCSI controller. It fakes a physical disk by redirecting I/O over the network using low-level network routines, maybe Ethernet, maybe IP. I also see it functioning something like EWF, storing the delta (changes) made to the image separately, so many clients can boot from the same image. The administrator chooses whether their changes are saved or discarded. I also see the ability to switch during run-time, once Windows networking gets started successfully, to using Windows' higher-level networking to continue accessing the datastore. There should be failover functionality so that if the datastore becomes unavailable, disk I/O becomes unavailable until it becomes available again maybe over another network connection, like wireless or VPN or another NIC.

This is only different from Ardence and NeoWare with the high-level networking switch and the failover features I'm talking about. Maybe Ardence or NeoWare will put these features in their next version!

[Sha0]

Hey everyone, I really hope this is considered OK to post, please let me know if it isn't.

I took a look at Ardence' product for network booting. A few details follow... While the Boot Sequence section is incomplete, it still shows some action. "LD" means driver was loaded, try to guess what "NL" stands for. The .SYS files without "---->" next to them I haven't checked. I will have to read up on why some drivers appear to be loaded apart from others in their group.

The files marked with asterisks to their right are part of the Ardence product.

A major difference with Ardence is that it loads NDIS stuff before Primary Disk, which is way earlier than a regular XP does. Is Primary Disk where we get UNMOUNTABLE_BOOT_VOLUME?

I will edit this post when I've completed the boot sequence listing.

Ardence Notes

~~~~~~~~~~~~~

vDisk:

The vDisk file is an HDD image with one extra sector at the beginning.  The first partition should be an offset of 64 sectors, then.



Boot Sequence as per NTBTLOG.TXT:

LD: \WINDOWS\system32\ntoskrnl.exe

LD: \WINDOWS\system32\hal.dll

LD: \WINDOWS\system32\KDCOM.DLL

LD: \WINDOWS\system32\BOOTVID.dll



[ Boot Bus Extender ]

LD: ACPI.sys -------> (Depends on WMILIB.SYS)

LD: WMILIB.SYS -----> (Dependency)

LD: pci.sys -------->

LD: isapnp.sys ----->



[ System Bus Extender ]

LD: compbatt.sys ---> (Depends on BATTC.SYS)

LD: BATTC.SYS ------> (Dependency & Service)

LD: intelide.sys ---> (Depends on PCIIDEX.SYS)

LD: PCIIDEX.SYS ----> (Dependency)

LD: pcmcia.sys ----->

LD: MountMgr.sys --->

LD: ftdisk.sys ----->

LD: PartMgr.sys ---->

LD: VolSnap.sys ---->



[ NDIS Wrapper ]

LD: NDIS.sys ------->



[ NDIS ]

LD: el90xbc5.sys --->

LD: bnns.sys -------> Network Intermediate Filter Driver (Depends on TDI.SYS) ******

LD: TDI.SYS --------> (Dependency)



[ Ardence ]

LD: bnistack.sys ---> Ardence Virtual HBA SCSI Disk Device (Depends on BNNS.SYS) ***

LD: bnsm.sys -------> Ardence SCSI Miniport Driver (Depends on SCSIPORT.SYS) *******

LD: SCSIPORT.SYS ---> (Dependency)

LD: bnsmdf.sys -----> Ardence SCSI Miniport Disk Filter Driver *********************



[ SCSI miniport ]

LD: atapi.sys ------>



[ SCSI Class ]

LD: disk.sys -------> (Depends on CLASSPNP.SYS)

LD: CLASSPNP.SYS ---> (Dependency)



[ FSFilter Infrastructure ]

LD: fltMgr.sys ----->



[ FSFilter System Recovery ]

LD: sr.sys --------->



[ Base ]

LD: KSecDD.sys ----->



[ File system ]

LD: Ntfs.sys ------->



[ Network ]

LD: Mup.sys -------->



[ !!!NO GROUP!!! ]

LD: BNPort.sys -----> Ardence PortBlocker Driver ***********************************

LD: bnnf.sys -------> Filter Driver for NDIS NIC ***********************************



[ PnP Filter ]

LD: agp440.sys ----->



[ Extended Base ]

LD: p3.sys --------->



[ !!!NO GROUP!!! ]

LD: CmBatt.sys ----->



[ Video ]

LD: ati2mtag.sys --->



[ Base ]

LD: usbuhci.sys ---->



[ Keyboard Port ]

LD: i8042prt.sys --->



[ Pointer Class ]

LD: mouclass.sys --->



[ Keyboard Class ]

LD: kbdclass.sys --->



[ System Bus Extender ]

LD: fdc.sys -------->



[ Extended base ]

LD: serial.sys ----->



[ PNP Filter ]

LD: serenum.sys ---->





LD: parport.sys

LD: ac97intc.sys

LD: audstub.sys

LD: rasl2tp.sys

LD: ndistapi.sys

LD: ndiswan.sys

LD: raspppoe.sys

LD: raspptp.sys

LD: msgpc.sys

LD: psched.sys

LD: ptilink.sys

LD: raspti.sys

LD: rdpdr.sys

LD: termdd.sys

LD: swenum.sys

LD: update.sys

LD: mssmbios.sys

LD: NDProxy.SYS

NL: NDProxy.SYS

LD: usbhub.sys

NL: lbrtfdc.SYS

NL: Flpydisk.SYS

NL: Sfloppy.SYS

NL: i2omgmt.SYS

NL: Cdrom.SYS

NL: Changer.SYS

NL: Cdaudio.SYS

LD: Fs_Rec.SYS

LD: Null.SYS

LD: Beep.SYS

LD: vga.sys

LD: RDPCDD.sys

LD: Msfs.SYS

LD: Npfs.SYS



[ Streams Drivers ]

LD: rasacd.sys



[ PNP_TDI ]

LD: ipsec.sys

LD: tcpip.sys

LD: netbt.sys



[ !!!NO GROUP!!! ]

LD: ipnat.sys

LD: wanarp.sys



[ TDI ]

LD: afd.sys



[ NetBIOSGroup ]

LD: netbios.sys



[ PCI Configuration ]

NL: PCIDump.SYS



[ Network ]

LD: rdbss.sys

LD: mrxsmb.sys



[ Pnp Filter ]

NL: Imapi.SYS





LD: Fips.SYS

LD: ndisuio.sys

NL: rdbss.sys

NL: mrxsmb.sys

LD: mrxdav.sys

LD: ParVdm.SYS

LD: srv.sys

NL: ipnat.sys

LD: TDTCP.SYS

LD: RDPWD.SYS

LD: wdmaud.sys

LD: sysaudio.sys

LD: splitter.sys

LD: aec.sys

LD: swmidi.sys

LD: DMusic.sys

LD: kmixer.sys

LD: drmkaud.sys

LD: HTTP.sys



Ardence changed the driver group load order from:

-------------------------------------------------

System Reserved

Boot Bus Extender

System Bus Extender

SCSI miniport

Port

Primary Disk

SCSI Class

SCSI CDROM Class

FSFilter Infrastructure

FSFilter System

FSFilter Bottom

FSFilter Copy Protection

FSFilter Security Enhancer

FSFilter Open File

FSFilter Encryption

FSFilter Compression

FSFilter HSM

FSFilter Cluster File System

FSFilter System Recovery

FSFilter Content Screener

FSFilter Continuous Backup

FSFilter Replication

FSFilter Anti-Virus

FSFilter Undelete

FSFilter Activity Monitor

FSFilter Top

Filter

Boot File System

Base

Pointer Port

Keyboard Port

Pointer Class

Keyboard Class

Video Init

Video

Video Save

File System

Event Log

Streams Drivers

NDIS Wrapper

COM Infrastructure

UIGroup

LocalValidation

PlugPlay

PNP_TDI

NDIS

TDI

NetBIOSGroup

ShellSvcGroup

SchedulerGroup

SpoolerGroup

AudioGroup

SmartCardGroup

NetworkProvider

RemoteValidation

NetDDEGroup

Parallel arbitrator

Extended Base

PCI Configuration

MS Transactions

-------------------------------------------------

To:

-------------------------------------------------

System Reserved

Boot Bus Extender

System Bus Extender

NDIS Wrapper

NDIS

Ardence

SCSI miniport

Port

Primary Disk

SCSI Class

SCSI CDROM Class

FSFilter Infrastructure

FSFilter System

FSFilter Bottom

FSFilter Copy Protection

FSFilter Security Enhancer

FSFilter Open File

FSFilter Encryption

FSFilter Compression

FSFilter HSM

FSFilter Cluster File System

FSFilter System Recovery

FSFilter Content Screener

FSFilter Continuous Backup

FSFilter Replication

FSFilter Anti-Virus

FSFilter Undelete

FSFilter Activity Monitor

FSFilter Top

Filter

Boot File System

Base

Pointer Port

Keyboard Port

Pointer Class

Keyboard Class

Video Init

Video

Video Save

File System

Event Log

Streams Drivers

COM Infrastructure

UIGroup

LocalValidation

PlugPlay

PNP_TDI

TDI

NetBIOSGroup

ShellSvcGroup

SchedulerGroup

SpoolerGroup

AudioGroup

SmartCardGroup

NetworkProvider

RemoteValidation

NetDDEGroup

Parallel arbitrator

Extended Base

PCI Configuration

MS Transactions

---

[was_jaclaz]

Just to keep things together I am crosslinking to this:
http://www.boot-land...?...c=2854&st=0

Is a copy of TFTP "embedded" in SETUPLDR.BIN?

jaclaz

[bombastic]

Hey Andy, have you made any progress over the last year or so?

[Sha0]

Tons of progress... I have been successful with two scenarios:

* Netbooting a full XP SP2 via SMB
* Netbooting XP SP2 via SAN-booting (iSCSI/AoE)

I've just recently added a new post which has a link to an article. You might enjoy it, though it focuses on SAN-booting rather than SMB-booting.

http://www.etherboot...t_winnt_sanboot
http://www.etherboot...t_winnt_sanboot

Perhaps this is the proper forum to post the instructions for booting a full XP SP2 via SMB... I'll try to work on that soon.

EDIT by jaclaz:
fixed link.

[Brito]

Excellent article!

Was a very enjoyable read, the instructions are very clear..

[Sha0]

Only 174 reads for that other Windows XP iSCSI post as of the time of this typing.

I'll put this link here, then: http://www.etherboot...i/sanboot/winxp

I'm messing around with tiny XPs booted via SAN-boot and will update with status.

[George In]

Hi Andy ...

Do you have a link for your successful "Netbooting a full XP SP2 via SMB"?

Thanks!

[Sha0]

I must apologize to everyone; I've been delayed in getting the documentation together for booting a full XP via SMB. Life (and work) happens, though.

Just to give you _something_, the idea is that you have your TFTPBOOT/ directory shared as, let's say, NetXP$. Then your WINNT.SIF file's SetupSourceDevice points to \\Device\LanmanRedirector\Server\NetXP$\Windows.

You have to add SETUPDD.SYS as a boot service in your fully functional Windows installation, as well it's likely a good idea to set the network adapter to boot-start. A cheap way to take care of this is to use Michael Brown's SANBootConf package from the gPXE website, otherwise, in essence the network adapter, TcpIP, PSched, GPC, NDIS, all have to have their "Start" value changed to 0 in the registry. Make sure it boots with these changes!

One this is done, you copy its registry over top of SETUPREG.HIV, which is what a WinPE (XP, 2003) loads. Then the whole installation goes into the TFTPBOOT/ directory (your NetXP$) share.

Another slight delay is that I'm considering programming some drivers to help with FS-redirection at boot time... Imagine having the FS provided over WebDAV, for example! Your WebDAV server could dynamically provide different files to different computers, based on the computers. Hence, one could have the majority of files the same, but feed different (client-specific) registries. Speed decreases, but space is gained from having a single file repository for your "image". Anyway, the driver idea is something akin to UnionFS.

I'd still like to make a nice and tidy document for booting over SMB using a RIS-like setup, but it's not done yet.

[Sha0]

By the way, you can use the uncompressed OSLOADER.EX_ from XP Pro SP2 installation source as NTLDR in a RIS setup (startrom.0) and it will TFTP BOOT.INI and allow loading boot files via TFTP. This is handy because a

ramdisk(0)\Windows="RAMXP" /fastdetect /sos /rdpath=ramxp.ntfs

entry will work. XPSP2 NTLDR supports RAMdisks, while XPSP2 SETUPLDR.EXE doesn't seem to, as has been discussed many times. Of course, you have to deal with TFTP speeds.Or, you can have

net(0)\Windows="NetXP" /fastdetect /sos

and try your luck with some of the info in this thread of posts. It's critical that the Windows installation have the appropriate services set to boot-start.I enjoy the OSLOADER.EXE option because that way I do not have to worry about licensing for XP Embedded. Read that as: An enterprise audit's results are A-OK. Also, it's nice to have the single source to build the environment from.

[Rinrin]

Hi Andy:
I have been tried with your method of "Netbooting a full XP SP2 via SMB" but no luck.
setupdd just crashed in setupdd!SpInitialize0:
*** Fatal System Error: 0x0000007e
(0xC0000005,0xF9886392,0xF9FC39E0,0xF9FC36CC)

I have found that when I'm booting from NTLDR,the SetupLoaderBlock in KeLoaderBlock is just NULL.

[Sha0]

Rinrin: This topic has been stale and without a proper HowTo for too long. Let me re-tackle this later today and see about providing the proper information. Sorry about the delay. - Sha0

[Sha0]

There are too many complications when trying to boot non-PE (full), XP/2003 clients to an SMB share. Instead, I'd like to offer the Recovery Console via PXE, TFTP, SMB.

• Install the XP/2003 Recovery Console
• Create a NetXP\ directory anywhere
• Create a Windows\ sub-directory
• Copy the CMDCONS\ directory into the NetXP\Windows\ directory named as I386\
• Move NetXP\Windows\I386\NTDETECT.COM into the NetXP\ directory
• Share the NetXP\ directory via SMB as NetXP
• Add Anonymous permissions to the share (Sharing tab)
  
  • Read
• Add Anonymous permissions to the NTFS directory (Security tab, not applicable on a FAT filesystem)
  
  • Read & Execute
  • List Folder Contents
  • Read
• Add Everyone permissions to the NTFS directory (Security tab, not applicable on a FAT filesystem)
  
  • Read & Execute
  • List Folder Contents
  • Read
• Add the share to the list of null session shares
  
  • RegEdit.exe
  • My Computer\HKLM\SYSTEM\CCS\Services\lanmanserver\parameters
  • NullSessionShares : Add NetXP to the list
  • Restart the Server service
• Make sure no firewalls are blocking your share from being accessed via SMB
• Expand the following files into the NetXP\ directory
  
  • expand d:\i386\startrom.n1_ startrom.0
  • expand d:\i386\setupldr.ex_ ntldr
  • expand d:\i386\tftpd.ex_ tftpd.exe
• Copy the following files into the NetXP\Windows\I386\ directory
  
  • copy d:\i386\ipnat.sy_ .
  • copy d:\i386\ipsec.sy_ .
  • copy d:\i386\mrxsmb.sy_ .
  • copy d:\i386\mup.sy_ .
  • copy d:\i386\ndis.sy_ .
  • copy d:\i386\netbt.sy_ .
  • copy d:\i386\rdbss.sy_ .
  • copy d:\i386\tcpip.sy_ .
  • copy d:\i386\tdi.sy_ .
• Copy any NIC drivers into the NetXP\Windows\I386\ directory
• Install MS TFTP service
  
  • sc create tftpd binPath= "drive:\path\to\NetXP\tftpd.exe"
  • reg add hklm\system\currentcontrolset\services\tftpd\parameters /v Directory /t reg_sz /d "drive:\path\to\NetXP"
  • net start tftpd
• Make sure no firewalls are blocking your TFTP service from being accessed by clients
• Create the following NetXP\WinNT.SIF file, using the appropriate ServerName:
  

  [SetupData]
  
  OsLoadOptions = "/fastdetect /sos /bootlog"
  
  SetupSourceDevice = "\Device\LanmanRedirector\ServerName\NetXP\Windows"
  
  
  
  [UserData]
  
  ComputerName = *

• Your final directory layout should look like:
  
  • NetXP\
  • NetXP\NTDETECT.COM
  • NetXP\NTLDR
  • NetXP\STARTROM.0
  • NetXP\TFTPD.EXE
  • NetXP\WINNT.SIF
  • NetXP\Windows\
  • NetXP\Windows\I386\
  • NetXP\Windows\I386\Usual Recovery Console Contents
  • NetXP\Windows\I386\Extra NIC drivers
  • NetXP\Windows\I386\ipnat.sy_
  • NetXP\Windows\I386\ipsec.sy_
  • NetXP\Windows\I386\mrxsmb.sy_
  • NetXP\Windows\I386\mup.sy_
  • NetXP\Windows\I386\ndis.sy_
  • NetXP\Windows\I386\netbt.sy_
  • NetXP\Windows\I386\rdbss.sy_
  • NetXP\Windows\I386\tcpip.sy_
  • NetXP\Windows\I386\tdi.sy_
• Get Sherpya's binlsrv.py and infparser.py
• Process an INF\ directory with .INF files for the NICs you need to support
• Serve BINL clients with binlsrv.py
• Make sure no firewalls are blocking your BINL service from being accessed by clients
• PXE-boot a computer to startrom.0

Enjoy.

- Shao Miller

[Sha0]

Now with that out of the way, you might have some fun...

It seems that the SET command is already enabled in this setup.

You can run your favourite native-mode programs by substituting them in for AUTOCHK.EXE. Consider the following NATIVE.BAT file:

x:

cd \i386

del autochk.exe

copy native.exe autochk.exe

chkdsk

Then from the Recovery Console CLI, you could do:

C:\>batch native.bat

to execute NATIVE.EXE. Note that because of the display mode, programs like Alex Ionescu's NCLI will have output that you cannot see. You could run such a program blindly since it's still accepting keyboard input. I'd like to produce a more useful native-mode program for the Recovery Console CLI.

Here's something else that might be fun:

C:\>net use \\server\share /user:dom\user n:

\\server\share has been mapped to drive letter N:



C:\>n:

N:\>

Also consider that with an SMB-booted Recovery Console, you can copy files to and from the HDD and SMB shares. This might be useful for grabbing Registry hives for modification and restoration, or whatever.

[Wonko the Sane]

There are too many complications when trying to boot non-PE (full), XP/2003 clients to an SMB share. Instead, I'd like to offer the Recovery Console via PXE, TFTP, SMB.

Very, very good.

Wonko approves of this.

Another occasion where an XPCLI might be useful.

I have a couple of questions, if you have such a build handy.

#1 What is the output of the RC commands:

map

and

map arc

?

#2 Are all the settings:

set AllowAllPaths = true

set AllowRemovableMedia = true

set AllowWildCards = true 

set NoCopyPrompt = true

by default enabled or you still need a "no more CATCH 22" batch?

Reference:
http://www.911cd.net...o...20983&st=25


Wonko

[Sha0]

#1 What is the output of the RC commands:

map

C: FAT16		210MB	\Device\Harddisk0\Partition1

D:					   \Device\CdRom0

N:					   \Device\LanmanRedirector\;N:0\server\share

X:					   \Device\LanmanRedirector\ServerName\NetXP\Windows

and

map arc

?

C: FAT16		210MB	multi(0)disk(0)rdisk(0)partition(1)

D:					   \Device\CdRom0

N:					   \Device\LanmanRedirector\;N:0\server\share

X:					   \Device\LanmanRedirector\ServerName\NetXP\Windows

#2 Are all the settings:

set AllowAllPaths = true

set AllowRemovableMedia = true

set AllowWildCards = true 

set NoCopyPrompt = true

by default enabled or you still need a "no more CATCH 22" batch?

You need to SET these away from their defaults still. You may use a BATCH file. No need to create drivers\ directory or special SOFTWARE Registry hive, as far as I can tell.

[Wonko the Sane]

Thanks.
So the batch is needed anyway.

What it is not clear is however that if the SETCOMMAND is enabled, it means that the key on the local install is not read:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Setup\RecoveryConsole\SetCommand

And if the above is what happens, also this won't probably be read:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Setup\RecoveryConsole\SecurityLevel

which equates to the "old" trick of using the 2K recovery console on XP installs:
http://pubs.logicale...icle.asp?ID=173


I mean, you do have a local install to which you connect with RC, don't you?
(without the local install the settings are obviously ignored)

And does the local install have the two keys set to 1, right?



Wonko