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

http://technet.microsoft.com/en-us/library/aa998834.aspx

This topic explains how to use the Exchange Management Shell to add permissions for users of client programs (such as Microsoft Outlook) to access and modify public folder content. When adding these permissions, you can either use predefined permission roles (which consist of specific access rights) or you can customize permissions by manually applying the available access rights. To specify the permissions for the client user, you can use the Add-PublicFolderClientPermission cmdlet or the AddUsersToPFRecursive.ps1 user management script.

Procedure:
To use the Exchange Management Shell to specify client access rights to a public folder by using the Add-PublicFolderClientPermission cmdlet

To add Publishing Editor permissions for the user Kim to access the public folder named West Coast, run the following command:
Add-PublicFolderClientPermission -Identity “\Marketing\West Coast” -AccessRights PublishingEditor -User Kim

For detailed syntax and parameter information, see Add-PublicFolderClientPermission.
To use the Exchange Management Shell to specify client access rights to a public folder by using the AddUsersToPFRecursive.ps1 management script:

To add Reviewer permissions for the user David to access the top-level public folder named Sales and all of the public folders contained within the Sales tree, run the following command:
AddUsersToPFRecursive.ps1 -TopPublicFolder “\Sales” -User “David” -Permission Reviewer

In most pre-Exchange 2007 organizations that were using OWA, a third-party cert for the public FQDN of your mail server was all you needed.  In Exchange 2007, things changed a bit and certificates play a much larger role in the organization.  One of the lingering issues I’ve seen was a certificate error internally saying that the certificate name did not match the name of the server.  This was because the certificate was a third-party issued cert using the public FQDN of the server and not the internal hostname of the server.  To avoid running into this issue any longer, I followed another article I found online and simply created a new forward lookup zone in the internal DNS for the public domain name of our organization (i.e. kazmarek.com).  In that forward lookup zone I created the host (A) record for the mail server and pointed it to the internal IP.  Next, following the article (see link below) I changed the links in Exchange 2007 so that they would reference the public FQDN even when working internally.  What this does is effectively use the same public FQDN for all transactions with the Exchange 2007 server so it will match your existing third-party cert.

http://forums.msexchange.org/m_1800444783/mpage_1/key_/tm.htm#1800444783
(Search down to the section that reads: “Next we need to change the URLs used autodiscover”)