If you recently upgraded your server hardware and software to Exchange 2003, you probably aren't going to like this announcement.
Microsoft announced today that Exchange 12, the upcoming version, will be compatible with the 64 bit versions of Windows Server only.
I'm sure Intel is loving this announcement, but all those companies out there running Exchange on 2.5 to 3ghz boxes aren't going to like it one bit, particularly if they are using Software Assurance licenses.
Here's a question that got asked by a reader today. They were wondering how to configure their Exchange server so that all inbound emails sent to invalid addresses for their domain got redirected to the administrator.
I don't think that there's a mechanism to give them exactly what they want, however, Exchange (both 5.5 and 2000/2003) allow for Non-Delivery Reports (NDRs) to be copied to an administrative mailbox. To me, this accomplishes much the same thing, unless you don't want NDRs ever to be sent out by your server.
You can find a relevant Microsoft KB article here: http://support.microsoft.com/kb/294757/
I test turning off sending of NDRs to the internet and the admin account still continues to receive NDRs even if they aren't sent to the original sender.
Anyhow, to set this up in 2003/2000, go to each Default SMTP Server for each server in your site. Go to Messages tab in Properties and fill in the proper email address in the text box for "Send copy of all Non-Delivery Reports To".
If you are using Exchange 5.5, the same functionality is built into the Internet Message Service. Go to the IMS properties for your site and select the Internet Mail tab. Set up the Administrator's Mailbox and then click Notifications to set up which NDRs you want the mailbox to receive (or all if you wish).
Here's an interesting tidbit. Apparently, CDW's Microsoft Licensing sales reps have been told that if your back end is running Exchange 2003 Enterprise, that your front end must as well. Some Microsoft sales reps are telling the same story as well.
Well, I got word from KC Lemson (through my brother) that this is not true. That it's perfectly legal to run Standard on the front end and Enterprise on the back end. Apparently, this wasn't the case with 2000 as front end/back end functionality wasn't available in Standard back then.
So save yourself $2200 or whatever it is when setting up your Exchange organization in this manner and get Standard for your front ends, unless you need Enterprise to do clustering or for other features only supported on Enterprise.
We send out invitations for our Chautauqua seminars on a montly basis to about 500 people or so now. More and more mail servers are starting to quarantine or reject the messages out of turn now because they get identified as "bulk mail".
I've been asked to find a solution that will automatically send the emails to each addressee individually as opposed to just sending one email to all 500 addressees.
Just another example of how spammers make it hard to use email for legitimate business.
Anyhow if anyone out there knows of any products that do this, please let me know. Thanks in advance.
Just by looking at their interface, you wouldn't know about one feature that Mailive has. When you go to set up a server, it looks like you can only enter in the IP (internet protocol) Address or Fully Qualified Domain Name (FQDN) for one server.
Well, let's say you don't want to put in the IP Address or FQDN of a server, but would rather they go by your MX (Mail Exchange) DNS (domain name services) record instead. Then instead of putting in a server's IP or FQDN, you simply enter MX in that field.
Then Mailive sends to whatever server is at the top of your domain's MX list.
Last week I think I mentioned that I was going to try out Mailive to see how it compares to Siterecon.
Let me tell you, there's a world of difference between the two services. Mailive hasn't bothered me with a single false positive since I've set it up. I got an email, unprompted, from one of the support people at Knowledge Front (the people who run Mailive) asking if I had any questions or needed any help. He also explained exactly what the price structure was ($360 per server per year).
Plus they have a contact phone number listed on their web page.
Anyhow, so far, the service I've gotten out of Mailive far exceeds that of Siterecon. Mailive is definitely a service that I can recommend.
Today, I finally got tired enough of all the false positive error messages that I was receiving from Siterecon, that I turned off monitoring from that site.
Was still getting A LOT of false positives even with their new false positive protection feature. I don't know what the deal is with mail flow between here and there, but it's obviously problematic.
Anyhow, our first free month of mailive email scanning is up and going. Will report more as the month gets further along.
All I can say, is if you are looking for an end to end web based email test and alert system, Siterecon IS NOT it. Unless you want to receive multiple false positives every day.
Some people will take the preceeding comments to mean that I'm not happy with Exchange. Anyone that knows me knows that I like that product pretty much above any other from Microsoft.
Having said that though, it's hard to be exuberant about a product that you've spent the last 8 hours fixing.
There's always tomorrow, however. :)
So I've been on the phone with Microsoft for over 5 hours now. Looks like there was some sort of unknown corruption in one of the stores of the affected storage group.
Wasted a lot of time checking to make sure that it wasn't caused by a mail loop or excessive spam.
Fix ended up being to move the 5 users off the mail store onto a temp one, unmount the affected store and see if the problem stopped, delete the database files for the affected store, remount it, again make sure that the problem doesn't reappear and then move the users back.
So it took about an hour to actually fix the problem and the rest of the time was spent waiting for someone from the appropriate team to become available and for troubleshooting to isolate the problem.
About the only thing that the tech could recommend to prevent this from happening again is to regularly perform an offline defrag. Problem is, how often should this be performed? Also, I don't find bringing down a store to perform maintenance on it regularly a particularly satisfactory practice.
Then again, I guess I don't have much choice if I don't want the same thing to happen again...
Recent Comments