Exchange 2010 Messages Stuck in Retry status in "MapiDeliveryQueue"

In case your Exchange admin life wasn't difficult enough, you can always have this problem, manifested with the following symptoms:

- Mail delivery hung
- Messages stuck in local delivery "MapiDeliveryQueue" with a status of "Retry"

Classic tactics such as restarting the server or right-clicking the queue and selecting "Retry" have no effect.

The key here is that Exchange 2007 and later treat these messages differently than standard SMTP queues. In order to process these messages, they need to be re-submitted using the following Exchange cmdlet:

Retry-Queue -Filter {Status -eq "Retry"} -Server "exchangeserver" -resubmit $true

The default re-submit queue time is 12 hours. To modify this:

1. Using Notepad, edit the file: C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config.
2. Modify the following line in the section:

<add key="MaxIdleTimeBeforeResubmit" value="<hh:mm:ss>"/>

3. Save the file.
4. Open up the Exchange Command shell and run restart-service *rt

Outlook Anywhere and Wildcard Certificates in Exchange 2010

When migrating to a new Exchange 2010 environment, I decided to use a wildcard certificate instead of a UC certificate. It cost about twice as much, but seeing as how I have several other services that currently require SSL certificates, it seemed like a good investment.

When running through the Exchange Remote Connectivity Analyzer, I noticed that my configuration kept failing the Outlook Anywhere test with the following error:

Testing SSL mutual authentication with the RPC proxy server.
Verification of mutual authentication failed.
> Additional Details
>> The certificate common name *.domain.com doesn't validate against the mutual authentication that was provided: msstd:mail.domain.com

The solution was relatively easy. Log into your Exchange CAS server and run the following cmdlet from the Exchange Command Shell:

Set-OutlookProvider -Identity EXPR -CertPrincipalName *.domain.com

I've seen some documentation that replaced the CertPrincipalName value with msstd:*.domain.com, but I believe that is incorrect. The name on the actual SSL certificate is *.domain.com, not msstd:*.domain.com. For giggles, I did try using msstd:*.domain.com as the CertPrincipalName value, but it did not allow me to pass ExRCA.

Run the Get-OutlookProvider cmdlet to review your settings:

RunspaceId : 841d7d59-e89c-42b4-9c3c-9388d40dcd95
CertPrincipalName : *.domain.com
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : EXPR
DistinguishedName : CN=EXPR,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=A
pex Digital Solutions,CN=Microsoft Exchange,CN=Services,
CN=Configuration,DC=domain,DC=com
Identity : EXPR
Guid : d81b1280-1843-4808-812c-48375ed744e0
ObjectCategory : domain.com/Configuration/Schema/ms-Exch-Auto-Discove
r-Config
ObjectClass : {top, msExchAutoDiscoverConfig}
WhenChanged : 11/5/2010 11:53:39 AM
WhenCreated : 1/30/2009 9:23:30 PM
WhenChangedUTC : 11/5/2010 3:53:39 PM
WhenCreatedUTC : 1/31/2009 2:23:30 AM
OrganizationId :
OriginatingServer : mydc03.domain.com
IsValid : True

General Authentication Failed when using IMAP over SSL on Exchange 2010

Ran into an interesting certificate issue with Exchange 2010 and wildcard certificates.

I had installed a wildcard certificate for our domain on an Exchange 2010 server (just like I had previously for Exchange 2007) and enabled the IMAP service (Microsoft Exchange IMAP4 is the Exchange 2010 name of the service). However, when running the Enable-ExchangeCertificate cmdlet, I received an error enabling the wildcard certificate for IMAP services.

I eventually stumbled across this KB Article, Certificates that contain wildcard characters may not work correctly on an Exchange 2007 Service Pack 1-based server. When I ran the Get-ImapSettings cmdlet, I received the following output:

UnencryptedorTLSBindings SSLBindings LoginType X509CertificateName
------------------------ ----------- --------- -------------------
{:::143, 0.0.0.0:143} {:::993, 0.0.0.0:993} SecureLogin myservername

According to the KB, this is due to a problem with the way the cmdlet generates the X.509 certificate name. It can't interpret the wildcard character correctly, so it says that the FQDN of your server is just the NetBIOS name of your server. Oops. Exchange 2007 SP1 Roll-Up 4 is supposed to fix this behavior, but I experienced it on an Exchange 2010 server that was updated to current before deploying the certificate.

After I updated the X.509 Certificate name (using the command Set-ImapSettings -X509CertificateName "myserver.mydomain.com"), I restarted the IMAP service.

To make sure everything was working, I configured an Outlook profile with the IMAP settings of my test mailbox. When I clicked the "Test Connection" button, I was greeted with yet another error:

Log on to incoming mail server (IMAP): General authentication failed. None of the authentication methods supported by your IMAP server (if any) are supported on this computer.

The answer, was, in fact, in the output of the Get-ImapSettings cmdlet that I previously ran. Apparently, it was looking for a secure login method. However, in most SSL-enabled configurations, data is submitted in clear text through the SSL tunnel. To test my theory, I ran the command Set-ImapSettings -LoginType PlainTextlogin and restarted the IMAP service again. In my Outlook client, I clicked the "Test Connection" button again and all was right with the world.