WinPE 3.0 SCCM OSD - multiple raw disks, unable to apply OS image - bug was thought to have been fixed?
Hopefully a quick question for everyone – I’m running into an issue when I have servers that have multiple raw unformatted disks attached to them; either from a newly created RAID array, or two disks presented via dual HBA’s. The problem is I get this error after I format the disks and try to apply the OS image: component="ApplyOperatingSystem" context="" type="0" thread="1500" file="diskvolume.cpp:128"> <![LOG[System partition not set]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="ApplyOperatingSystem" context="" type="3" thread="1500" file="diskvolume.cpp:128"> <![LOG[Unable to locate a bootable volume. Attempting to make F:\ bootable.]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="ApplyOperatingSystem" context="" type="2" thread="1500" file="installcommon.cpp:751"> <![LOG[bBootDiskDefined == true, HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installcommon.cpp,677)]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="ApplyOperatingSystem" context="" type="0" thread="1500" file="installcommon.cpp:677"> <![LOG[Unable to find the system disk]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="ApplyOperatingSystem" context="" type="3" thread="1500" file="installcommon.cpp:677"> <![LOG[MakeVolumeBootable( pszVolume ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installcommon.cpp,759)]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="ApplyOperatingSystem" context="" type="0" thread="1500" file="installcommon.cpp:759"> <![LOG[Failed to make volume F:\ bootable. Please ensure that you have set an active partition on the boot disk before installing the operating system. Unspecified error (Error: 80004005; Source: Windows)]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="ApplyOperatingSystem" context="" type="3" thread="1500" file="installcommon.cpp:759"> <![LOG[ConfigureBootVolume(targetVolume), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\applyos\applyos.cpp,364)]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="ApplyOperatingSystem" context="" type="0" thread="1500" file="applyos.cpp:364"> <![LOG[Process completed with exit code 2147500037]LOG]!><time="07:32:40.420+420" date="03-31-2011" component="TSManager" context="" type="1" thread="452" file="commandline.cpp:1102"> If I reboot the system and start the task sequence again, it works fine, because I’m assuming WinPE was able to start and saw there was an NTFS drive to use. I’ve done the following: 1. Created a devcon script to disable the device presenting the 2<sup>nd</sup> raw disk – no luck, even though one disk shows in Diskpart when I do that. 2. Tried to add a reboot step to the TS – but it just fails because it can’t apply WinPE again. I’d really like to not have it format, bomb out, and tell my admins to try again – supposedly this bug was fixed with the Vista SP1 version of WinPE 2.0, but I’m on 3.0 now with ConfigMgr SP3. Any idea around this? Here’s an article that describes the behavior: Task sequence fails at “Apply Operating System” with “Failed to make volume X:\ bootable” Several problems can cause this error. This issue is indicated by log content similar to the following text: MakeVolumeBootable( pszVolume ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installcommon.cpp,759) Failed to make volume E:\ bootable. Please ensure that you have set an active partition on the boot disk before installing the operating system. Unspecified error (Error: 80004005; Source: Windows) ConfigureBootVolume(targetVolume), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\applyos\applyos.cpp,326) Process completed with exit code 2147500037 This issue can be related to two different scenarios: · If you are using a Format & Partition action in your task sequence to partition the hard drives, make sure that you select the check box for Make this the boot partition on one of the partitions. If you do not make a drive bootable and the computer has only the single drive, the task sequence engine automatically makes one of the partitions the boot partition. But if there are multiple drives, the task sequence engine cannot determine which drive should be bootable, and you see this error. · If you upgraded from the Configuration Manager RTM to SP1, you might have a problem if both hard drives are completely raw. If you have never partitioned the drives, a known bug in Windows PE prevents Windows PE from determining the drive where it was booted, and you see this error. This situation is likely on a server with a RAID controller where you have just formed two or more RAID sets. The new RAID sets are completely raw because they have never existed before. The only workaround to the problem of multiple raw drives is to manually boot into Windows PE and run "diskpart" to partition at least one of the drives. Then run the task sequence again. The task sequence should work. The known problem with Windows PE is fixed in Windows Vista SP1 and hence in the Windows PE that is derived from Vista SP1.
March 31st, 2011 11:02am

Are you using a vanilla Task Sequence or an MDT 2010 integrated task sequence? The only reason I ask is there is some addition logic added at the front of the MDT integrated Task Sequences that may get around this issue. I have not looked in to it in-depth but I seem to remember there being an issue around this that was fixed with the MDT task sequences.... If that's not the case, Could you add a DiskPart script at the front of your Task Sequence to try and get around this? Diskpart is easy enough to script and add to the task sequence and may prepare the disks before the tasks sequence begins it's OS Deployment tasks. Another solution might be to generate a user driven install that adds additional steps for the admins to run though before the task sequence kicks off. Extreme solution I know but could be a useful way to customise you builds also with specific apps, settings or custom scripts being selected by the admin depending on what they are bilding the server for.Brett Moffett
Free Windows Admin Tool Kit Click here and download it now
June 9th, 2011 2:48am

I am seeing a similar issue when I unlock a Safeboot encrypted volume. The Task Sequence engine keeps trying to apply staging boot image to the E:\ (FullMedia USB HDD) instead of the C:\ after I have captured the data and Formatted & Partitioned the this. I cannot set the SMSTSLocalDataDrive variable because before the Task Sequence starts the C:\ volume is encrypted and not readable (I launch WinTech + Safeboot driver to unlock). If anyone knows any way to get the TS to use the C:\ drive for staging the reboot. Let me know.Levi Stevens Technical Consultant - End User Computing - West Region Dell | Services
September 13th, 2012 10:45pm

Levi, Any luck? We can get the task sequence to apply WinPE and boot, its after the partitioning and format from disk part, apply PE again and reboot for the second time we get stuck. Disk shows as RAW.
Free Windows Admin Tool Kit Click here and download it now
October 23rd, 2012 3:43pm

Snowbunny9501, We did solve our problem, but it was a two-part issue. 1) Safeboot (McAfee Endpoint Encryption for PC 5.2.5) did not boot properly after the Format Disk & Partition step. 2) USB HDD 1 TB drive is used for the TS Data and for staging the boot image (preferred of course is after formatting C:\ to move TS data to the C:\ and stage the boot image there. Here was our solution: 1 - After unlocking the encrypted volume to capture the data (which required taking disk offline/online to prevent corruption by WinPE 3.0) then we automated steps to the WinTech application to basically "corrupt" the SB volume, and taking the disk offline/online to release the drive from the SB driver. This allowed us to stage & reboot. 2 - We found no supported workaround to this issue. No matter what, even when using non-encrypted C:\ volumes, the TS engine always tries to use the E:\ drive (USB) for the TS Data and Staging Boot image. The issue we had is after the reboot, the TSBootShell would complain it could not find the TS environment and failed (it didn't like the fact the USB HDD looked like a fixed disk). The workaround for this was to replace the TSBootShell with a custom one in the winpeshl.ini, and we manually called TSBootStrap and specified the configpath. Levi Stevens Technical Consultant - End User Computing - West Region Dell | Services
October 23rd, 2012 6:53pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics