Using Sdelete to Wipe Workstations, with PDF Documentation, as an MDT Task Sequence

Sanitizing old hard drives before they are disposed is a pretty common activity in most organizations, and if you work for a company that has more stringent security guidelines you may also need to retain proof that the drive was wiped to provide to auditors. Most organizations in this situation end up purchasing an expensive third party wiping tool, but in this post we’ll show you that isn’t always necessary. Using MDT, SDelete, and a little PowerShell, you can achieve a wiping solution that no only meets Department of Defense Standard DOD 5220.22-M for wiping drives, but provides an audit trail as well.

 

Starting Out

First of all, the idea for this is heavily inspired by Gary Blok’s work as he has an excellent post on the idea here. The main differences being this solution only requires MDT and will net you a PDF when you’re done that is a little more auditor friendly.

For any of this work, make sure you download Sdelete from the following location. Make sure you place it in the same folder as the script and all other files.

https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete

You can download the script here.

SanitizeDocumenter

 

Task Sequence

The task sequence is straightforward.

The first task re-enables the FinalSummary screen, since I had it disabled. If yours it still enabled, or you prefer it off, you can ignore this task. I normally prefer an imaging PC to skip this summary if there are no errors. But in this case, I think it helps keep track of what state the PC is in, as well as avoid things like auto-rebooting into PXE and then sitting at the task sequence selection screen. It gets to be a little confusing when you are wiping and imaging several PCs a day.

The real meat of the sequence is the second task.

It uses the built-in Run PowerShell Script task and (surprise, surprise) runs the script. A parameter is passed in that tells the script how many “passes” to make. In this case, just one. Currently, if you want more options, you can make different task sequences. If you have certain standards to keep for different kinds of workstations, you can add some conditions to different tasks in the same task sequence. In the future, I think it might be nice to have a custom screen that asks you how many times you want to wipe.

 

The Script

The first thing the script does is set up all the functions required for creating our final documentation. This is done using the iTextSharp PDF Library. Admittedly, it was a lot of trial and error to get this exactly how I wanted it to be, as resources on how to use it in PowerShell are limited. But in the end, it came out pretty dang nice.

The body of the script copies all the files it needs locally to the X:\ drive. This includes Sdelete’s executable, some diskpart scripts, your cool corporate logo, and a few other things to give us the final documentation.

Next, it gathers some variables to detect your disks and populate our documentation later.

It does some basic error checking:
• Is the disk detected, but unreadable?
• Is no disk detected?

If errors are detected, they are both shown on the FinalSummary screen and on the documentation.

Next, it checks how many disks you have. It slaps together a simple diskpart script based on that information and uses it to clean the disks. Next, it runs Sdelete against each disk simultaneously. When you’re running it as part of the task sequence, you’ll see a few things happen.

First, the normal progress window appears and informs you about the overall progress. Second, it’ll show the actual Sdelete processes as command windows in the background. You can view these if you want to keep better track of what’s happening, how far along each disk is exactly, etc. Once it’s done, you’ll see a normal summary screen.

The script finishes by putting together our documentation. The reports are named according to the workstation’s serial number, the year, month, and day, in a PDF format. All of this is prefixed by “SUCCESS” or “FAIL”, letting you know very clearly what the result was. By default, it will try to dump them to a WipeReports folder on your DeploymentShare.

Here’s an example report generated by the tool.

Leave a Reply

Your email address will not be published. Required fields are marked *