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.

I recently came across a client’s backup that was completing successfully daily but not flushing the transaction logs for Exchange as it should.  In the job properties of Backup Exec, the Exchange section declares that it will perform a full backup and flush the comitted logs but it simply never happens.

After some research, Veritas article 280659 had the answer…and it was a simple one.  In the job properties, review the options under Advanced Open File and make sure the option “Process Logical Volumes for backup one at a time” is not checked.   As its explained in the article, if this is unchecked, Backup Exec will use a different open file option (VSS) for the Exchange logs to allow it to flush them afterwards. 

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/

This microsoft article details the various Exchange Server versions, including service packs.

http://support.microsoft.com/kb/158530

Some recent ones:

Microsoft Exchange Server  2003                       6.5.6944                             October 2003
Microsoft Exchange Server  2003 SP1                 6.5.7226                             May 2004
Microsoft Exchange Server  2003 SP2                 6.5.7638                             October 2005

Microsoft Exchange Server  2007                       8.0.685.24 or 8.0.685.25    December 2006
Microsoft Exchange Server  2007 SP1                 8.1.0240.006                      November 2007

I came across a situation where an organization had been setup to use RPC/HTTPs “Outlook Anywhere” for some time and all the Outlook 2003 clients seemed to work fine. One user had Outlook 2007 and was unable to connect using this method. In the LAN and through OWA everything worked fine. I tried tons of different solutions online but in the end, the problem was with the configuration in Exchange. I looked over the suggested configuration here:

http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

and I discovered that the RPC ports hadn’t been configured as the article suggests. I used the recommended “RPCnofrontend” tool: http://www.petri.co.il/software/rpcnofrontend.zip and everything worked fine after that.