Microsoft Exchange and Remote Desktop Services Specialists


Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Change of Company Name

As you may be aware, my consultancy company is Amset IT Solutions Ltd. If you hire me, then this who you pay your bills to. As from 1st April 2009, that company name is no more. I changed it to Sembee Ltd.

There are a number of reasons why I changed it, the main one being to more closely link the company to me in an attempt to increase business. I also wanted a shorter more general name for business purposes.

It will take some time for the change to be reflected in everything I do, for example the branding on is still amset, but points to the same place.

That was also the reason why the blog URL changed to, as I wanted to use for the company address.

Otherwise everything else remains the same.

Blackberry BES Application Pushing - HardwareID not found error

Blackberry - not a subject I usually touch on, but as I am using a BES variant with my Exchange system I thought I would post this little snippet.

Recently exchanged by very old 7230 Blackberry for a new Curve 8310. I found that my previously published applications of Google Maps and Google search were not appearing on the device.

A look through the event long on the server gave me this error:

Event Type: Warning
Event Source: BlackBerry Policy Service
Event Category: None
Event ID: 20000
Date:  29/03/2009
Time:  21:15:32
User:  N/A
Computer: BES-SERVER
Device info for hardwareID 0x8d000f03 could not be found.

No idea what that meant, and I couldn't find anything clear on Google either.
However looking through older posts on some forums from when the 8700 series was released, I was pointed to a file called device.xml, which can be found in this location: "C:\Program Files\Common Files\Research In Motion\AppLoader"

Apparently if your device doesn't appear in the list, then you will get the above error.

I am using Blackberry Professional Edition, which is currently on 4.1.4, whereas the current version of Blackberry Enterprise Server is 4.1.6 (or very close, at the time of writing). The device.xml file was quite out of date and the ID number in the error message did not appear in the file. I needed to update the file!

You can get an updated device.xml by installing the latest Desktop Software from Blackberry somewhere. (4.7 at the time of writing) I have seen references to the desktop software being installed on the server, but I already had it on my laptop for playing around with the device. It will be found in the same location on both the server and the workstation. I went from a file that was only 8kb in size to a 16kb file.

I simply copied the file from my laptop in to the same location on my Blackberry server re-ran the "loader /index" command and then restarted the Blackberry Policy service. The application pushed out to the device shortly afterwards.

Are you using the right feed address for this blog?

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 "" 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 then you will need to change it to the Feedburner feed to ensure that you continue to receive the feed from this blog: 

Exchange 2007 and SMTP Banner Tests

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 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 - - where is the host name that resolves to your Exchange server.

References and Further reading

Receive Connectors:
DNS Configuration for Exchange:

Did the Spam Originate Inside Your Network?

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:
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.


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! ( Professional
  • User-Agent: Thunderbird (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 ([]) by  host.domain.local ([]) 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.