Need to delete unmanageable Badmail directory

[Charles Lavin]

Hi --

I'm trying to clean up an Exchange 2000/Win 2000 (SP4) machine prior to a
migration. This server is massively bogged down and almost out of disk
space. One of the biggest issues is an Exchange Badmail folder that has what
are probably millions of files. It doesn't seem like the prior IT manager
ever cleaned out this folder, and this machine bounces back a ton of spam a
day.

Any attempt to open Badmail from Explorer usually results in Explorer
hanging. Actually, you won't even get that far -- opening up its parent
folder usually hangs Explorer.

I navigated to the Badmail folder from a command prompt. I let a dir call
scroll for about 20 minutes before I stopped it.

A dir call redirected to a text file produced a 47 MB file before I stopped
the process almost two hours after it began.

A del *.* ran for well over an hour before I stopped it.

An rmdir Badmail /s ran for almost two hours before I stopped it.

I downloaded the Badmail maintenance script from the MS site. But it has yet
to tell me what it plans to delete -- and it's been running for almost two
hours.

Is there a way to wipe out that folder without forcing Windows to read it
all? I need to clean up this folder ..

Thanks,
CL

 

[Bharat Suneja [MVP]]

You should be able to delete the Badmail folder without opening it in
Explorer - just open the folder a level above it.
Stop the SMTP VS if required. Additionally, you can also change the location
of the mailroot folder used by the SMTP VS (after stopping it).

How to change the Exchange 2003 SMTP Mailroot folder location
http://support.microsoft.com/kb/822933

--
Bharat Suneja
MVP - Exchange
www.zenprise.com
NEW blog location:
exchangepedia.com/blog

 

[Meinolf Weber]

Hello Charles,

Have a look here:

Exchange Server Badmail Deletion and Archiving
http://www.microsoft.com/downloads/...0f-6239-40ad-adda-97863d852ff7&displaylang=en

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.dts-l.org/goodpost.htm

 

[Rich Matheisen [MVP]]

[ snip ]

I downloaded the Badmail maintenance script from the MS site. But it has yet
to tell me what it plans to delete -- and it's been running for almost two
hours.

Kill it.

Is there a way to wipe out that folder without forcing Windows to read it
all? I need to clean up this folder ..

Run the command line DIR command and stop watching it run. Just let it
complete. It'll take a good long while with that many files in the
directory.

Don't be impatient.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected] mailto:[email protected] mailto:[email protected]

 

[Rich Matheisen [MVP]]

You should be able to delete the Badmail folder without opening it in
Explorer - just open the folder a level above it.

Still takes a looooong time to remove the folder. BTDT.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected] mailto:[email protected] mailto:[email protected]

 

[Charles Lavin]

Hi --

I already directed Exchange to another Badmail folder and stopped the SMTP
VS. I cannot open the folder above Badmail (vsi 1) in Windows; it too hangs.
I _can_ open the folder from a command prompt. But even a command prompt dir
command doesn't seem to ever get to the bottom of that folder.

CL

 

[Charles Lavin]

Hi --

That's the script I downloaded from the MS site. It doesn't ever get to the
bottom of that folder, either. I know because the first time I ran it, I had
already switched Exchange to use a Badmail2 folder -- and there were already
several hundred messages in there. I saw that script determine the proper
folder, how many files were in it, and then delete the files. But when I
changed Exchange back to the original Badmail folder, the script ran for
almost two hours without ever even telling me what it planned to delete.

CL

 

[Charles Lavin]

Well ...

I'm not watching it run, and I don't think I'm being impatient. But when I
launch a "del *.*" and return two hours later to find it apparently still
running, and can see no apparent increase in available disk space, I wonder
if anything is happening ...

I'll launch another one. But I'd like to know exactly how many files are in
there ... The client isn't going to believe this

Thanks,
CL

[ snip ]

I downloaded the Badmail maintenance script from the MS site. But it has
yet
to tell me what it plans to delete -- and it's been running for almost two
hours.

Kill it.

Is there a way to wipe out that folder without forcing Windows to read it
all? I need to clean up this folder ..

Run the command line DIR command and stop watching it run. Just let it
complete. It'll take a good long while with that many files in the
directory.

Don't be impatient.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected]
mailto:[email protected]
mailto:[email protected]

 

[Rich Matheisen [MVP]]

Well ...

I'm not watching it run, and I don't think I'm being impatient.

With that many files in the directory you are.

But when I
launch a "del *.*" and return two hours later to find it apparently still
running, and can see no apparent increase in available disk space, I wonder
if anything is happening ...

It is. The "*.*" has to enumerate the set of file names in the
directory before it can do anything. The manipulation of the MFT to
get rid of the information will take a while, too -- as will the
linking of all the freed sectors back to the file system.

It's doing this while Exchange (and other processes) are taking up
lots of memory and I/O, too.

The reason the GUI takes so long is that no only does it have to
enumerate the files it also sorts their names, and then update the
display as each file is removed.

I'll launch another one. But I'd like to know exactly how many files are in
there ... The client isn't going to believe this

If you're curious about the number of files you'll have to wait a long
time to get the answer -- and then wait longer to have them deleted.


--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected] mailto:[email protected] mailto:[email protected]

 

[Rich Matheisen [MVP]]

"Charles Lavin" <[email protected]> wrote:

[ snip ]

If you're accumulating that many file in the badmail directory I'm
guessing that you don't filter any of your inbound mail for spam? And
that you're not using anything to validate the RCPT TO addreses
against your AD?

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected] mailto:[email protected] mailto:[email protected]

 

[Charles Lavin]

With that many files in the directory you are.

That's the rub -- I had _no idea_ that there were that many files in there.
I _still_ don't know how many files there are in there. That folder is also
apparently the cause of problems we've had with Disk Cleanup and Error
Checking.

That "dir > \badmail.txt" run I stopped after two-and-some hours and 47 MB
of .txt file resulted in a list of 632,131 files. And I think that barely
scratched the surface. I converted that .txt file into a batch file with
632,131 del calls -- that way the system doesn't have to enumerate anything,
and I can at least verify that it's doing something. I ended it with another
redirected dir call to see what's left in there. I see that this is going to
take days to resolve ...

Thanks,
CL

 

[Charles Lavin]

By the looks of it, they don't ...

I was brought in to migrate this box to SBS 2003, where I have a bit more
control over this spam problem. What we're doing on the Win2K server is
supposed to be just preliminary stuff prior to the migration. But I've
encountered a server with corrupt Exchange databases, improperly configured
AV software, less than 200 MB of free disk space, 9-plus-GB mailboxes, tons
of missing updates (including an entire Exchange SP) ... Cleaning this box
up so that it can be migrated is proving to be more work than the migration
itself was expected to be.

CL

"Charles Lavin" <[email protected]> wrote:

[ snip ]

If you're accumulating that many file in the badmail directory I'm
guessing that you don't filter any of your inbound mail for spam? And
that you're not using anything to validate the RCPT TO addreses
against your AD?

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected]
mailto:[email protected]
mailto:[email protected]

 

[Pegasus \(MVP\)]

That's the rub -- I had _no idea_ that there were that many files in
there. I _still_ don't know how many files there are in there. That folder
is also apparently the cause of problems we've had with Disk Cleanup and
Error Checking.

That "dir > \badmail.txt" run I stopped after two-and-some hours and 47 MB
of .txt file resulted in a list of 632,131 files. And I think that barely
scratched the surface. I converted that .txt file into a batch file with
632,131 del calls -- that way the system doesn't have to enumerate
anything, and I can at least verify that it's doing something. I ended it
with another redirected dir call to see what's left in there. I see that
this is going to take days to resolve ...

Thanks,
CL

Having 632,131 del calls will take much, much longer than del *.*.

 

[Rich Matheisen [MVP]]

That's the rub -- I had _no idea_ that there were that many files in there.
I _still_ don't know how many files there are in there. That folder is also
apparently the cause of problems we've had with Disk Cleanup and Error
Checking.

That "dir > \badmail.txt" run I stopped after two-and-some hours and 47 MB
of .txt file resulted in a list of 632,131 files. And I think that barely
scratched the surface. I converted that .txt file into a batch file with
632,131 del calls -- that way the system doesn't have to enumerate anything,
and I can at least verify that it's doing something. I ended it with another
redirected dir call to see what's left in there. I see that this is going to
take days to resolve ...

I think that batch file will finish around New Year's day! Not only
will the program be loaded more than a half-million times, each
execution will have to find the file in the mass of file names in that
directory before it can delete it.

Just do the DEL *.* and let it run. If it takes a couple of days, so
what?

As an alternative, I suppose you could make a backup of the disk and
then fdisk it, format it, and restore everything except that
directory. I'd just let the DEL run, though.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected] mailto:[email protected] mailto:[email protected]

 

[Charles Lavin]

Maybe ... But at least I'm making some headway.

If a del *.* takes 10, 12 or more hours (by what I see) to enumerate the
folder before even beginning to delete files, and the job is aborted for
whatever reason during that time, then the server has been spinning its
wheels for nothing.

This server has had to be rebooted three times since Friday, for reasons not
related to what we're doing. And my TS run has been aborted at least twice.

What I would really like to do is just zero out the directory entry, and
then run a scandisk (or whatever) to return the suddenly "unused" disk space
....

CL

 

[Dave Patrick]

It may go faster if you delete from the recovery console. First you'll need
to Control Panel|Admin Tools|Local Security Policy Recovery console: "Allow
floppy copy and access to all drives/folders" set to enabled

Then from the recovery console command line;
SET allowallpaths = TRUE

to gain access to all folders.

To start the Recovery Console, start the computer from the Windows 2000
Setup CD or the Windows 2000 Setup floppy disks. If you do not have Setup
floppy disks and your computer cannot start from the Windows 2000 Setup CD,
use another Windows 2000-based computer to create the Setup floppy disks. At
the "Welcome to Setup" screen. Press F10 or R to repair a Windows 2000
installation, and then press C to use the Recovery Console. The Recovery
Console then prompts you for the administrator password. If you do not have
the correct password, Recovery Console does not allow access to the
computer. If an incorrect password is entered three times, the Recovery
Console quits and restarts the computer. Note If the registry is corrupted
or missing or no valid installations are found, the Recovery Console starts
in the root of the startup volume without requiring a password. You cannot
access any folders, but you can carry out commands such as chkdsk, fixboot,
and fixmbr for limited disk repairs. Once the password has been validated,
you have full access to the Recovery Console, but limited access to the hard
disk. You can only access the following folders on your computer: drive
root, %systemroot% or %windir%

(Note: If your drive controller is not natively supported then you'll want
to boot the Windows 2000 install CD-Rom. Then *F6* very early and very
important (at setup is inspecting your system) in the setup to prevent drive
controller detection, and select S to specify additional drivers. Then later
you'll be prompted to insert the manufacturer supplied Windows 2000 driver
for your drive controller in drive "A")


--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

 

[Charles Lavin]

Thanks for the tip. But I can't shut down the server without the OK from the
client.

It may go faster if you delete from the recovery console. First you'll
need to Control Panel|Admin Tools|Local Security Policy Recovery console:
"Allow floppy copy and access to all drives/folders" set to enabled

Then from the recovery console command line;
SET allowallpaths = TRUE

to gain access to all folders.

To start the Recovery Console, start the computer from the Windows 2000
Setup CD or the Windows 2000 Setup floppy disks. If you do not have Setup
floppy disks and your computer cannot start from the Windows 2000 Setup
CD, use another Windows 2000-based computer to create the Setup floppy
disks. At the "Welcome to Setup" screen. Press F10 or R to repair a
Windows 2000 installation, and then press C to use the Recovery Console.
The Recovery Console then prompts you for the administrator password. If
you do not have the correct password, Recovery Console does not allow
access to the computer. If an incorrect password is entered three times,
the Recovery Console quits and restarts the computer. Note If the registry
is corrupted or missing or no valid installations are found, the Recovery
Console starts in the root of the startup volume without requiring a
password. You cannot access any folders, but you can carry out commands
such as chkdsk, fixboot, and fixmbr for limited disk repairs. Once the
password has been validated, you have full access to the Recovery Console,
but limited access to the hard disk. You can only access the following
folders on your computer: drive root, %systemroot% or %windir%

(Note: If your drive controller is not natively supported then you'll want
to boot the Windows 2000 install CD-Rom. Then *F6* very early and very
important (at setup is inspecting your system) in the setup to prevent
drive controller detection, and select S to specify additional drivers.
Then later you'll be prompted to insert the manufacturer supplied Windows
2000 driver for your drive controller in drive "A")


--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

Maybe ... But at least I'm making some headway.

If a del *.* takes 10, 12 or more hours (by what I see) to enumerate the
folder before even beginning to delete files, and the job is aborted for
whatever reason during that time, then the server has been spinning its
wheels for nothing.

This server has had to be rebooted three times since Friday, for reasons
not related to what we're doing. And my TS run has been aborted at least
twice.

What I would really like to do is just zero out the directory entry, and
then run a scandisk (or whatever) to return the suddenly "unused" disk
space ...

CL

 

[Charles Lavin]

What program will be loaded more than a half-million times? I'm using del.
When did del become an external program?

 

[Pegasus \(MVP\)]

"del" is an internal program. However, each application of "del"
involves a "seek" process, which takes a lot of time in a large
directory. If you use a wildcard then the seek process happens
just once.

Here is a quick demonstration. I created a folder with 10,000
files inside. I then cleared it in two ways:
a) I got a batch file to execute 10,000 individual "del" commands.
b) I used the usual del *.* command.

Results:
a) 37 seconds
b) 7.4 seconds

I suggest you try it for yourself.

 

[Pegasus \(MVP\)]

BTW, using "rd /s /q" took just 4.2 seconds.

What program will be loaded more than a half-million times? I'm using del.
When did del become an external program?