MSSTD: Keeps removing itself from the proxy FQDN in Outlook

We are on Exchange 2007 and Outlook 2007. Starting about two weeks ago, some Outlook users started getting prompted for their username and password, but Outlook would not accept their credentials. We discovered the cause was that the prefix "MSSTD:" in the proxy FQDN in the Outlook Anywhere settings was missing. Putting it back in fixes it. The problem is, with some people (including me) it is disappearing repeatedly. What could be causing that? Our SSL certificates haven't been changed recently.

Thanks,

Richard
adramisAsked:
Who is Participating?
 
MesthaConnect With a Mentor Commented:
That is autodiscover doing that. You haven't got one of the settings correct.

First - I presume you have checked the value of the Outlook Anywhere URL in the management console to ensure it isn't blank?

get-outlookanywhere will also show you what the URL is in the entry "externalhostname". It should be just the host name, no http or / anything.

The next thing it could be is OutlookProvider

Do

get-outlookprovider

The value for CertPrincipleName should be blank in most installations.

If you have a single name SSL certificate then it needs to be set. If you are using a SAN/UC certificate then it should not.

Set-OutlookProvider expr -CertPrincipalName:"msstd:mail.example.net"

Don't set it to "see if it helps" if you don't need to, because it can cause problems if set incorrectly. The vast majority of installations do NOT need that value set.

Simon.
0
 
adramisAuthor Commented:
Mestha,

We do have a UC certificate, and a get-outlookprovider does show our domain (minus the "msstd:") under EXCH and EXPR. So, following you suggestion I have issued:

 Set-OutlookProvider expr -CertPrincipalName:""

to remove the entry. I will wait a bit and see if this helps.

Should I keep the CertPrincipalName for the EXCH entry?

Many thanks,

Richard
0
 
MesthaCommented:
That may not work.
You might have to use $null instead.

After running the command, run get-outlookprovider again to see if it has been cleared.

If you have a UC certificate then I am not sure why the value was set in the first place.

Simon.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
adramisAuthor Commented:
It was cleared, but for good measure I re-issued the command with the $null instead. It reported

"The command completed successfully but no settings of 'EXPR' have been modified"

So I think the double quotes probably work too.

We initially started out Exchange 2007 with a single name certificate, then a consultant helped us switch to a UC cert. I'm ignorant to these details, but am guessing the value have been left in from when we had a single name cert?
0
 
adramisAuthor Commented:
Mestha,

I'm hopeful that yours is the solution. The original problem has been sporadic, and did not affect everyone on the outside. Is this a "wait and see" solution, or is there a way to verify now that this has solved the problem?
0
 
MesthaCommented:
If you have a single name certificate then it would be a setting that was required and was missed when you made the change. Although it wasn't valid for a single name certificate either, which is also somewhat of a puzzle if it was working.

Simon.
0
 
MesthaCommented:
You could run an autodiscover test to see if things are working correctly.
In Outlook 2007, hold down CTRL while right clicking on the Outlook icon in the system tray and choose test email autoconfiguration.

If the system is Internet facing you could also run a test on the Microsoft test site:
https://testexchangeconnectivity.com/

Simon.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.