Deployment and Imaging Group

I am using winpe 2.1 in two different ways, and am not sure why one method is not working correctly.

1. PXE boot into winpe 2.1 boots fine, maps express share fine, can access local partitions fine.

2. Winpe 2.1 Installer package run on the PC to install winpe 2.1 automatino partition installs fine, maps express share fine, runs tasks fine, but it has no access at all to the local partitions. When accessing any of the drives it says drive not ready. C:(bootworks) T:(express) and X:(boot) are all accessable.

Why is the winpe installer package not able to access the ocal partitions. I need access so I can do a Token copy to generate the unattend.xml file and put it into D:\windows\panther. But without access to the local partitions this is not possible. 

It can access the Drive itself to lay down image.

On the Express share the PXE folder contains the files for the PXE boot, and the Bootwiz contains files for the installer package, but they are all pretty much default, am not sure what to check.

appreciate any help on this.

Running DS 6.9 SP4.

Not sure if this will help, but is the D: partition active at the time you want to access it?

-BBC

Im going to say yes, because it is a working WindowsXP PC with 3 partitions. So D: (in winpe) would have to be the active boot partition for XP to boot from.

Sorry for the late reply... Do you have the storage drivers included in the WinPE? Sounds as if that is the cause for PE failing to access or see the drives.

not sure about the problem but will agree BBC above comment of storage drivers?

Can you confirm, that the WinPe package puched through PXE and manually installed are same.

Also try, if you can get any info of disk through this tool

https://www-secure.symantec.com/connect/downloads/disk-info-windows-pe

I have gone through many forums, and there does seem to be some people saying that it could be the drivers, and it seems logical. I am a bit reluctant to go down that path because we have the PXE winpe boot working fine, and we have not had to add any drivers into that to get it to work across our HP DC7800/7900/800/8200/8300 desktops.

So the correct files are already in the altiris directories (somewhere)

Arjain, I can confirm that the PXE winpe boot and the winpe package install are NOT the same. I would love to make them the same ...HOW?

If I could make the package the same as the PXE boot I would. But I do not know how. I know where the winpe.wim/boot.wim file is for the package and have forced it to use the same one for PXE, but that changed the boot to similar to the PXE but it could not see the local partitions, so the issue is not the content of the winpe.wim/boot.wim file.

Any updates around this issue?

We have the same issue. We use DS 6.9 SP5 with PXE. Due to the fact it takes few minutes to download winPE image over pxe/tftp I have been asked to implement automation partition.

I tried both embedded and hidden partitions, and I have the same issue as described here.

"rdeploy drives" output:

D1P1

D1P2

Bootworks

"diskpart list volumes" output:

Volume 1, C, 8GB, bootworks.

We use ghost to do the imaging therefore it is not possible for us to use rdeploy.

wiht PXE booted winPE, everything works as expected.

Can somebody confirm whether this is an issue, or "feature by design" ?

Thanks,

Matt.

Not a solution, but a suggestion here...

I don't use the automation partition, but simply lay down an RDeploy image that contains WinPE and the DAgent. This then boots up and I can do anything I want against the HDD as the PE resides in RAM.

Thinking of the issue described, could it be that the partitions are wiped after installing the boot partition?

-BBC

You could try running these two cmds before attempting to use ghost

.\techsup\windows\apmapp.exe prod2mbr
.\techsup\windows\apmapp.exe ReloadPartitions

Did you use the Bootwiz Boot Disk Creator to make your installed WinPE image? It has options to insert drivers into the image for network cards, disk controllers etc, and it may be that one of those drivers is needed.

Refer below script it may help you

select disk 0
clean
convert gpt
create partition primary size=300
format quick fs=ntfs label="Windows RE tools"
assign letter="T"
create partition efi size=100
rem == Note: for Advanced Format Generation One drives, change to size=260.

format quick fs=fat32 label="System"
assign letter="S"
create partition msr size=128
create partition primary
format quick fs=ntfs label="Windows"
assign letter="W"

rem == CreatePartitions-UEFI.txt ==
rem == These commands are used with DiskPart to
rem    create five partitions
rem    for a UEFI/GPT-based PC.
rem    Adjust the partition sizes to fill the drive
rem    as necessary. ==
select disk 0
clean
convert gpt
rem == 1. Windows RE tools partition ===============
create partition primary size=300
format quick fs=ntfs label="Windows RE tools"
assign letter="T"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
rem == 2. System partition =========================
create partition efi size=100
rem    ** NOTE: For Advanced Format 4Kn drives,
rem               change this value to size = 260 **
format quick fs=fat32 label="System"
assign letter="S"
rem == 3. Microsoft Reserved (MSR) partition =======
create partition msr size=128
rem == 4. Windows partition ========================
rem ==    a. Create the Windows partition ==========
create partition primary
rem ==    b. Create space for the recovery image ===
shrink minimum=15000
rem       ** NOTE: Update this size to match the size
rem                of the recovery image           **
rem ==    c. Prepare the Windows partition =========
format quick fs=ntfs label="Windows"
assign letter="W"
rem === 5. Recovery image partition ================
create partition primary
format quick fs=ntfs label="Recovery image"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
list volume
exit

Have you tried to use FIRM instead?  If you just applied an image without a restart, it may not be "visible" yet, but FIRM will see it.  So will one of the ghost utilities.  Otherwise, if you just applied an image, then newly imaged drive simply is not "visible" yet.

Alternatively, try reversing the order.  You indicated later here that you have something already on the drive, right?  What if you try to access it BEFORE laying anything down?  Is it available at the beginning of the process and then gone later?  Maybe if you can isolate when exactly things break, we can figure out how to get past it.

Hello.

Thanks for great input. I have actually raised this as a support case with symanced and they have advised me that this is "as per design" and advised to either PXE boot or use rdeploy/firm.

However just recently I had a moment to test what MundroN01 suggested -

.\techsup\windows\apmapp.exe prod2mbr

.\techsup\windows\apmapp.exe ReloadPartitions

and yes - this resolves the issue* 

*There are some limitations. It appears that bootworks is overwriting partiton table on the disk so standard tools see only bootworks partition. When you isse the abouve commands the "production" partition table is written to a disk and reloaded. This allows standard tools to see normal partitions, and you can do all your operations, etc. The catch is however that when production partition table is "loaded" standard tools can no longer access automation partition, i.e. ghost cannot access image stored on automation partition. Firm/rdeploy can.   This does however solve the issue at least partially, i.e. I no longer have to use PXE to boot and can boot of local disk, which is very important for me due to large number of small, poorly connected sites which dont have deployment/package servers.

I'll look into my options about storing image and supporting files on the disk. Perhaps another hidden production partition.

Thank you all very much and especially to MundroN01.

Matt.

[edited to fix formatting]