Test e-mail autoconfiguration endless prompt for password and no Lync EWS configuration
I am trying to get an Exchange 2013 server to co-exist peacefully with Exchange 2007 and Lync 2013 and its been a few months of head bashing with little progress. I am currently having issues with Lync 2013 client prompting for credentials and not accepting them, nor locking out the AD account if intentionally putting them in incorrect more than 3 times (our AD lockout Policy). Lync 2013's configuration information shows that EWS Internal and EWS External URL are blank. This lead me to investigate the autodiscover service running on Exchange 2013.
Now I am in test mode, so on a spare computer I have a modified hosts file containing the new Exchange 2013 IP address for mail, autodiscover, webmail.
I can ping autodiscover.domain.com and I get the Exchange 2013 server's IP address. In Outlook if I right click on the tray icon and do a Test E-Mail AutoConfiguration, it constantly asks me for password, despite putting that password in correctly. If I cancel it just leaves me with "Unable to determine your settings!". I think this is the root cause as to why LYNC is not obtaining the Exchange information.
In Internet Explorer if I browse to https://autodiscover.domain.com/autodiscover/autodiscover.xml, I get the standard Outlook Web App screen. I can log in here but its OWA not the autodiscover file I was expecting.
On Exchange 2013 IIS, I checked the Default Web Site and there are no redirects. I also checked the Autodiscover directory and there are no redirects there either.
I am at a complete loss as to what to go.
The other oddity is that Autodiscover seems to work to initially create an Outlook Profile. In fact it kept BREAKING outlook (requiring endless password prompts). I would have to go into Outlook Anywhere proxy settings and change the authentication from Basic to NTLM. It would fix it, but next time you fire up Outlook it would change it back to Basic! So the InternalClientAuthenticati
Now I am in test mode, so on a spare computer I have a modified hosts file containing the new Exchange 2013 IP address for mail, autodiscover, webmail.
I can ping autodiscover.domain.com and I get the Exchange 2013 server's IP address. In Outlook if I right click on the tray icon and do a Test E-Mail AutoConfiguration, it constantly asks me for password, despite putting that password in correctly. If I cancel it just leaves me with "Unable to determine your settings!". I think this is the root cause as to why LYNC is not obtaining the Exchange information.
In Internet Explorer if I browse to https://autodiscover.domain.com/autodiscover/autodiscover.xml, I get the standard Outlook Web App screen. I can log in here but its OWA not the autodiscover file I was expecting.
On Exchange 2013 IIS, I checked the Default Web Site and there are no redirects. I also checked the Autodiscover directory and there are no redirects there either.
I am at a complete loss as to what to go.
The other oddity is that Autodiscover seems to work to initially create an Outlook Profile. In fact it kept BREAKING outlook (requiring endless password prompts). I would have to go into Outlook Anywhere proxy settings and change the authentication from Basic to NTLM. It would fix it, but next time you fire up Outlook it would change it back to Basic! So the InternalClientAuthenticati
ASKER
Ok from that website I get Connectivity Test Successful.
I thought it had something to do with the wildcard cert in the Exchange 2013 autodiscover, so I made all 3 outlook providers (EXCH, EXPR, WEB) cert principal names equal msstd:*.domain.com. On Exchange 2013 the command test-outlookwebservices shows all success. Also Outlooks Test e-mail autoconfiguration accepts the username and password and returns the proper URL's dependent on if the credentials used are for a 2007 or 2013 mailbox.
I am not sure why Lync cannot read the EWS Internal or External URL's when doing power shell commands they do show that they are populated. Am I do do some kind of configuration on the Lync front end server or do something in Topology builder or the Lync control panel to inform Lync of the new Exchange server?
I thought it had something to do with the wildcard cert in the Exchange 2013 autodiscover, so I made all 3 outlook providers (EXCH, EXPR, WEB) cert principal names equal msstd:*.domain.com. On Exchange 2013 the command test-outlookwebservices shows all success. Also Outlooks Test e-mail autoconfiguration accepts the username and password and returns the proper URL's dependent on if the credentials used are for a 2007 or 2013 mailbox.
I am not sure why Lync cannot read the EWS Internal or External URL's when doing power shell commands they do show that they are populated. Am I do do some kind of configuration on the Lync front end server or do something in Topology builder or the Lync control panel to inform Lync of the new Exchange server?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I had to use *.domain.com in order for Outlook Anywhere to work correctly. I found that answer at this blog: http://www.cgoosen.com/2010/11/outlook-anywhere-and-wildcard-certificates/
That was just for EXPR, but I did it for EXCH. What is WEB? Is that the one for autodiscover?
Do you think using a wildcard certificate is a bad idea? It's just we already have it and with all of the additional domain names it was the easy route. Do you think its worth spending the $600 or whatever it costs to buy a cert with the names on it, which in this case I think would be: webm.domain.com, mail.domain.com, autodiscover.domain.com, legacy.domain.com? My only concern is what if I miss a name, or do the cert wrong, I hope that it's not a $600 virtual paperweight.
That was just for EXPR, but I did it for EXCH. What is WEB? Is that the one for autodiscover?
Do you think using a wildcard certificate is a bad idea? It's just we already have it and with all of the additional domain names it was the easy route. Do you think its worth spending the $600 or whatever it costs to buy a cert with the names on it, which in this case I think would be: webm.domain.com, mail.domain.com, autodiscover.domain.com, legacy.domain.com? My only concern is what if I miss a name, or do the cert wrong, I hope that it's not a $600 virtual paperweight.
ASKER
Btw, Microsoft's remote connectivity analyzer for Outlook Autodiscover always errors out, but what's odd is if I do the test from right clicking on the Outlook icon, or create a new mail profile, it seems to work. Any idea why?
This is what Microsofts ExRCA says.
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml for user testuser@domain.com.
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
Additional Details
An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).
HTTP Response Headers:
Content-Length: 58
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate,NTLM,Basic realm="autodiscover.domain
request-id: 1c91241a-0240-4280-a71a-1e
X-Powered-By: ASP.NET,ARR/2.5,ASP.NET
X-DiagInfo: EMAIL
X-BEServer: EMAIL
Date: Mon, 03 Nov 2014 14:47:25 GMT
Elapsed Time: 620 ms.
This is what Microsofts ExRCA says.
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml for user testuser@domain.com.
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
Additional Details
An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).
HTTP Response Headers:
Content-Length: 58
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate,NTLM,Basic realm="autodiscover.domain
request-id: 1c91241a-0240-4280-a71a-1e
X-Powered-By: ASP.NET,ARR/2.5,ASP.NET
X-DiagInfo: EMAIL
X-BEServer: EMAIL
Date: Mon, 03 Nov 2014 14:47:25 GMT
Elapsed Time: 620 ms.
ASKER
Ok I followed your guide and instead of the wildcard cert that we already have, I purchased a UCC Cert with all the names I want on it:
webm.domain.com (for web mail)
mail.domain.com (internal)
email.domain.com (the Exchange 2013's actual hostname)
AutoDiscover.domain.com (autodiscover - strange that the 2013 cert request capitalized the A and the D, I hope this doesn't cause issues)
legacy.domain.com (for the 2007 server)
Its put on and no cert errors, so I temproarally changed the external DNS for webm to the new server, and that also changes autodiscover since that is a cname to webm, and still I get an error from Microsofts Outlook Autodiscover test.
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
Additional Details
Elapsed Time: 781 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml for user testuser@domain.com.
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
Additional Details
An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).
HTTP Response Headers:
Content-Length: 58
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate,NTLM,Basic realm="autodiscover.domain
request-id: 1350dacd-e0eb-4899-bd0a-cd
X-Powered-By: ASP.NET,ARR/2.5,ASP.NET
X-DiagInfo: EMAIL
X-BEServer: EMAIL
Date: Tue, 04 Nov 2014 12:51:56 GMT
Elapsed Time: 780 ms.
The Ceriticate portion of Microsofts test passes with just one warning that I guess only applies to unpatched versions of XP (which we do not have anymore):
The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
Elapsed Time: 6 ms.
webm.domain.com (for web mail)
mail.domain.com (internal)
email.domain.com (the Exchange 2013's actual hostname)
AutoDiscover.domain.com (autodiscover - strange that the 2013 cert request capitalized the A and the D, I hope this doesn't cause issues)
legacy.domain.com (for the 2007 server)
Its put on and no cert errors, so I temproarally changed the external DNS for webm to the new server, and that also changes autodiscover since that is a cname to webm, and still I get an error from Microsofts Outlook Autodiscover test.
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
Additional Details
Elapsed Time: 781 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml for user testuser@domain.com.
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
Additional Details
An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).
HTTP Response Headers:
Content-Length: 58
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate,NTLM,Basic realm="autodiscover.domain
request-id: 1350dacd-e0eb-4899-bd0a-cd
X-Powered-By: ASP.NET,ARR/2.5,ASP.NET
X-DiagInfo: EMAIL
X-BEServer: EMAIL
Date: Tue, 04 Nov 2014 12:51:56 GMT
Elapsed Time: 780 ms.
The Ceriticate portion of Microsofts test passes with just one warning that I guess only applies to unpatched versions of XP (which we do not have anymore):
The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
Elapsed Time: 6 ms.
ASKER
Ok That cert is installed but now Outlook is moaning about it not being trusted. Do I have to change the CertPrincipal Name for EXCH, EXPR and WEB? When I run Get-OutlookProvider it shows the Exchange 2007 server for EXCH and WEB. A server name is not listed for EXPR. If I need to change all 3, what is the syntax to only apply it to the Exchange 2013 server?
I don't want to make changes to the 2007 server and cause an outage.
I don't want to make changes to the 2007 server and cause an outage.
Hey IT,
Just to confirm. Are you seeing this error for Outlook for a user whose mailbox is still on the Exchange 2007 server?
I assume you have legacy.domain.com DNS records created internally and externally and pointed to the IP of the 2007 server? If so, what happens when you type https://legacy.domain.com/owa into the web browser? Any certificate errors then?
It almost seems like a intermediary cert or root cert is missing for GoDaddy. Because it seems like that error is indicating an error in the certificate path. For example, it doesn't like GoDaddy's root or intermediary certs.
Just to confirm. Are you seeing this error for Outlook for a user whose mailbox is still on the Exchange 2007 server?
I assume you have legacy.domain.com DNS records created internally and externally and pointed to the IP of the 2007 server? If so, what happens when you type https://legacy.domain.com/owa into the web browser? Any certificate errors then?
It almost seems like a intermediary cert or root cert is missing for GoDaddy. Because it seems like that error is indicating an error in the certificate path. For example, it doesn't like GoDaddy's root or intermediary certs.
ASKER
No, if I am on the Exchange 2007 server, and I use a machine outside the network with an altered hosts file for webm.domain.com and autodiscover.domain.com pointed to the outside IP of Exchange 2013, it proxies fine to legacy.domain.com which is the Exchange 2007 server.
Not really having a problem with Outlook Anywhere and Exchange 2007. But I tried to put a real cert on, instead of the wildcard cert that I had on both 2007 and 2013 servers.
The screen shot was from inside with an account who's mailbox is on 2013 server. Its a fully updated Windows 7 machine, so it should have all the latest trusted root certificates, especially from a big name like GoDaddy. Sure I could use Group Policy or scripting to auto enroll or import the root certs, but I don't think I should have to with a public cert like that.
If I type https://legacy.domain.com/owa it tries to redirect to webm.domain.com/owa and I get an http 400.
Not really having a problem with Outlook Anywhere and Exchange 2007. But I tried to put a real cert on, instead of the wildcard cert that I had on both 2007 and 2013 servers.
The screen shot was from inside with an account who's mailbox is on 2013 server. Its a fully updated Windows 7 machine, so it should have all the latest trusted root certificates, especially from a big name like GoDaddy. Sure I could use Group Policy or scripting to auto enroll or import the root certs, but I don't think I should have to with a public cert like that.
If I type https://legacy.domain.com/owa it tries to redirect to webm.domain.com/owa and I get an http 400.
ASKER
Ok I tested on another machine, Windows 8.1 updated and Outlook 2013, Lync 2013. Same issue. Though this time we did get EWS Internal and External URL's to populate in Lync, and Lync shows the meetings icon, so we did get somewhere by removing the wildcard certificate on Exchange 2013 for a UCC certificate.
Is if the user is on Exchange 2007 server, there is no issue.
If the user is on the Exchange 2013 server, you get constant password prompts that are never accepted, they do not lock out the account in AD either. You get the error message that the proxy certificate name is not trusted and in the Outlook Connection status you see 3 entries for proxy server webm.domain.com, the UUID of the server name, Connecting for the status, RPC/HTTP for the Protocol, and the type is Exchange Directory, and 2 Exchange Mail (One foreground, one cache). There is no 4th entry for the 2007 public folders anymore.
I'm at a loss and under pressure to get this done. Outlook 2010 in our Environment freezes a lot, especially when clicking send on an email, or drops connection an has to be killed and reopened. So we want to move off of this aging Exchange 2007 server.
Is if the user is on Exchange 2007 server, there is no issue.
If the user is on the Exchange 2013 server, you get constant password prompts that are never accepted, they do not lock out the account in AD either. You get the error message that the proxy certificate name is not trusted and in the Outlook Connection status you see 3 entries for proxy server webm.domain.com, the UUID of the server name, Connecting for the status, RPC/HTTP for the Protocol, and the type is Exchange Directory, and 2 Exchange Mail (One foreground, one cache). There is no 4th entry for the 2007 public folders anymore.
I'm at a loss and under pressure to get this done. Outlook 2010 in our Environment freezes a lot, especially when clicking send on an email, or drops connection an has to be killed and reopened. So we want to move off of this aging Exchange 2007 server.
ASKER
Ok if user is on Exchange 2013, outlook only gives that certificate error if internal. If external there is no issue and Outlook works normally. I believe because externally its going through IIS reverse proxy. That still has the wildcard certificate on it. I tried to put the GoDaddy cert on it, but it just never shows up under site bindings. I did put it in the local computer personal store and it shows up there in certificates mmc, but it does not show up in IIS Manager. Also if you look at the root server in IIS Manager and go to Server Certificates and try to import it there, it is looking for a pfx file, but GoDaddy gives .crt files. You can ignore the file extension but the system gives an error trying to read the certificate. It says "Certificate does not contain a private key".
The other thing when looking at the certificate is that in the details tab, Basic Constraints and Key Usage have yellow exclamation points on them. I don't know but that leads me to think there is an issue. I also tried re-keying this under Starfield Technologies, and that has the same exact issues.
I'm sorry but I was much further along with the wildcard certificate than before when I followed your article on using a real certificate. Maybe you can help me see what went wrong? Our Wildcard certificate expires in January anyway, so it would be preferred if we could get it to work with the new certificate.
The other thing when looking at the certificate is that in the details tab, Basic Constraints and Key Usage have yellow exclamation points on them. I don't know but that leads me to think there is an issue. I also tried re-keying this under Starfield Technologies, and that has the same exact issues.
I'm sorry but I was much further along with the wildcard certificate than before when I followed your article on using a real certificate. Maybe you can help me see what went wrong? Our Wildcard certificate expires in January anyway, so it would be preferred if we could get it to work with the new certificate.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'm not sure why my systems wouldn't trust GoDaddy, as it is a big name. But we normally use Starfield anyway, and now that its rekeyed to Starfield, it seems to be working.
Yep that is odd. GoDaddy normally works fine. Based on the error you were getting it didn't look like the cert itself, But one of the root or intermediary certs. Can't remember if you reapplied GoDaddy's root/intermediary certs. I know they sometimes have you do that.
My last issue before this migration is OWA. If a user has a mailbox on 2007 and they go into OWA, I get an http 400 error. If I manually try to directly get into the 2007 OWA at https://legacy.domain.com/owa, something is redirecting it to https://webm.domain.com. A coworker thinks there may have been some kind of powershell command to change some IIS headers for security but we have to try to figure that out. I have another question on here that you have participated in.
Did you have a separate question open on this already?
ASKER
Yes I do, it is over here:
https://www.experts-exchange.com/questions/28548893/Exchange-2013-2007-OWA-coexistance-not-redirecting-properly-HTTP-400.html?anchorAnswerId=40419967#a40419967
I will mark some answers here, but maybe you or someone can help me over on the other thread.
https://www.experts-exchange.com/questions/28548893/Exchange-2013-2007-OWA-coexistance-not-redirecting-properly-HTTP-400.html?anchorAnswerId=40419967#a40419967
I will mark some answers here, but maybe you or someone can help me over on the other thread.
ASKER
Gareth's answer pointed me in the right direction and was a great help. Though I still had issues with the certificate, so I think its important to note the extra steps in our case, that the Starfield cerifitcate worked while the GoDaddy did not.
We usually use Starfield anyway because of GoDaddy's famous promiscuous super bowl ads. Some people do not like GoDaddy because of that, so we make sure that Starfield is in the certificate names.
We usually use Starfield anyway because of GoDaddy's famous promiscuous super bowl ads. Some people do not like GoDaddy because of that, so we make sure that Starfield is in the certificate names.
Glad to help!
Try the Lync Autodiscover test from the Lync tab.
Try the Autodiscover test from the Exchange tab.
What do you get? Passes or failures?
Please post error codes here.