Winmail.dat Received by Non-Exchange Mail Server Without Attachment Included from Exchange 2007 Server

Situation: Exchange 2007 has a contact (not a mailbox) within the GAL that end-user use 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.

Exchange 2007 Certificate Issues – Avoid them the easy way.

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”)

E2K3 Public folder management – SSL certificate server name is incorrect error

Credit: http://mostlyexchange.blogspot.com/2006/11/e2k3-public-folder-management-ssl.html

I ran in to a problem where I was trying to remove a public folder store from a front-end server. The SSL certificate on the front-end server is wrong (wrong FQDN/CN, unknown CA, and it is expired). I could not manage the public folder hierarchy using Exchange System Manager.

Depending on what I was trying to do, I got this error:

The SSL certificate server name is incorrect.
ID no: c103b404 Exchange System Manager

I also saw this error:
The token supplied to the function is invalid
ID no 80090308

Lots of newsgroup and web discussion forms pointed to this KB article indicating that the problem might be related to SSL being required on the /ExAdmin virtual directory. “You receive an SSL Certificate error message when you view public folders in Exchange System Manager” http://support.microsoft.com/kb/324345 I checked that and it was NOT the case.

Finally found some instructions in a newsgroup that worked. This requires ADSIEDIT and a little bit of Exchange configuration editing.
Run ADSIEDIT  ( DOWNLOAD HERE: http://www.computerperformance.co.uk/w2k3/utilities/adsi_edit.htm )

Navigate to the following object: CN=Configuration, then CN=Services, CN=Microsoft Exchange, CN=, CN=Administrative Groups, CN=First Administrative Group, CN=Servers, CN=Protocols, CN=HTTP, CN=1, CN=Exadmin
Display the properties of the CN=Exadmin object
Locate the msExchSecureBindings attribute, highlight it and click Edit button
If it has a value of :443:, select that value in the Values list, click Remove.
Click OK twice and then close ADSIEDIT
Give this a few minutes to replicate through Active Directory and try it again!

You do not have permission to send to this recipient. For assistance, contact your system administrator.

From: http://blogs.technet.com/sbs/archive/2006/06/30/439685.aspx

When you try to send an e-mail message in Microsoft Exchange 2000 Server or in Microsoft Exchange Server 2003, you cannot send the e-mail message. Additionally, you may receive one of the following error messages or one of the following Non Delivery Reports (NDRs):

• Access denied 

• You do not have sufficient permission to perform this operation on this object. See the folder contact or your system administrator. 

• Unlisted Message Error 

• MAPI_E_NO_ACCESS -2147024891 

• Failed to submit mail message for user USERNAME (HRESULT:-2147024891) Pausing user USERNAME. (Security error – Cannot access the users mailbox.)

NDRs

• You do not have permission to send to this recipient. For assistance, contact your system administrator. 

• The message could not be sent using your mailbox. You do not have the permission to send the message on behalf of the specified user. 

This issue is known to affect the following third-party products:

• Research In Motion (RIM) Blackberry Enterprise Server (BES) 

• Good Technology GoodLink Wireless Messaging 

 

CAUSE

This issue may occur when one of the following conditions is true:

•     You do not have permissions to send e-mail messages as the mailbox owner in the account that you are using to send the e-mail message.

•     You are running Microsoft Exchange 2000 Server Service Pack 3 (SP3) with a Store.exe file version that is equal to or later than version 6619.4. Version 6619.4 was first made available in the following Microsoft Knowledge Base article:

915358 A hotfix is available to change the behavior of the Full Mailbox Access permission in Exchange 2000 Server

•     You are running Microsoft Exchange Server 2003 Service Pack 1 (SP1) with a Store.exe file version that is equal to or later than version 7233.51. Version 7233.51 was first made available in the following Microsoft Knowledge Base article:

895949 “Send As” permission behavior change in Exchange 2003

Note that this fix is not included with Microsoft Exchange 2003 Service Pack 2 (SP2). If you have installed the Exchange Server 2003 SP1 version of this hotfix, you must install the Service Pack 2 version after you upgrade to Service Pack 2.

•     You are running Exchange Server 2003 SP2 with a Store.exe file version that is equal to or later than version 7650.23. Version 7650.23 was first made available in the following Microsoft Knowledge Base article:

895949 “Send As” permission behavior change in Exchange 2003

Note This change was not included in Exchange 2000 Server SP3, in Exchange Server 2003 SP1, or in Exchange Server 2003 SP2. The change was implemented after release of all of these service packs. However, the change is supported in each of them. The change will be included in future service packs for these products.

 

If you install Exchange Server 2003 SP2, you must install the additional update to retain the new behavior. You must do this even if you already installed the version of the update for Exchange Server 2003 SP1.

 

RESOLUTION

 

Grant the Blackberry or other application’s service account the Send As permission on every user in a container or domain.

To grant Send As for the service account on a single user account, follow these steps:

1. Start the Active Directory Users and Computers management console.

2. On the View menu, make sure that the Advanced Features option is selected. If this option is not selected, the Security page will not be visible for domain and container objects.

3. View the properties of the user account and click the Security tab.

4. The service account (BESAdmin, for instance) is not listed.

5. Add the service account (BESAdmin, for instance). It will default to having Read permissions, but not Send As.

6. Note: This step is optional. The only permission the service account needs is Send As, so you can remove the Read permissions if you wish.  To do so, uncheck the following checkboxes in the Allow column for the service account (BESAdmin, for instance):

Read

Read Account Restrictions

Read General Information

Read Group Membership

Read Logon Information

Read Personal Information

Read Phone and Mail Options

Read Public Information

Read Remote Access Information

Read Web Information

 

7. With the service account (BESAdmin, for instance) still selected, check the following box in the Allow column:

Send As

8. Click OK until you have exited and saved all changes. 

9. Restart the Microsoft Exchange Information Store service.

Configure POP3 in Exchange 2007

These are pre-SP1 instructions.  POP3 is supported in Exchange 2007 but not turned on by default.  To turn it on (from the management shell):

1) Enable the service:      Set-Service msexchangepop3 -StartupType automatic
2) Start the service:         Start-Service msexchangepop3
3) Enable POP3 for mailboxes:     Set-CASMailbox -identity mailboxname -PopEnabled $true
4) OPTIONAL To enable plain-text authentication:     Set-PopSettings -LoginType PlainTextLogin
5) If you did number 4 then restart the service: restart-service msexchangepop3

Exchange Server 2003 mailbox store does not mount when the mailbox store database reaches the 16-GB limit

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

Routing Between Exchange 2007 and Exchange 2003

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

Exchange 2007 Certificate Errors

I received several certificate errors when attempting to connect Outlook to Exchange 2007.  This is because Outlook 2007 and Exchange 2007 encrypt all communications between themselves.  The solution was to create a new certificate (using Exchange PowerShell) for the intranet.  The relevent Microsoft Article can be found here:

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

**This article says to use the same cert for IIS however, to use a third party cert (i.e. from Thawte) don’t include IIS when assigning the certficate to services.  If you do (as I originally did) use the following command:

Get-ExchangeCertificate -DomainName “<Exchange-Server-Name>” 

to get the thumbprint of the third party certificate and then use the command:

Enable-ExchangeCertificate -thumbprint <certificate-thumbprint> -services “IIS,SMTP”

to assign it to IIS and SMTP (see below).

I was then noticing some issues with Outlook Anywhere and found the following in the event log:

Product:
Exchange

ID:
12014

Source:
MSExchangeTransport

Version:
8.0

Symbolic Name:
CannotLoadSTARTTLSCertificateFromStore

Message:
Microsoft Exchange couldn’t find a certificate that contains the domain name %1 in the personal store on the local computer. Therefore, it is unable support the STARTTLS SMTP verb for the connector %2 with a FQDN parameter of %1 (if connector’s FQDN is not specified, the machine’s FQDN is used). Verify that connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that connector FQDN. If this certificate exists, run Enable-ExchangeCertificate –services SMTP to ensure transport service has access to its key.

Explanation

This Warning event indicates that there is a problem loading a certificate to be used for STARTTLS purposes. Generally, this problem occurs if one or both of the following conditions is true:

• The fully qualified domain name (FQDN) that is specified in the Warning event has been defined on a Receive connector or Send connector on a Microsoft Exchange Server 2007 transport server, and no certificate is installed on the same computer that contains the FQDN in the Subject or Subject Alternative Name fields.
• A third-party or custom certificate has been installed on the server and it contains a matching FQDN. However, the certificate is not enabled for the SMTP service.

To fix this, I simply ran the command referenced above (Enable-ExchangeCertificate…) to assign the Thawte cert to the SMTP service.

Migrated Mailbox from Exchange 2003 to Exchange 2007 Prevents User from Logon to Outlook Web Access 2007 (OWA) Post Mailbox Move.

Link to full PDF
“If your Exchange 2007 Outlook Web Access (OWA) is failing for a user after the mailbox is
migrated from Exchange 2003 to Exchange 2007, the user account should be checked on the
Security tab under Advanced to see if it has “Allow inheritable permissions from the parent to
propagate to this object and all child objects.”

So how does this get turned off? Well, if the account is an administrative account or was ever an
administrative account previously, it will be turned off automatically. Reference the following:”

XADM: Do Not Assign Mailboxes to Administrative Accounts
http://support.microsoft.com/kb/328753

From Article ID: 328753
“To help guard against such security issues, the Administrator account and accounts that are
members of these security groups are not permitted to inherit permissions. On the Security tab of
the group or account’s properties page, you can see that the Allow inheritable permissions from
parent to propagate to this object check box is not selected. Moreover, if you click to select this
check box, a Microsoft Windows 2000 system task soon clears it automatically. Clearing the
check box is a function of Windows 2000 intended to prevent hackers from playing with security
and inappropriately increasing their permissions to the level of administrator.”
While the article applies to Windows 2000, a similar thing occurs in Windows 2003.

-Credit to Forrest McDuffie of Pointbridge Consulting

How to tell if you have Exchange 2003 Enterprise or Standard

1) Application Log – Use the event viewer on the Exchange server and analyze the Application Log.  If event id 1216 is reported when the Information Store comes online then you have Standard.  If 1217 is reported then you have enterprise.

2) System Manager – In Exchange System Manager, tree down to the “Servers” folder  and click the folder itself so your servers appear in the right pane.  This view should show 2 columns including an “Edition” column.  This was originally found here where this a screenshot.