• Home
• Application Notes
  • PXE/BINL
    • 1 Windows Basis
    • 1.1 Windows WDS
    • 1.2 Windows RIS
    • 2 Windows Adv/PE
    • 3 Non-Windows
    • 4 Custom Menu
    • 5 Windows TSM
    • 6 Windows ARM
• Advanced
  • Serva Protocols
  • TFTP Topics
  • DHCP Topics
  • Creating NSS
  • PXE Error Codes
• Troubleshooting
• Tools
  • PXESERVA Pwd
  • ePuTTY 32/64
• References
• Download
• Contact

Serva PXE/BINL - Application Note Set
PXE/BINL - AN01: Windows Network Install - Basis
PXE/BINL - AN01.1: Windows Network Install - WDS OSs
PXE/BINL - AN01.2: Windows Network Install - RIS OSs
PXE/BINL - AN02: Windows Network Install (Adv) & WinPE Boot
PXE/BINL - AN03: Non-Windows Network Boot/Install
PXE/BINL - AN04: Custom menu
PXE/BINL - AN05: Windows Network Image Capture & Deploy
PXE/BINL - AN06: Windows Network Image Capture & Deploy on ARM

0 Index

1. Deployment
2. Customization
3. Security
4. Performance
5. Troubleshooting
6. Final Words

1 Deployment

In this chapter we explore Serva's capabilities installing WDS OSs (MS Vista and up) as an extension of the concepts initially developed on PXE/BINL - AN01: Windows Install - Basis

1.1 Serva has been tested installing the following WDS OS distributions:

Windows Thin PC - (x86)
Windows Embedded 2009- Standard/POSReady(x86/64)
Windows Embedded 7- Compact/Standard/POSReady (x86/64)
Windows Embedded 2013- Compact (x86/64)
Windows Embedded 8- Standard/Industry Pro (x86/64)
Windows Embedded 8.1- Industry Pro/Industry Enterprise (x86/x64)
Windows 10 Iot Enterprise LTSC 2019 - High End Edition/Value Edition/Entry Edition (x86/x64)
Windows 10 Iot Enterprise 1909 - (x86/x64)
Windows 10 Iot Enterprise 2004 - (x86/x64)
Windows 11 Iot Enterprise 21H2/22H2 - (x64/Arm64)

Windows Vista - Starter/Home Basic/Home Premium/Business/Enterprise/Ultimate (x86/64)
Windows 7 - Starter/Home Basic/Home Premium/Professional/Enterprise/Ultimate (x86/64)
Windows 8 upgrade ESD - Pro (x86/64)
Windows 8 - Basic/Pro/Enterprise (x86/64)
Windows 8.1 - Basic/Pro/Enterprise (x86/64)
Windows 10 (all releases and updates) - Home/Education/Pro/Enterprise (x86/x64)*
Windows 11 (all releases and updates) - Consumer/Business (x64)
*ISOs created by the Media Creation Tool should be either x86 or x64 but not both.

Windows Server 2008 R2 - Foundation/Standard/Web/Enterprise/Datacenter (x86/64)
Microsoft Hyper-V Server 2008 R2 (x64)
Windows Home Server 2011 - Standard/Premium (x86/64)
Windows Small Business Server 2011 - Essentials/Standard/Premium (x64)
Windows Server 2012 - Standard/Essentials/Datacenter (x64)
Microsoft Hyper-V Server 2012 (x64)
Windows Server 2012 R2- Standard/Essentials/Datacenter (x64)
Microsoft Hyper-V Server 2012 R2 (x64)
Windows Server 2016- Standard/Essentials/Storage (x64)
Microsoft Hyper-V Server 2016 (x64)
Windows Server 2019- Standard/Datacenter/Essentials (x64)
Microsoft Hyper-V Server 2019 (x64)
Windows Server 2004- Standard/Datacenter (x64)
Windows Server 20H2- (x64)
Windows Server 2022- (x64)

1.2- Creating the MS Network Share.

While the initial net install stages use TFTP for transferring the required components there's a moment when the install process requires accessing the rest of files by using the services of a Microsoft network share.

1.2.1 When installing WDS OS's directory WIA_WDS has to be shared as WIA_WDS_SHARE . This share will be required to grant access to at least one user with reading rights (read-only). Access credentials (valid username with a non-empty password) will be required by ServaPENet (see 1.6) before remotely accessing the share from a booting client.

1.3- Populating Serva's WIA_WDS class directories.

It is time now to populate WIA_WDS class directoriy with the content taken from the Windows Installation Distributions (WIDs) corresponding to the OSs that we are planning to offer for network install.

Please consider:
a) WIA_WDS will hold only Windows Vista and up distributions (32/64).
b) Every distribution has to be copied in full under its own manually created "head" directory exactly as it comes from the Microsoft distribution media.
c) While "head" directory names do not really matter they can only contain ASCII characters with no spaces.

When we finish creating the head directories and copying our Windows distributions into them we might have gotten something like this:

Where i.e. W_S2022_x64, W10_bz_22h2_x64, W10_bz_22h2_x64, etc, are the user created head directories and,
W_S2022_x64, holds the files and directory structure identically copied from a windows_server_2022_x64_dvd.iso,
W10_bz_22h2_x64 holds the files and directory structure identically copied from a windows_10_business_editions_version_22h2_x64_dvd.iso, etc, etc...

1.4- Quit and restart Serva.

At this point, after quitting and restarting Serva, we will see most of BINL's "preparation" processes in full action. The Log window (default on Serva init) will show all this activity where every Windows Install Distribution (WID) is basically converted into a Serva Windows Installation Asset (WIA). Every WID conversion usually takes no more than a few seconds (see Performance).
On the following Serva quit and restart cycles, BINL on init, will mostly perform quicker "maintenance" procedures of the already processed installation assets.
A quick way to find errors on the Log pane is holding depressed [CTRL] while going up/down with your keyboard arrows or mouse wheel. Alternative holding depressed [CTRL]+[Shift] while going up/down will keep selected all the error lines found.

1.5- Booting a PXE Client.

If there were no errors in the former step (see the Log pane) it is now time to boot our first PXE client. We should quickly see one of the three possible Serva multi-OS PXE Boot/Install Menu:

The Fig 1 shows the menu that a generic PXE client, depending on its pre-boot environment, will display as soon as it boots-up. From this point we just select the desired OS and hit [Enter] to install it from the net. Of course the displayed menu entries correspond to the OS distributions that were conveniently copied under WIA_WDS and other class directories.

WDS OSs sometimes contain more than one OS flavor within the same distribution. On these cases Serva uses a simple algorithm displaying as menu entry name the longest character string common to all the included OS flavor names. i.e. Windows 8 DVD includes flavors “Windows 8” and “Windows 8 Pro”. Serva will take “Windows 8” as the displayed menu entry name. Of course despite the displayed menu entry name the user is always able to select the flavor to be installed in a further step; sometimes by the use of a flavor selecting menu (i.e. Windows Vista), sometimes automatically selected upon the user provided license key (i.e. Windows 8). Menu entry names are finished by indicating the distribution included architecture/s (x86, AMD64, etc.).
Customizing menu items implies manual editing of the corresponding menu definition file (please see Customization).

1.6- Log in to Serva's WIA repository.

As we have said before WDS OSs use a regular share (WIA_WDS_SHARE) and also need some extra processing. Both things are automatically handled on the booting client by ServaPENet.

This shell finishes its job by asking a valid username/password set in order to connect to WIA_WDS_SHARE and continue with the net install.

1.7- Understanding PXE and Windows 10 deployment example with Serva.

2 Customization

2.1- Serva Menu

Serva menu can be user customized but only "Serva Pro" includes the engine able to of keep those user customizations when Serva needs to re-create its menu. For more information see Serva PXE/BINL - AN04: Custom menu paragraph 4.5 Menu entry Title.

2.2- Serva Help

Serva multi-OS PXE Install Menu includes a Help system (template) that can be easily customized editing

C:\SERVA_REPO\BM\PXESERVA\BIOS\pxeserva.cfg\F1
C:\SERVA_REPO\BM\PXESERVA\EFI64\pxeserva.cfg\F1
C:\SERVA_REPO\BM\PXESERVA\EFI32\pxeserva.cfg\F1

following the PXESERVA text file rules or by using this handy graphic utility IsoLinuxMate_1.0.1

2.3- Serva Windows Assets

All the Windows Install Distributions (Retail, MSDN, etc.) install a Windows OS containing the set of features and applications defined by Microsoft at design time. There are situations when users might want to customize the install process in order to get copied/installed i.e. new applications, new files, probably trigger some new functionality, etc.

2.3.1- WDS Windows Install Distributions

a) Customizing WDS distributions can be easily done by editing the install image <head_dir>\Sources\Install.wim with the "Microsoft Deployment Image Servicing and Management" (dism.exe) tool.

b) "Serva Pro" allows to copy/overwrite alternative files at the end of the OS install process according to the following table.

b.1) Transferring OEM/additional Applications:
i.e. the following file:
.\Sources\$OEM$\$1\AppSetup\MSOffice\en_office_professional_plus_2016.iso
will be copied at the target PC as:
C:\AppSetup\MSOffice\en_office_professional_plus_2016.iso
When the OS setup is finished the OEM applications can be manually or automatically installed from the local disk drive.

b.2) Updating OS components:
i.e. the following file:
.\Sources\$OEM$\$$\Notepad.exe
will be copied at the target PC as:
C:\Windows\Notepad.exe
When the OS setup is finished the existent Notepad.exe gets overwritten by the new one.

3 Security

Network installations of Microsoft's OSs are usually performed on non-hostile environments (or at least behind a firewall and/or NAT device). Nonetheless, a brief Serva PXE/BINL security assessment will help users deploy network install environments with the highest possible level of security.

3.1- Serva's BINL net offered file resources associated risks

3.1.1- TFTP
Serva's TFTP root directory (i.e. C:\SERVA_REPO) is the heart of Serva's PXE/BINL strategy. This means absolutely all the files we add under this directory will be potentially available for download using a TFTP client if the "attacker" knows the full TFTP path and filename.
This should not represent a security breach considering TFTP has not file browsing capabilities and Windows installation distributions do not really contain security-sensitive information. Users installing customized or unattended versions of Microsoft OSs could potentially expose their embedded license keys.
Serva TFTP service should always be set as "read-only" (default) when used with BINL; this way a potential "attacker" will not be able to overwrite BINL file structure using a TFTP client.

3.1.2 WIA_WDS_SHARE Microsoft Network Share
Only authenticated users would be able to read-only browse its content.

3.2- Serva's BINL net offered install services associated risks

The PXE/BINL install services are accessed by Serva Multi-OS PXE Boot/Install Menus. If required its definition files

C:\SERVA_REPO\BM\PXESERVA\BIOS\pxeserva.cfg\menu.def
C:\SERVA_REPO\BM\PXESERVA\EFI64\pxeserva.cfg\menu.def
C:\SERVA_REPO\BM\PXESERVA\EFI32\pxeserva.cfg\menu.def

can be manually “customized” adding password protection to menu entries.
i.e. considering
C:\SERVA_REPO\BM\PXESERVA\EFI64\pxeserva.cfg\menu.def

a) Serva automatically created "Windows 10" menu entry for EFI64 targets

LABEL WIA_WDS\Win10_64\
 menu label  ^  5) Windows 10, AMD64
 kernel      pxechn.c32
 append      ::WIA_WDS\W10_bz_22h2_x64\_SERVA_\bootmgfw.efi

b) Manually customized (now password protected) "Windows 10" menu entry for EFI64 targets

LABEL WIA_WDS\Win10_64\
 menu label  ^  5) Windows 10, AMD64
 menu passwd $5$2T5Bidc2$.BbmhroqhplGQZhqv9WAUGMiiWb5XDG6rSHbM2FCli3$
 kernel      pxechn.c32
 append      ::WIA_WDS\W10_bz_22h2_x64\_SERVA_\bootmgfw.efi

Where the highlighted string of characters is in this case a SHA2.256 cryptographic hash (digital fingerprint) of the chosen menu entry password or pass-phrase. A valid hash has to be obtained following the ISOLINUX MD5/SHA1/SHA2.256/SHA2.512 conventions and this can be done i.e. by using the following hash calculator.

Fig 3: Password protected menu entries

4 Performance

Serva PXE/BINL has two distinctive mutually exclusive working phases:

1. BINL Preparation/Maintenance
2. PXE/BINL Server

4.1- On the first stage we mainly convert every Windows Install Distribution into Windows Installation Assets. This is a local task mostly involving file manipulation. The time consumed on this preparation stage is directly linked to the amount of assets on Serva's repository.

i.e. Preparation of:

These figures were obtained with Serva running on:

1. Windows 7 PC, Intel Core 2 duo @ 2.2 GHz, 4GB RAM, HDD.
2. Windows 8.1 PC, Intel i7 3630QM @ 2.40GHz, 16GB RAM, SSD.
   At December 2020 modern hardware produces even faster figures.

Maintenance times on the other hand (if they do not involve the re-creation of the ServaBoot.wim on WDS OSs) are much shorter but you should know that there are certain actions that force the maintenance of the "whole" Serva repository:

1. Changing the Repository root directory (in our example SERVA_REPO)
2. Changing Serva PC name
3. When required by certain Serva upgrades

4.2- When the BINL Preparation/Maintenance stage finishes the PXE/BINL Server stage begins its job until Serva is manually closed. Performance at this point is mainly driven by Serva's host capabilities and it is virtually unaffected by Serva's repository size.

5 Troubleshooting

5.1- Serva general troubleshooting topics.

See here.

5.2- Troubleshooting Network card PXE/PXESERVA/PXELINUX/BOOTMGFW compatibility

There are rare occasions where certain cards present PXE/PXESERVA/PXELINUX/BOOTMGFW compatibility issues right after boot-up. Please be sure you have installed the latest available firmware for your motherboard and network card.

5.3- Troubleshooting Network driver issues.

On init a PXE client relies on its NIC's firmware providing a TCP/IP stack and DHCP+TFTP client capabilities. Of course all these services run on top of a network driver also included on NIC's firmware. But there's a point on the network install process where the previous network stack is replaced by one one used by the Windows PE executive (WDS) being initially booted. At this point we can be informed that a required network driver is not available or that it failed doing its job. This is probably the most common error we might come across on a Microsoft OS network install.

5.3.1- WDS OS OEM network drivers
When the WDS OS we are network installing, uses a Windows PE executive that does not include a network driver that matches our PXE client NIC, we could get an error like this one:

Fig 4: WDS, Missing NIC/Driver error

To circumvent this situation we can add up-to-date versions of the required OEM network driver/s to the corresponding WDS WIA, under the directory i.e.

C:\SERVA_REPO\WIA_WDS\Vista32\$OEM$\$Boot$\$1\$WinPEDriver$\NIC\

The required files would be i.e.
NetDriverX.inf
NetDriverY.sys
NetDriverY.cat (if available)

As an example lets try to find the Windows 10 x64 driver for "HP Pro Mini 400 G9 PC (4G4N7AV)", from HP website we download the file sp145252.exe, runing the file will expand the driver and run the install process but in this case we can just open it with 7z and get the needed components. Looking at the different .inf files we see that this particular package contains 3 drivers for VEN_8086&DEV_153A, VEN_8086&DEV_1521, and VEN_8086&DEV_15F3. The components for VEN_8086&DEV_15F3 are:

e2f.inf
e2f.sys
e2f.cat
e2fmsg.dll

In this case the aditional dll must be included in the injection process.

To identify the specific NIC and then get its matching driver we can rely on manufacturer specifications as we did in our previous example or we can look for the network card VEN/DEV (Vendor/Device) identifiers by launching a console session from ServaPENet (or just pressing SHIFT+F10) and listing with Notepad.exe the content of the file:

x:\Windows\inf\setupapi.app.log

i.e.

>>>  [DIF_SELECTBESTCOMPATDRV - PCI\VEN_10B7&DEV_9200&SUB&YS_010D1028&REV_78\4&19FD8D60]
>>>  Section start 2012/04/25 12:42:59.281
      cmd: winpeshl.exe 
     dvi: No class installer for 'Ethernet Controller'
     dvi: No CoInstallers found
     dvi: Default installer: Enter
     dvi:      {Select Best Driver}
!    dvi:           Selecting driver failed(0xe0000228)
     dvi:      {Select Best Driver - exit(0xe0000228)}
!    dvi: Default installer: failed!
!    dvi: Error 0xe0000228: There are no compatible drivers for this device.
<<<  Section end 2012/04/25 12:42:59.296
<<<  [Exit status: FAILURE(0xe0000228)]

In the setupapi.app.log file (created by Microsoft during the Windows PE start-up) we locate the section that identifies the Plug and Play ID (PnPID) of the third-party network adapter i.e.

>>>  [DIF_SELECTBESTCOMPATDRV - PCI\VEN_10B7&DEV_9200&SUBSYS_010D1028&REV_78\4&19FD8D60]

We see on the previous fragment that the 'Ethernet Controller' with VEN=10B7 and DEV=9200 has failed selecting its driver: "There are no compatible drivers for this device". Now with the identifiers VEN=10B7 and DEV=9200 we can look after the card manufacturer and model on Google, next let's get the correct driver from the card manufacturer website. When looking after notebook NIC drivers you should get them from the notebook manufacturer website instead.

In most cases, the driver packages available from the OEM will include an installation program, but not any instructions on how to get their basic file components. While this represents a bit of a challenge the task can be certainly done.
Please consider that:
a) Some driver files are named differently depending on the operating system to which they apply; driver_w2k.sys, driver_w2k3.sys, and driver_w2k3_64.sys, for example, might apply to Windows® 2000, Windows Server 2003, and Windows Server 2003 64-bit.
b) The installation program might rename the files to base names before installing the driver, such as a generic driver.sys. If this is your case manual editing of NetDriverX.inf will be required.
c) Remember on a WDS install the required OEM network drivers will be used by the Windows PE
executive which is always just a reduced set of a full-blown Windows XP/Vista/7/8/8.1/10/11.

The loading of OEM drivers can be traced by launching a console session from ServaPENet and listing with Notepad.exe the content of the Microsoft's created file:

x:\Windows\inf\setupapi.dev.log

ServaPENet activity it is logged to:

x:\Windows\Sytem32\ServaPENet.log

Windows PE activity it is logged to:

x:\Windows\Sytem32\wpeinit.log

Troubleshooting Windows PE generally involves a lot of command line action considering PE has not a Desktop/File Manager. If you are one of those guys that would love a File Manager within PE just get Explorer++ and copy its tiny single exe at i.e.

C:\SERVA_REPO\WIA_WDS\Vista32\$OEM$\$Boot$\$1\Windows\System32\

All the files added to the former directory after a Serva quit and restart will be available at run-time at PE's:

x:\Windows\Sytem32\

Injection of files different than driver components requires "Serva Pro"

Remember PE does not include the “Windows on Windows 32” (WOW32) then 64Bit versions of PE will not be able to run 32Bit executables.

5.3.2- Virtual Environments Network Driver Errors
When a virtual machine is created on virtual environments like i.e. VMware, we have to specify the target OS. If we indicate the wrong OS or the wrong platform (32/64bits) the virtual environment will emulate a NIC that probably does not have a matching net driver within the target OS. On these situations the remedy is not adding missing drivers but just creating the virtual machine declaring the right target OS.

5.4- Troubleshooting Network Share issues.

5.4.1 WDS OSs ServaPENet login ERROR:0x35:
Microsoft defines error 0x35 (53) as ERROR_BAD_NETPATH and is supposed to mean "The network path was not found" but in fact it really means a lot more things.

The error can be triggered in several ways:
1) Network connection unreliable.
2) WIA_WDS_SHARE bad configured.
3) WIA_WDS_SHARE running on a very busy/slow/unresponsive server.
4) NIC not working properly.
5) NIC driver not working properly (even if there are no errors).
6) Wrong login credentials.
7) Using a not properly created/authorized account (i.e. "admin").
If your network and server are ok I would recommend checking the NIC and specially its driver.

Sometimes point-to-point scenarios (PXE booting client directly connected to Serva's PC with a crossover Ethernet cable) present 0x35 errors. In this case you should add DHCP option 44 (NetBIOS over TCP/IP name server) on Serva’s DHCP Setting tab pointing to Serva's IP. i.e. adding:
44|192.168.0.10 where 192.168.0.10 is in this example Serva's IP address connecting to the PXE booting PC.

There were reported 0x35 errors when installing Windows N while the same client installed Windows Window N-1 correctly. On all these cases:
1) Replacing Windows N \sources\Boot.wim with Windows N-1 \sources\Boot.wim.
2) Erasing Windows N _SERVA_ directory.
3) Quit and restarting Serva.
Solved the problem.

5.4.2 WDS OSs ServaPENet login ERROR:0x43:
Microsoft defines error 0x43 (67) as ERROR_BAD_NETNAME and it means "The network name cannot be found".

The error can be triggered in several ways:
1) The share WIA_WDS_SHARE is not created or it is miss-configured.
2) Sometimes when the client "directly" connects to Serva's PC by an Ethernet crossover cable ("back-to-back" scenario).
3) Sometimes when there is a router between the client and Serva's PC.

On all these cases sequentially try:
1) Checking that the share WIA_WDS_SHARE is correctly creed.
2) Adding the “WINS” DHCP option (44) to the Serva DHCP Server/proxyDHCP, pointing to Serva's IP.
3) Enabling "WINS" services at Serva's PC.

5.4.3 WDS OSs ServaPENet login ERROR:0x520 (Windows/Server May 2020 updates):
Microsoft defines error 0x520 (1312) as ERROR_NO_SUCH_LOGON_SESSION and it means "A specified logon session does not exist. It may already have been terminated.".

This error has been found when trying to install Windows 10 2004, Server 2019 (May 2020 update), Server 2004.

You usually login on ServaPENet with:
<username>
<password>

if you get error 0x520 please try:
<pcname>\<username> (i.e. SERVA_PC_NAME\Charles)
<password>

or

<workgroup>\<username>
<password>

if you are in Windows Domain environment you should login as usual with:
<domain>\<username> (i.e. MY_DOMAIN\Charles)
<password>

Remember; Username and Password correspond to an user with minimally reading rights on WIA_WDS_SHARE on Serva's PC.

5.4.4 WDS OSs ServaPENet login ERROR:0x4CF:
Microsoft defines error 0x4CF (1231) as ERROR_NETWORK_UNREACHABLE and it means "The network location cannot be reached".

This error has been found when the booted Windows PE executive (ServaBoot.wim) does not have a valid, fully functional NIC driver. To check if this is the case just open a console and see if ipconfig shows a NIC up and running and/or try to ping a known IP address i.e. your Serva server IP address. If ipconfig shows a blank answer and/or the ping command fails then the network stack of the booting PC does not have a working NIC.
If you are booting a real PC please add the required NIC driver as explained before.
If you are booting a VM please edit the VM parameters selecting a compatible emulated NIC among the ones offered by your particular hypervisor; usually selecting e1000 or e1000e will solve your problem.

5.5- Troubleshooting saving Serva settings (Serva.ini) issues.

Serva requires full read/write permissions on its running directory in order to keep updated its configuration file Serva.ini. If for any reason Serva has not the right permissions it will fail and refuse to continue. Please consider for some special running directories, on some particular MS OSs, only an Admin account would be able to grant Serva.ini the required permissions.
if you are joined to a domain permissions might be inadvertently limited even if you are an Admin; in this case selecting properties to full control manually solves the problem.

5.6- Troubleshooting TFTP issues.

5.6.1- Errors that are not really Errors.
TFTP is a file transfer protocol that does not have special provisions for telling the client in advance the size of a file the client is planning to retrieve. The client sometimes needs this information for control or memory allocation purposes, then you will see this kind of log sequence:

[1] TFTP Inf: Read file <\WIA_WDS\w8_32\_SERVA_\boot\bcd>. Mode octet
[2] TFTP Err: Peer returns ERROR <TFTP Aborted> -> aborting transfer
[3] TFTP Inf: Read file <\WIA_WDS\w8_32\_SERVA_\boot\bcd>. Mode octet
[4] TFTP Inf: <WIA_WDS\w8_32\_SERVA_\boot\bcd\>: sent blks=9 blkSz=1456, 
        Total 12288 bytes in 0s, err recovery=0

In this particular case:

1. The client requests the bcd file.
2. The client quickly aborts the transfer, but it received the bcd file size from the first packet transmitted by the purposely stopped transfer.
3. The client verifies the bcd file size is within the expected values and if everything is OK it requests a new transfer.
4. This time the transfer is completed.

This type of sequence (even when there's an error involved) does not represent anything you have to be worried about.

5.7.2- Enforced Windowed mode Errors.
Enforced Windowed is one of Serva's advanced TFTP modes. It allows the transfer of TFTP data in bursts of N consecutive blocks. You can read more about this mode here "Advanced Topics on TFTP.

Most of the client NICs do not present problems with this mode, some old ones might.
See this pattern:

[1] TFTP Inf: Read file <pxeserva.0>. Mode octet
[2] TFTP Err: timeout waiting for ack blk #4
[3] TFTP Err: timeout waiting for ack blk #9
[4] TFTP Inf: <pxeserva.0>: sent blks=12 blkSz=1456, Total 19710 bytes in 3s,
      err recovery=2 

1. The client requests pxeserva.0
2. The TFTP server times out waiting for a client acknowledge on a block multiple of the Enforced windowed parameter
3. The TFTP server times out waiting for a client acknowledge on a block multiple of the Enforced windowed parameter
4. The transfer is aborted or completed with many errors.

When the initial small file transfers (i.e. pxeserva.0) present this kind of errors the chances are your clien'ts NIC firmware does not support "Enforced windowed".
You can solve this problem by disabling the TFTP "Enforced windowed" mode or upgrading your NIC's firmware.

5.7.3- Serva's PC wrong MTU (Maximum Transmission Unit)
TFTP transfers are UDP based; originally they were limited to 512 byte blocks. Improvements in the protocol brought by RFC 2348 allow client and server to negotiate bigger block sizes what leads to faster transfers.
In order to avoid packet fragmentation a TFTP client will usually negotiate a block size around but not higher than 1468 bytes. The last figure equals the Ethernet MTU (1500 bytes) minus the headers of TFTP (4 bytes), UDP (8 bytes) and IP (20 bytes).
If the PC running Serva for some reason limits the MTU to a value smaller than its default (1500) you will probably see logs like this:

...
[08/20 18:38:40.197] TFTP Inf: Read file <pxeserva.0>. Mode octet
[08/20 18:38:41.298] TFTP Err: timeout waiting for ack blk 16#1    #1
[08/20 18:38:43.301] TFTP Err: timeout waiting for ack blk 16#1    #1
[08/20 18:38:46.302] TFTP Err: timeout waiting for ack blk 16#1    #1
[08/20 18:38:49.302] TFTP Err: timeout waiting for ack blk 16#1    #1
[08/20 18:38:52.303] TFTP Err: timeout waiting for ack blk 16#1    #1
[08/20 18:38:55.303] TFTP Err: timeout waiting for ack blk 16#1    #1
[08/20 18:38:55.303] TFTP Err: TIMEOUT & abort waiting for Ack block #1

-^- stops here.

In this case (if your firewall is not blocking TFTP traffic) the chances are the TFTP IP packets are being fragmented. Most PXE clients will not be able to deal with this situation. To solve this problem just restore Serva's PC MTU to its default value (1500).

5.7.4- BCD Not Found
The BCD (Boot Configuration Data) file is a key component initially TFTP transferred when installing WDS OSs.

While a normal BCD TFTP transfer log could look like:

[1] TFTP Inf: Read file <\WIA_WDS\w8_32\_SERVA_\boot\bcd>. Mode octet
[2] TFTP Inf: <WIA_WDS\w8_32\_SERVA_\boot\bcd>: sent blks=9 blkSz=1456, 
     Total 12288 bytes in 0s, err recovery=0 

A faulty BCD TFTP transfer log will look like:

[1] TFTP Inf: Read file <\Boot\BCD>. Mode octet
[2] TFTP Err: File <\Boot\BCD> : error 3 in CreateFile;  The system cannot 
      find the path 

In the last case we see the client asks for the BCD without including the required asset's path information.
This error is usually displayed at client's screen showing something like:

Fig 5: Missing \Boot\BCD error.

This error can be triggered by:

1. The Client has received PXE "booting parameters" (file, next server, DHCP option 66, DHCP option 67) from other DHCP/proxyDHCP server besides Serva.
   Serva PXE/BINL is required to be the only working PXE server on the install subnet. Serva (on proxyDHCP mode) is able to work side-by-side with another DHCP server "if this one is not also providing booting parameters along with its IP addresses".
   
   
2. Serva DHCP BINL Add-on has been mistakenly turned off.
   Serva requires the DHCP BINL Add-on always on when using its PXE/BINL capabilities.
   
   
3. The Client has a broken PXE implementation.
   A NIC firmware upgrade is required.
   
   
4. The client runs under Oracle VirtualBox without the Extension Pack.
   Install the VirtualBox Extension Pack.

5.7.5- VMware PXE "firmware" bug.
When PXE booting VMs under VMware Workstation, ESXi, etc, the associated TFTP transfers always present the following error pattern.
i.e.

...
[16:15:38.723] TFTP Inf: Read file <\WIA_WDS\s2012_R2\_SERVA_\boot\ServaBoot.wim>. Mode octet
[16:15:43.553] TFTP Err: timeout waiting for ack blk 16#24032     #24032
[16:15:49.675] TFTP Err: timeout waiting for ack blk 16#56792     #56792
[16:15:55.696] TFTP Err: timeout waiting for ack blk 16#24016     #89552
[16:16:01.583] TFTP Err: timeout waiting for ack blk 16#56776     #122312
[16:16:06.391] TFTP Inf: <\WIA_WDS\s2012_R2\_SERVA_\boot\ServaBoot.wim>: sent blks=152873 
                             blkSz=1456, Total 222629455 bytes in 28s, err recovery=4
...

The pattern consist of an initial timeout error on a random block# < 32767 followed by a sequence of similar errors periodically repeated every (32768 - windowsize) blocks.
Note that, despite the logged errors, the bug can pass unnoticed because Serva's TFTP error recovery routine does its job; finally the affected file gets correctly transfered but with some considerable delay (+2 sec per error => +40% in our 200Mb transfer example). This error is harder to be seen on small file transfers (let's say less than 32768 blocks).
The problem has already been reported to VMware people here (Oct/2013) and they are working on it. Please do not blame VMware on this; it seems the bug is located in some old 3rd party PXE ROM code used by VMware products.
The problem is currently (Jan/2015) solved; VMware 11.

5.8- Troubleshooting WDS OSs missing "Repair your computer" link

After a successful ServaPENet login we'll see one of these screens:

The link "Repair your computer" is missing. This is because of a bug within autorun.dll (one of Setup.exe components) which mistakenly checks for the availability of the Recovery Environment based on the current directory (GetFullPathName()) instead of parsing the %systemdrive% variable. While this error passes totally unnoticed when installing from DVD it presents the missing link problem when Setup.exe is run from a network location.

In order to regain the access to the Recovery Environment if needed we can create RecEnv.bat i.e.

C:\SERVA_REPO\WIA_WDS\Vista32\sources\RecEnv.bat

@ECHO OFF
cd /d %systemdrive%\sources\recovery
RecEnv.exe 

Then when we reach the "Install Now" screen on W8/7 or the one after on Vista, we open a console windows with Shift+F10 and just run RecEnv.

5.9- Troubleshooting "Initial menu has no label entries" displayed at the client.

Basically the PXE/BINL service works by you copying your Windows distribution components under some “head” directory under WIA_WDS\ or WIA_RIS\. Then Serva BINL processes all those "head" directories making a Serva “asset” out of everyone of them. Finally at the booting client every Serva asset is accessed by a menu entry on Serva’s automatically created menu.

But, what if the Windows distribution components that you just added do not really conform a standard (Retail, MSDN, etc) Windows distribution? Probably they present a heavily customized file/directory structure unknown to Serva's BINL. In that case Serva’s BINL layer will not be able to do its job properly and it will not create the corresponding Serva asset out of them.

If Serva was unable to parse a single valid asset you will get "Initial menu has no label entries" when booting your client. Just use the right Windows distributions and you will not have this problem.

5.10- Troubleshooting Preparation stage issues.

5.10.1- WDS OS ServaBoot.wim creation error

...
[22:19:14.789] BINL Inf: Preparation/Maintenance procedures "Start"  **
[22:19:15.185] BINL Inf: Expandd  OK, C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\pxeboot.n12
[22:19:15.602] BINL Inf: Expandd  OK, C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\bootmgr.exe 
[22:19:15.625] BINL Inf: Copied   OK, C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\boot\boot.sdi 
[22:19:15.635] BINL Inf: Created  OK, C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\ServaBINL.dat
[22:19:16.672] BINL Err: Creating C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\boot\ServaBoot.wim
[22:19:17.009] BINL Inf: Preparation/Maintenance procedures "End"    **
...

This error can be triggered by:
1) Serva does not have writing rights on the target directory.
2) The asset's Boot.wim is a read only file (pretty common if you populated the asset's head directory copying components from a read only media i.e. DVD).

5.11- Troubleshooting UEFI specific issues

The single Boot Manager included in former versions of Serva (pxeserva.0) is able to display Serva's menu of boot/install assets only on BIOS based systems (or UEFI systems running in "Legacy Mode"). Now Serva v3.x handles 5 Boot Managers (pxeserva.0/pxeserva.efi/bootmgfw.efi) covering the whole landscape of Pre-OS runtime environments available today (BIOS/EFI64/EFI32).

5.11.1- UEFI firmware compatibility
We have found that sometimes UEFI firmware implementations are not rock solid; PC vendors:
a. Do not completely implement the current UEFI standard.
b. Implement ancient versions of it in fairly new hardware.
c. Produce faulty firmware.

i.e. HP-EliteBook-2560p-8460p or LenovoT14 Gen 2 (20W1)

For all of the above and also considering people needing UEFI Secure Boot since Serva v3.x BINL service includes two “Boot Manager Modes”. A Boot Manager Mode defines the set of Boot Managers offered by Serva to the different clients based on their Pre-OS runtime environments.

* Supports UEFI Secure Boot and UEFI 32/64-ARM (this mode requires "Serva Pro")

A PXE client declares its pre-OS runtime environment at boot within its initial DHCP request by including the DHCP Option 93 (RFC 4578 and DHCPV6 Processor Architecture Types). Serva DHCP/proxyDHCP service parses client's DHCP Option 93 and provides to the client the path of the corresponding booting Boot Manager taking into account the current BINL BMM.

Serva’s BINL BMM defaults to "1" where pxeserva.efi offers on UEFI environments virtually the same features pxeserva.0 offers on BIOS environments.

When UEFI Secure Boot and/or UEFI 32/64-ARM support is required BMM=3 (also based on Microsoft's bootmgfw.efi) is needed.
BMM value can be set on the DHCP tab of Serva’s Settings dialog box.

NOTE: BMM=2 was deprecated in v4.4.0.

5.11.2- UEFI Secure Boot - EFI_STATUS=15

If your client is netbooting UEFI-Secure Boot you must select "Boot Manager Mode" = 3 indicating Serva to use the Microsoft signed Boot Managers. Failing to do so leads to an error:

6 Final words

Initially targeting the sysadmin in a hurry and the average IT enthusiast, Serva PXE/BINL was originally designed as the simple alternative to the server functionality of that fantastic piece of software called Microsoft WDS. Today Serva's reliability, mild learning curve, and affordable cost make it the option of choice for business, military and industrial environments. See our customers here.

Serva PXE/BINL also includes advanced features like unattended installs, Windows PE booting, or single-menu multi-repository integration. Please read about these exiting features here:
Serva PXE/BINL - AN02: Windows Network Install (Adv) & WinPE Boot.

When Serva PXE/BINL services are enabled, "Community" builds of Serva stop processing network requests after 50 minutes of use. This amount of time is more than enough for any OS installation. "Professional" builds of Serva on the other hand do not have this limit.
If you are a Serva Community user and you find it useful please consider purchasing Serva Pro. Non-personal or commercial use of Serva always requires a Serva Pro license (see Serva's download page for further details).

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