Novell is now a part of Micro Focus

AppNote: Building Nterprise Deployment Solutions using NetWare 6.5

Novell Cool Solutions: AppNote
By Simon Lidgett

Digg This - Slashdot This

Posted: 23 Mar 2004

A Technical Insight into Novell's New PXE-based Imaging Deployment Solution

Simon Lidgett
Strategic Engineer
Novell Developer Services

Table of Contents

Deconstruction of the Server
Functional Deconstruction
Blade Servers
Form Factor Change
Legacy Free Environments
Deployment Strategy
Deployment Solutions
PXE-based Installation and Imaging
PXE-based Imaging Deployment solution
Component Architecture
NetWare Reference Image
Response File Generation
Reference Response File
File Definition Structure
TFTP Setup
DHCP Setup
Working Example
Product Partner Page

1.0 Introduction

Deciding on a Novell solution is a step in the right direction, but without an efficient deployment strategy you may encounter unnecessary and costly delays. Building a deployment solution that works for your organization is paramount. Using Novell's new PXE-based imaging deployment solution, organizations can choose from a variety of deployment paths that meet their needs.


This paper will focus on how to build Nterprise deployment solutions using NetWare 6.5 in the context of blade servers, to demonstrate new technologies from Novell and its partners that facilitate unattended (fully automated) and scripted, semi-automated deployments. Before introducing Novell's new PXE-based imaging deployment solution, it is worth setting the scene beforehand to explain what is driving the need for such a solution.

Deconstruction of the Server

Computing has progressed down a road of ever increasing density and power, and ever decreasing cost. The original "beige box" towers gave way to departmental standalone machines to computer center rack-mount machines which, in turn, will give way to the recently promoted blade servers (completely headless machines). This trend has been stimulated by two factors: first, chip density and second, functional deconstruction (Moore's Law -- see

Functional Deconstruction


Functional deconstruction of hardware works like this. In the beginning, the big box held everything and everything was a discrete piece of hardware: motherboard (CPU and memory), storage, video card, LAN card, power supply, cooling fans, communications, and peripherals (floppy, CD, etc.). Over time, devices like LAN and video migrated to the motherboard, which not only accommodated the integration, but became smaller in the process. Then, storage was separated from the server box.

The advent of SCSI paved the way for detached RAID. The NAS (Network Attached Storage) box made storage even more independent. Finally, fibre-channel and iSCSI technology gave birth to the Storage Area Network (SAN). In the end, storage had walked away from the server box. With the server box becoming increasingly hollow, the rack mount server box was born. The rack mount stood 1.75 inches high, 19 inches wide and about 24 inches deep. It was one big motherboard with integrated I/O, with power and cooling, and some minimum floppy/CD support. Density in the data center grew dramatically.


The deconstruction of the server at the hardware level is matched by an equal deconstruction at the software level. To be concise, software only needs to do whatever needs to be done on the deconstructed hardware. The forces of commoditization that bring ubiquitous hardware components to the market also force ubiquitous software components into existence. What once comprised a large operating system has gradually fragmented into separate components.

Both MicrosoftTM and NovellTM separated the I/O driver components into modules that stood separate from the core operating system. This separation allowed for the replacement and upgrade of drivers without rebuilding the operating system. The UNIX/Linux vendors have been slower to separate the drivers, but progress is being shown. On the other hand, the UNIX/Linux world was early in its treatment of file systems as pluggable components, an optional component based on the particular use of the system.

Blade Servers

Dense computing capability does solve one set of problems. Conventional technology limits the electrical draw and cooling capability for a rack. This directly limits rack capacity. Each machine could have dual processors thus raising the CPU inventory. Moreover, these CPUs could represent such high powered chips as the Intel XEON and Pentium 4 lines. This is a significant amount of computing power in a single rack. Unfortunately, the demands on data centers have made even this large amount of computing power inadequate to meet the demands of the emerging digitally connected economy. Expanding the physical data center is a very expensive proposition. Consequently, increased computing power in the same physical space is a very attractive alternative.

The introduction of the blade server form factor provides such an alternative. New blade and chassis designs can populate hundreds of low power Pentium 3 class blades in that same single rack space.

The initial offerings have used the low power "mobile" chips to meet the power limitations, but current offerings are beginning to sacrifice such high density for higher powered CPUs such as the Intel XEON chips. Thus, there will emerge an optimal level of density for a given set of data center tasks. This is much cheaper than expanding the data center.

IHVs taking the lead in Blade Server designs include:

  • DELL -- PowerEdge 1655MC
  • Fujitsu Siemens -- PRIMERGY BX300 Blade Server
  • HP --- Proliant BL p-Class
  • IBM -- eServer Blade Center

Much of Novell's focus as it moves forward is to anticipate and embrace the changes taking place in the hardware industry. We witness the continued deconstruction of the traditional server and the benefits that are arising from the new found modularity.

Form Factor Change

Blades are a form factor change, one that improves density and lifts the traditional limits on processing density and rack HVAC consumption. Data center floor space is expensive real estate. The advent of blades allows the IT shop to meet the increasing demand for computing services without having to build another data center. This is a very cost effective solution.

Legacy Free Environments

Most hardware vendors are now moving toward a "legacy free" environment. The traditional notion of floppy disks, etc. is being replaced by a single USB port. New devices are USB and simply plug into the port. This simplifies the design of the computing machine, but it also forces software vendors to approach their task a little differently. Most importantly, there can be no assumptions made about what kind of device might be attached to the USB port. Software vendors must anticipate totally headless environments. Future processor boards might have no video chip sets. The operating platforms must accommodate this. (All references to USB in this document should be interpreted as USB 2.0.)

Therefore it is obvious that traditional methods of deploying traditional OSs, such as Novell NetWare, to a blade server now prove awkward. There is little provision for locally attached peripheral devices such as a floppy disk or IDE/SCSI-based CD-ROM unit needed in support of the Operating System media, during install time.

Deployment Strategy

The first iteration of Novell's deployment strategy effort is focused on supporting blade servers. However, it becomes a part of an overall direction, which will evolve into a broader scope. Importantly, the deployment of NetWare on blade servers represents the "worst case" scenario. By solving this we can provide customers with a unique and universal solution irrespective of the actual hardware procured.

Secondly, Novell is actively working with hardware vendors to make sure that new deployment methods involving NetWare can happen within existing IHV (Independent Hardware Vendor) management scripts and utilities, examples being:

  • IBM Remote Deployment Manager
  • HP SmartStart
  • Fujitsu Siemens Computers ServerStart

Novell will still provide DR-DOS 7.0 where the configuration software has not provided an alternative boot vehicle. And Novell will ensure that the configuration software still works with the new boot loader (Bootable NetWare) introduced with NetWare 6.5 SP1 (Overlay).

Deployment Solutions

The short term technical goal is to provide for two methods of installation and deployment:

  • Support for local USB CD-ROM/DVD media
  • Support for remote PXE-based installation and imaging

Note: PXE is short for Pre-Boot Execution Environment. Pronounced pixie, PXE is one of the components of Intel's WfM specification. It allows a workstation to boot from a server on a network prior to booting the operating system on the local hard drive.


USB based CD-ROM/DVD support is required by all major hardware vendors and Novell has already put in place mechanisms to support it, namely:

  • USB Pre-boot CD-ROM
  • Bootable NetWare

These deployment methods are classed as 'attended-mode' installations, since manual user intervention is required. They are therefore out of scope for this particular document. However, there are plans to write supporting documentation to explain the technical insights for both these methods at a later date.

PXE-based Installation and Imaging

PXE based deployment is new to our customer base and Novell will provide an intuitive method of implementing the necessary architecture for simple PXE-based deployments, from an installation point of view.

Full customization of imaged machines through PXE is still being defined and developed as an on-going Engineering activity. Ideally, having a solution that allows on-the-fly deployments of images to multiple servers, each then having their own programmed identity, is a future initiative that Novell is working on together with its Imaging vendors.

Novell will continue to focus on the evolving legacy-free environments to insure that NetWare 6.5 and future versions are fully functional in that environment.

This deployment method is classed as an 'unattended-mode' installation, since little or no user intervention should be required. The totally headless environment that is a blade server must be completely manageable remotely. From bare-metal blade to fully functional services, the deployment must be driven automatically by scripting mechanisms and policies.

PXE-based Imaging Deployment solution

Novell's new PXE-based Imaging Deployment Solution (referred to as PIDS, for the purposes of this document) encompasses both new and existing tools from Novell, the Open-Source developer community, and third-party imaging vendors. It has been developed to satisfy the following design, useability and business requirements:

  • Flexible, extensible and fully scriptable
  • Easy implementation of off-the-shelf third-party imaging tools, which simply snap into the solution
  • Helps to preserve and maintain customer investment
  • Provides a granular, configurable and manageable deployment
  • Customized so that fully or semi-automated deployments can take place (customer requirement)
  • Uses Linux as its operating system foundation

Note: Initial support for Linux will come through SUSE and Red Hat Enterprise Server (and/or Professional) Linux distributions.

Component Architecture

The components that make up PIDS can be listed as follows and each will be described in turn, with a working example given to show how all the components interoperate with each other:

  • nvlnbpd -- Imaging Policy Engine
  • nvlnbp.sys - Network Bootstrap Program
  • Configuration Files/Scripts
    • pxenics, hwdrv, response_ip, genresponse, floppyimages (optional) and startpxe
  • Configuration Tools
    • getsrvnm.exe, genclnt.exe
  • Floppy Boot Images
    • floppy1, floppy2.img
  • Supporting Linux Services/Components
  • Third-party Imaging Software

Components that are needed in support of PIDS can be summarized here as:

  • A TFTP Service -- Trivial File Transfer Protocol
  • A DHCP Service -- Dynamic Host Configuration Protocol
  • Proxy DHCP service (optional)

Third-party imaging software supported by PIDS currently is:

  • Portlock Storage Manager
  • PowerQuest Deploy Center

For the Portlock Storage Manager solution, all the new and supporting components in addition to the imaging software can be deployed, configured and executed from a single PC Server, known for the purposes of this document as an Image Repository Server. Since the Image Repository Server will be running Linux, standard daemons such as TFTPD and DHCPD can be used to facilitate the Novell-developed services.

In the case of PowerQuest Deploy Center, a PXE Server needs to be additionally installed and running. Please refer to the Novell NetWare 6.5 Blade Server Installation Guide ( for more information.

Support for other imaging vendors will be integrated over time, as Novell forms partnerships with these vendors.

The procedure described below assumes that Portlock's StorageManager is used as the imaging software solution.


Located and running at the Image Repository Server, nvlnbpd is a Linux daemon (supporting SUSE and Red Hat). It is akin to a 'ZENworks Image policy engine' and its main responsibility is to determine which floppy boot image to download to a PXE Client. The term PXE Client refers to any system making a valid PXE request. For the purposes of this document a PXE Client is defined as a blade server.

The floppy boot image downloaded to the PXE Client is determined by reading the pxenics configuration file. The TFTP service running on the Image Repository Server is responsible for downloading the actual floppy boot image to the PXE Client. Nvlnbpd will respond to UDP requests from nvlnbp.sys, see below. This is important since nvlnbpd is also responsible for determining and acting upon the hardware configuration of the PXE Client. (In the future nvlnbpd will use this information to derive image policies.)


Running at the PXE Client, nvlnbp.sys is a Network Bootstrap program. It gets downloaded to the PXE Client from the Image Repository (DHCP/PXE) Server via TFTP. Its main responsibility is to gather the hardware configuration information about the PXE Client and sent it back to nvlnbpd, via UDP. It also makes a request for a boot image filename, which it then uses within a TFTP request to download the actual floppy boot image from the Image Repository Server. Once downloaded, nvlnbp.sys transfers control over to this boot image.

The communication paths involved between nvlnbp and nvlnbp.sys are summarized in Figure 1. nvlnbpd and nvlnpb.sys communication path.


Created automatically by nvlnbpd and located at the Image Repository Server, pxenics is a configuration file which records information relating to the PXE Client in terms of its current boot sequence number and MAC Address. This information is used by nvlnbpd to determine which floppy boot image the PXE client should receive. Entries are dynamically added and updated as new and existing PXE Clients communicate with nvlnpbd.

This file can be edited in order to override a PXE Client's current boot sequence. However, only modify this file in terms of the Boot Sequence Number. Do not modify the associated MAC Address. Figure 2 pxenics file example, gives an example showing the typical entries found inside pxenics.

The boot sequence number is first interpreted and then incremented by nvlnbpd in the following way:

0     Means that the PXE Client has never booted before, nvlnbpd sees it for the very first time. A new entry gets recorded, based on the PXE Client's MAC Address. Setting the boot sequence to zero is useful if you wish to reset a PXE Clients boot sequence and start again from fresh.
1     The PXE Client has booted once. nvlnbpd will send the PXE Client the floppy boot image filename "floppy1.img".
2     The PXE Client has booted twice. nvlnbpd will send the PXE Client the floppy boot image filename "floppy2.img".
3     The PXE Client has booted a third time. The PXE client is told to boot from its local hard disk.


Located at the Image Repository Server, hwdrv is a configuration file which stores "PCI Configuration Space' information pertaining to the PXE Client's LAN driver (Figure 3 hwdrv file example). Each entry takes the form:


This information is used by Floppy Boot Image floppy1.img when loading Novell's DOS Client32 network stack, explained later in this document. This is extremely useful in that a user does not have to manage nor modify the LAN driver load sequences for a host of PXE Clients which may have different LAN hardware configurations, instead it is done dynamically.

In the example above there are two LAN entries, one detailing the PCI Vendor and Device identifiers for an Intel CE100B LAN driver and the other, a Broadcom B57 LAN driver.

Presently this file has to be created manually. The Vendor_ID and Device_ID for many of the popular (Industry Standard) PCI LAN controllers can be obtained by using PCI.EXE, a freeware utility, which has no copyright restrictions on use nor distribution. The tool ( and pcidrv.txt) can be downloaded from:

Extract the zip file and pcidrv.txt (latest supported drivers list) to a bootable floppy diskette. Boot the machine from the floppy diskette and execute:

pci --d > report.txt

This will produce a report, detailing all the PCI devices found in addition to their respective vendor ID's and description. For example, on a machine with an integrated Broadcom 1GB LAN controller, PCI.EXE will report:

Vendor 14E4h Broadcom Corp
Device 16A7h BCM5703X NetXtreme Gigabit Ethernet

Please note that Novell will not provide support for this tool.


Floppy Boot Image floppy1.img is downloaded to a PXE Client, via TFTP from the Image Repository server, based upon the information contained in pxenics. Once the download is complete the PXE Client will boot from this image.

Floppy1.img will:

  • Download third-party imaging software into a RAM drive.
  • Download hwdrv from the Image Repository Server and, using a tool called genclnt, dynamically build a batch file to start the Novell DOS Client32 stack, with the correct LAN driver.
  • Launch the Novell DOS Client32 stack up to the point of loading TCPIP.NLM, in order to receive a dynamic IP address from the DHCP server.
  • Execute the third-party imaging software
  • Start the imaging process of the PXE Client using a [base] NetWare image (termed NetWare Reference Image, explained in the next sub-section)
  • Once the imaging is complete, the PXE Client reboots.


    Floppy Boot Image floppy2.img is downloaded to a PXE Client, via TFTP from the Image Repository server (again based upon the information contained in pxenics). Once the download is complete the PXE client will boot from this image.

    Floppy2.img will:

    • Execute a tool called getsrvnm in order to request a "Server Name" from the Image Repository Server
    • Receive a dynamically generated response file (response.tmp) from the Image Repository Server, this gets stored on the PXE Client in the C:\NWINST.TMP directory. This response file is created at the Image Repository Server by a tool called genresponse
    • Receive via TFTP other files necessary to compliment the deployment of NetWare, namely: Licensing Files, Device Driver files, and Support Modules (depending on the machine type).

    Both floppy1 and floppy2.img should be created manually, using a preferred floppy disk image creator. Novell will assist this process by offering sample image files, which can be modified in accordance to the Imaging Software used and additional support files required. In addition the default floppy boot images can be overridden and different images used instead. This is made possible through the use of the floppyimages configuration file.


    Created manually and located at the Image Repository Server this configuration file is used to override the default Floppy Boot Image files -- floppy1 and floppy2.img.

    Choosing to have alternative boot images is an optional method to enhance the way the PXE client boots. For example, there may be a number of different Blade Servers that need to be deployed and they should boot in different ways. Perhaps a high memory manager (like EMM386) is needed in support of the PXE Client hardware and DOS Client32, the Imaging Software or both. Perhaps special device drivers are needed, which are not included in the default floppy boot images supplied by Novell. Using the floppyimages configuration file helps to solve this issue.

    The 'floppyimages' file and associated boot images must be created manually. 'floppyimages' simply lists the image file names to be used preceded with a phase number. This phase number should match exactly the boot sequence number found in the pxenics configuration file. Each entry in the floppyimages configuration file takes the form:

    <Phase> <Floppy_Image_Name><Manufacturer_Name>

    An example of this file is given in Figure 4. floppyimages file example

    In the above example we see that a customer is using a mixture of blade servers from HP/Compaq, Fujitsu and IBM. When the HP/Compaq blade server boots it will receive the boot image 'n7hepq1.img' rather than 'floppy1.img'. When it boots a second time it will receive 'n7he2.img' rather than 'floppy2.img'. On the other hand a Fujitsu Siemens blade server will receive a different image file, n7he1.img, when it first boots, but the same image as the HP/Compaq when it boots again. Different boot images are sent to an IBM blade. This shows the customization that can be achieved through the use of floppyimages.

    Any entry that does not have a matching manufacturer_name entry will be ignored, and the Novell floppy boot images will be downloaded instead. The manufacturer_name must match exactly that reported in the machines System BIOS' SMBIOS table.

    To create these images simply take the Novell boot images and, using a preferred image editor, write them to one or more floppy disks and then modify them to suit. Re-create each image using whatever filename convention suits, and create 'floppyimages' based around the names of these images.

    Under Linux you can use the 'dd' command to expedite this -- for example, to write image n7he2.img to a floppy diskette, execute dd using the following syntax:

    dd if=n7he2.img of=/dev/fd0 count=1 bs=1440k

    Assuming that the contents of the floppy diskette are then changed, use dd to write the diskette back to an image thus:

    dd if=/dev/fd0 of=<name_of_image>

    NetWare Reference Image

    Located at the Image Repository Server a NetWare Reference Image is required, which serves as a base install image for every PXE Client. In earlier versions of NetWare (5.1 and 6.0) a base install was termed a factory install and this was made possible through the use of a special response file. In NetWare 6.5 there is no need to create a response file. New install options are available to automatically generate a base image:

    To create a base install image using NetWare 6.5 start the installation using the following option (executed from DOS, after selecting to start a manual install):


    To create a base install image using the NetWare 6.5 SP1 (OS Overlay CD) start the installation using the following option (after interrupting the Bootable NetWare boot sequence):

    [INST: image]

    For more information on how to use these install options please refer to Novell's Product Documentation web site at

    Once the base install is complete shutdown the server and take a full image using Portlock Storage Manager or PowerQuest Deploy Center. Copy the image to the Image Repository Server. It is advisable that the base install be performed on a machine which matches the hardware configuration used by a would-be PXE Client. However, the NetWare install process will carry out a full hardware check and load drivers for new hardware found, once the machine reboots.

    Novell does intend to make a generic NetWare Reference Image available for free download, so that customers do not have to carry out this manual install step. However support for this image will be limited.

    Response File Generation

    As mentioned previously response files, which define unique characteristics for a server, are dynamically created for each PXE Client. This is achieved using the genresponse script and an associated configuration file called response_ip.

    Created manually, each entry in response_ip takes the form (Figure 5 response_ip file example):

    <IP_Address> "Server_Name> available|<MAC Address>

    An example is given here:

    The keyword available means that the IP Address for the would-be PXE Client (in this case a Blade Server) has not been assigned yet. This entry will be ignored until such time as a valid MAC Address associated with this particular Blade Server is entered.

    When an entry contains a valid MAC Address the following will occur at the Image Repository Server:

    • A directory is created, based on the Server_Name entry
    • A reference response.tmp file is copied into this directory (Response.tmp must be created manually first, see below)
    • genresponse uses the Linux SED utility to modify the 'ServerName' and 'IP Address' parameters found in response.tmp, based on response_ip.

    For more information on response files refer to the Novell Documentation web site at

    Reference Response File

    A reference response file can be created using Novell's Deployment Manager utility. Brief instructions are given below:

    • Start the Deployment Manager utility on a workstation by inserting NetWare 6.5 CD 1(Operating System) and running nwdeploy.exe from the root of the CD.
    • Click the Automate an Installation link under the Install/Upgrade Options heading for instructions on automating the NetWare 6.5 installation using a response file.
    • Click the Response File Generator link to access the Response File Creation utility, which assists in creating response files.
    • Follow the instructions in "Using the Response File Generator" in the NetWare 6.5 Response File Installation Guide to specify the server name, IP address, and other information for the new server.
    • Be sure to select the Blade Image option when asked if the response file is for a new server or a headless blade image (Figure 6 Deployment Manager -- Offline response file example)

    Figure 6. Deployment Manager -- Offline response file example

    Once the response file is created, copy it to the Image Repository Server.

    File Definition Structure

    When setting up the PIDS environment all components should be first copied to the Image Repository Server. The following is a general recommendation as to where these components should be stored.

    floppyimages (optional)
    NetWare Reference Image
    License files
    Support Files
    {Server_Name}/ (Directory created dynamically)

    **startpxe is simply a script used to launch all daemons needed in support of PIDS. An example of this script is given below, given that no services are being started automatically:

    /etc/init.d/dhcpd start ./etc/init.d/tftpd start ./nvl_tftpd/nvlnbpd

    This script starts the DHCP Server and TFTP server demons and then launches the nvlnbpd demon.

    TFTP Setup

    If the PIDS components are to be stored elsewhere then the TFTP demon must be made aware of this, through its configuration file, which is stored at: /etc/xinit.d/tftp. The following is an example for this file. The "-s .../nvl_tftp" argument for "server_args" indicates the default home directory from which all files downloaded via TFTP are located. So, if the PIDS components have been copied to /home/slidgett/nvl_tftp the tftp configuration file will look something like this:

    service tftp
       socket_type	= dgram
       protocol	= udp
       server_args	= -u nobody -s /home/slidgett/nvl_tftp
       cps		= 100 2
       disable	= no

    DHCP Setup

    As dhcpd starts, the configuration file /etc/sysconfig/dhcpd is used to configure DHCP in the specified way. Ensure that the DHCPD_INTERFACE entry is set to the appropriate interface that is going to support DHCP, i.e:


    There are entries in the /etc/services file that will also need to be added to support PXE extensions, i.e:

            pxe 67/tcp
      pxe 67/udp
      tftp 69/tcp
      tftp 69/udp
      tftp-mcast     1758/tcp
      tftp-mcast 1758/udp
      pxe 4011/udp

    To ensure that these entries are added to the right section of /etc/services search on the Port Number (67, 69, 1758, 4011) to locate and then add a new entry.

    Working Example

    The following is a working example of PIDS in the context of using Portlock's Storage Manager imaging software.

    Once all the files are in the appropriate places on the Image Repository Server and all the necessary services are started along with nvlnbpd, the PXE Clients (Server Blade or Blades) to be installed can be powered on.

    The Blade PXE boots and requests a DHCP IP number. Along with the IP number, nvlnbp.sys is downloaded to the Blade. Nvlnbp.sys sends an UDP packet to the server which is received by nvlnbpd. Nvlnpd uses pxenics to determine which floppy image file to send to the blade. The pxenices file records the install phase and MAC address of the booting blade. Nvlnbpd determines that floppy1.img should be downloaded and replies as such. Nvlnbp.sys downloads floppy1.img via TFTP and transfers control to floppy1.img. Floppy1.img now executes as if the Blade booted from this image.

    Floppy1.img runs through its autoexec.bat which in effect downloads the Portlock Storage Manger code into a RAM drive. It then Downloads hwdrv and generates a batch file to start Novell Client32. Client32 executes up to loading TCPIP. Storage Manage then executes. Storage Manager then proceeds to image the Blade's hard drive using a NetWare Reference Image stored at the Image Repository Server. Once the image is complete the Blade reboots.

    Upon reboot floppy2.img is determined to be downloaded. Nvlnbp.sys transfers control to floppy2.img and floppy2.img runs as if the Blade booted from that image. Among other things the image requests the name of the soon to be installed NetWare server via getsrvnm.exe. This utility sends a UDP packet to nvlnbpd running on the Linux server. Nvlnbpd creates a process which executes genresponse. Genresponse reads the response_ip file to find the Server Name and IP number that is to be used for this Blade install. It also copies and modifies the response.tmp file to contain the found Server Name and IP number. The server name is then sent back to the blade. Using the returned name, the blade can then download the response.tmp file that was prepared for it by the server genresponse script and place the response.tmp file on the Blade's imaged hard drive. Other files, licenses, etc as necessary are also downloaded. The Blade reboots again.

    Upon the third sequential reboot the Blade will perform a local boot. Nvlnbp.sys exits and lets the Blade boot from its imaged hard drive. At this point, the NetWare Reference Image is running. NetWare loads and starts its install and since a response.tmp file exists, no user intervention is needed for the install to complete.

    Note: Presently to perform a fully automated installation using the response file, it must be modified manually to resolve eDirectory install properties.

    At the end of the install the Blade reboots and like always the Blade PXE boots. Again the Blade is told to local boot. The blade boots off the hard drive and starts the server. This time the server is fully complete and comes up configured using the server name and IP number as specified by the previously generated response.tmp file.


    PIDS can provide a fully automated and remote deployment solution for Novell customers. However, the overall level of automation will largely depend on the Imaging software used.

    In the Working Example section Portlock's Storage Manager was used. Storage Manager is a menu-driven facility, which allows for image creation and restore of images. It is not scriptable, so any image restored down to a would-be server becomes a manual process. However, recognizing this limitation Portlock now provide command line scripting for their STORMGR utility and on request, a cut-down version of STORMGR, which can automate just the restore process -- called RESTORE.EXE. RESTORE uses an INI file, which users can create to define exactly what image file to download, where it is located and what method to use to retrieve it. For more information regarding Portlock's Restore utility please visit Portlock's web site at

    Product Partner Page

    See the list of Blade Servers specifically designed to work with Novell on Novell's Product Partner page.


    Novell's PXE-based Imaging Solution (PIDS) is designed to be a flexible and configurable method of deploying NetWare down to headless servers. The degree of automation and scripting that can be achieved largely depends on user requirements and the Imaging software selected. PIDS represents the first phase of an overall deployment methodology, which is designed to mature over time and compliment new found IHV modularity with ISV imaging technologies.


    Kirk Kimball -- Manager, Core OS Development
    Kirk Allan -- Software Engineer, NetWare Engineering, Provo
    Stafford Masie -- Country Manager, South Africa (previously Product Manager, NetWare)

    Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

    © Copyright Micro Focus or one of its affiliates