17

Some years ago at my university, I recall that the labs there booted Windows NT over the network.

There was a shared drive for your own stuff and other than that any changes you did to the running OS were reset when you restarted the machine.

Now I'd like to be able to do the same thing with Windows 7.

I have found some how to's for this using iSCSI, but I don't want an iSCSI disk for every single PC, I want one image for multiple PC's. I've also found PXE Boot setup files for installing Windows locally, but that's not what I want either.

How would I go about setting up what I had at university but with Windows 7 as a OS to netboot?

i.e. How do I netboot Windows 7 images? I do not want to netboot a Windows 7 installer to a PC to install Windows locally, I want to run a Windows 7 image from memory/network.

slayernoah
  • 1,570
  • 2
  • 12
  • 19
hookenz
  • 14,132
  • 22
  • 86
  • 142
  • You'd set up a server with a Windows7 image on it, set your clients to PXE boot and... well, what's the real question or issue here? – HopelessN00b Aug 08 '12 at 02:39
  • 1
    "with a Windows7 image on it". How do you generate pxe bootable images? I presume these have to run like a livecd. – hookenz Aug 08 '12 at 02:53
  • 1
    @HopelessN00b I think Matt is asking about *how* to build/configure custom WIMs to boot via PXE. Perhaps info about PXE booting multi-gig WIMs would also be helpful? – jscott Aug 08 '12 at 02:53
  • 1
    Absolutely. They will be multi-gig. On Linux I can use nfsroot which means for large images they don't all have to be in memory. What option is there for windows? minimal windows and software installed on SMB share? – hookenz Aug 08 '12 at 03:00
  • @Matt You're looking to netboot into a Window7 image, not "deploy"/install a Windows7 image to clients, right? – HopelessN00b Aug 08 '12 at 03:31
  • That's exactly what I'm asking. I'll update the question with that stated. – hookenz Aug 08 '12 at 03:57
  • 1
    What about virtual desktops? Run multiple instances of windows on a central server and then clients can access them with a wide variety of clients. – rnxrx Aug 08 '12 at 06:35
  • The problem with virtual desktops is that you don't get access to the graphics hardware. Also, have you ever tried to watch a video over terminal server? it's generally unwatchable. So while I think VD is a good solution in some instances... it's not for mine. – hookenz Aug 08 '12 at 22:51
  • @Matt, Not only does Hyper-V and ESX have remote hardware video acceleration these days, but Terminal Server 6.0+ with MSTSC 7.0+ plays 1080i over GbE fairly well. – Chris S Aug 09 '12 at 03:45
  • @Chris S - what about CUDA? according to this, no because it's still an emulation layer. http://stackoverflow.com/questions/2260931/cuda-program-on-vmware – hookenz Oct 01 '12 at 20:46
  • 1
    Citrix Provision server had this feature. I could boot an entire 30 station lab (All the same hardware) with out having an local harddrive installed. It did a PXE Boot and booted from an disk image. Users then logged in and saved data to a network drive. It was very fast and not hard to setup. But alas it was too expensive and so I am back to the old method of booting from a local harddrive. I also would like to accomplish this. –  Jan 04 '13 at 21:36
  • Remote desktop is not a practical solution when you want access to cuda for your local graphics hardware. What if you have 50 PC's needing it? Sharing one or two GPU's in a server isn't going to cut the mustard sorry. – hookenz Oct 17 '13 at 20:54

5 Answers5

6

To answer my own question. It is possible using iPXE and iSCSI or AoE. The idea is to either replace the network card option ROM with iPXE or to chainload ipxe and then do a sanboot.

iSCSI is the easier of the two san protocols because you can actually install Windows 7 directly to an iSCSI target. This is because iSCSI support is built into windows 7 while AoE is not.

See: archive.org mirror of windowsdiskless.wordpress.com

Or: archive.org mirror of windowsdisklessaoe.wordpress.com

Noting of course that although iSCSI supports multiple machines accessing the same target with NTFS. Corruption will occur. Either a Copy on Write mechanism at the back end needs to be employed, or create a base image (template) and copy that to a newly exported target.

I ended up patching the open source iscsi target from freebsd and adding copy on write. So I could use the same LUN but the writes were directed elsewhere. I was able to direct them to local RAM or to another file on the server. I'm not using this anymore though, it was a proof of concept.

Andrew Domaszek
  • 5,103
  • 1
  • 14
  • 26
hookenz
  • 14,132
  • 22
  • 86
  • 142
  • 3
    Doing this with block-level storage will lead to NTFS corruption. In your question you state that you want *multiple* computers to be able to boot the same installation. Mounting and sharing the same NTFS volume across multiple clients will cause corruption, file lock issues, etc. Have you actually tried this? – MDMarra Oct 01 '12 at 00:22
  • 1
    I'm aware of that issue. You can do this with a copy on write mechanism at the back end or copy the base image as a template to a new copy and export that. – hookenz Oct 01 '12 at 20:16
5

The scenario you describe essentially amounts to the use of each workstation as a thin client to access a centrally located desktop environment. It would be highly impractical for Windows 7 to boot from PXE even if it could be done.

Whenever PXE is used to boot, it downloads the entirety of the boot image to the client system, which would mean several GB of transfer at each boot.

Ideally, this scenario is accomplished by keeping the desktop environments on the network in the central location. In a Virtual Desktop Infrastructure (VDI) environment, this is accomplished using virtualization to allow separate virtual desktop environments to reside together on hardware, the virtual environments are provided to the clients through a manager. In a session based environment, each user’s desktop environment launches natively on the server and is brokered to the clients through a technology like Remote Desktop Services.

In both instances, the workstation must still run an operating system; however it is typically a very lightweight operating system providing a basic interface for the hardware and a client for redirection to the server hosting the desktop environments. For customers with Software Assurance, Microsoft provides Windows Thin PC as a lightweight operating system designed to connect through Remote Desktop Services to a Windows Server. Additional features supported like RemoteFX support for enhanced graphics, DirectAccess VPN connectivity, and BitLocker encryption help to provide the optimum thin client operating system for repurposing desktop hardware.

If the above sounds like the right route for you, you can find more information, guides for IT professionals, access to trials and betas, and much more in the Desktop Virtualization Center of the Springboard Site on TechNet.

slayernoah
  • 1,570
  • 2
  • 12
  • 19
WinOutreach2
  • 276
  • 1
  • 3
3

It's not possible to boot Windows 7 over PXE or anything similar to that. Windows PE (Pre-Installation Environment; which is licensed only for maintenance and installation purposes and has nothing like a normal Windows Desktop) can be PXE booted. Certain other versions of Windows that you're not interested in can also be PXE booted, but nothing like a Desktop OS.

Most Enterprise-grade iSCSI targets can do thin provisioning, where they use the same base image for all systems and only the differences take up extra space. Also, Windows doesn't support single instance boot (yet; it's something MS has been kicking around internally for a while now). So each computer does need to see different storage, they can't yet share.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • After some more research I found ccboot. And then I found AoE and vblade and this link looks promising. http://www.etherboot.org/wiki/appnotes/cow – hookenz Aug 08 '12 at 04:33
  • 4
    The Etherboot CoW stuff looks interesting, but a kitten dies every time a SysAdmin deploys AoE =[ – Chris S Aug 08 '12 at 04:46
  • It should have better performance than iSCSI though. AoE isn't exactly that secure. If an iSCSI target were to be compromised surely iSCSI is not any more secure as AoE. Once you break into the target you're in. A hacker could just delete the filesystem if they have enough permissions. – hookenz Aug 08 '12 at 04:55
  • 1
    AoE has nothing but MAC filtering for security. The whole RFC is 7 pages long. iSCSI has CHAP password authentication, standard firewall rules, IPSec, *and* MAC Filtering. iSCSI is slower than AoE, unless you have iSOE NICs (iSCSI Offload Engine Network Interface Cards), which accelerate iSCSI similar to TOE (TCP Offload Engine). Regardless, AoE can't be routed over the Internet, so hacking it is pretty tough; iSCSI best practices are to vLAN the SAN traffic; hacking any form of SAN is oddly rare. – Chris S Aug 08 '12 at 12:38
  • Thanks that's really interesting. The other problem with AoE is that it would appear it is not very friendly to other network traffic. Which may cause some problems if there is a lot of AoE traffic on the network. – hookenz Aug 08 '12 at 22:49
  • @Matt That's the problem with questions like that, it used to be an emulation layer in ESX (and several other visualization platforms). That's not the case now however, and there are virtualization extensions for the PCI Express bus itself to make passthrough easier, with less overheard, and with more features (this only applier to fairly recent hardware, look for PCIe-IOV and PCIe-ATS). For ESX [VMware KB 1010789](http://kb.vmware.com/kb/1010789) has instructions for setting up the passthrough. KVM & Xen works (note: may not work with just any hardware). Hyper-V doesn't (thanks MS) – Chris S Oct 01 '12 at 21:38
2

not possible to use same image, but you can use the deduplicated filesystem to use a lot of cloned images and safe disk space, i think the result will be the same.

Try to use my distro with SDFS, OpenDHCP for simple configuration and AoE to boot diskless Windows...

http://windowsdisklessaoe.wordpress.com

and the preview release of distro here:

http://susestudio.com/a/UZQFsW/windows-diskless-with-aoe

user156166
  • 21
  • 1
2

xMy solution for identical problem:

Hardware: Igel Thin Client (winNET p680, 1.5 Ghz, 1 GB CF, 1 GBit NIC in pci)

does a IPXE-Boot to iSCSI-disk with Windows 7 ThinPC (ISCSI is located on nas4free)

The Steps are:

  1. Format USB / CF with FAT32 with freeware USBFormat

  2. Install grub4dos on USB / CF and copy files "grldr" an "menu.lst" from grub4dos directory to USB / CF with editor change menu.lst

    default 0

    title Windows ThinPC

    kernel /ipxe.lkrn

  3. build with "rom-o-matic.eu" ipxe.lkrn and save it after download on USB /CF choose advanced and linux kernel Attention 1: only mark option for booting iSCSI, rest unchanged Attention 2: Embedded script is (change ip an iqn !):

    "#!ipxe

    dhcp net0

    sanboot iscsi:192.168.???.???::::iqn.2007-09.jp.ne.peach.istgt:disk?

    set keep-san 1"

    With Virtualbox I installed a Windows 7 TC VM. The disk has to be VHD with fixed size (
    7 GB and later expanded on LUN to 25 GB).
    Then I "restored" with winimage 9.0 the VHD to iSCSI from my Windows machine.

Remark for owners of Igel: The Igel TC has now dual monitor in Windows 7 (driver from Top4download 22.00.01u). For Audio use Vinyl Deck. The Igel performs like a desktop. The processor isn't lame.

The Solution from windowsdiskless isn't smart and simple and did not work for me.

avalk
  • 21
  • 1
  • I ended up modifying the source code to a popular iSCSI client and adding in a new backend with copy on write. Writes went to temporary storage or ram if you choose. – hookenz May 27 '14 at 20:41