|
padamsj -> RE: 800040005 error at end of SMS image installation (6/12/2008 5:54:56 PM)
|
Bump!
Was this ever resolved? I'm having this exact issue and this is the only reference I can find to this perplexing problem. It's not often that I raise my hand for help but this has been drivng me mad. I'm using SMS 2003 SP2, lastest version of OSD and Microsoft Deployment. Everything works end-to-end if I boot from the OSD CD and run the image, no problem. However, if the process is initialized from WITHIN Windows using the boot disk or via SMS advertisement (i.e. PE is transferred to and booting up from the local hard disk in both scenareos, not the CD) then ZTI fails in the postinstall phase, just as SBond describes in his post above. I want to do my best to expand on what has already been said here.......
The events causing the failure are loggeed in the smsts.log file. The concerning entries are as follows:
*"We do not find an available volume to store the local data path"
*"Failed to save environment to (80070057)"
*"Failed to save the current environment block. this is usually caused by a problem with the program. .... The parameter is incorrect. (Error 80070057;Source;Windows)"
*"Volume D: is not a fixed hard drive" (true, it's a DVD-ROM)
*"Volume X: is not a fixed hard drive" (wrong, it's got 75gb free and just took an image)
*"Fatal error is returned in check for reboot request of the action (end phase). Unspecified error (Error 80070057;Source;Windows)"
These are things I have verified:
1. PE is up to date (using PE 2005 linked to Server 2003 SP1 OS source in Microsoft Deployment).
2. PE is customized with appropriate mass storage devices via driver .sys files and custom TXTSETUP.SIF added to Extra Files path in Microsoft Deployment
3. Custom PE has been imported into SMS from the custom PE source that was regurgitated by Microsoft Deployment
4. I have recreated my OSD boot image using appropriate NIC drivers
5. I have implemented the OSD debug executable so I have a command window available at fail. I have verified these things using the command window after fail.
a) I have network connectivity. I can ping stuff and "net use" to a server share, etc. etc.
b) I can access the hard drive (the WIM was installs to it successfully, my HAL select script can access it at the beginning of postinstall, logging is happening there)
c) I can see the volume and disk information using diskpart. I have Disk0 as D: (DVD ROM) and Disk1 as X: (hard disk, 75gb).
6. All of the ZTI files that the Microsoft Deployment spit out for my task sequence are imported into the OSD image package via the program advanced tab, blah blah.
8. I have implemented the /debug:true switch for every phase and all logs are being written to MININT (on the local disk that smsts.log says doesn't exist, mind you!)
9. The issue is not specific to any machine type. it fails on all machine types I have tried it on including models with ide, with sata, with scsi, and virtual machines.
Some things that stand out about the issue are:
I notice a difference in the behavior of PE 2005 in this ZTI process compared to PE 2004 in my existing OSD-only process. Maybe this is how it's supposed to be...don't know, it's just different:
* When PE 2004 (current and working proccess) boots from CD, it assigns X: to ramdrive and C: to local hard disk. When PE 2004 boots from hard disk, having been invoked from within Windows, it assigns C: to ramdrive and X: to local hard disk, reversing the letters.
* When PE 2005 boots from CD, the behavior is the same as 2004...X: is ramdisk and C: is hard disk, however, when it boots from hard disk (where I am having the issue) X: is local hard disk and that's it...no ramdisk. Where did my ramdisk go? Is this process expecting to see a ramdisk and a hard disk? could this have anything to do with the entry in smsts.log that says it cannot find a local disk? I do not know!
From the logging, it appears that it is executing all of the scripts that should not run until the state restore phase AFTER a reboot. It appears that the reboot after the postinstall phase may be failing. Of course the ZTI scripts in the state restore phase don't expect to be running in a PE environment. Of course this would wreak havoc!
Anyone have any further insight they could offer...or, better yet, just tell me how to fix it?? [;)]
|
|
|
|
