I am working on a similar process to use OS Deploying through the gateway and I am close to finished.
Create a a vboot.bat that Vboots to WinPE and make it a Distribution Package. Open an OSD Script. Look at what files are downloaded. Maybe copy them all to a Web Share (they are already in a web share but it is nice to have them all in the same folder with the vboot.bat). Add those files to the Distribution Package. Deploy it as a policy.
You can prestage the files even to a device over the Management Gateway if you want:
You could use this or some other tool as a batch file inside WinPE to dispose of the hard drive.
I modified my Vboot.bat that I am using for OS Deployment through the gateway.
It is modified to work for your purpose of wiping a drive. I haven't really tested it.
I just dumped this batch file into the Managementsuite\LANDesk\Vboot directory.
REM REM Copywrite (R) REM LANDesk an Avocent Company REM REM Written by Jared Barneck REM REM Step 1 - Copy diskinfo.exe from the LANDesk\Files direcroty to the REM LANDesk\Vboot directory. REM REM Step 2 - Create a distribution package and include all the files needed. REM Check an OSD Script and look at the files that are downloaded. REM REM Step 3 - Add the tools you use for cleaning the drive to the WinPE image. REM REM Step 4 - Copy the Startnet.bat file from a PXE Rep's PEBOOT.IMG file REM And modify it to not contact the Core Server but just run the "cleaning" REM of the drive and reboot. Place it on the share and make it an additional REM file to the batch file distribution package. REM Client directory SET LDMS_CLIENT_DIR=%LDMS_LOCAL_DIR:~0,-5% REM The above varialble %LDMS_LOCAL_DIR% may not exist starting with REM The 8.8 client. REM Modify the files tokreplw.exe GUID.PDS DEVICEID=%2 tokreplw.exe winbom.ini COMPUTERNAME=%COMPUTERNAME% diskinfo.exe update_winnt_sif winnt.sif.new REM Inject modified files copyfile.exe ldvpe1.img GUID.PDS \ldclient\ldiscan.cfg copyfile.exe ldvpe1.img winbom.ini \winbom.ini copyfile.exe ldvpe0.img winnt.sif.new \winnt.sif REM Inject a new StartNet.bat file that runs the wipedisk copyfile.exe ldvpe0.img StartNet.cmd \i386\system32\StartNet.cmd REM Place the ldvpe1.img file in the root of c:\ move /Y ldvpe0.img c:\ldvpe0.img move /Y ldvpe1.img c:\ldvpe1.img REM Defrag the image lddefrag.exe c:\ldvpe0.img REM Sets the partition table to boot off a virtual partition made up of ldvpe0.img and reboots bootfile.exe c:\ldvpe0.img /keep /bootunsafe EXIT /B 0
So there is a lot of work to do, but hopefully you get the idea that you need to do.
A bit of a "dirty hack" that I seem to recall from yesturyear to "easily" wipe a drive is to use
The trick to do this is that you need to use an FDISK version from a DOS/OS-version that's different.
NORMALLY "FDISK /MBR" would simply re-write the Master Boot Record (the MBR) - and that's that. HOWEVER, if you're using it with an old version of FDISK (such as DOS 6.22) it essentially renders the drive useless. There's also other ways to do these things ... I've not tested how reliably "zap.exe" from IBM* wipes out drives ("reliably" in terms of "can't actually get the data back) but it might be worth while.
I find that many of the common procedures which people use to erase data leave enough of a trail on the disk for a clever individual to restore that data. Personally, I've not found a way yet to "fix" a disk (short of having had a backup of the old MBR) once I ran a DOS 6.22 "FDISK /MBR".
Fringe-benefits - it only requires a DOS-VBOOT/PXE boot, and it's a tiny executable :).
It's been quite a few years since I played with this sort of thing though (and might require a DOS 6.22 based VBOOT/PXE-boot image), so some work might be involved as yet.
Hope this helps.
I looked at that link...
Does that batch file really work for you? I have not been able to call SDCLIENT.EXE /F in a batch file because it fails with the error:
-1918091239 Facility: 3500 Error: 16409 Failed: Another installation is currently in progress.
See, because SDCLIENT.EXE is running the batch file, it actually cannot be used to download files with the /F parameter or you get this error.
You have to add these as additional files or use something like wget to download the files.
You know what...now that I think about it...It probably worked when you tested it because the files were already there on the client.
I'm sure that it worked... however, that was written a year ago, and it's entirely possible that things have changed. At any rate, sdclient is not the only file transfer tool possible.