Serva PXE/BINL - AN02: Windows Install Adv & WinPE Boot

Starting an automated network boot of Windows PE or an advanced network install of anything from Windows 2000 to Windows 8, taking no more than 15 minutes and a ~1 MB download.

The objective of this document is to show you how to handle Microsoft Windows unattended PXE install scenarios, PXE booting WindowsPE, and finally setting Serva as a single PXE front-end simultaneously targeting Serva's own repository, Microsoft WDS/MDT/SCCM repositories, and more.

Procedures described in this document require Serva "Supporter"

Serva PXE/BINL - Application Note Set
Serva PXE/BINL - AN01: Windows Install
Serva PXE/BINL - AN02: Windows Install Adv & WinPE Boot
Serva PXE/BINL - AN03: Non-Windows Boot/Install
Serva PXE/BINL - AN04: Custom menu


0 Index

  1. Requirements
  2. Unattended Installs
  3. PXE Booting WindowsPE executives
  4. PXE Booting MS WDS, MDT, and SCCM repositories
  5. PXE Booting PE based Symantec Ghost clients
  6. PXE Multi-Repository Integration
  7. PXE Booting PE based recovery/test tools
  8. Troubleshooting
  9. Final Words

 

1 Requirements

1.1 Required Software
1.1.1 Microsoft Windows Serva 2.1 "Supporter" or higher.
1.1.2 Microsoft Install CD/DVD/ISO of the OSs you want to network install.
1.1.3 WIM files you want to network boot.
1.1.4 Microsoft WAIK/Windows ADK.
1.1.5 Microsoft WDS/MDT/SCCM boot WIMs and their repositories.

1.2 Assumed knowledge
1.2.1 Serva PXE/BINL - AN01: Windows Install
1.2.2 WAIK/Windows ADK tools.
1.2.3 WDS/MDT/SCCM.

 

2 Unattended Installs

In this chapter we explore the unattended install capabilities of Serva as an extension of the concepts developed on Serva PXE/BINL - AN01: Windows Install

2.1 RIS OSs:
In this case the WIA unattended install capabilities are fully controlled by the corresponding \_SERVA_\winnt.sif. This file normally contains information about available RIS services, the destination computer, and the type of installation you are performing. In case of an unattended install it additionally becomes the answer file that holds the install automation data.
winnt.sif is initially created by Serva setting the networking parameters required by the net install process. Additionally when we include OEM drivers under \$OEM$\$1\Drivers\NIC\ Serva updates winnt.sif telling the OS being installed that there are certain directories containing OEM drivers ready to be processed.
Users that want to automate this kind of install have to populate winnt.sif with the desired unattended parameters considering a couple of points:

  1. Serva "non-Supporter" updates winnt.sif by overwriting the previous version of it. This means "non-Supporter" users have to manually re-enter their unattended settings after a Serva winnt.sif update. Serva "Supporter" on the other hand has an edition engine able to keep winnt.sif user added parameters.

  2. Serva "Supporter" will respect your winnt.sif entries, then there is always the risk of breaking things by overwriting some of Serva's required parameters. If anything goes wrong just erase winnt.sif; Serva will automatically re-create a new working copy for you.

2.2 WDS OSs:
In this case the WIA unattended install capabilities can be fully controlled by an XML answer file (Unattend.xml) created with the "Windows System Image Manager" ImgMgr.exe (from WAIK) and conveniently placed at the corresponding WIA's \$OEM$\$1\Unattend.xml.
ServaPENet initial login to WIA_WDS_SHARE can be also automated by adding to Unattend.xml file the component "Microsoft-Windows-Setup" to the windowsPE pass with the following information:

AppliedConfigurationPass:  1 windowsPE 
Component:                 Microsoft-Windows-Setup 
Path:                      WindowsDeploymentServices/Login/Credentials 

Settings: 
Domain   = WIA_WDS_SHARE_DomainName     (populate only when required)
Password = WIA_WDS_SHARE_Password
Username = WIA_WDS_SHARE_Username
Fig 1: ImgMgr.exe ServaPENet unattended login parameters


2.2.1 For those users that only want to automate ServaPENet login and really do not want to deal with ImgMgr.exe creating Unattend.xml there is an alternative; Serva also parses WIA's \$OEM$\$1\Unattend.ini (plain text file) looking for ServaPENet login parameters:

[windowsPE-Setup-Login-Credentials] 
;Domain  = WIA_WDS_SHARE_DomainName     (uncomment only when required)
Password = WIA_WDS_SHARE_Password 
Username = WIA_WDS_SHARE_Username

2.2.2 For those users that want to automate ServaPENet login globally for all the served WDS OSs there's also an alternative by just creating a single Unattend.ini file right under WIA_WDS class directory i.e. C:\SERVA_ROOT\WIA_WDS\Unattend.ini.

When installing i.e. Windows 8 32Bit, ServaPENet will look for its automated login parameters sequentially parsing the information contained within the following files:

  1. C:\SERVA_ROOT\WIA_WDS\Unattend.ini
  2. C:\SERVA_ROOT\WIA_WDS\Win8_32\$OEM$\$1\Unattend.ini
  3. C:\SERVA_ROOT\WIA_WDS\Win8_32\$OEM$\$1\Unattend.xml


C:\SERVA_ROOT
    pxeserva.cfg
    WIA_RIS
    WIA_WDS
      Win_S2012_64
      Win8_32
        _SERVA_
        $OEM$
          $1
            Unattend.ini
            Unattend.xml
        boot
        efi
        sources
        support
        setup.exe
        autorun.inf
        ...
      w8_Ent_64
      Unattend.ini

Unnatend.xml/ini location within Serva repository structure

ServaPENet first parses the Unattend.ini common to all the WDS WIAs, next it parses the WIA's own Unattend.ini, finally it looks for login credentials within WIA's own Unattend.xml.
The first existing file having valid parameters (non-empty Username and Password) is used and stops ServaPENet's parsing sequence.

Please consider Unattend.ini only for providing login credentials and know that it can be used side-by-side with Unattend.xml i.e. in the case that you want globally set login parameters for all your WDS OSs where some of them might have unattended parameters contained on their Unattend.xml. In those cases the login information will be taken from the global Unattend.ini and the rest of unattended parameters will be taken from the corresponding Unattend.xml. When login parameters are taken from Unattend.ini, login credentials contained within Unattend.xml (if any) will be just ignored.

2.2.3 Creating and testing Unattend Answer Files is a lengthy process that implies the creation of images and their corresponding booting media support (DVD). Even if you are not planning to use network deployment Serva can really help you testing your job. Just create Unattend.xml with ImgMgr.exe directly saving it on \$OEM$\$1\Unattend.xml, close/re-start Serva and in 15 seconds you will be able to test your just created Unattend.xml by booting a PXE client; Very handy.

Notes
  1. Serva only processes "Unattend" files (xml/ini); it will ignore "Autounattend" (xml/ini)
  2. Unattend.xml should be created following the guidelines from this MS Technet article "Walkthrough: Build a Simple Answer File"
  3. Serva injected answer files will be considered by the installing OS when parsing %SYSTEMDRIVE% according to the "Implicit Answer File Search Order".
  4. The creation/edition/deletion of the global \WIA_WDS\Unattend.ini file implies the BINL re-processing of all your WDS OSs.

 

3 PXE Booting WindowsPE executives

The Windows Preinstallation Environment (aka WindowsPE, WinPE) is a lightweight version of Windows mostly used on the early stages of the deployment of workstations and servers or in troubleshooting scenarios. This tiny version of Windows comes packed in bootable WIM files originally crafted with the "Windows Automated Installation Kit" (Windows AIK or WAIK) or lately with the "Windows Assessment and Deployment Kit" (Windows ADK or WADK).

Windows PE release Operating system
1.6 Windows Server® 2003 with SP1
2.0 Windows Vista® RTM
2.1 Windows Vista with SP1, Windows Server 2008
2.2 Windows Vista with SP2, Windows Server 2008 with SP1
3.0 Windows 7 RTM
3.1 Windows 7 with SP1
4.0 Windows 8, Windows Server 2012
5.0 Windows 8.1, Windows Server 2012 R2


Serva initially boots a WindowsPE (ServaBoot.wim) every time it installs a WDS OS and it is also able to boot stand alone WindowsPE executives. It only takes populating a "head" directory under \WIA_WDS with the corresponding bootable WIM file and a very small set of extra files.
i.e.


C:\SERVA_ROOT
    pxeserva.cfg
    NWA_PXE
    WIA_RIS
    WIA_WDS
      WinPE_32
        winpe_32.wim
        boot.sdi
      WinPE_64
        winpe_64.wim
        boot.sdi
        pxeboot.n12
        bootmgr.exe

Where i.e. WinPE_32 and WinPE_64 are the user created head directories while winpe_32.wim and winpe_64.wim are the corresponding bootable WIMs.

Directory WinPE_32 holds:

  1. The WindowsPE file winpe_32.wim as it comes from Vista WAIK (Windows PE 2.0).
  2. The System Deployment Image boot.sdi as it comes from the WAIK or any WDS Windows Install Distribution DVD/ISO (\boot\boot.sdi).


Directory WinPE_64 holds:

  1. The WindowsPE file winpe_64.wim as it comes from Vista WAIK (Windows PE 2.0).
  2. The System Deployment Image boot.sdi as it comes from the WAIK or any WDS Windows Install Distribution DVD/ISO (\boot\boot.sdi).
  3. The Windows PXE Network Bootstrap Program pxeboot.n12 as it comes from WAIK or any WDS WIA (_SERVA_\pxeboot.n12).
  4. The bootmgr.exe as it comes from WAIK or any WDS WIA (_SERVA_\pxeboot.n12).
Notes
  1. A head directory must contain a single WIM file, otherwise it will be ignored.
  2. A booting WIM does not necessarily require the services of the WIA_WDS_SHARE; if you are not installing WDS OSs with Serva you do not need to create WIA_WDS_SHARE.

Now lets talk a bit about Serva/BINL internals when booting WindowsPE. Serva PXE/BINL WDS booting process takes the following steps:

  1. A PXE client boots up and after the DHCP transaction the initial TFTP transfer loads the first Network Boot Program (NBP) pxeserva.0.
  2. pxeserva.0 transfers vesamenu.c32 and displays Serva's menu.
  3. When the user performs a WDS menu selection a second NBP \_SERVA_\pxeboot.n12 gets transferred and loaded.
  4. pxeboot.n12 TFTP transfers \_SERVA_\bootmgr.exe and the \_SERVA_\boot\BCD store.
  5. bootmgr.exe reads the BCD entries, then it TFTP transfers \_SERVA_\boot.sdi and the WindowsPE WIM image (i.e. winpe_32.wim).
  6. bootmgr.exe expands and loads in memory the WindowsPE WIM image, then begins booting it by calling into its Winload.exe.
  7. At this point the loaded WindowsPE executive could do many things like displaying a console window, perform a network connection to a remote repository to continue with an OS network install, load a test/recovery environment, etc. It all depends on how the WindowsPE was crafted.

Because of the above sequence, one is able to see there is a strong relationship between pxeboot.n12, bootmgr.exe and the WIM file (i.e. winpe_32.wim). in the early days of the WIM file format it was pretty common having WIM files that were not compatible with some versions of pxeboot.n12/bootmgr.exe. Today (02/2013) the WIM file format is somehow stable and WIM files and matching pairs of pxeboot.n12/bootmgr.exe can be exchanged fairly easily.
The bootmgr.exe performs the TFTP transfer of the WIM file which is about 150-200 Mb in size. This size is not small for a protocol like TFTP. Since Windows PE 2.1 bootmgr.exe is able to handle the TFTP negotiated variable windowsize normally offering faster TFTP transfers on high quality networks. Serva's TFTP server module handles the windowsize variable; it always helps to use the "windowsize enabled" bootmgr.exe. In order to know if your bootmgr.exe handles windowsize you can always open the file with your favorite Hex editor looking for the word windowsize in plain ASCII.

Notes
  1. Most of the time the files pxeboot.n12 and bootmgr.exe are included within the bootable WindowsPE file; for that reason Serva will automatically try to extract them if they are not already present next to the WIM file. If the files are neither next to the WIM nor included within it; Serva gives an error.
  2. In the unusual case that the embedded pxeboot.n12/bootmgr.exe were not compatible with the container WIM (i.e. poorly crafted custom WindowsPE) you can always add a working pair of files next to the WIM. For Serva the external pxeboot.n12/bootmgr.exe set has always precedence over the internal set.

In the example above we boot the 2 versions of winpe.wim coming with the old Vista WAIK (Windows PE 2.0). winpe_32.wim is booted using its internally contained pxeboot.n12 and bootmgr.exe.
winpe_64.wim
is booted using an externally provided set of pxeboot.n12 and bootmgr.exe coming from i.e. a Windows 8 WIA or from some of the WindowsPE today included within Windows ADK (Windows PE 4.0).
For all the preceding explanation about TFTP transfers winpe_64.wim using Windows 8 pxeboot.n12 and bootmgr.exe will boot faster than winpe_32.wim using its old internal files.


Fig 2-3: Booting WindowsPE executives

The text displayed on menu entries is gathered by Serva from the booting WIM itself. Unfortunately there are times when booting WIM based products do not include an appropriate descriptive name or this one is completely missing. i.e.
"Acronis Back up & Recovery" entries will be displayed as "Microsoft Windows Vista PE (x86)"
"Ghost SGSS" entries will be displayed as "Product ?"
After the menu creation you can always manually rename menu entries adding more suitable names by editing \pxeserva.cfg\menu.def.

Note
  1. In the former example we boot old Windows PE 2.0 WIMs just to address the related TFTP topic. The procedure for booting current Windows PE 4.0 WIMs is exactly the same.
  2. From a consistency point of view you should always initially try to boot letting Serva extract pxeboot.n12 and bootmgr.exe from within the bootable WindowsPE. Only in case of file extraction errors (missing files) you should think of providing them externally always as a matching pair.


3.1- OEM Driver injection.
Driver injection when booting WindowsPE executives works exactly the same as when installing WDS OSs. See "8.3.2- WDS OS OEM network drivers" at Serva PXE/BINL - AN01: Windows Install.

 

4 PXE Booting MS WDS, MDT, and SCCM repositories

When we PXE install a WDS OS with Serva the process can be split on two different stages:
a) TFTP transferring and booting of the corresponding ServaBoot.wim (WindowsPE).
b) Transferring of the OS components from Serva repository in order to continue with the OS install.
It is the booting ServaBoot.wim which has the information on how to network locate Serva repository and what to do with it.
Microsoft WDS, MDT and SCCM all use a similar strategy; they all produce booting WIMs, containing the information on how to network locate their repositories (stores) or DPs (SCCM Distribution Point), and know what to do with them.
If we would be able to PXE boot those WIM files with Serva we would get integrated within the same single menu, entries pointing to Serva's own assets with entries pointing to WDS, MDT, and SCCM "entry points". We certainly can do this by using what we just have learnt in 3 PXE Booting WindowsPE executives !

4.1- PXE Booting WDS repositories under Serva control.

From MSDN:
The Windows Deployment Services "client" is an application that runs within Microsoft Windows Preinstallation Environment (Windows PE), enabling you to select and install an install image from a Windows Deployment Services server. This application is, in fact, Setup.exe from Windows Vista with some additional functionality that is needed for network deployments. This mode differs from the normal Setup.exe mode in that the Windows Deployment Services client has the following features:

  1. Logic to interact with a Windows Deployment Services server to retrieve the list of available install images and perform the installation
  2. A unique set of user interface (UI) screens, including an authentication and credentials page
  3. The ability to handle more advanced unattended installation scenarios, including obtaining an unattend file from a Windows Deployment Services server and performing variable string replacement
  4. The ability to deploy install images from Windows 2000, Windows XP, and Windows 2003 along with Windows Vista and Windows Server 2008

While the above paragraph describes the WDS "deployment" windowsPE client there is also a similar WDS "capture" WindowsPE client. All these clients come in both 32 and 64 bit flavors.

Depending on how you named your WindowsPE booting images within WDS you might have gotten something like this:

\Boot\x32\Images\WDS_Capture_WinPE_x32.wim
\Boot\x64\Images\WDS_Capture_WinPE_x64.wim
\Boot\x32\Images\WDS_Deploy_WinPE_x32.wim
\Boot\x64\Images\WDS_Deploy_WinPE_x64.wim

Just take copies of the needed WIMs and put them under Serva control within their corresponding head directories as explained at 3 PXE Booting WindowsPE executives. Next, just boot your PXE client.

Note
Always remember turning WDS PXE capabilities off when booting the PXE client:
WDS Server right click "Properties", click on the "PXE Response" tab, selecting "Do not respond to any Client".


4.2- PXE Booting MDT repositories under Serva control.
Considering i.e. an updated MTD "MDTDemo" deployment share at C:\MDTDemo you should be able to find its booting images at:

C:\MDTDemo\Boot\LiteTouchPE_x86.wim
C:\MDTDemo\Boot\LiteTouchPE_x64.wim

Just take copies of the needed WIMs and put them under Serva control within their corresponding head directories as explained at 3 PXE Booting WindowsPE executives. Next just boot your PXE client.

Note
MDT forces you to use Windows Server OSs for PXE because this capability is in fact provided behind the scenes by WDS which is a server-only component. If you need PXE initiated MDT functionality at locations where you do not have a Windows Server OS, you should probably consider Serva on Windows 7/8 as a neat and affordable solution.


4.3- PXE Booting SCCM repositories under Serva control.
Considering i.e. a particular DP on your SCCM hierarchy having:

C:\RemoteInstall\SMSBoot\x86\boot.wim
C:\RemoteInstall\SMSBoot\x64\boot.wim

Just take copies of the needed WIMs and put them under Serva control within their corresponding head directories as explained at 3 PXE Booting WindowsPE executives. Next just boot your PXE client.

Note
SCCM forces you to host your DPs (Distribution Point) on Windows Server OSs for PXE because this capability is in fact provided behind the scenes by WDS which is a server-only component. If you need PXE initiated OSD functionality at locations where you do not have a Windows Server OS, you should probably consider Serva on Windows 7/8 as a neat and affordable solution.

4.3.1 If you ever wonder which architecture of boot image to use during SCCM OSD please consider:

  32bit Image 64bit Image 32bit Pkg 64bit Pkg
x86 Boot WIM Yes Yes Yes No
x64 Boot WIM No Yes No Yes

 

5 PXE Booting PE based Symantec Ghost clients

Both the Console, and the Standard Tools include WinPE 2.0 based booting capabilities. The Ghost Boot Wizard allows you to select the PreOS version to use; just select WinPE and the created booting ISO will contain:

G:\SOURCES\BOOT.WIM

Just put BOOT.WIM under Serva control within its corresponding head directory as explained in 3 PXE Booting WindowsPE executives. Next just boot your PXE client.

Note
Ghost crafted WIM files have "missing" WindowsPE names, forcing Serva to name the corresponding menu entries as "Product ?". You can always manually rename menu entries using more suitable names by editing \pxeserva.cfg\menu.def

 

6 PXE Multi-Repository Integration

The integration in one network segment of the PXE access to different solutions like WDS, MDT, SCCM, Ghost, Acronis, etc, can many times result complicated and time consuming.
Serva offers the simple alternative of a single PXE service able to target as many different solutions as you need, under the control of just only one automatically created access menu. i.e.

 

Fig 4: multi-Repository single-Menu Serva PXE/BINL integration


The Fig 4 depicts the WIM/Asset flow on a Serva PXE/BINL "multi-Repository" scenario.

  1. Initially we copy under Serva control (as explained in 3 PXE Booting WindowsPE executives) the different repositories's boot.wim files (actually depending on the repository they have different names like LiteTouchPE_x86.wim, WDS_Capture_WinPE_x32.wim, Boot.wim, etc.)
  2. Next when a PXE client boots-up it receives Serva's PXE offer displaying Serva's PXE/BINL menu including entries pointing to all the repositories.
  3. When the client makes its booting decision the corresponding Boot.wim is TFTP transferred from Serva repository and run at the client. It is this particular component the one that knows how to connect to its corresponding back-end repository and what to do with it.
  4. From this moment-on all the component transfers between the repository and the client are carried-out using a repository offered network share, while Serva's PXE/BINL services rest.

 

7 PXE Booting PE based recovery/test tools

Serva is able to PXE boot thousands of PE based recovery/test tools, the following are just a few examples for you to know how to get running your particular case.

7.1 Windows Defender Offline (WDO)
Download WDO downloader mssstool32.exe or mssstool64.exe from here. Run the corresponding downloader and save WDO as ISO file.

Fig 5: Downloading WDO as ISO file with mssstool32.exe/mssstool64.exe

7.1.1 WDO 32Bit

Extract from the downloaded WDO_Media32.iso
G:\sources\boot.wim
G:\mpam-fe.exe
G:\FilesList32.dll

Put boot.wim under Serva control within its corresponding head directory as explained in 3 PXE Booting WindowsPE executives.
Copy mpam-fe.exe and FilesList32.dll under i.e.
C:\SERVA_ROOT\WIA_WDS\WDO_32\$OEM$\$1
Stop/re-start Serva.


7.1.2 WDO 64Bit

Extract from the downloaded WDO_Media64.iso
G:\sources\boot.wim
G:\mpam-fex64.exe
G:\FilesList64.dll

Put boot.wim under Serva control within its corresponding head directory as explained in 3 PXE Booting WindowsPE executives.
Copy mpam-fex64.exe and FilesList64.dll under i.e.
C:\SERVA_ROOT\WIA_WDS\WDO_64\$OEM$\$1
Stop/re-start Serva.

Note
  1. WDO crafted WIM files have "default" WindowsPE names; their Serva menu entries will look like i.e. "Microsoft Windows Vista PE (x86)". You can always manually rename menu entries using more suitable names by editing \pxeserva.cfg\menu.def
  2. PXE booting WDO for parsing a 64 bit OS requires booting WDO 64 bit.
  3. Keeping the definition file updated only takes updating FilesList32.dll/FilesList64.dll and stop/re-start Serva.

 

7.2 ESET SysRescue
From the created ISO extract:

G:\SOURCES\BOOT.WIM

Put BOOT.WIM under Serva control within its corresponding head directory as explained in 3 PXE Booting WindowsPE executives. Next just boot your PXE client.

Note
Eset SysRescue crafted WIM files have "default" WindowsPE names; their Serva menu entries will look like "Microsoft Windows Vista PE (x86)". You can always manually rename menu entries using more suitable names by editing \pxeserva.cfg\menu.def

 

7.3 Acronis Backup & Recovery CD
Use the generated Acronis.wim or from Acronis CD/ISO extract:

G:\sources\boot.WIM

Put Acronis.wim or boot.wim under Serva control within its corresponding head directory as explained in 3 PXE Booting WindowsPE executives. Next just boot your PXE client.

Note
Acronis crafted WIM files have "default" WindowsPE names; their Serva menu entries will look like "Microsoft Windows Vista PE (x86)". You can always manually rename menu entries using more suitable names by editing \pxeserva.cfg\menu.def

 

7.4 Active@ Boot Disk, Active@ Undelete, etc.
From the created ISO extract:

G:\SOURCES\BOOT.WIM

Put BOOT.WIM under Serva control within its corresponding head directory as explained in 3 PXE Booting WindowsPE executives. Next just boot your PXE client.

Note
Fortunately these are well crafted WIM files offering meaningful names to the corresponding Serva menu entries i.e. "Active@ Boot Disk"

 

7.5 Paragon Advanced Recovery CD, etc.
From Paragon CD/ISO extract:

G:\SOURCES\BOOT.WIM

Put BOOT.WIM under Serva control within its corresponding head directory as explained in 3 PXE Booting WindowsPE executives. Next just boot your PXE client.

Note
Paragon crafted WIM files have "default" WindowsPE names; their Serva menu entries will look like "Microsoft Windows Vista PE (x86)". You can always manually rename menu entries using more suitable names by editing \pxeserva.cfg\menu.def

 

8 Troubleshooting

8.1 General WDS boot/install

Please see the WDS related topics from the troubleshooting section at Serva PXE/BINL - AN01: Windows Install.


8.2 Booting Windows PE Executives

8.2.1 Missing required files.
When Serva processes Windows PE assets you can see errors like:

[...] BINL Inf: Expandd OK, C:\SERVA_ROOT\WIA_WDS\WinPE_x64\_SERVA_\pxeboot.n12
[...] BINL Err: Expanding C:\SERVA_ROOT\WIA_WDS\WinPE_x64\_SERVA_\bootmgr.exe

In this case the file bootmgr.exe was not found next to the bootable WIM nor within the WIM either. The error mentions "Expanding" as the last process that failed when looking for bootmgr.exe before aborting any further process on the asset.
You can quickly solve this problem by adding next to the WIM a matched pair (same Windows PE version) of pxeboot.n12/bootmgr.exe files.

 

9 Final words

The discussed Serva PXE/BINL advanced techniques represent one more step in the road to master the different Microsoft Windows net boot/install scenarios. Advanced users can now perform unattended PXE installs and PXE multi-repository integrations on a simple to use application.
For those Serva PXE/BINL users also interested on network boot/install Linux distributions, Native Hypervisors, Recovery Tools, DOS/FreeDOS, etc, please read here Serva PXE/BINL - AN03: Non-Windows Boot/Install about all of these exiting new features.

If you find Serva useful please consider contributing to the project by purchasing Serva's "Supporter" build. Supporter builds make possible Serva's maintenance and future development.

Serva bugs, comments, or ideas on how to improve the information contained in this document please contact me here.

Originally published 02/01/2013
Edited by Tyler Cookson