Jump to content

  • 0


As the title suggests: I'm looking for guidance on how to wipe the MBR via Task Sequence during an OSD. Any suggestions?

We use Symantec Encryption Desktop (aka PGP) and it adds a bootguard to the MBR which needs to be cleared out (we need to wipe the MBR) in order for the machines to boot successfully.

If I boot a Win8.1 amd64 ISO, select Repair > Advanced > Command Prompt > Run bootrec.exe /fixmbr, it works fine and corrects the issue so I thought "Why not add bootrec to our amd64 WinPE.wim?"

I copied what I thought were the necessary files into our amd64 winpe.wim, based on the following sites:

And although it appears to run successfully, it executes and produces no errors, it doesn't seem to actually be doing anything as the problem persists on a reboot.
Running bootrec /fixmbr and/or bootrec /fixboot multiple times in our amd64 WinPE media doesn't work; but booting a amd64 Win8.1 ISO and running bootrec /fixmbr once works.

I've tried the following with no positive results:

  • Creating a diskpart script to sel dis 0 and clean isn't sufficient; doesn't wipe the MBR
  • Converting the disk to GPT then back to MBR, but prior to the format & partition step, will remove bootguard.
    HOWEVER, it causes the TS to fail once it gets into Windows with the following error:
    "Wizard Error: Unable to find the SMS Task Sequencer. The deployment will not proceed."

    I've tried doing this two ways, and while it clears the MBR, I get the 'Wizard Error' above.
    1) Via a Task Sequence step that runs a diskpart script (again, prior to the format & partition step), and
    2) Adding 'oUtility.RunCommandWrite oExec, "CONVERT GPT NOERR"' to around line 340 of the ZTIDiskPart script.
  • Symantec says that uninstrumenting the drive should correct this, but you cannot uninstrument an encrypted disk and the decryption process takes way too long. (About 24 hours)
  • Secure wiping the disk (e.g.: via WipeDisk, DBAN) works but takes way too long. (Several hours)


Share this post

Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0

Thanks for the reply. Do you have suggestions on such apps, especially ones that work in a 64-bit PE environment?

I used to use mbrwiz back when we were still using Ghost in WinPE 2 & 3, and although it appears to work in WinPE 5 (no errors when executing; claims it completed successfully) it doesn't appear to be doing anything.


There wouldn't happen to be a x64 fdisk executable floating around, right?

Share this post

Link to post
Share on other sites

  • 0

I went through a number of tests using diskpart, bootrec and mbrwiz. Yesterday I had a troubleshooting session with Microsoft who provided me with two versions of dskprobe (v2 & v3). They were able to witness that every time, the commands 'succeeded' but the MBR was still intact.

In DskProbe we can see exactly what's in sector 0, re-write it or copy from another sector to sector 0, and here's where it gets interesting.

DskProbe shows the bootguard data in sector 0 (as expected) so we tried leveraging DskProbe's builtin utilities to manipulate sector 0:

  • write zeros to sector 0
  • save another zeroed out sector to a file then import that file to sector 0
  • copy another zeroed out sector to sector 0

Each time, it completed successfully and DskProbe showed all zero's in the UI. However, upon refreshing the disk or re-reading sector 0 or restarting DskProbe and re-reading the disk, sector 0 is intact! Its as if we never touched it.


  • performing the same steps on the same machine to an unencrypted volume, like a 1GB VHD,all the tools work as expected.
  • booting a Windows ISO and running bootrec or diskpart works also

Therefore, we all had to assume that since:

  • the MBR/sector 0 wipe commands don't work from machines that have PGP installed
  • the MBR/sector 0 wipe commands don't work from our WinPE WIM (which has the PGP drivers baked in for recovery purposes)

But the stock Windows ISO's (7, 8, 8.1) do work, it must be PGP. There seems to be something about Symantec Encryption Desktop/PGP, perhaps their filter driver, that prevents one from wiping the MBR or sector 0.

I've circled back to Symantec's support team and I hope they can tell me there's a way to bypass this.

The only thing that does wipe the MBR, and we confirmed this yesterday, is running 'convert gpt noerr' & 'convert mbr noerr' in diskpart. But adding that step to the Task Sequence causes the imaging process to break, and I don't yet know why:

  • Task Sequence Starts
  • Before the format & partition step I run the diskpart script that cleans, converts to gpt then converts back to mbr
  • The format & partition step runs
  • WIM is applied
  • Reboots
  • Windows does its hardware detection
  • Reboots
  • Windows boots and I see the 'Wizard Error' message: Unable to find the Task Sequencer. The deployment will not proceed.

I'm able to reproduce this on 3 out of 4 machines.
If I take that diskpart step out, all machines image successfully every time.
And, in case anyone is wondering, it doesn't matter of the machines were encrypted to begin with or not prior to imaging. Adding that script results in a high failure rate and I don't know why.

At this point, I think this thread can be closed since its not a Microsoft issue, but a third-party that's preventing the tools from functioning correctly. If I find a solution to why adding the diskpart script creates that 'Wizard Error' then I'll update this post.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.