SEMblog

Last year I wrote an article about how spam could not originate from inside your network and go through your Exchange server, because that was simply too much hard work.
You can read the original article here: http://blog.sembee.co.uk/archive/2008/03/13/73.aspx
As a brief summary, I basically said that a spammer needs to get their BOT inside the network, find the Outlook installation and then abuse it, or they could take the simple route of having their own SMTP engine and send email directly.
Remember a spammer doesn't want to be found, and sending a large amount of messages through Exchange will alert network administrators that something is wrong.

Alas despite that posting some people continue to believe that someone who is being flooded with spam in their queues will have a compromised client, despite the changes being very slim.

The purpose of this posting is to help you diagnose whether the message has come from a client inside your network, or not.
Do that, you need the SMTP headers of one of the messages.

Background

First a little bit of background about Exchange and SMTP headers.
When you send a message from a MAPI client (so that is Outlook, Outlook Web Access, a Windows Mobile device using Exchange ActiveSync or a Blackberry using a BES) then the SMTP headers are not actually put on to the message by the client, but by Exchange when the message hits the SMTP server. That is why you do not see any headers on internal email messages or show the internal IP address of the machine that originated the message on external email messages.  

If you send the message via an SMTP client (Outlook Express etc, a PDA with IMAP/POP3 access etc), the SMTP header is generated by the application originating the message.

If you bounce the message off Exchange's SMTP virtual server (relaying) then the header stays intact and  Exchange simply treats it like any other SMTP message that is passing through.

It is the originating application line that will show you whether the message has come from inside.

Getting the Headers

If the server has already been blacklisted, then on many of the blacklists you can see the message that was received, which will show the complete headers.
If you have a large number of messages in the queues, then you simply need to get hold of one of those messages. You will find them in \exchsrvr\mail root\vs 1\queue.
Drop one on to a notepad document, which should open for you.

What you are looking for.

When you can see the raw header, you are looking for something like the below.

If the message originated outside of Exchange, then look for something along the lines of these examples:

• X-Mailer: Microsoft Outlook Express 6.00.2600.0000
• X-Mailer: The Bat! (3.0.2.8) Professional
• User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

If the message originated on Exchange, then you will see something similar to these:

• Exchange 2000:
  X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12
• Exchange 2003:
  X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
  X-MimeOLE: Produced By Microsoft Exchange V6.5
• Exchange 2007:
  Received: from host.domain.local ([fe80:xxx:xxxx:xxxx:xxxx]) by  host.domain.local ([fe80:xxxx:xxxx:xxxx:xxxx]) with mapi;
  Received: from host.domain.local ([123.123.123.123]) by  host.domain.local ([123.123.123.123]) with mapi;

Of course the headers are not completely fail safe. Antivirus and anti spam applications can strip content off the headers, as can other third party tools that will scan SMTP traffic. However the presence of non-Microsoft products in the headers is a clear sign that the message originated outside of your network.

This is another post in my series of articles on why you shouldn't use certain features in Exchange, even though they are there - although in this post is about an Outlook feature - PST files.  

The other articles in this series to date are:

Why you shouldn't use logos in signatures (http://blog.sembee.co.uk/archive/2008/04/14/76.aspx)
Why you shouldn't enable the POP3 Server (http://blog.sembee.co.uk/archive/2008/03/03/71.aspx)
Why you shouldn't use the POP3 connector (http://blog.sembee.co.uk/archive/2006/09/25/28.aspx)
Why you shouldn't use a self generated SSL certificate (http://blog.sembee.co.uk/archive/2006/03/05/9.aspx)
Why you shouldn't put Exchange 2003 in to a DMZ (http://blog.sembee.co.uk/archive/2006/02/23/7.aspx)

In this post I am going to outline why you shouldn't use PST files.

Anyone who has worked with Exchange or Outlook for more than 10 minutes will know about PST files. However despite their numerous flaws, they continue to be in widespread use. Where possible you should ban their use, particularly for archiving purposes.

The main arguments against using PST files are:

Data Loss When They Get Too Large

With Outlook 2002 and older, PST files can go to a maximum of 2gb, but in an annoying flaw, the file will allow you to continue to add data past the 2gb limit. You only get problems when you try to open the file again. Microsoft do have a tool that will allow you to open a file that has gone over the limit, but it simply chops off all data over 2gb - therefore resulting in data loss.

With Outlook 2003 and higher a new format of PST file is used (which is not backwards compatible) which allows PST files to go to 20gb. You cannot convert the old version to the new one. If you have create the wrong type then you will need to create it again and move the content across.

PST files are very fragile things, particularly the larger they get. Many people will suggest a new PST file at 1gb or less to protect the data.

Backup of the Files is Awkward

Microsoft do not support accessing PST files over a network. (http://support.microsoft.com/default.aspx?kbid=297019 and
http://blogs.technet.com/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx ).

That basically means they are impossible to backup. You cannot store them locally and backup over a network, and you cannot store them on a network share and access them over the network. Considering how fragile they are this is asking for problems.

Single Point of Failure / Risk of Corruption without Knowing

It is perfectly possible to have a corrupt PST file and not know about it for weeks or months. It is perfectly possible to continue to access and have open a PST file and not know that some of the data has become inaccessible.
Furthermore due to the fact that they are not supported being accessed over a network, that means keeping copies of them is not really practical. You cannot store them in "Read Only" format or access directly from a CD as the file will not open. Outlook needs write access to open the file. That would mean copying the file off the read only source, changing the tag on the file and then opening it. That could cause corruption in the file.

File Bloat

Due to the way that PST files store their data, they will actually use more space than the same data in Exchange - up to three times, and that is not taking in to account the loss of single instance storage.
100mb of email can be as much as 300mb in a PST file.
If ten users were sent a 2mb file in Exchange, then it uses 2mb of space in the store. Extract to PST files that same file would use up to 60mb as each user has their own copy in three different formats.

PST Files are not an Archiving Solution

The above should be enough to know that they are not an archiving solution. If you value your data do not store it in a PST file.
If you need to keep content for regulatory reasons, then a PST file will fail on many counts, such as allowing the user to modify the item after it has been received.

Are there any reasons to use PST Files?

If you aren't connected to Exchange, then you have no option but to use PST files.

With migrations, in some scenarios they are the only option, because they are domain independent. A PST file from one domain can have its contents imported in to another domain. However the same issues with the files remain, so when using them for this type of migration caution must be taken to ensure the data remains intact. 

Conclusion

Hopefully the above will give you some idea why PST files should not be used where there is any value to the data.

A while ago I wrote a blog posting about creating a custom MMC which contained the Exchange 2007 Management Console, public folders, queue viewer and ADUC. This made them easier to find instead of going through the Toolbox in EMC. (http://blog.sembee.co.uk/archive/2007/11/06/60.aspx)

However you can create shortcuts for each of the icons in the toolbox and put them in the start menu to allow direct access.
The paths to the toolbox items are in the registry in the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox

The icons, for when you create the shortcuts, can be found in this file:

C:\Program Files\Microsoft\Exchange Server\bin\Microsoft.Exchange.Management.NativeResources.dll

Create a new shortcut in the usual way, and paste the path exactly as shown. If you have installed Exchange application in a different location then you may have to adjust the path to match your environment.

Once the shortcut has been created, right click on it and choose Properties. Then choose change icon and select the icon that you want to use.

These shortcuts work on both Windows 2003 and Windows 2008 and also work with SBS 2008.

Full List of Shortcuts

Here is the full list of the toolbox items, including their paths.

• Best Practises Analyzer
  "C:\Program Files\Microsoft\Exchange Server\bin\ExBPA.exe"
• Exchange Performance Monitor
  mmc "C:\Program Files\Microsoft\Exchange Server\bin\ExchPrf.msc"
• Exchange Troubleshooting Assistant
  "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe"
• Database Recovery Management
  "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchDatabaseRecoveryManagement
  (Icon available simply by pressing "Change icon")
• Mail Flow Troubleshooter
  "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchMailflowTroubleshooter
  (Icon available simply by pressing "Change icon")
• Database Troubleshooter
  "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchDatabaseTroubleshooter
  (Icon available simply by pressing "Change icon")
• Message Tracking
  "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchMessageTracking
  (Icon available simply by pressing "Change icon")
• Performance Troubleshooter
  "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchPerformanceTroubleshooter
  (Icon available simply by pressing "Change icon")
• Public Folder Management Console
  mmc "C:\Program Files\Microsoft\Exchange Server\bin\Public Folder Management Console.msc"
• Routing Log Viewer
  "C:\Program Files\Microsoft\Exchange Server\bin\RoutingView.exe"
• Queue Viewer
  mmc "C:\Program Files\Microsoft\Exchange Server\bin\Exchange Queue Viewer.msc"
  (Uses the same icon as the Routing Log Viewer, so use change icon and browse to the Routing Log Viewer executable location.)
• Exchange Details Templates Editor
  mmc "C:\Program Files\Microsoft\Exchange Server\bin\Details Templates Editor.msc"

Update March 17th 2009.
I have removed the download of the tools shortcut because of the prompt you get from Windows when trying to run files downloaded from the internet - each time you start the shortcut. You should create your own shortcuts instead.  

One of the most common questions on forums is why does a user get a NDR (Non Delivery Report) report similar to the one below when they send an appointment to another person. The NDR will reference a user who is no longer part of the company and does not have an account on the system any longer.

Your message did not reach some or all of the intended recipients.
Subject: Sales Meeting
Sent: 8/22/2008 8:54 AM

The following recipient(s) could not be reached:
Another User on 8/22/2008 8:54 AM
The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address.
<mail.example.net #5.1.1>

This is caused by delegates.
The user referenced in the NDR was a delegate on the recipient of the appointment.

However what you may find is that when you look at Delegates through Outlook, the user is not listed.
This is because the delegate system can get "stuck" and the information in Outlook and on the server are not in synchronisation.

To reset it, simply follow the procedure below.

1. Remove any delegates that are currently listed for the user.
2. Add a new delegate to the list. IMPORTANT - this new delegate must not have been a delegate to the user before. I will usually create a temporary mail enabled account for this process and then delete afterwards.
3. Wait at least 30 minutes for this change to be propagated to the server correctly.
4. Remove the new delegate from the list.
5. Wait at least 30 minutes again.
6. Add the preferred delegates back in to the list.

This works by replacing the complete list of delegates on the account.

If this still doesn't work then you will have to scan the domain using adsiedit.msc for references to the former user on the user's settings. I have only ever had to do that once, when Outlook wouldn't open the delegates tab. Otherwise the procedure outlined above has always worked for me.

There have been a number of posts on forums about the database limits in various versions of Exchange. This post is a quick summary.

The limits shown also apply to Small Business Server, which has Standard edition of the relevant version installed.

Exchange 2000 Standard Edition: 16gb *
Exchange 2000 Enterprise Edition: Unlimited **

Exchange 2003 Standard Edition RTM and SP1: 16gb *
Exchange 2003 Standard Edition SP2: 18gb soft limit, 75gb hard limit ***
Exchange 2003 Enterprise Edition: Unlimited **

Exchange 2007 Standard Edition: 50gb soft limit, unlimited hard limit ***
Exchange 2007 Enterprise Edition: Unlimited **

* Exchange 2000 and 2003 Standard edition SP1 or older, can both be increased to 17gb as a temporary measure to allow the store to be remounted to remove content.

** The actual maximum possible size of the Exchange database is 8TB, effectively unlimited.

*** Exchange 2003 SP2 and Exchange 2007 have soft limits. This is a setting in the registry that limits the database to the size shown. It can be increased as required.
The idea is to stop run away store growth. Should something happen within the Exchange setup that causes rapid store growth, it will hit this limit and be dismounted.

With this introduction of a soft limit, the way that the database limit is enforced was changed.
With Exchange 2000 and 2003 prior to SP2 the database limit was the physical size of the store. The amount of white space in the store was not taken in to account. This meant that once you hit the limit you needed to do an offline defrag of the database to get it below 16gb, even after you had removed content.

With Exchange 2003 SP2 and later, this behaviour has been changed. The limit is now the physical size of the store, minus the amount of white space. Therefore if you hit the physical limit of 75gb on Exchange 2003 SP2 then an offline defrag is not going to help. Users need to actually remove content to create white space in the store.
Furthermore the database size is not checked in real time. It is checked once a day, by default at 5am (this can be changed via a registry modification). Therefore if the store dismounts because the limit has been breached, you can simply restart the service and the store will mount again.

However in my experience, once you hit the limits, even removing the content will only be a temporary solution. Either an investment needs to be made in an archiving solution that actually removes the content from the store, or an upgrade to Exchange 2003 Enterprise edition or Exchange 2007 Standard needs to be carried out.

Relevant Links at microsoft.com

Exchange 2003 Limit Changes: http://technet.microsoft.com/en-us/library/aa998066.aspx
Exchange 2007 Limit Changes: http://technet.microsoft.com/en-us/library/bb232092.aspx

Increase the limit of the Exchange 2000 database to 17gb: http://support.microsoft.com/kb/813051