Batch file automated a clean-up job, then fouled itself by deleting the wrong directory
A reader known as "Pascal", writing in The Register's regular "Who, Me?" confessional column, recounted how a routine maintenance script he wrote crippled a company's first Exchange server. Tasked with keeping the mailbox database running smoothly, he created a batch file to stop the Information Store, compact it, clear temporary files, and restart the service, a fix that tested successfully and was approved by management before being scheduled to run unattended over a weekend.
The script contained a "DEL *.*" command without a specified target directory, so when it executed from the System32 folder it began deleting core Windows NT 4 system files instead of the intended temporary files. The server, which hosted around 600 mailboxes, became unusable and required a full weekend rebuild and restore to fix. Pascal noted that despite the error passing testing and sign-off, he was the one called in to repair it, earning double pay for his trouble but no lasting damage to his job.
- A batch file's unqualified DEL *.* command wiped Windows NT 4 system files.
- The error crashed an Exchange server serving about 600 mailboxes.
- Fixing it took a full weekend rebuild, though the author was paid double time.
New here? Start with this
Exchange Server was Microsoft's email and calendar system, widely used by businesses in the 1990s and 2000s to store staff mailboxes on a central server. Keeping the underlying mailbox database running smoothly required occasional maintenance, such as stopping the mail service, compacting the database to save space, clearing out temporary files, and restarting it, tasks that were often automated with simple scripts to save time and reduce human error.
The account in question comes from The Register's "Who, Me?" column, a regular feature in which readers anonymously confess to IT mishaps from their careers. These stories are typically shared years after the fact and are told from memory by the person involved, often to illustrate how small technical oversights can have outsized consequences in a live business environment.
The wider point of interest is how automated scripts, even ones tested and approved beforehand, can behave unpredictably if run from the wrong location or without proper safeguards, since a single command can affect far more than intended. This matters because many organisations still rely on scheduled, unattended scripts for routine IT upkeep, and the episode illustrates the kind of risk that testing and sign-off do not always catch.