Serva PXE Windows Network Install

8/8/2017

Home Application Notes Advanced Troubleshooting Tools

Serva PXE/BINL - AN01: Windows Network Install

PXE/BINL - AN01: Windows Network Install St arting arting an automated an automated network install of anything from Windows 2000 to W indows indows 10 t aking aking no more than 15 minutes and a ~3 MB download.

The objective The objective of this document is to show you how to perform simple network ne twork installations installations of Microsoft's OSs neither requiring to follow cryptic proced pr ocedures ures nor being dependant on Microsoft’s RIS/WDS/WAIK/ ADK suites. su ites. Procedures described in this document do not require not require Serva "Pro"

References Download Contact Co ntact

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

0 Index 1. 2. 3. 4. 5. 6. 7. 8. 9.

Requirements Definitions Stage Deployment Customization Security Performance Troubleshooting Final Words

1 Requirements 1.1 Required Software 1.1.1 Microsoft Windows Serva 3.0.0 or 3.0.0 or higher. 1.1.2 Microsoft Install CD/DVD/ISO of the OSs you want to network install. Serva has been tested installing the following distributions: Windows 2000 - Professional/Server/Advanced Server/Datacenter Server Windows XP - Home/Tablet PC/Media Center/Professional/Professional (x86/x64) Windows Server 2003 - Standard/Enterprise/Datacenter/Web (x86/64) 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) https://www.vercot.com/~serva/an/WindowsPXE1.html

1/29

8/8/2017


Windows 8.1 - Basic/Pro/Enterprise (x86/64) Windows 10 - Home/Education/Pro/Enterprise (x86/x64)* *ISOs created by the Media Creation Tool should be either x86 or x64 but not both . Windows Server 2008 R2 R2 - Foundation/Standard/Web/Enterprise/Datace Foundation/Standard/Web/Enterprise/Datacenter nter (x86/64) Microsoft Hyper-V Server 2008 R2 (x64) 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) 2012 (x64) Windows Server 2012 R2R2- Standard/Essentials/Datacenter (x64) Microsoft Hyper-V Server 2012 R2 (x64) Windows Server 20162016- Standard/Essentials/Storage (x64) Microsoft Hyper-V Server 2016 (x64) Windows Thin PC - (x86) Windows Windows Windows Windows

Embedded Embedded Embedded Embedded

2009-- Standard/POSReady(x86/64) 2009 7 - Compact/Standard/POSReady (x86/64) 2013- Compact (x86/64) 20138- Standard/Industry Pro (x86/64)

Windows Embedded 8.18.1- Industry Pro/Industry Enterprise (x86/x64)

1.2 Assumed knowledge 1.2.1 Setting PC UEFI/BIOS parameters. 1.2.2 Creating Microsoft network shares.

2 Definitions Let's define some key terms used on this and following documents. 2.1 BIOS: BIOS: The BIOS (Basic Input/Output System) is a PC pre-OS environment, a type of firmware mainly used to initialize, test the system hardware components, and to load a boot manager or an operating system boot loader from a mass memory or network device. 2.2 EFI/UEFI: EFI/UEFI: The The EFI (Extensible Firmware Interface) initially introduced by Intel in 1998 by 2005 became an industry-wide driven effort known as UEFI (Unified Extensible Firmware Interface). It is designed as a successor to BIOS, aiming to address its technical shortcomings. In this document we use the terms "EFI" and "UEFI" as synonyms. 2.3 PXE: PXE: The The Pre-boot eXecution Environment (PXE, pronounced pixie) was introduced by Intel as part of the Wired for Management framework. It is described in the specification (v2.1) published by Intel and Systemsoft on September 20, 1999. PXE is an environment to boot computers from a server using a network device independently of available mass storage devices or installed operating systems. It relies mainly on DHCP and TFTP services and it is implemented either as a Network Interface Card (NIC) BIOS extension or today in modern devices as part of their UEFI firmware. In this document we use the terms "PXE boot" and "Network boot" as synonyms. 2.4 NBP: NBP: A Network Boot Program or Network Bootstrap Program (NBP) is the first file downloaded and executed as part of the Pre-Boot Execution Environment Environment (PXE) boot process. In multi boot PXE the NBP is a Boot Manager (BM) able to display a menu of the available booting options. 2.5 RIS: Back 2.5 RIS: Back in the days of Windows 2000 the first Microsoft's net install attempts were carried out by the Remote Installation Services (RIS). After a couple of updates RIS ended up net installing Windows 2000, Windows XP, and Windows Server 2003. It can be considered PXE based with some MS custom extensions. 2.6 WDS: WDS: The The Windows Deployment Service (WDS) is the updated and redesigned version of RIS. It is able to perform network installs of Windows Vista and up . It can also install the old RIS OSs when their images are conveniently assembled. 2.7 BINL: BINL: The The Boot Information Negotiation Layer (BINL) service is a key component of RIS and WDS. It includes certain preparation processes and a network protocol that could be somehow considered a https://www.vercot.com/~serva/an/WindowsPXE1.html

2/29

8/8/2017


Microsoft crafted DHCP extension. 2.8 BINL+: BINL+: Serva BINL extension able to process Non-Windows systems. Serva documentation refers to it just as BINL. 2.9 WID: WID: A A Windows Install Distribution Distribution (WID) is the whole set of files and its directory structure structure as it is found within any Microsoft OS install CD, DVD, or ISO file. 2.10 WIA: WIA: A A Serva Windows Installation Asset or just Windows Asset (WIA) is either a WID, or a stand alone Windows PE bootable image, successfully processed by Serva BINL. A WIA can be offered for network boot/install by Serva's PXE/BINL net services. 2.11 NWA: NWA: A Serva Non-Windows Asset (NWA) is any Non-Windows based bootable/installable distribution successfully processed by Serva BINL. A NWA can be offered for network boot/install by Serva's PXE/BINL net services.

3 Stage 3.1- Hardware lay-out. a) PC running Serva. Serva is able to run on anything from Windows 2000 to Windows 10. b) Net booting target PCs (PXE clients) installing over the net anyone of the available versions of MS Windows.

Fig 1: Hardware Lay-out

Notes 1. The PXE standard requires a wired network connection for Target PCs. 2. Serva PC can either use a wired or wireless network connection (Notebooks, Netbooks, NUCs, etc.). 3. Serva and Gigabit connectivity (even on modest hardware) offers the fastest way available today for installing any Microsoft OS.

https://www.vercot.com/~serva/an/WindowsPXE1.html

3/29

8/8/2017


3.2- PXE Client UEFI/BIOS set-up. When a PC boots-up its basic input/output system firmware (BIOS) turns the PC hardware into a functioning system able to boot an OS. PC makers have increasingly been replacing BIOS with the newer Unified Extensible Firmware Interface (UEFI). There's a UEFI/BIOS parameter called boot option priority list which which dictates the order in which the PC will attempt to boot from its ready to boot devices. They could be local SATA/ATA/SCSI HDDs, USB HDDs, CD/DVD drives, or "Network Cards". In the last case the PC firmware downloads to RAM and runs a Network Bootstrap Program (NBP) starting a boot/instal boot/installl process directly from the network. PCs trying to perform a network boot/install must set their boot option priority list headed headed by the network card device that connects to the booting network. Note The NBP file file is the 1st piece of network retrieved code that takes control right after the PXE clients boots-up. In Serva's PXE/BINL case the NBP is a Boot Manager (BM) (BM) which displays a menu of the available boot/install options. Virtual machines implement emulated UEFI/BIOS environments where the boot option priority list can can also be defined.

Fig 2: Boot option priority list configured for Network Boot on UEFI and BIOS PCs

Most UEFI systems include a "Legacy "Legacy Mode" Mode" also known as "Compatibili "Compatibility ty Support Module (CSM) Mode"" which can alternatively emulate the old BIOS environment. Serva v2.X BM (pxeserva.0) was Mode able to boot and display its menu of boot/install options only on BIOS systems (or UEFI systems running in "Legacy Mode"). Serva v3.X BMs (pxeserva.efi and bootmgfw.efi) on the other hand, are now also able to natively boot and work on UEFI systems not requiring "Legacy Mode".

Warning 1. Please be sure that the PCs you want to PXE boot/install (targets) have been configured with the appropriate NIC device at the top of their boot option priority list . 2. When a network install is finished, and before the first boot of the newly installed OS takes place, remember changing back the boot option priority list by setting the target's HDD device https://www.vercot.com/~serva/an/WindowsPXE1.html

4/29

8/8/2017


as the first booting option. Failing to do this would take the target to the beginning of a new net install cycle.

3.3- DHCP server vs. proxyDHCP. A net booting PC needs to gather basic network information as soon as it powers up: 1. 2. 3. 4. 5.

IP address Network mask Additional DHCP options (if any) IP address of the TFTP server that hosts the bootstrap loader Boostrap loader File Name

The first three items are regular DHCP parameters and the last two are the specific BOOTP/PXE DHCP extensions. At this point we know we need a DHCP server; Serva is a DHCP server. But, what if we already have a working DHCP server on our network? Let's go even further; what if we have no access/permission to change its configuration at all? Here are the 2 scenarios explained: explained:

Fig 3: proxyDHCP vs DHCP server scenarios

In the first case we already have a working DHCP server assigning and administering IP addresses but not providing booting information, then Serva acting just like a "proxyDHCP" will automatically provide the required complementary PXE info: 4. IP address of the TFTP server that hosts the bootstrap loader 5. Boostrap loader File Name In the second case Serva behaves as DHCP server providing all the needed information.

Notes https://www.vercot.com/~serva/an/WindowsPXE1.html

5/29

8/8/2017


1. The term proxyDHCP many times leads to confusion: a) It really has nothing to do with the "HTTP proxy" concept you probably already have. b) A proxyDHCP and a "DHCP relay agent" or "DHCP helper" are completely different things. 2. Whenever possible it is always better to use your already working and known DHCP server and setting Serva just as proxyDHCP. 3. Serva's proxyDHCP only answers to DHCP requests when comming from PXE booting clients, it remains silent otherwise.

4 Deployment Serva is a single exe that does not require installation. Let's consider you run Serva from C:\SERVA\ directory. Serva requires full read/write permissions on its running directory in order to keep updated its configuration file Serva.ini. When running Serva.exe you can reach its menu by either typing [Alt][Space] or right-clicking its title bar. Alternatively you can directly access Serva's Settings Settings dialog dialog box by double-clicking the application icon at the title bar.

4.1- Configuring Serva's TFTP server. The initial stages on a network install require TFTP file transfers, then we start Serva and go to the TFTP Settings tab. Here we mainly define the directory that will act as TFTP root. This directory in fact will become Serva's "repository" root directory holding all the windows installation assets. Serva needs full read/write permissions on this directory; i.e. C:\SERVA_REPO C:\SERVA_REPO\ \

Fig 4: TFTP server settings

Notes https://www.vercot.com/~serva/an/WindowsPXE1.html

6/29

8/8/2017


1. The TFTP service does not usually need to be bound to an specific Serva's NIC/IP address. In case of problems try binding it to the Serva's NIC/IP address that physically connects to the install subnet. 2. Since version 2.0 2 .0 Serva includes include s 2 faster modes mode s besides classic cla ssic RFC 1350; 1350; "RFC 7440 Windowed" and "Enforced Windowed". They are able to dramatically improve TFTP transfer rates. Warning Serva TFTP service will not run correctly on a PC that already has a TFTP server running For more details on TFTP please see "Advanced Topics on TFTP". TFTP".

4.2- Configuring Serva's proxyDHCP/DHCP server. 4.2.1- BINL Service Add-on. Serva automated network boot/install of Windows (and also non-Windows) assets requires the Serva BINL service add-on checked. Remember BINL is not just only a DHCP protocol extension but also a set of preparation and maintenance procedures run every time Serva is started. When Serva BINL is checked Serva takes control of several PXE parameters including " Boot File" (automatically set to pxeserva.0/pxeserva.efi ). ). In non-automated scenarios where you might, for some reason, need full control over the Preboot Execution Environment please remember to uncheck the BINL checkbox. 4.2.2- proxyDHCP vs DHCP server. Remember what we said before; if you already have a working DHCP server then just select the proxyDHCP mode. On this mode you will not be required to define IP address assignation related parameters and those dialog box fields will be automatically grayed-out. Warning Installing RIS OSs requires OSs requires Serva DHCP protocol always on proxyDHCP mode. mode. This also implies the need of an external DHCP server for regular IP/MASK assignation.


7/29

8/8/2017


Fig 5-6: proxyDHCP vs DHCP server settings

Notes 1. The DHCP/proxyDHCP service does not usually need to be bound to an specific Serva's NIC/IP address. In case of problems try binding it to the Serva's NIC/IP address that physically connects to the install subnet. 2. The variable "Next Server" (IP address of the TFTP server) is automatically handled by Serva. In case of TFTP transfer problems try manually setting it to the Serva's NIC/IP address that physically connects to the install subnet. 3. When the PXE client resides on a virtual environment that already includes a virtual DHCP server like VMware, setting Serva as proxyDHCP is always the best option. Warning Serva DHCP/proxyDHCP services will not run correctly on a PC that already has a DHCP server running.

4.2.3- MAC Filter. For advanced DHCP scenarios Serva DHCP/proxyDHCP services includes MAC filter capabilities. The MAC filter engine allows Serva to discriminate and decide which clients will or will not receive Serva DHCP/ProxyDHCP DHCP/ProxyD HCP services based on their MAC addresses. 4.2.3.1- Graphical user interface settings. Serva's DHCP Setting tab allows quickly to define up to 10 MAC filter entries. entries . The MAC filter combo combo box field configures the engine as:

MAC Filter: Off - All DHCP requests are honored. (default) Accept - Only requests requests with MACs that match a predefined set of addresses are honored. Ignore - Only requests requests with MACs that do not match a predefined predefined set of of addresses are honored. The set of MAC addresses is made of up to 10 entries of the form: form : MAC[[|MASK MAC |MASK]] i.e.

[+] BINL [+] DHCP Options [-] MAC Filter ├ opt_1 | 00:01:02:03:04:05:0 00:01:02:03:04:05:066 ├ opt_2 | 00:01:02:03:04:05:0 00:01:02:03:04:05:06|FF:FF:FF:FF:00:00 6|FF:FF:FF:FF:00:00 ... └ opt_10 | [+] Static Leases In the first case all of the bits of the MAC address are required for producing a match. In the second case every bit of the MASK set to 1 anchors as “required-for-matching” the corresponding bit on the preceding MAC address. This way it's very simple to define a group of related MAC addresses just in a single entry. 4.2.3.2- Whitelist Whitelist/Blacklist /Blacklist settings. When 10 MAC filter entries are not enough it is possible to define unlimited number of entries by manually creating a whitelist or blacklist file next to Serva.exe (this feature requires " Serva Pro") Pro")

ServaDHCP_mac_wl.def ServaDHCP_mac_bl.def https://www.vercot.com/~serva/an/WindowsPXE1.html

MAC address Whitelist MAC address Blacklist 8/29

8/8/2017


The file format is just a plain ASCII list of Ethernet MAC addresses i.e.

ServaDHCP_mac_wl.def

7B:99:4F:11:67:4F 5A:D8:73:5F:11:98 5B:F7:6C:19:8F:2B 72:0E:64:E9:70:DB D4:47:7A:B1:20:FD When either a whitelist or blacklist file exists next to Serva.exe the GUI defined MAC filter entries are ignored. When ServaDHCP_mac_wl.def exists next to Serva.exe only clients in this list will receive DHCP/proxyDHCP DHCP/proxy DHCP services. When ServaDHCP_mac_bl.def exists next to Serva.exe only clients not in this list will receive DHCP/proxyDHCP DHCP/proxy DHCP services. If both files are present next to Serva.exe an error condition is triggered.

For more details on DHCP please see "Advanced Topics on DHCP and related protocols". protocols" .

4.3- Quit and Restart Serva. Every time we quit and restart Serva (when the BINL Service Add-on is checked) the application will run on init all the BINL preparation/maintenance processes. At this point, on restart, we'll see Serva BINL creates its repository initial empty structure. Open All | All | Close All C:\ SERVA_REPO BM ... WIA_RIS ServaReadme.txt WIA_WDS ServaReadme.txt NWA_PXE ServaReadme.txt

Notes 1. ServaReadme.txt contains a summary of the instructions found on this document for future reference. 2. Serva PXE/BINL class directory NWA_PXE is not used within this document and we will be back to it when booting/installing "Non-Windows Assets".

4.4- Populating Serva's WIA_RIS and WIA_WDS class directorie directories. s. It is time now to populate WIA_RIS and WIA_WDS class directories 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_RIS will hold only Windows 2000, XP, and Server 2003 distributions (32/64). b) WIA_WDS will hold only Windows Vista and up distributions (32/64). c) Every distribution has to be copied in full under its own manually created "head" directory exactly https://www.vercot.com/~serva/an/WindowsPXE1.html

9/29

8/8/2017


as it comes from the Microsoft distribution media. media . d) While "head" directory names do not really matter they can only contain ASCII characters with characters with no spaces.. spaces When we finish creating the head directories and copying our Windows distributions into them we might have gotten something like this: Open All | All | Close All C:\ SERVA_REPO BM ... WIA_RIS Win2000_Pro ... win_xp_32 DOCS DOTNETFX I386 SUPPORT VALUEADD Setup.exe AUTORUN.INF ... win_S2003_64 ... WIA_WDS win_S2008_64 ... win_7_32 ... W10_64 boot efi sources support setup.exe autorun.inf ... W8_Ent_64 ... S2012_R2_64 ... Serva repository structure (only win_xp_32 win_xp_32 and and W10_64 W10_64 head head directories are shown populated)

Where i.e. win_xp_32, win_7_32, S2012_64, etc, are the user created head directories and, win_xp_32 holds win_xp_32 holds the files and directory structure identically copied from a Win XP 32Bit install CD, win_7_32 holds win_7_32 holds the files and directory structure identically copied from a Win 7 32Bit install DVD, S2012_R2_64 holds the files and directory structure identically copied from a Win Server 2012 R2 S2012_R2_64 install ISO, etc, etc...

Additional steps for 64-Bit RIS OSs 1. "Copy" the content \AMD64\*.* (about 400 MB) to I386\ (it implies merging the content of the \LANG directories)


10/29

8/8/2017


2. Optionally if we want to recover the extra 400 MB used, we can: a) Erase the \AMD64 directory with all its content. b) Make a junction i.e. C:\>junction C:\SERVA_REPO\WIA_RIS\XP_64\AMD64 C:\SERVA_REPO\WIA_RIS\XP_64\I386

4.5- Creating MS Network Shares. 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. RIS and WDS OSs require different type of share (remember they both -RIS & WDS- belong to different generations of software). 4.5.1 When installing RIS OS's: WIA_RIS' parent directory which is also the TFTP Server Root directory directory (C:\SERVA_REPO\ in our example) has to be shared as WIA_RIS_SHARE WIA_RIS_SHARE using a read-only "Null Session Share". Share". Please consider this will (by default) expose to "ANONYMOUS LOGON" users, WIA_WDS' content. This probably unwanted side effect can be mitigated by editing \WIA_WDS default sharing permits after WIA_RIS_SHARE is created. This particular RIS sharing requirement might look a bit awkward but please remember RIS was Microsoft first attempt on network installations; therefore there are some RIS hard-coded parameters that make this technology not easily ready for a multi-OS network install system like Serva. Warning 1. When offering RIS RI S OSs it seems natural to think that th at WIA_RIS_SHARE WIA_RIS_SHARE should point at C:\SERVA_REPO\WIA_RIS but that is not how MS RIS works. WIA_RIS_SHARE must point point at C:\SERVA_REPO C:\SERVA_REPO (TFTP (TFTP Server Root directory) instead. 2. Please consider "Null Session Shares" got some bad reputation over the years from a security point of view, therefore setting them up on modern OSs it's not just a straight forward singlestep operation. See here here for for details.

4.5.2 When installing WDS OS's: Directory WIA_WDS WIA_WDS has has to be shared as WIA_WDS_SHARE (read-only). This share should not be a "Null Session Share" and it will be required to grant access to at least one user with reading rights. Access credentials (valid username with a non-empty password) will be required by ServaPENet (see 4.8) before remotely accessing the share from a booting client.

Note Please create only the shares you need. i.e. if you are not installing RIS OSs (XP, Server 2003) then you should not create WIA_RIS_SHARE WIA_RIS_SHARE..

4.6- 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 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. Note When Serva processes an Installation Asset it creates and populates the directory _SERVA_ under under its head directory. If for any reason we want to force the re-process of a particular asset we just need to erase its _SERVA_ its _SERVA_ directory directory an restart Serva.


11/29

8/8/2017


4.7- 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 v3.0.0 multi-OS PXE Boot/Install Menu: Menu:

Fig 7: Serva Multi-OS PXE Boot/Install EFI64/BIOS/EFI32 Menus

The Fig 7 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_RIS and WIA_WDS 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 ). Notes 1. In case we want to temporarily stop offering for installation one of the WIAs but we do not really want to erase it, we can just prepend its head directory with off_ and and quit/restart Serva. Serva will "ignore" head directories when their name begin with "off_" i.e. off_win_8.1_64. If we want it back on we just remove "off_" from its head directory name and quit/restart Serva. 2. "Serva "Serva Community" Community" a. Displays only the first 7 enabled BIOS based menu entries. b. Displays only the first 2 enabled UEFI based menu entries. c. Serves a maximum of 2 PXE clients per session.


12/29

8/8/2017


4.8- Logging to Serva's WIA repository. As we have said before RIS OSs use a "Null Session Share" (WIA_RIS_SHARE) for accessing their install components, then a transparent (no user input required) anonymous login is all it takes for completing a RIS OS installation. On the other hand WDS OSs use a regular share (WIA_WDS_SHARE) and also need some extra processing. Both things are automatically handled by ServaPENet.

Fig 8: WDS OS requiring WIA_WDS_SHARE user and password

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

5 Customization 5.1- Serva Menu Serva menu can be user customized but only " Serva Pro" 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. menu.

5.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

5.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. 5.3.1- RIS Windows Install Distributions Distributions Customizing the old RIS distributions required third party applications (i.e. nLite) but they usually failed producing PXE compatible systems. The official way was just recreating the distribution using the corresponding Microsoft's OS OEM Preinstallation Kit (“OPK”). (“OPK”). 5.3.2- WDS Windows Install Distributions https://www.vercot.com/~serva/an/WindowsPXE1.html

13/29

8/8/2017


a) Customizing WDS distributions can be \Sources\Install.wim with the (dism.exe)) tool. Management " (dism.exe

easily done by editing the "Microsoft Deployment Image

install image Servicing and

b) "Serva "Serva Pro" Pro" allows to copy/overwrite alternative files at the end of the OS install process according to the following table. Content under: \Sources\$OEM$\$1 \Sources\$OEM$\$$ < he head_dir>\Sources\$OEM$\$progs \Sources\$OEM$\$docs

Copied to: %SYSTEMDRIVE% %WINDIR% %PROGRAMFILES% Users folder

Example: C:\ C:\Windows C:\Program Fi Files C:\Users

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. Warning Great care must be taken when overwriting OS components in this way; it can easily lead to a broken system.

6 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. 6.1- Serva's BINL net offered file resources associated risks 6.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. 6.1.2- WIA_RIS_SHARE Microsoft Network Share It is very similar to point 6.1.1 with the difference that a read-only "Null Session Share" can be easily mapped and browsed. 6.1.3 WIA_WDS_SHARE Microsoft Network Share Only authenticated users would be able to read-only browse its content.

6.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 https://www.vercot.com/~serva/an/WindowsPXE1.html

14/29

8/8/2017


C:\SERVA_REPO\BM\PXESERVA\BIOS\pxeserva.cfg\menu.def C:\SERVA_REPO\BM\PXESERVA\BIOS\pxeserv a.cfg\menu.def C:\SERVA_REPO\BM\PXESERVA\EFI64\pxeser C:\SERVA_REPO\BM\PX ESERVA\EFI64\pxeserva.cfg\menu.def va.cfg\menu.def C:\SERVA_REPO\BM\PXESERVA\EFI32\pxeser C:\SERVA_REPO\BM\PX ESERVA\EFI32\pxeserva.cfg\menu.def va.cfg\menu.def can be manually “customized” adding password protection to menu entries. i.e. considering C:\SERVA_REPO\BM\PXESERVA\EFI64 C:\SERVA_REPO\BM\PXESERVA\ EFI64\pxeserva.cfg\ \pxeserva.cfg\menu.def menu.def a) Serva automatically created "Windows 10" menu entry for EFI64 targets

menu.def

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

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

menu.def

LABEL WIA_WDS\Win10_64\ LABEL WIA_WDS\Win10_64\ menu label ^ 5) Windows 10, AMD64 menu passwd $5$2T5Bidc2$.Bbmhr $5$2T5Bidc2$.BbmhroqhplGQZhqv9WAUGMii oqhplGQZhqv9WAUGMiiWb5XDG6rSHbM2FCli3$ Wb5XDG6rSHbM2FCli3$ kernel kernel pxechn.c32 append append ::WIA_WDS\Win10_64\_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. calculator.


15/29

8/8/2017


Fig 9: Password protected menu entries

Warning Even when the calculated hash uses a randomly generated "salt" which makes password recovery from its hash very difficult all the good practices for password selection still apply.

7 Performance Serva PXE/BINL has two distinctive mutually exclusive exclusive working phases: 1. BINL Preparation/Maintenance 2. PXE/BINL Server 7.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: Asset OS Windows 10 Enterprise ltsb 64Bit Windows 8 Enterprise 64Bit Windows Server 2003 64Bit

Specs A 2 0s 21s 16s

Specs B 1.4s 1.5s 5.5s

These figures were obtained with Serva running on: A. Windows 7 PC, Intel Core 2 duo @ 2.2 GHz, 4GB RAM, HDD. B. Windows 8.1 PC, Intel i7 3630QM @ 2.40GHz, 16GB RAM, SSD. Maintenance times on the other hand (if they do not involve the re-creation of the driver database on RIS OSs nor ServaBoot.wim on WDS OSs) are much shorter but you should know there are certain actions that force the maintenance of the "whole" Serva repository: repository: 1. Changing the Repository root directory (in our example SERVA_REPO) 2. Changing Serva PC name 3. When required on certain Serva upgrades 7.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.

8 Troubleshooting 8.1- Serva general troubleshooting topics. See here here..

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

8.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 https://www.vercot.com/~serva/an/WindowsPXE1.html

16/29

8/8/2017


replaced by one provided by the OS being installed (RIS) or by the one used by the Windows PE executive (WDS). 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. 8.3.1- RIS OS OEM network drivers When the RIS OS we are network installing does not include a RIS network driver that matches our PXE client NIC we get an error message like this:

Fig 10: RIS, Missing Net driver error

Fig 10 shows the error displayed at client's screen, at the same time we can see a BINL net protocol transaction error logged on Serva's BINL and Log panels indicating "Net driver not found". On rare occasions, even when the BINL net protocol transaction correctly provides the requested driver, the driver code, for some reason, fails when running at the client. On these situations while Serva will not show any logged error, the error message at client's screen could even be as cryptic as this one:


17/29

8/8/2017


Fig 11: RIS, Not common Net driver failure

To circumvent these situations we can add up-to-date versions of the required OEM RIS capable network driver/s to the corresponding RIS WIA, under the directory i.e.

C:\SERVA_REPO\WIA_RIS\win2000P\$OEM$\$1\Drivers\NIC\ The required files would be i.e. NetDriverX. inf , NetDriverY.sys NetDriverY. sys,, and NetDriverY.cat NetDriverY.cat (if available). Please consider some OEM drivers might require the inclusion of some other additional files contained within the driver package. Always read the OEM driver documentation for details. The \NIC is a directory that is parsed twice; by Serva first and later-on by the OS install process itself. Serva only looks after "Net" class drivers in order to create the network driver database used by the the initial text phase of the install process. Serva completely ignores sub-directory content and other driver classes like i.e. "Storage" class drivers. To identify the NIC and then get its matching driver we can rely on manufacturer specifications or look for the network card VEN/DEV (Vendor/Device) identifiers on the corresponding failed BINL transaction displayed on Serva's BINL Log. In some circumstances, the driver packages available from the OEM 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. Notes 1. NetDriverX.inf and NetDriverY.sys are just two generic names but please consider con sider that NetDriverX.inf is a text file containing variables pointing to NetDriverY.sys; then if you change NetDriverY.sys name NetDriverX.inf affected variables must be edited accordingly. 2. In case we need to add more than one OEM network driver we repeat the process copying the corresponding driver components under the same directory (without creating subdirectories; Serva will ignore their content). https://www.vercot.com/~serva/an/WindowsPXE1.html

18/29

8/8/2017


3. In case we add an OEM driver with a missing NetDriverY. cat cat file file we will get a warning message about an "unsigned" driver being installed; If we trust the driver we just accept and continue the installation. 4. In case you need to add other than "Net" class drivers like i.e. a SATA "Storage" class driver you can add them under \Driver\ on their corresponding directories (see MS documentation) and finally add the necessary Unattended/OemPnpDriversPath entry to winnt.sif. Remember "Community Community"" versions of Serva will overwrite any manual editing of winnt.sif when necessary.

8.3.2- 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 12: 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. sys,, and NetDriverY.cat NetDriverY.cat (if available). Please consider some OEM drivers might require the inclusion of some other additional files contained within the driver package. Always read the OEM driver documentation for details. To identify the NIC and then get its matching driver we can rely on manufacturer specifications or 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.

setupapi.app.log

>>> [DIF_SELECTBESTCOMPATDRV [DIF_SELECTBESTCOMPATDRV - PCI\VEN_10B7&DEV_9200&S PCI\VEN_10B7&DEV_9200&SUB&YS_010D1028&REV_78 UB&YS_010D1028&REV_78\4&19FD8D60] \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)]


19/29

8/8/2017


In the setupapi.app.log file we locate the section that identifies the Plug and Play ID (PnPID) of the third-party network adapter i.e.

>>> [DIF_SELECTBESTCOMP [DIF_SELECTBESTCOMPATDRV ATDRV - PCI\VEN_10B7&DEV_9200 PCI\VEN_10B7&DEV_9200&SUBSYS_010D1028&REV_ &SUBSYS_010D1028&REV_78\4&19FD8D60] 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 some circumstances, the driver packages available from the OEM 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/etc. Notes 1. NetDriverX.inf and NetDriverY.sys are just two generic names but please consider con sider that NetDriverX.inf is a text file containing variables pointing to NetDriverY.sys; then if you change NetDriverY.sys name NetDriverX.inf affected variables must be edited accordingly. 2. In case we need to inject more than one OEM "Net" class driver (or for WDS OSs even a different class driver like i.e. an OEM "Storage" class driver) we repeat the process copying the corresponding driver components under the same directory (without creating subdirectories; Serva will ignore their content). If you are a professional installer you should know this injection method results convenient for a small amount of occasional OEM drivers; in case of a vast list of frequently used OEM drivers it is always a better idea adding them permanently to the corresponding \sources\Boot.wim using the "Deployment Image Servicing and Management" (DISM.exe) included within Windows AIK 2.0, MS 7, MS 8, etc. 3. In case we add an OEM driver with a missing NetDriverY. cat cat file file we will get a warning message about an "unsigned" driver being installed; if we trust the driver we just accept and continue the installation. 4. Serva injected OEM drivers are installed into the Windows PE executive at run-time; for this reason old-style OEM drivers that require to re-boot as part of their install process cannot be used. 5. If you are installing several WDS OSs you should know the corresponding Boot.wim files of the same architecture (32/64) architecture (32/64) are exchangeable. Then exchangeable. Then i.e. if your Vista install is missing some driver but your Windows 8 install has it just overwrite Vista's \sources\Boot.wim with Windows 8's and quit/restart Serva. 6. If you are a professional installer you could create a "super" Boot.wim including all the drivers you need and use it on all the WDS OS installs of the corresponding architecture.

The loading of OEM drivers can be traced by launching a console session from ServaPENet and listing with Notepad.exe the content of the 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: https://www.vercot.com/~serva/an/WindowsPXE1.html

20/29

8/8/2017


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 components requires "Serva " Serva Pro" 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. 8.3.3- 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.

8.4- Troubleshooting Network Share issues. 8.4.1- RIS OSs Null Session Share Installing RIS OSs always requires the creation of a Null Session Share as described in 4.5.1. When this share is not correctly set we will get stuck on a screen like:

Fig 13: Installing Windows XP/ Server 2003; process stopped. https://www.vercot.com/~serva/an/WindowsPXE1.html

21/29

8/8/2017


When your RIS Windows XP or Windows Server 2003 install process gets stopped on a screen like Figure 13 the chances are your Null Session Share is not properly configured. Windows 2000 also displays a similar waiting screen when experiencing similar problems. See here here for for help on how to set up Null Session Shares.

8.4.2- RIS OSs PROCESS1_INITIALIZATION_FAILED BSOD (Blue Screen of Death).

Fig 14: RIS, NSS WIA_RIS_SHARE pointing to the wrong directory

While the BSOD is displayed at the booting client Serva's log will look like:

Log

... [06/25 [06/25 [06/25 [06/255 [06/2 [06/25 [06/25

08:18:07.753] 08:18:07.941] 08:18:07.941] 08:18:08.097 08:18:0 8.097]] 08:18:08.097] 08:18:08.362]

TFTP TFTP TFTP TFTP TFTP TFTP TFTP

Inf: Inf: Inf: Inf: Inf: Inf: Inf:

Read file <\WIA_RIS\Win_XP_32\i386\rdbss.sy_>. Mode octet <\WIA_RIS\Win_XP_32\i386\rdbss.sy_>: <\WIA_RIS\Win_XP_32\ i386\rdbss.sy_>: sent blks=60 blkSz=1432, Read file <\WIA_RIS\Win_XP_32\i <\WIA_RIS\Win_XP_32\i386\mup.sy_>. 386\mup.sy_>. Mode octet <\WIA_RIS\ <\WIA _RIS\Win_X Win_XP_32\ P_32\i386\ i386\mup.s mup.sy_>: y_>: sent blks= blks=37 37 blkSz= blkSz=1432, 1432, T Read file <\WIA_RIS\Win_XP_32\i386\mrxsmb.sy_>. Mode octet <\WIA_RIS\Win_XP_32\i386\mrxsmb.sy_>: <\WIA_RIS\Win_XP_32\ i386\mrxsmb.sy_>: sent blks=154 blkSz=143

-^- stops here after correctly transferring mrxsmb.sy_

You get this error when the correctly created Null Session Share WIA_RIS_SHARE WIA_RIS_SHARE is wrongly pointing at i.e. C:\SERVA_REPO\ WIA_RIS WIA_RIS when it should have been pointing at C:\SERVA_REPO instead. Please re-read 4.5.1 When installing RIS OS's .

8.4.3 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. https://www.vercot.com/~serva/an/WindowsPXE1.html

22/29

8/8/2017


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. If your network and server are ok I would recommend checking the NIC and specially its driver. There were reported 0x35 errors when installing Vista while the same client installed Windows 7/8 correctly. On all these cases: 1) Replacing Vista's \sources\Boot. \sources\Boot.wim wim with Windows 7/8 \sources\Boot. \sources\Boot.wim. wim. 2) Erasing Vista’s _SERVA_ directory. 3) Quit and restarting Serva. Solved the problem.

8.4.4 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_SHAR WIA_WDS_SHARE E is not created or it is miss-configured. 2) Sometimes when the client "directly" connects to Serva's PC by an Ethernet crossover cable cable ("backto-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_SHAR WIA_WDS_SHARE E 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.

8.5- Troubleshooting DHCP configuration issues. 8.5.1- RIS OSs proxyDHCP requirement RIS clients expect getting their BINL server IP from a PXE/BINL transaction carried out on port 4011. Serva provides those transactions when its DHCP service is set to proxyDHCP mode. Then when installing RIS OSs remember choosing proxyDHCP on on Serva's DHCP configuration tab. Failing to do this will lead to RIS OS installations that are interrupted just before the BINL NIC request takes place. Once the installation gets stopped and after a long delay a somehow misleading Missing Network Driver Error (like (like the one at Fig 10) will be displayed.

Log

... [03:48:46.843] [03:48:46.884] [03:48:46.889] [03:48:46.891] [03:48:46.896] [03:48:46.898] [03:48:46.904] [03:48:46.906]

TFTP TFTP TFTP TFTP TFTP TFTP TFTP TFTP

Inf: Err: Inf: Err: Inf: Err: Inf: Err:

Read File Read File Read File Read File

file <\WIA_RIS\XP_32\i386\migrate.in_>. <\WIA_RIS\XP_32\i386\migrate.in_>. Mode octet : error 2 in CreateFile; The file <\WIA_RIS\XP_32\i386\migrate.inf>. <\WIA_RIS\XP_32\i386\migrate.inf>. Mode octet : error 2 in CreateFile; The file <\WIA_RIS\XP_32\i386\unsupdrv.in_>. <\WIA_RIS\XP_32\i386\unsupdrv.in_>. Mode octet : error 2 in CreateFile; The file <\WIA_RIS\XP_32\i386\unsupdrv.inf>. <\WIA_RIS\XP_32\i386\unsupdrv.inf>. Mode octet : error 2 in CreateFile; The

-^- stops here, long delay, then a Missing

Network Driver Driver Error (Fig

10) will be displayed.

8.6- 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. https://www.vercot.com/~serva/an/WindowsPXE1.html

23/29

8/8/2017


8.7- Troubleshooting TFTP issues. 8.7.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] [2] [3] [4]

TFTP Inf: Read file <\WIA_WDS\w8_32\_S <\WIA_WDS\w8_32\_SERVA_\boot\bcd> ERVA_\boot\bcd>.. Mode octet TFTP Err: Peer Err: Peer returns ERROR -> aborting transfer TFTP Inf: Read file <\WIA_WDS\w8_32\_S <\WIA_WDS\w8_32\_SERVA_\boot\bcd> ERVA_\boot\bcd>.. Mode octet TFTP Inf: : Inf: : 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.

8.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. TFTP. Most of the client NICs do not present problems with this mode, some old ones might. See this pattern:

[1] [2] [3] [4]

TFTP Inf: Read file . Mode octet TFTP Err: timeout Err: timeout waiting for ack blk #4 TFTP Err: timeout Err: timeout waiting for ack blk #9 TFTP Inf: : 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". windowed". You can solve this problem by disabling the TFTP "Enforced windowed" mode or upgrading your NIC's firmware.

8.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 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:


24/29

8/8/2017


... [08/20 [08/20 [08/20 [08/20 [08/20 [08/20 [08/20 [08/20

18:38:40.197] 18:38:41.298] 18:38:43.301] 18:38:46.302] 18:38:49.302] 18:38:52.303] 18:38:55.303] 18:38:55.303]

TFTP TFTP TFTP TFTP TFTP TFTP TFTP TFTP

Inf: Err: Err: Err: Err: Err: Err: Err:

Read file . timeout waiting for ack timeout waiting for ack timeout waiting for ack timeout waiting for ack timeout waiting for ack timeout waiting for ack TIMEOUT & abort waiting

Mode octet blk 16#1 #1 blk 16#1 #1 blk 16#1 #1 blk 16#1 #1 blk 16#1 #1 blk 16#1 #1 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).

8.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 \boot\bcd>. >. Mode octet [2] TFTP Inf: : >: 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 <\Boot\BCD>. >. Mode octet [2] TFTP Err: File <\Boot\BCD <\Boot\BCD>> : error error 3 in 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 15: 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. https://www.vercot.com/~serva/an/WindowsPXE1.html

25/29

8/8/2017


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.

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

Log

... [16:15:38.723] [16:15:43.553] [16:15:49.675] [16:15:55.696] [16:16:01.583] [16:16:06.391] ...

TFTP TFTP TFTP TFTP TFTP TFTP

Inf: Err: Err: Err: Err: Inf:

Read file <\WIA_WDS\s2012_R2\_SERVA_\boot\ServaBoot.wim>. <\WIA_WDS\s2012_R2\_SERVA_\boot\ServaBoot.wim>. Mode octe timeout waiting for ack blk 16#24032 #24032 timeout waiting for ack blk 16#56792 #56792 timeout waiting for ack blk 16#24016 #89552 timeout waiting for ack blk 16#56776 #122312 <\WIA_WDS\s2012_R2\_SERVA_\boot\ServaBoot <\WIA_WDS\s2012_R2\ _SERVA_\boot\ServaBoot.wim>: .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 here (Oct/2013) (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.

8.8- Troubleshooting WDS OSs missing "Repair your computer" link After a successful ServaPENet login we'll see one of these screens:


26/29

8/8/2017


Fig 16-18: WDS OSs missing "Repair your computer" link

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 RecEnv.bat i.e. i.e.

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

@ECHO OFF cd /d %systemdrive%\sources %systemdrive%\sources\recovery \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.

8.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.

8.10- Troubleshooting Preparation stage issues. 8.10.1- WDS OS ServaBoot.wim creation error

Log

... [22:19:14.789] [22:19:15.185] [22:19:15.602] [22:19:15.625] [22:19:15.635] [22:19:16.672] https://www.vercot.com/~serva/an/WindowsPXE1.html

BINL BINL BINL BINL BINL BINL BINL BINL BINL

Inf: Inf: Inf: Inf: Inf: Err:

Preparation/Maintenance procedures "Start" ** Preparation/Maintenance Expandd OK, C:\SERVA_REPO\WIA_WDS\win8_x64\_SER Expandd C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\pxeboot.n12 VA_\pxeboot.n12 Expandd OK, C:\SERVA_REPO\WIA_WDS\win8_x64\_SER Expandd C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\bootmgr.exe VA_\bootmgr.exe Copied OK, C:\SERVA_REPO\WIA_WDS C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\boo \win8_x64\_SERVA_\boot\boot.sdi t\boot.sdi Created OK, C:\SERVA_REPO\WIA_WDS\win8_x64\_SER Created C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\ServaBINL.dat VA_\ServaBINL.dat Creating C:\SERVA_REPO\WIA_WDS C:\SERVA_REPO\WIA_WDS\win8_x64\_SERVA_\boo \win8_x64\_SERVA_\boot\ServaBoot.wim t\ServaBoot.wim 27/29

8/8/2017


[22:19:17.009] BINL Inf: Preparation/Mainten Preparation/Maintenance ance 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).

8.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 environments available today (BIOS/EFI64/EFI32). 8.11.1- UEFI firmware compatibility We have found that UEFI firmware implementations are not rock solid yet; sometimes 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 For all of the above and also considering people needing UEFI Secure Boot Serva v3.x BINL service includes three “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. BMM 1 2 3*

BIOS Client pxeserva.0 pxeserva.0 pxeserva.0

EFI64 Client pxeserva.efi bootmgfw.efi bootmgfw.efi

EFI32 Client pxeserva.efi bootmgfw.efi bootmgfw.efi

* Idem BMM=2 but supporting UEFI Secure Boot (this mode requires "Serva " Serva Pro") Pro") A PXE client declares its pre-OS runtime environment at boot within its initial DHCP request by including the DHCP Option 93 (RFC ( RFC 4578). 4578). 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. DHCP DH CP Op Opti tion on 93 0 6 7 9

Clie Cl ient nt's 's pr pree-OS OS ru runt ntim ime e BIOS EFI32 EFI64 EFI64

Serva’s BINL BMM defaults to "1" where pxeserva.efi offers on UEFI environments virtually the same features pxeserva.0 offers on BIOS environments. If UEFI related compatibility issues are found (i.e. an UEFI client fails to correctly display Serva's menu) BMM=2 provides an alternative based on Microsoft's Boot Manager (bootmgfw.efi) but it only supports the boot/install of MS assets. When UEFI Secure Boot 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.

9 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 those fantastic pieces of software called Microsoft RIS and WDS. Today Serva PXE/BINL also includes advanced features like unattended installs, Windows PE booting, or single-menu multi-repository integration. Please read


28/29

8/8/2017


about these exiting features here: Serva PXE/BINL - AN02: Windows Network Install (Adv) & WinPE Boot. 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. Nonpersonal or commercial use of Serva always requires a Serva Pro license (see Serva's download download page for further details). Professional 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 us here here..

Updated

08/30/2016

Originally published

05/08/2012

Copyright © 2010-2017 Patrick Masotta. All rights reserved.


29/29

Serva PXE Windows Network Install

Recommend Documents