1. Are these PowerQuest images? (Isn't that a dead end of life product?)
2. Are you in DOS when you are imaging?
3. Are you in version 8.6.1 or prior?
What I am getting at is that in DOS, there have been tons of problems where the DOS nic drivers are not written correctly (because honestly, who really takes time to properly code DOS drivers anymore) and the image is corrupted during the transfer.
In answer to your questions.
1) Yes they are and they have been working perfectly well until the new batch of hardware came in
2) The imaging tool loads fine and begins the deployment process, the HDD is fdisk etc.. and then the job fails
Many thanks for the reply
what sort of batch dell gives you ? Is it a HD driver or firmware ?
Message was edited by: steflevy
I would be that the file is fine on disk on the share. Your old hardware still works probably.
Are you using the alternate PXE disks that allow you to specify the driver?
Really there are some boxes that just won't work with DOS and PXE and that is why we moved to WinPE and LinuxPE, cause both Windows and Linux are going to be maintained in the future and DOS is not.
My only suggestion is to used the PXE disk that allow you to specify the driver and keep trying different drivers and hopefully one will work.
Other than that, the suggestion is that it is time to upgrade to a version that has WinPE.
If you take LANDesk out of the picture and capture and deploy your image with the Powequest tool what are the results? My bet is you are going to have the same failure. Just because you ordered the same model of machine from Dell does not mean they have the exact same hardware. I have had in the same shipments from vendors several different hardaware types in the same system model.
Thank you for your input, in retrospect this may be a driver issue, I also cannot recall when the hardware from IDE changed to SATA within our corporate environmnet. I am going to re-path LD 8.5, and if that fails upgrade to 8.8.
I think you are right TY. It is very annoying when hardware vendors change what is supposed to be a standard specification...
Thanks for the comment though
which Dell hardware makes this trouble?
We've to change some settings in BIOS from time to time to use our installation (from AHCI to ATA and back from ATA to AHCI...).
1 of 1 people found this helpful
It's not overly specific to any particular Dell model - or any OEM for that matter. They all do that.
From the 1,000-s of units they ship, there's always (usually 2-3) suppliers for most parts (NIC's - ASIC's - other bits of silicon). Then you have internal revisions ... maybe they detect a problem with the NIC, and need to rev it. Or there's a problem with the south bridge, and it gets a new revision.
And so on.
All OEM's do that - Intel, HP/Compaq, Dell, etc, etc. It's unfortunately part of the game - it would be ideal if things could be uniform, but there are reasons on why things are the way they are (I've seen it from the other side, so I can assure that it isn't malice that motivates this) :).
This can in effect happen with any particular hardware - laptop/desktop from any vendor. Something to be cautious of - just because you order the same 2 model PC's on the same day doesn't mean that they're going to be identical "under the bonnet". Chances are there are going to be differences. In most cases, those differences are small and don't matter.
At other times - they can mess you up well and proper :).
LANDesk EMEA Technical Lead
Its a dell latitude D630 rev 09. I toyed with the idea of changing from ATA to AHCI, but heard that Windows would not boot in this mode
I agree with your comments phoffmann , however what is annoying is the amount of work it creates me as an administrator to resolve the issues. In this instance we have been happily running with 8.5 for some time, and now it looks as though in order to resolve the issue, I will need to upgrade to 8.8... a learnng curve in itself. With at present over 18 Laptops to deploy and setup this is time I could well do without losing...
I can get around the issue using an old image of the Dell d630 we made back in August 2007, but it means longer patching times for each machine. I stil cannot work out though why the newer models will work with an older image and not any of the newer ones....
<< Plays music from the Twighlight Zone >>
We use a unattended installation, but I think it's similar for imaging:
Open BIOS - Onboard Devices - SATA Operations - switch from ATA to AHCI mode
After reboot of the text mode installation (the file copy process) change the BIOS settings again:
Onboard Devices - SATA Operations - switch from AHCI to ATA mode and the installation will be finished
If you do not change the BIOS after step 2 you'll get a bluescreen during hardware check!
So, after imaging change the setting from ATA to AHCI mode could be a 'solution' for you ...
One additional hint: we do not have this problem if we use Windows PE, we've this problem with our DOS based and (our own) Linux based installation method!
I absolutely understand the frustration and share it - I was just hoping to explain the existence of these phenomena which make all our lives difficult, not justify them. I'm too much an idealist to think the present way OEM's work as "good", but oh well :).
As for 8.5 -> 8.8 upgrade - just in case you want to do this in-place, do remember that you MUST go through 8.7 first. 8.5 effectively breaks completely the second you put .NET 2.0 on it (and very horribly at that), while 8.8 requires .NET 2.0 to be installed. So you need to go to 8.7 first in this scenario - install .NET 2.0 (to which 8.7 does not react allergically to), as well as the other 8.8 requirements, and then upgrade to 8.8 finally.
If you want to do a side-by-side upgrade (or just use the DB), then that's not an issue. It would be - ultimately - a lot easier to it this way :).
Just hoping to spread important information so as to prevent another problem along the way.
LANDesk EMEA Technical Lead