In this fifth article gathered from my Deployment Solution training notes, we'll look at how to add DOS as an automation option to the Altiris PXE server. DOS has several advantages as a PXE option -it's small, it can be multicast to clients, it can use the universal NIC driver, and it can natively image many hardware RAID disks which Linux and WinPE can't without loading additional mass-storage support.

There are of course downsides to DOS - the 640K conventional memory limit for one. Further, it was written in the hay-day of 16-bit processors, which means it can't take full advantage of the 32 & 64 bit compute power provided by modern processors. These drawbacks do sadly compromise image deployment as memory is required for buffers, and processing power is required for image decompression. I'll show in this article how DOS can be tweaked to regain respectable imaging performance.

In this article you'll learn how to,

• Add DOS as one of the pre-boot options on the PXE Server
• Configure DOS to use the UNDI driver
• Tweak the DOS TCP Stack to speed up image deployment
• Configure Deployment Tasks to use a specific PXE automation option

So, grab your dusty MS-DOS floppies from the back of your desk drawer - you'll need them to implement what follows.

Introduction

When we installed Deployment Solution in Chapter 2, we selected the 'Simple' install with PXE server. This installation path gave us the option of pre-installing just one automation OS from the three available of DOS, Linux and WinPE. We chose Linux, and I indicated that this OS was a good overall choice for delivery by a PXE server. DOS and WinPE still have their uses, and in this article we will focus on how to add the first of these, DOS, as an alternative PXE automation option.

Why bother with DOS at all?

Despite its age and waning popularity, DOS still works very well as a pre-boot OS,

• It's very small

  This makes it superb for over the network delivery through PXE. It literally takes seconds to download DOS automation, substantially less than the minutes it can sometimes take for WinPE. DOS is also the only automation OS which can be delivered by multicast.

• Mass-Storage Controller Support

  A lesser known benefit of using DOS is that can access any disk whose disk controller exposes itself over the standard disk interrupt Int 13. What this means is that a machine with hardware RAID which may require hours of work to image using Linux or WinPE can actually turn out to be natively supported in DOS. A nice time saver.

• The Universal Network Device Interface

  Machines booted through PXE can make use of the UNDI driver. This driver is unique in that it allows the TCP/IP stack to be loaded on any PXE booted NIC which adhers to Intel's UNDI specification. This is a great fallback for those cases where NIC drivers prove tricky to obtain, or prove buggy.

Creating a DOS automation option using the Altiris PXE Configurator

The PXE Configuration Utility (available from both the Tools menu and the Tools bar in the DS Console) allows us to configure how the PXE server should respond to requests from our PXE Clients. From this interface, we can also load DOS, Linux and WinPE automation options into the PXE server. Click on the toolbar icon (or menu item) now to open the utility.

As you can see from the screenshot left, the PXE Configuration Utility opens up a multi-tabbed window. The initial focus is on the 'Boot Menu' tab which holds all the possible boot options presented to your clients as they PXE boot. These options are the 'boot menu items'. The first item listed is the default, and unless someone manually selects an alternate boot option at the PXE booted client, this will be executed after a timeout of 3 seconds. As you can see, the default option is Next Boot Device, an entry which contains instructions to get the client booted to the next device in the BIOS boot order -typically the harddisk.

It is important to emphasise here that as far as the PXE Server is concerned it will always offer clients the full boot menu listed here, informing the client to boot to the next device after the timeout. This is great -it prevents machines from booting into automation when there is no work to do.

But what happens when there is work scheduled for that computer in automation? In this case, Deployment Solution's integration with the PXE server comes into play. Deployment Solution instructs the PXE Server to bypass the normal boot menu offering, and to instead offer directly the download location of the task's automation image for immediate download.

Looking more at the screenshot, you can also see from the bottom of the screen we can tailor our Boot Menu Prompt which will be offered for 3 seconds before proceeding to the default item of 'Next Device'. The F8 function key is programmed in the PXE Client to present all the boot items for manual selection. If you were to PXE boot a client now, and press F8 to reveal all the automation boot options, at the moment we can see only one automation option in the boot menu list -Linux. Let's click the 'New' button so we can add MS-DOS to this list.

• Adding MS-DOS to the PXE boot Menu
  

  On the 'New Shared Menu Option' screen, we can see from the Operating System & Processor Options section that neither DOS nor WinPE are currently available. Click 'Add-Preboot' to begin the process of adding MS-DOS for use as an automation OS.
  1. Install Pre-Boot Operating System Files
     

     On this screen, we can install and update any of the supported automation operating systems. The only automation OS enabled at the moment is Linux, as this was activated during our initial setup of Deployment Solution.

     Before proceeding with our DOS installation, we have to choose between MS-DOS and FreeDOS. FreeDOS can be loaded from the .frm downloaded from the Altiris site, but frankly I tend to avoid it as I find it tends to freeze on desktops whose disk controllers it takes a disliking to. We will install MS-DOS for what follows, as I feel this produces a slightly more stable DOS environment.

      

     Click the 'Install' button in the MS-DOS section.
  2. MS-DOS Operating System Files
     

     Here we declare where our MS-DOS source files are. I always keep them handy in a DOS folder, but you can also use a Windows 95/98 CD or a MS-DOS floppy. I'll assume you've got them safely in a folder, so click 'Use MS-DOS files from a folder' and click 'Next'
  3. MS-DOS System Folder
     

     Browse to the folder where you've stored these dusty old DOS files, and click 'Next'.
  4. Install Complete
     

     This confirmation screen joyfully exclaims that DOS is now ready for use. Click 'Finish'
  5. Install Pre-Boot Operating System Files
     

     Notice now that MS-DOS is installed. Click 'Close'

      

• Updated 'Shared Menu'
  

  On returning to the 'New Shared Menu Option' screen, we can see from the Operating System & Processor Options section that DOS is available. We can now proceed and create our MS-DOS PXE Boot menu option.

  For the name of the Menu Item enter 'DOS (UNDI)', as we will be using PXE's facility to invoke the UNDI (Universal Network Device Interface) driver. This driver is very special - it allows the TCP/IP stack to load on any NIC following the PXE/UNDI specification. Click 'Add-Preboot' to open BootDisk Creator, the tool which will allow us to configure MS-DOS for use as an automation OS.

• Step 1: Configuration Name
  

  The UNDI driver is great for its universal NIC support, but it has one drawback -Altiris does not support it for multicasting images. Multicasting is a bandwidth saving mechanism whereby the Deployment Server selects one of the PCs being imaged as the session's multicast master, and sends the image to this computer only. This master computer then distributes the image packets to the other clients as they arrive from the server.

  So, why no mulitcasting with UNDI? It sadly turns out that multicasting with the UNDI driver can lead to corruption of image data. So Altiris forces all imaging sessions over UNDI to run as unicast sessions. This driver is therefore not suitable for mass-imaging as all the bandwidth saving features of muliticast are lost.

  In the description field, enter in a reminder as shown in the screenshot that this DOS image is not suitable for large-scale imaging sessions. Click 'Next'

• Step 2: File Server Type
  

  Here we specify what type of File Server the automation environment will be connecting too. As we'll be storing all our images on the Deployment Solution server, the default setup of connecting to a Windows File Server is fine. Click 'Next'
• Step 3: DOS Network Adapters
  

  It's time now to choose the network adapters this DOS environment will support. As you can see, there are 49 NICs supported out-the-box with Deployment Solution 6.8SP2, and you can add support for your specific models if they are not list here by clicking the 'Have Disk..' button. For now though, we are going to opt for the UNDI driver, so tick the 'Use the Intel UNDI driver for PXE' checkbox, and click 'Next'.

  You will now recieve a warning that the Intel UNDI driver does not support multicasting -sigh gently for this tragic loss, and click 'Yes' to move on.

• Step 4: TCP/IP Protocol Settings
  

  I haven't managed to think yet of a scenario where you would want to set your client IPs statically for Bootworks and I'm losing sleep over this obvious lack of imagination.

  I must stress that DHCP is really, really important for imaging, and this is not a vendor hang-up, it just makes sense. A bootdisk with DHCP means that one bootdisk will work for all of your clients without resulting in IP conflicts. Setting static IP address within your bootdisk configurations is generally going to lead you down a very dark road.

  Click 'Next', and forget you ever saw the option to set IP addresses statically... ;-)

   

• Step 5: Altiris Deployment Server Communication
  

  This screen assumes, quite rightly, that automation will want to connect to Deployment Solution directly by IP address. You can use multicast to discover your Deployment Solution server, but in the vast majority of cases this is not neccessary. Also, multicast discovery can open the door for a rogue server to harvest clients on your network, so you should think twice before looking at this option. Note that the wizard is kind, and pre-populates your Deployment Server's IP address.

  An often overlooked checkbox at the bottom of the screen allows us to lock the keyboard. I generally tick this checkbox if automation is intended to be deployed in a live environment. This prevents users cancelling a imaging session with a CTRL-ALT-DELETE, but alas cannot stop them pressing the power button. For testing/troubleshooting though, it can be useful to keep the keyboard unlocked so we can take a rummage in automation and perhaps run some diagnostics. So, let's leave this checkbox clear for now.

• Step 6: Network Connection
  

  On this screen, we get an opportunity to reconfigure the credentials used to connect to the eXpress share on the server. The defaults are fine to get things going for the moment, but note that the credential pre-populated here is the 'Application Identity', that is the account underwhich Deployment Solution was installed. As such, it will have full access rights over the eXpress share. This is not fantastic from a security viewpoint, and in a later chapter we will create additional user accounts limit the exposure of the express share whilst clients are in automation.

  Click 'Next' to proceed.

• Step 7: Network Drive Mappings
  

  In order for our DOS Pre-boot environment to be effective, it must be able to access the automation tools residing on the eXpress share. To do this, automation must map a drive to the eXpress share, which by default is set to the F:\ drive.

  In addition to providing access to automation tools like RDeploy.exe and Firm.exe, the eXpress share also serves as a handy image store. However, if you have other servers you wish to use for your image store then you can add them here by selecting another driver letter and entering the UNC path to the share. Note that the File Server credentials supplied in the previous step are used to authenticate to all the shares you map here.

  In order to speed up name resolution, your Deployment Solution server is added automatically to the LMHOSTS file. This removes the need for your client to locate server by WINS or subnet broadcast.

  We are quite happy to stick with the simple setup with a single F:\ drive mapping, so click 'Next'.

• Step 8: Configuration Summary
  

  This screen provides a summary of the settings configured in the previous steps. Give it a scan to ensure it all looks sane, and press 'Next'.
• Step 9: Edit Configuration
  

  This screen gives you a chance to tweak the DOS environment by editing the DOS batch and ini files directly. We'll come back to this soon, but for now let's leave this in its virgin state, and click 'Next'.
• Step 10: Create PXE Boot Image Files
  

  This screen really just provides you with the opportunity to bottle out of creating the PXE image. We are the brave sort, so click 'Next' to confirm that you want to proceed and create the PXE boot image.
• Step 11: Creating PXE Image
  

  Creating the DOS PXE boot image takes just under a second, so blink and you might miss this screen!
• Step 12: PXE Boot Image Creation Complete
  

  All done now, and hopefully you too will find that your DOS PXE boot image has been created successfully. Click 'Finish' to return to the 'New Shared Menu Option' screen we originally launched the BootDisk Creator from.

  Click 'OK' on the 'New Shared Menu Option' window to return to the 'PXE Configuration Utility'

• PXE Configuration Utility
  

  On the PXE Configuation Window, you now see the (DOS UNDI) option. Click 'Save' to upload your changes to the PXE server, and then click 'OK' to close the 'PXE Configuration Utility' and return to the console.

   

PXE Server Installation -Quick Review

PXE booting is a complex business, so I'm going to take a few moments to review all that we've done on the PXE side of the house since we started this series of articles.

During the original installation of Deployment Solution we selected the Linux as the automation option and provided the wizard .frm file which contains all the Redhat Linux files required. This allowed the wizard to create our default automation environment named 'Linux Managed'. This automation option was created behind the scenes during the install, and used the defaults set in BootDisk creator for that OS,

• File Server Type: Windows
• Transport Type: TCP/IP
• Keyboard Lock: Not enabled
• IP Address: Use DHCP
• Deployment Server Communications: By IP address, TCP port 402
• NIC adapter: auto-detect
• Share Mount point: //Altiris-DS/eXpress /mnt/ds
• Share Credentials: altservice (the application identity)

The out-of-box installation of the Altiris PXE server boots clients to their 'Next Boot Device' when there is no requirement for them to load automation. When they are scheduled to enter automation however, Deployment Solution nudges the PXE server to force the client to load the automation environment specified in the scheduled task. If you don't set automation environment for the task, Deployment Solution will select Default Automation, which generally speaking will be the first automation OS you loaded onto the PXE server. In our case, this is Linux.

This ability to choose your automation when PXE booting is incredibly powerful. We'll shortly see in our imaging tasks how we can change this.

Configuring Image Upload/Download Tasks to use DOS

In the last article, we used PXE to upload and deploy and XP image. We will now build on this, by creating image tasks to upload and download images using a specific automation OS.

1. Create a folder called in the jobs pane called 'Image tasks'.
2. In this folder create a job called 'Upload XPSP2 Image (Linux)'. Add a 'Create Disk Image' task, entering the path for the image file as .\Images\Windows\XP.img. Now lets specifically set the automation OS we want to use. The last option on the window allows us to select the Automation pre-boot environment -leave it set at the current selection of 'Default Automation (Auto-Select)'.

   This means that the PXE Server will deliver the default automation (as configured under the DS tab in the PXE Configuration Utility) and it will also auto-select the correct architecture build from the 32bit or 64bit options (if available).

   Change this now to 'Linux Managed (Auto-Select)', noting with a wry smile that this will make no change whatsoever to the image task, as currently Linux is our default automation. What this does mean however is that this job will always run under Linux, no matter how we change the PXE Server configuration options.

3. In the 'Image Tasks' folder create a job called 'Deploy XPSP2 Image (Linux)'. Add a 'Distribute Disk Image' task, entering the path for the image file as .\Images\Windows\XP.img. Now set the automation OS we want to use again as 'Linux Managed (auto-select)'
4. Make a copy of the 'Upload XPSP2 Image (Linux)' job, renaming it to 'Upload XPSP2 Image (DOS)'. Edit the task within to use the pre-boot option 'DOS (UNDI) (auto-select)'
5. Make a copy of the 'Deploy XPSP2 Image (Linux)' job, renaming it to 'Deploy XPSP2 Image (DOS)'. Edit the task within to use the pre-boot option 'DOS (UNDI) (auto-select)'

The picture left shows the Jobs which you should now have in your 'Image Tasks' folder, and the critical screen in the 'Distribute Disk Image' wizard which allows you to choose your PXE automation environment.

Try some image uploads and downloads using each of these four jobs and note the times taken for each. Can you guess the winner??

Imaging Results for DOS and Linux

Below is a table showing some the results of my own image upload/download sessions for a XP Client image.

To the left I also provide a graphical timeline of an upload and download imaging session. It not only shows the imaging time, but the automation boot time and the OS reconfiguration time as well. This gives a more complete picture of how long it takes to deploy a computer.

Without getting carried away with the exact figures, (different environments expose different bottlenecks) Linux looks to be twice as fast as DOS for downloading images. This looks rather bleak in the light that I'm trying to advocate using DOS for imaging ;-)

But something is rather odd when you compare the image upload times: for uploading images, DOS catches up significantly. So, DOS can be quick. Why is it slow slow then on image deployment then?

After some digging, you'll find it all comes down to DOS's TCP stack buffers. These buffers are the temporary storage areas for data sent and received over the network. Once they are full the contents must be acknowledged, processed and cleared before comms can continue. And herein lies the problem: in DOS, these buffers are by default very small.

Tuning the TCP Stack

When an image is downloading from the server to the DOS client, DOS tells the server how many packets it can handle at once by revealing to the server its tcpwindowsize. The server is then careful never to exceed this window when sending a sequence of packets, and once sent, the server will wait for DOS to acknowledge receipt before sending more. This constant acknowledgement of packets introduces a significant comms overhead, and has a detrimental impact on the image download performance. The default tcpwindowsze for DOS is 1450 bytes, which is tiny in comparison to the default buffer size of 16K in Windows.

So why is uploading images to the server fast? Well, here DOS can keep sending packets until the server's 16K window is filled, and then it is up to the server to send an acknowledgement before DOS can send out another burst of packets. This means a lot less acknowledgements are sent, which means fewer gaps in the comms and therefore a much better performance. This is reflected in our results above where the image upload performance in DOS is on par with Linux - image upload times are just not unimpacted by the tcpwindowsize in DOS.

The way to reduce the overhead introduced by the acknowledgements which must be generated each time the number of packets sent by the server fills DOS's TCP window, is to decrease their number. This is done by increasing the TCP Stack parameter for the window size, tcpwindowsize, in DOS. But we must take care, there is another magic memory limit within DOS which means both the buffers and the network driver must fit in one 64K segment.

Calculating the TCP Window Size

To increase the tcpwindowsize parameter in DOS we need to tweak the file which sets the configuration of the TCP stack. This is the protocol.ini file, and this resides in the \net folder within DOS.

To maximise the tcpwindowsize buffer we'll need to take into account the following,

1. Each tcp connection requires two buffers -one for sending data, and the other for receiving.
2. The send and receive buffers together cannot not have a memory footprint greater than 64KB minus the driver overhead.
3. Each TCP connection requires an independent buffer, but multiple NetBIOS sessions (TCP 139) to the same server will share a buffer.
4. We can neglect neglect the TCP connection from Bootworks on TCP 402, as the comms here are managed by a separate network stack.
5. Buffer sizes are best set in multiples of 1450 bytes.
6. Although the Microsoft TCP Stack can load with only one set of send & recieve buffers, a minimum of two sets of send/recieve buffers are needed to map a network drive -I have no idea why.

So, lets crunch some numbers. If we've got tops 64K to play with, and we must have at least two sets of send of send/recieve buffers for a usable TCP stack, our maximum possible buffer size will be (64K/2)/2 = 16K. The largest integer muliplier of 1450 which doesn't exceed 16K is 11, i.e. 15950 Bytes.

So, in short, the largest value of tcpwindowsize DOS will support without taking into account the memory footprint of the network driver is 15950 Bytes. To leave some space for the NIC driver lets use 10*1450=14500 as our guide window size -which isn't so bad. And because of the oddity which means the stack isn't useful without two sets of buffers, we can have enough memory to connect to two servers with this buffer size if we wish. This can be handy for attaching to other fileservers.

Editing Protocol.ini

Let's now edit the DOS UNDI automation option in the PXE Server,

1. Open up the PXE Configuration Utility
2. Double-Click on the 'DOS UNDI' option to bring up its properties
3. Click 'Edit Boot Image' to open up the DOS PXE image

    

4. In the 'Edit Configuration' window, open up the net folder and click on the protocol.ini file within.
5. The [TCPIP] section should read as follows,

   [TCPIP]
   NBSessions=6
   DisableDHCP= 0
   drivername=TCPIP$
   BINDINGS=GEN_NDIS
   LANABASE=0
   tcpwindowsize=2800
   
   

   The parameters which are of interest to us are NBSessions and tcpwindowsize. NBSessions governs the number of NetBIOS sessions we can make in using this TCP Stack. In effect, this dictates the number of send/recieve buffers the TCP stack will reserve for us. So, with the current configuration the stack is reserving (2800*2)*6 ~ 32K for the buffers.

   Most of the memory allocated in the current configuration is therefore unused in the most common Deployment Solution scenarios where we intend to use only one NetBIOS session. To use our memory more effectively, we would therefore like to set NBSessions to 1, but as I mentioned earlier this won't actually work. The minimum value we can set here is two.

   Our first stab at a modified protocol.ini file should then have its [TCPIP] section detailed as follows,

   [TCPIP]
   NBSessions=2
   DisableDHCP= 0
   drivername=TCPIP$
   BINDINGS=GEN_NDIS
   LANABASE=0
   tcpwindowsize=14500
   
   

   Change the two lines in the protocol.ini as described above, and click 'Next'. You will be asked whether you wish to save the changes. Click 'Yes'.

6. On the 'Create PXE Boot Image Files' dialog, click 'Next'
7. On the 'PXE Boot Image Creation Complete' dialog, click 'Finish'
8. On the 'Edit shared Menu option' dialog, click 'OK'
9. In the PXE Configuration Utility, click 'Save' to transfer these new settings to the PXE Server.

Now try a DOS imaging task again.

Revising the Buffer Size

When DOS automation loads, you'll likely be presented with the screen shown left -Ooops. It seems our buffer size was a little ambitious, and has left no room for the driver to load. We need to free up a little more space by revising the protocol.ini file again. Let's this time use a lesser multiplier of 13050 for the tcpwindowsize,

[TCPIP]
NBSessions=2
DisableDHCP= 0
drivername=TCPIP$
BINDINGS=GEN_NDIS
LANABASE=0
tcpwindowsize=13050

Recreate the PXE Boot image as above, and try the DOS imaging tasks again. This time you should have success, and your image deployment time should be significantly faster. In my case the imaging times are as follows,

A pretty good improvement.

Choosing a 'Best' TCP Window Size

Whilst the largest TCP Window size you can get away should offer you the best imaging performance, there is one other consideration to bear in mind -the memory left for DOS applications. In short, the more memory you use for your buffers, the less memory you'll have for other processes.

The graph to the left shows the effect of increasing the tcpwindowsize on image deployment times. The exact figures will vary depending on your network, but the trend is this: beyond a tcpwindowsize of about half the optimum for your network, the gains made from further window increments follow a law of diminishing returns. On a typical LAN, the optimum window is around 16K, so by setting a 8700 byte window size for DOS will give you an excellent return on your memory investment. This gives great imaging performance, whilst keeping memory free to facilitate the execution of DOS diagnostic applications or the 16bit Windows 2000/XP installers.

If you look a closer at my graph, you might notice I actually have a sweet spot with a TCP window size of 8700 bytes in my environment. Imaging is actually faster here than if I deploy with larger TCP window sizes. This I like. ;-)

If you really want to squeeze every ounce of imaging power out of DOS, I recommend,

• Finding the sweet spot for your network Do some image runs, varying the TCP windowsize. See what's best for your LAN.
• Create multiple DOS PXE images There is if course no reason why you can't create more than one PXE image for DOS. You could create one option with the maximum tcpwindowsize you can get away with for best imaging performance, and another with a less ambitious windowsize which allow other DOS apps to run like the 16bit winnt.exe setup programs for Windows 2000/XP. In your automation jobs, you just then select the DOS environment suitable to the task.
• Create DOS PXE images specifically tailored with your client NIC drivers. This is something we haven't covered in this article, but loading automation with drivers for your target to your NICs population can result in faster imaging. I like to stick with a single NIC manufacturer on any PC estate as much as possible so that a single DOS image with a couple of drivers works pretty much everywhere.

Summary

This has been another large article, and an awful lot to absorb. My key objective here has been to show you that DOS is still a very capable imaging environment. To revise, the key advantages to using DOS automation for deployment by PXE are,

1. DOS images 1.44/2.88 MB, making this the fastest automation environment to download from a PXE server
2. The UNDI driver allows a one driver fits all approach to imaging
3. Rdeploy in DOS can image many RAID controllers natively

It is quite unfortunate that the out-of-box TCP/IP stack configuration for DOS can be quite misleading with regard to its imaging performance -with a little tweaking though, imaging times can in many instances be competitive to Linux & WinPE.

To achieve respectable imaging performance with DOS, try incrementing the TCP Window size from 2900 to 8700 bytes. This can be realised by editing protocol.ini, the Microsoft TCP configuration file.

Well, thats it for now. May this article embolden the WinPE Maestro's out there enough to give DOS imaging a go when that next generation of desktops come out with hardware RAID.

Kind Regards,
Ian./

Chapter 4: Introduction to Imaging using PXE

Chapter 6: WinPE as a PXE Automation Option