You may have trouble sending mail to certain domains while using Exchange Server 2007 on Windows Server 2008. The Queue Viewer displays the following status error for the domain in question:

“451 4.4.0 primary target IP address responded with “421.4.4.2 unable to connect.”attempted failover to alternate host, but that did not succeed.Either there are no alternate hosts, or delivery failed to all alternate hosts.”

This problem occurs because routers do not support the TCP autotuning settings in Windows Server 2008.

To disable autotuning, follow these steps:

Run CMD as Administrator

At the command prompt, type the following command, and then press ENTER:

netsh interface tcp set global autotuninglevel=disabled

This command disables the Receive Window Auto-Tuning feature.

Exit the Command Prompt window.

Restart the computer.

In the situation I came across, Outlook 2007 clients were constantly prompting for a password eventhough the users were on the LAN, members of the domain, and logged in to the PC with domain credentials.  While I found several potential causes, the solution ended up being an SSL setting in IIS on the mail server. 

The solution was to allow client certificates on the virtual directory for Exchange Autodiscover.  It turns out the clients were attempting to use the Autodiscover service with Exchange 2007 to detect settings and the website wasn’t accepting their client certificate.  The client certificates are apparently used for encryption between the client and the server.  Disabling the checkbox to enable that type of communication may also have been a solution, but this is a better one because it maintains the security of an encrypted channel.  Here are the instructions:

1. Using IIS6 - Click Here
2. Using IIS7 - Open the IIS manager.  Expand the Sites group and expand down to the Autodiscover virtual directory.  Select this virtual directory then selec “SSL Settings” from the center pane.  In the settings window, select “Accept Client Certificates”.

In addition, the authentication settings on this virtual directory can also cause this to happen if not configured correctly.  Just make sure that Integrated Windows Authentication is checked.

After installing the latest version of Trend Micro Scanmail 8.0 on an SBS 2008 server, the Exchange Transport service kept stopping and reporting the following errors in the Application event log:

Event ID: 16023 Source: MSExchangeTransportMicrosoft Exchange couldn’t start transport agents. The Microsoft Exchange Transport service will be stopped. Exception details: Failed to create type ‘TrendMicro.SMEX.hookE12TransportAgent.hookE12RoutingAgentFactory’ from assembly ‘D:\Program Files\Trend Micro\Smex\hookE12TransportAgent.dll’ due to error ‘Invalid agent assembly path.’ …

Event ID: 1052 Source: MSExchange Extensibility

The creation of an agent factory for the agent ‘ScanMail Routing Agent’ failed with error ‘Failed to create type ‘TrendMicro.SMEX.hookE12TransportAgent.hookE12RoutingAgentFactory’ from assembly ‘D:\Program Files\Trend Micro\Smex\hookE12TransportAgent.dll’ due to error ‘Invalid agent assembly path.’.’. Verify that the corresponding transport agent assembly and dependencies with the correct version are installed.

The issues turned out to be a permission issue on the SMEX program file directory.  Exchange uses the Network Service account for the Transport Service credentials but this account didnt get security permissions to the Trend Micro SMEX program folder after install.  Adding the appropriate read permissions did the trick.

With the newer versions of Backup Exec and Exchange 2007, Granular Recovery Technology (GRT), a requirement of the Microsoft Exchange Server MAPI Client and Collaboration Data Objects needs to be downloaded and installed on the Exchange/Media server. Microsoft has updated the Mapi and CDO to 1.2.1 to include Windows Server 2003 and Windows Server 2008. 64bit servers have no problem installing.

Link to download.

http://technet.microsoft.com/en-us/library/bb332342(EXCHG.80).aspx

Situation: Exchange 2007 has a contact (not a mailbox) within the GAL that end-user uses to email instead of using the actual non-exchange email address. The non-exchange (network solutions) user does not get attachment sent (Word, Excel, etc.), but does get a winmail.dat file attached.

Fix: Launch Exchange Management Console, goto Recipient Configuration/Mail Contact container, open up contact you’re having the issue with, on the ‘general’ tab change the ‘Use MAPI rich text format’ drop-down to ‘Never’ and test.

Microsoft Forefront Security for Exchange Server is the cause of this messsage:

The original contents of this file have been replaced with
this message because of its characteristics.
File name: ‘winmail.dat’
Virus name: ‘CorruptedCompressedFile’

====================

Quick fix:

Goto Forefront Server Security Administrator > Settings> General Options > Scanning
Goto checkbox name “Delete Corrupted Compressed File”
Uncheck the box and test

To find the product version in Exchange 2007, execute the following command in PowerShell:

Get-ExchangeServer | fl name,edition,admindisplayversion

Refer to the article below to find out how the build number corresponds to a product version:

http://blog.kazmarek.com/2008/07/04/exchange-server-version-and-build-numbers/

There is no specific SMTP service like you saw with Exchange 2003 and IIS. However, if you’re just trying to stop the listening port 25 for Inbound/Outbound mail, stop the ‘Microsoft Exchange Transport’ service.

These days many mailservers are requiring reverse DNS (rDNS) and SPF records to validate the sender from this domain.

How does SPF work:

SPF is easy to understand. The “Internet” uses DNS (Domain Name System) to resolve Domain Names (as an example www.msexchange.org) into IP addresses. DNS is also used to direct requests for different services like e-mail and Web Servers. For every Domain around the world an MX (Mail Exchanger) record must exist. An MX record tells the e-mail sender where the target server for receiving mail is located.

SPF is publishing “reverse MX” records in DNS which tells the mail sender which machines send mail from the domain.

The recipient of the e-mail can now check these records to ensure that e-mail is coming from a “trusted” sender from this domain.

These “reverse MX” records can be easily published in DNS. It takes only one line in DNS to fullfil all requirements.

Microsoft has come up with a good and easy wizard (webpage not downloadable tool) that asks a few questions and spits out the correct SPF.

How to add SPF file to Windows Server DNS - link

OpenSPF Website - link or old site