Link to home
Start Free TrialLog in
Avatar of Blue Orange
Blue Orange

asked on

IIS6 Virtual SMTP server resends old email after reboot

After a reboot my Windows Server 2012 Standard starts sending very old emails which have already been sent weeks if not months ago.
As far as I know it only uses the C:\inetpub\mailroot directory for handling all traffic. I've monitored the Queue for days now and nothing strange there (emails getting sent). So I wonder what could cause this behaviour?
Avatar of Andy
Andy

Hi,

The best free method would be DNS (round robin) load balancing.
Used this before and it works well, although it can't do any kind of weighted (or intelligent) balancing.
Multiple A records for the same mail DNS name to several IP addresses for CAS servers.

You can also get a free version of the KEMP loadbalancer up to 20Mbps or maybe look at ARR
Avatar of Blue Orange

ASKER

@Andy, this SMTP server cannot be targeted by outside requests, it only accepts this from local applications who want to send an email.
Therefor having DNS changes will not work, it has to be something local.
SOLUTION
Avatar of Dan McFadden
Dan McFadden
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@Dan MacFadden:
To which queue are you refering? Is there a different way to access an IIS6 Virtual SMTP queue then its filesystem (mailroot dir)?
The smtp server always tries to make a bulk out of a bunch of email before it tries to sent them.

@SkullNoBrains:
I dont use exchange to send the emails, just the SMTP Server feature of IIS6.
The system had some Windows updates (normal reboot), but it does this every time we reboot the server.
I have check the logs from before and after the reboot and these are just normal send messages; no errors.
One customer refers to an email from september this year.

@Andy:
There are not tasks that start after a reboot.

I wonder where IIS6 SMTP Server could store these messages, apart from the mailroot directory?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@Andy; Pickup is empty.
I think it has todo something with a web applicatie accessing the SMTP server, since all those resends come from that single application (origin email is the same).

I'll get back to you guys, maybe it isnt even a SMTP server thing... durr
My next comment was going to be it could be another server using this as a relay!
@SkullNoBrains:
I dont use exchange to send the emails, just the SMTP Server feature of IIS6.

oops but the same applies, anyway + it most definitely is heavily bugged + i recollect there is a whole mess of temporary queues when you are using virtual IIS containers and the likes. if that is the case, the files must be stuck somewhere in the container.

i'd start by looking at known places for email files and possibly scan the drive(s).
alternatively you can use process monitor (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) and monitor which files are accessed on startup.

--

i don't believe too much a bug in the app would do that right when the server starts up but it is a possibility. but a local queue for the instance running that app seems more likely
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Turned out there were items in the Queue, after a reboot the smtp server picked them up again and send em. Strange but it must be something else. Going to run a clean task every day to check if there are items older then the maximum retry time.
most likely removing them will be good enough : they are probably leftovers from an old migration or possibly manual operation. look at the access rights, it is very likely the server does not have the right to delete the files.