Deployment Solution

I'm stumped on this one, besides saying there seems to be some issues with upgrading Deployment Solutions instead of starting from scratch. Any ideas would be greatly appreciated.

We have multiple deployment servers running versions 6.5 SP1 to now 6.9 SP3. After upgrading to or past 6.9 SP2 the DOS automation environment no longer works, whether I reinstall from Windows 98 MSDOS files or use the downloaded FreeDOS from the Symantec site. The client boots into DOS, installs the driver (or uses the UNDI, it doesn't matter), maps the eXpress share and other drives. Then it tries to run BootWorks and it crashes repeatedly ending with a "SEGABRT" every time.

Here's an example of one server starting at 6.5 SP1. Upgrading to 6.8 SP1, rebuilt the DOS boot disks, all works fine. Upgrade that to 6.9 SP1, rebuilt the boot disks, all works fine. Upgrade to 6.9 SP2 or later, WinPE still works but DOS does not with BootWorks crashing above. We've repeatedly seen this issue on multiple servers now. 

Starting from scratch, DOS does seem to work correctly on a 6.9 SP2 or 6.9 SP3 server. Has anyone else run into these issues?

Thanks,
Ben

 Hi Ben,

I've not seen this issue before -and we've got several DS servers here now at the SP2 level. Does this problem manifest on all your clients? And have you tweaked DOS in any way?

Kind Regards,
Ian./

Is there a particular reason you're using DOS? I know we used DOS for the past three years and recently upgraded to strickly using WinPE 2.1. Our ability to manage and configure was much better. Our imaging, driver injection and sysprep recursing speed was improved drastically. I can say that the process time was reduced from 45 minutes to 1 hour down to 8- 15 minutes total.

I'm only asking because possibly if you're not reliant on DOS, WinPE 2.1 may be a better, faster solution. 

We're primarily missing DOS for its fairly stable multicasting ability. I agree with you damerd WinPE is a lot faster (32 bit drivers vs 16 bit) and more manageable, although dealing with the AAHCI mass storage drivers in WinPE 1.6 was a huge pain for us for a while - but WinPE 2.1 seems to use a default storage driver just like Vista, and seems simpler.

We're in a K12 environment where some our labs are not always wired together well and don't always use manageable switches so we tend not to have less than ideal networking environments. DOS seems to be able to negotiate and keep a fairly stable multicast speed even across these various devices while WinPE 2.1 (and 1.6 for that matter) gets slower and slower and usually eventually stops or will take days to complete if it actually does. That's why we're missing DOS.

We don't do much to our DOS PXE boot disks, just add some NIC drivers for Intel PRO 1000 nics and map two additional drives besides the eXpress share. And this stuff works, its just Bootworks that crashes on multiple servers now past 6.9 SP2. The DOS automation environment crashes on all clients with the same SEGABRT error repeatedly - it tries to load, it crashes, tries to load, it crashes. If you cancel the job the clients will enventually boot into their OS on disk again.

Ian, for your server with DOS automation environments in 6.9 SP2 and later working, was this upgraded or a fresh install? If it was an upgrade, what did you upgrading from?

Damerd, have you found any tricks or ways to make multicasting work better in WinPE?

Thanks for your responses!

 Hi Ben,

We upgraded fro DS6.9 (no service pack), straight to DS6.9SP1 (MP1), and then to DS6.9SP2. To troubleshoot, my first port of call is to guage the scope of the problem,

• How many clients affected... all?
  This can ascertain whether is a hardware/driver related issue, or a global one with you DOS automation environment
   
• Can you test clients on same switch/subnet as the DS Server? This will help you see if the issue is somehow network related, with bad comms forcing the automation agent to abort at the raw code level.
   
• If you create a new DOS automation environment from scratch, and create this as a boot ISO does the segabrt issue still manifest? This again will help you determine if the problem is automation environment related.

Best of luck!

Kind Regards,
Ian./