SEMblog

This is a posting for anyone reading this blog using a feed reader.  

I am going to be making some changes to the blog in the next couple of weeks, and this could affect the RSS feed.

If your feed address is "feeds.sembee.co.uk/sembee" then you can stop reading now and go somewhere else, as that feed will not be affected.  

If you are using a feed that starts with the address of www.sembee.co.uk then you will need to change it to the Feedburner feed to ensure that you continue to receive the feed from this blog: http://feeds.sembee.co.uk/sembee 

When you are setting up your server for SMTP delivery, one of the key things that is looked at is how the server is setup with regards to DNS and how the server announces itself. The latter can be referred to as the SMTP banner or EHLO/HELO.

As such, a number of sites, such as dnsreport.com have popped up which will run tests against your server to ensure that its setup is correct. However with Exchange 2007 you will get inaccurate results.

What Are They Testing?

In short, what these sites do is connect to port 25 on your server and see how the server announces itself. However this is basically incoming email traffic, whereas what you are interested in is outbound email.

What has Changed?

With Exchange 2003 and older, the same SMTP banner was used for both incoming and outgoing email. With Exchange 2007 that has changed. The FQDN values are set separately on the Send and Receive Connectors.
Furthermore, the values you can set for the FQDN on the receive connector is limited in Exchange 2007 SP1 to either blank, the NETBIOS name or the Server's real FQDN. You cannot set them to anything else, such as your public FQDN. If you do try, you will get an error message.
Microsoft actually go as far as to say that you shouldn't change the value at all.

What can you do?

There is little that you can do. Online testing sites cannot test the outbound message appearance because that would mean you would have to initiate the traffic flow.
Simply ensure that  the FQDN set on the SEND Connector for port 25 traffic is set correctly - host.example.com - where host.example.com is the host name that resolves to your Exchange server.

References and Further reading

Receive Connectors: http://technet.microsoft.com/en-us/library/aa996395.aspx
DNS Configuration for Exchange: http://www.amset.info/exchange/dnsconfig.asp

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.