I needed to install Windows Server 2012 R2 on a PC with no optical drive and I didn't have any USB device to put the image on. I resorted on using a network install through PXE.
I found a great win app to do so, Serva. Serva is a tiny (~1 Mb), yet powerful Microsoft Windows application. It was conceived mainly as an Automated PXE Server Solution Accelerator. It bundles on a single exe all of the underlying server protocols and services required by the most complex PXE network boot/install scenarios simultaneously delivering Windows and non-Windows resources.
While most of the process is quite straightforward and the Serva documentation is great, there were a few gotcha I will document now.
Install
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.
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_ROOT\
Configuring Serva's proxyDHCP/DHCP server.
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). 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.
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.
This is one big difference with the online documentation. I needed to install Serva on the Windows Domain / DHCP server because Windows would always serve its own IP address. The client received PXE "booting parameters" (file, next server, DHCP option 66, DHCP option 67) from the Windows Domain server instead of the Serva server. 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". It should be possible to alter DHCP options 66 and 67 in Windows but I didn't dare. As Serva doesn't need installation it was easier to just copy it over there.
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.
Populating Serva's WIA_RIS and WIA_WDS class directories.
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). For 64 bits you will need to copy the content \AMD64\*.* to I386\ (it implies merging the content of the \LANG directories). b) WIA_WDS will hold only Windows Vista and up distributions (32/64). No 32/64 copy/merging needed. c) Every distribution has to be copied in full under its own manually created "head" directory exactly as it comes from the Microsoft distribution media. d) 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:
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).
When installing RIS OS's :
WIA_RIS' parent directory which is also the TFTP Server Root directory (C:\SERVA_ROOT\ in our example) has to be shared as WIA_RIS_SHARE using a read-only "Null Session 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 makes this technology not easily ready for a multi-OS network install system like Serva.
Notes: It seems natural to think that WIA_RIS_SHARE in our example should point at C:\SERVA_ROOT\WIA_RIS but that is not how MS RIS works. WIA_RIS_SHARE must point at C:\SERVA_ROOT (TFTP Server Root directory) instead. 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 single-step operation. See here for details.
When installing WDS OS's :
Directory WIA_WDS 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.
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.
Booting a PXE Client.
Now is the interesting part! 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 the Serva v2.1.0 multi-OS PXE Boot/Install Menu.
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 here 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.
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.