Exchange Server Forums

Cert principal name and Outlookanywhere Failed Logins

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [Microsoft Exchange 2010] >> Migration >> Cert principal name and Outlookanywhere Failed Logins

Page: [1]

Message

<< Older Topic Newer Topic >>

Cert principal name and Outlookanywhere Failed Logins - 24.Aug.2012 8:46:18 PM

wavegeek

Posts: 35
Joined: 25.Sep.2008
Status: offline

We have just upgraded our Exchange 2007 environment to Exchange 2010 and are running in a hybrid mode right now. We have domain joined computers running Outlook 2007 and Outlook 2010. We also have non-domain joined clients running a mix of Outlook clients. We host smtp domains for these non-domain joined clients in our Exchange Environment and they use OutlookAnywhere. We have a SAN certificate for our 2007 CAS with the certificate principal name set to the FQDN of the 2007 CAS. Before the upgrade to Exchange 2010, when OutlookAnywhere users connected to the Exchange 2007 CAS with the Microsoft Proxy settings, the �Only connect to proxy servers that have this principal name in their certificate� was set to msstd: casservername.domain.com. This is the certificate principal name set in the SAN certificate on the 2007 CAS. After we introduced the Exchange 2010, we installed a new SAN cert on that server with autodiscover.domain.com, legacy.domain.com, casarray1.domain.com and webmail1.domain.com. On the Exchange 2010 CAS, we then set the certificate principal name to webmail1.domain.com. When some( but not all)OutlookAnywhere users tried to connect after this certificate principal name was instated, they kept getting prompted for a password and could not login. When I viewed their profile and then proxy settings, the users had msstd:webmail1.domain.com in the �Only connect to proxy servers that have this principal name in their certificate.� This is correct because I set this cert principal name on the Exchange 2010 CAS. However, a handful of users could not login, but many could. I was forced to set the principal name on the Exchange 2010 CAS back to casservername.domain.com(original cert principal name before 2010 upgrade) and users had this in their msstd: text box and users could reconnect again. A few users still could not connect and still had the webmail.domain.com msstd entry and I had to uncheck it manually so they could login.

I have no idea why some users could not use the newly added certificate principal name resulting in preventing logins and why that certificate principal name that was added on the Exchange 2010 CAS would affect the users connecting to the Exchange 2007 CAS. At this point, I don�t know what to do. Any opinions would be appreciated.

Alex