Deployment and Imaging Group

Ok, already bricked one beyond repair and have another one waiting...I had grabbed an image of the drive as it sits and tried to lay it back down as a test to see how it would perform/behave. Total destruction and couldn't even get back into the UEFI settings as I had before.

I am running 7.5 SP1 HF2 and am trying to clone a Surface 3 Pro and lay it back down properly. I know I need the destintion to be GPT instead of MBR like with normal BIOS cloning.

I do have PXE running and can boot into my x64 WinPE preboot environment on the Surface. That operates like all of our normal image processes on other machines.

So, any of you with a PXE boot setup and Surface tablet/tops laying around. How are you imaging them? Thanks.

Ah yes.

1) You are not alone.

2) We are imaging them fine now.

So, after we bricked our first one and talking with our Microsoft rep, we know the following:

1) Microsoft hosed us by storing files and firmware required for the device to boot on a hidden partition on the device.

2) The default deploy image task causes ghost to overwrite that partition and detroy the data contained within.

We had to create a script that mapped a drive to the location of the image file, then call ghost with the command line to only lay down the OS partition in the image, to the correct partition on the device.  Once I get back in the office I will post the details of the script with the ghost command lines.

We accomplish this in our environment by using a scripted deployment method.  Basically we use our same image which is built on a legacy MBR VM.  We use diskpart to create the UEFI/GPT image partition structure on the target Surface.  Then we take the windows partition from the source image and lay it down on the windows partition of the target system. The last and most important step is to copy the boot files to the system parition. Once you have accomplished this the system boots into windows and all is well.  We have yet to get a native process working using the built in tools but this works great for us because we don't have to maintain an additional image.  If you want the specifics on our process I would be happy to share...just shoot me a pm. :)

Ah HA! I suspected that, but needed someone to help with the details. Microsoft=job security :)

Ok, looking forward to the script you laid out. Thanks (to both posts)!

Todd

Hi Joel, I was just looking at your other post regarding this.

http://www.symantec.com/connect/forums/imaging-efiuefi-system-windows-8-and-symantec-ghost-usb

Couldn't you just target the secondary partition and leave the original boot partition in place for booting?

Here is the script.  Just create a run script task and use VBScript as the language.  Just update the variables as needed.

Attachment(s)

Deploy_SP3.txt   2 KB 1 version

Thank you for sharing!

So, why use DST=1:4? I would expect 1:2 to hit the secondary partition...or am I off base here?

Also, since this is for deploying...did you do anything special to capture the Surface image?

It actually depends on how you are creating/preserving the partition structure target.  If you were to install windows from scratch it would create a total of 4 partitions.  The recovery would not be included by default but could be leveraged to reimage the device without the need for USB/PXE/Partition Folders.

1. Winre
2. Msr
3. System
4. Windows
5. Recovery Image Embeded (Optional)

I see. For now I think we are going to grab the out-of-the-box image while we are testing other applications, etc. We just want a method to grab the factory image and lay it back down as we move forward in testing.

We have a hardware independent image process that we added support for the Surface to so our source is image will likely be quite different than yours...  But for a one off image and to keep things simple in our environment we leave the capture process the same:

Capture the entire disk as it exists with all partitions (including the ones ghost can't handle natively)

Later when we deploy it...we format the target disk as UEFI

Specify the Windows partition from the source.... usually something like Image:1 Partition 3/4.

We then lay that down to target system Disk 0 Partition 3/4.

After that we copy boot files to the system partition and thats it.

Hi Joel,

Thanks for the reply. So, for our testing, a straight out of the box capture of the Surface resulted in 5 partitions. See screenshot.

Is the first partition (350MB) the one that needs to be preserved (or re-copied with boot files)?

I finally got Ghost Explorer to load it up so i can see what is captured firsthand and it matches what you listed a few posts back :)

So, I could target partition 4 if I wanted to lay the OS back down as-is, I am thinking.

Hey tloenhorst,

Yeah I have never perserved the stock boot partition because we are on enterprise builds here and I just assumed you could not mix and match a pro bootloader with an enterprise windows partition.  We have other requirements as well such as bitlocker encryption but if you are preserving a pro boot partition with the intention of deploying a pro windows partition I would guess that it should work.  I might be totally wrong though because I have never tried it.

Also try loading up diskpart while in pe and running the command "list volume" ..it should give you a pretty good idea of what you are wanting to preserve/target.

For now, and maybe until Windows 10, this Surface image will be our only Windows 8 image in the entire enterprise as everything else is Windows 7. From a maintenance standpoint that shouldn't be a problem to have this one-off image. We only have about 10 Surface 3 Pro units right now.

I am testing right now. This is what I am using (Ghost cmd line) from the VB script given by Jeff Carlson. It has been modified to reflect partition 4:

"Ghost64.exe" & chr(34) & " -sure -clone,MODE=prestore,DST=1:4,SRC=" & strNetworkDrive & "\" & strImageName & ":4 -notrim",0,true

So, from the completely stock image capture, partition 4 is the Windows partition and I am grabbing ONLY that partition and laying it down to partition 4 on the destination drive (on another surface). Pretty much just a POC and then we will start making modifications for a custom image before capturing and laying it down again.

Update: Totally successful with the Surface 3 Pro now. Already developed a custom image and am able to get sysprep, image capture, etc.

Thanks for the help and multiple suggestions!

Well, spoke too soon. It seems that the prepare image task actually causes a BSOD and returns error: driver_power_state_failure and the faulting module is dxgkrnl.sys according to the minidump. Every time.

These Surface devices are such a treat!

Another update. I got it working, but with caveats.

Prepare Image Task still crashes. I'm still on 7.5 SP1 HF2...not sure if that issue will get fixed once upgraded. So, in the meantime I got Sysprep working as a stand-alone solution. I discovered that it would also crash, but with a fatal error because of certain apps being installed under an "unknown" user. I solved it by following this:

https://superuser.com/questions/861319/sysprep-exe-fatal-error-and-cant-delete-metro-app-in-windows-8-to-get-it-worki

And then for good measure:

https://support.symantec.com/en_US/article.TECH223595.html

After that, Sysprep worked as expected and it parsed my unattend.xml I developed for Windows 8.