Surface pro 4

  • Our company is new to the Surface pro 4 product and we started capturing images for deployment. The first few worked and then we started running into failures. I have even taken an image of a machine and tried to apply it back onto the same one and still get issues.

    **Processing /dev/nvme0n1 **
    ** Restoring MBR / GPT on /dev/nvme0n1 **
    Caution: invalid backup GPT header, but valid main header; reengineering backup header from main header.

    Warning! Main and backup partition tables differ! Use the 'c' and 'e' options on the recovery & transformation menu to examine the two tables.

    Warning! One or more CRCs don't match. You should repair the disk!

    ..... Complete

  • Those are just warnings and not the root cause of your problem. Can you attach the upload log and a failed deploy log

  • Here it is

  • It looks like the Windows partition was uploaded as raw instead of NTFS. Did the surface you uploaded from have bitlocker enabled?

  • That image had a few employees working on it. I will have to go back and see if anyone turned it on at any point in time. Thank you for your assistance

  • Ok looks like bitlocker was not enabled, but I did grab a brand new Surface Pro out of the box and tried to grab an image of it. It also collects it as raw. Is there a setting on the clonedeploy server software that would cause this to happen?

  • There is no setting for this. It means CloneDeploy can't detect what filesystem is in use. I have never seen this happen without bitlocker or some other type of encryption. I thought the Surface line had it enabled by default. It could be something new with Windows 10 though, it gets tough to keep up since Windows 10 changes so often.

  • Understood. The first few times we deployed images it worked great; just recently something changed and we can't figure it out. That's why I tested it on a new unused Surface and even that pulled only raw. we are using Kernal 4.13.2x64 over a USB. We are actually thinking about starting it all over from scratch.

  • Does it still do this when you install a fresh version of Win 10 instead of the factory version?

  • I'm still leaning towards bitlocker. Can you run this from an elevated cmd prompt to get the bde status on the surface to upload?
    [code]manage-bde -status C:[/code]

    And to ensure it is turned off
    [code]manage-bde -off C:[/code]

  • Got it to work on the main Partition; found Bitlocker enabled, but now we have another partition ( /dev/nvme0n1p2 ) giving only raw and trying to figure that out.

  • The second partition doesn't matter, sometimes raw is normal depending on the filesystem. The second one is probably the efi partition, so it's fine.

  • I went a head and installed Windows 10, not the factory version that came on the Surface Pro 4, and Clonedeploy grabbed it and imaged another unit successfully. Must be something else on our other image that is causing the issue. We do have quite a few changes to the local group policy, would anything in there possibly make clonedeploy unable to properly grab it?

  • No, but I thought you said bitlocker was enabled on the other image?

  • it was but we turned it off and decrypted it, would that still cause a problem?

  • Not that I'm aware of.