DOS IP networking...it's almost enough to make you long for the days of IPX, coax cable and ohm-meters. Well, ok, maybe not. Nonetheless, DOS IP networking was most assuredly an afterthought-- and it shows. You can't map drives by FQDN or IP address and NIC drivers are hard to find or are non-existent. But until WinPE has a boot image size of something other than Ungodly Large (well, actually have a look at PE Imaging for information on using BartPE with LANDesk) or imaging vendors make binaries for Linux, we're stuck with it (at least in terms of remote imaging). LANDesk tries to help with the driver issue by using DOS UNDI for its PXE process, but that's not possible for virtual boots and the UNDI drivers can lead to slightly slower throughput. If your DNS and WINS infrastructure are working well, you just may be ok with the default boot images, but...insert hysterical laughter.

Anyway, here are the few little tweaks I've found that seem to get things cranking on most networks.

what you need

The three files we'll be editing as part of this document are:

• bootmenu.1
• dosundi.1
• ldvboot.img

Bootmenu.1 and dosundi.1 can be found in \program files\landesk\managementsuite\landesk\files and ldvboot.img can be found in \program files\landesk\managementsuite\landesk\vboot on your core server. You'll also need Winimage or some other app capable of editing DOS boot images.

hard code it

By default, your boot images are most likely set to use the short name of your server. This is the primary source of failures htget'ing files during the boot process, etc. You can be brave and modify this to be the FQDN of your core or completely wimp out (like me) and set it to the IP address of your core. The latter obviously eliminates any need for name resolution. So, basically you need to:

1) Open up bootmenu.1 with Winimage.

2) Extract the startenv.bat file.

3) Open startenv.bat in notepad. It probably says something like::

set COREHOST=JITTER

4) Modify it to the FQDN or IP address of your core:

set COREHOST=JITTER.DROPPEDPACKETS.ORG

or

set COREHOST=192.168.0.52

5) Inject startenv.bat back into the original boot image.

Repeat and rinse for the dosundi.1 file. Re-deploy your PXE proxies afterward if you previously deployed them. The ldvboot.img file is slightly different:

1) Open up ldvboot.img with Winimage.

2) Extract the startnet.bat file. Notice the different filename. Modify it just like the above instructions:

set COREHOST=JITTER.DROPPEDPACKETS.ORG

or

set COREHOST=192.168.0.52

3) Inject startnet.bat back in into ldvboot.img. Ldvboot gets copied each time to client at the point you initiate the imaging script, so nothing further needs to be done to make your changes "active".

lmhosts

Neat-o. If you were having problems during the image boot process, this alone will probably get you to a point where you can execute scripts. So, if you're getting that far, but are now having problems mapping the shares you need to access/write your OS image and execute your imaging tool, the next tweak we need to make is to add entries to the lmhosts file in your boot images. This process is identical for all three files:

1) Open the respective boot image with Winimage.

2) Extract the lmhosts file from the net directory of the boot image.

3) Add entries for any machines names you may map within your LANDesk imaging script.

# The default file gives

# some samples to copy:

# 149.124.10.4 server1 # main office server

# 182.102.93.122 joe3 # joe's database server

# And you then add yours below the final comment

nic drivers

Finally, the other most common problem you might see is related to NIC drivers. When NIC drivers are an issue, you'll generally see one of two things after the client boots into DOS:

1) The client hangs at the LANDesk Splash Screen.

2) The client boots into DOS, starts to load the image, then suddenly reboots to its normal OS.

In either case, the issue could be that the correct DOS driver is not being loaded or, more likely, that it is a newer NIC with no descriptor in the nic.txt file.

The LANDesk Knowledgebase has an excellent article on correcting both of these issue, so I won't rehash it here. Simply go to:

http://kb.landesk.com and search for article ID 2718.