SSL Mismatch – Outlook Anywhere

UPDATE: Checked with Exchange 2010, and this also resolves the issue.

Today I was dealing with a customer who was receiving errors in Outlook for autodiscover each time they opened Outlook. This was all after they’d changed their domain name.

I’d run a script I use to alter all of the host names, to check that they were all correct and then spent considerable time hunting around Exchange for this incorrect setting, and eventually found it.

It’s in the OutlookAnywhere settings, rather than in all of the other URL’s my other script alters. Usually, this URL doesn’t change, and so I’d missed it, but as they’d changed their domain name, this also needed alteration.

So, if you get SSL mismatch errors, and you think you’ve changed all of the necessary URL’s, check this one:

get-outlookanywhere | select Identity, ExternalHostName

if the External Host Name is incorrect, then adjust it with this:

get-outlookanywhere | set-outlookanywhere -externalhostname ""

This certainly works with Exchange 2007, I’ve not yet checked it on Exchange 2010, but believe it’s the same cmdlets.

I’ll write up a full blog post this weekend with a list of all of the places that need to be changed, so that it’s all in one place.

Exchange Certificate Cleanup via PowerShell

A short post today, just to find all MS Exchange certificates which have expired, filtered by domain name, and remove them from your exchange server. This should work with Microsoft Exchange 2007 and 2010.

$Domain = read-host "Enter Domain Name to Search for (e.g. webmail.domain.tld)"

Get-ExchangeCertificate | where {$_.NotAfter -lt (get-date) -and $_.Subject -like "*$Domain*"} | Remove-ExchangeCertificate -confirm: $false

550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. “MapiExceptionNotAuthorized”

This morning I’ve been troubleshooting an Exchange public folder related issue that had me baffled for a little while.

Users could send e-mails to a public folder internally, but any external e-mails wouldn’t arrive in the folder. After running through message tracking I found the following error in the tracking logs:

550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: “MapiExceptionNotAuthorized:”…

Knowing that internal users could e-mail the public folder, and knowing that the e-mails were reaching the Exchange server meant that I had to be dealing with a permissions based issue. When I looked at the public folder’s MAPI permissions using Powershell (get-publicfolderclientpermission is the cmdlet for that one) I could see that the folder was set to “Anonymous: None”. This means that anonymous senders don’t have rights to create a new item in the public folder, and so the 550 5.2.0 message is logged.

To get around this issue, you need to add at least the “CreateItems” access right for the Anonymous user. You can do this within Outlook looking at the permissions, or, in PowerShell as follows:

add-publicfolderclientpermission -identity "\PathTo\PublicFolder" -accessright createitems

To check this afterwards you can perform the following script:

get-publicfolderclientpermission -identity "\PathTo\PublicFolder" | where {$_.User -match "Anonymous"} | fl

Exchange ActiveSync/Outlook Anywhere Connectivity Issues

Over the last several years I’ve come across all sorts of issues connecting mobile phones to Exchange servers for syncing purposes… These have ranged in fixes for Exchange 2003 and needing to create an exchange-oma virtual directory, with some registry key changes, to fixing security problems within AD to resolve the issues.

In the past 6 months or so, I’ve been using this site to test these configurations (it saves messing around with your phone, or Windows Phone simulators):

This is the Exchange Remote Connectivity Analyser, and it works miracles!

It’ll test Autodiscover for you… as well as then trying to sync (with the account details you provide) with your mailbox (change the password before and after!). It then gives detailed steps and error messages (as well as links pointing to the usual causes of the problem) which can be used to troubleshoot further.

Sometimes it’ll complain about public certificates (usually if there is an intermediate CA in the certificate path), but if this is the case, just tick the “Ignore SSL Errors” check box, and it’ll happily run the test and only give you a warning instead of an error.

This site has helped me so many times before, and is extremely useful for troubleshooting… I always make this my first port of call should I have any Outlook Anywhere/ActiveSync errors.

I hope you find it as useful as I do!

Problem connecting MS Outlook 2003 to MS Exchange 2010

I recently came across a problem after migrating a company from Exchange 2003 to Exchange 2010… none of the Outlook 2003 clients would connect to the server once their mailbox had been migrated. Other clients (MS Outlook 2007 and 2010) would work perfectly… so I knew this wasn’t necessarily a server-based problem…

After some digging around I came across this:

Outlook 2003 Exchange 2010 fix

This screenshot is from the advanced settings section of an Exchange connector in Outlook 2003. All that’s needed to be changed here, is to put a tick in the “Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server”. Once you’ve clicked OK, and saved the changes to the profile, Outlook works properly again.