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