SashcoIT
asked on
Autodiscover/Free busy/Out of Office issues with IIS 6.0 -ONLY XP USERS HAVE ISSUE!!
We recently set a http to https redirect on our Exchange 2007 server. For whatever reason this did not seem to take right, and in the process of a few people playing with it, we have seemed to have broken the Autodiscover service for XP clients using Outlook 2007. They are able to autodiscover and setup Outlook, however when trying to use the Out of office assistant or view free busy when scheduling, they error out. This is NOT the case for people using Vista or Windows 7, which leads me to believe that it is an issue with the way that the server is handling credential authentication.
The only reason that I mention Autodiscover is that if you run the "Test E-mail Autoconfiguration" on an XP client, it fails at the "Autodiscover to https://mycompany.com/autodiscover/autodiscover.xml", where I can then run this on a Vista/7 machine at the same time with the same user configured through Outlook and I get a Success at the autodiscover.xml
We are not using SANs in our cert, and I know this could cause similar errors (though not for specific types of clients) but this was working OK before. We also have also had a similar permission problem on the /Exchange directory since the other day which prevented Entourage users from connecting... upon getting the credential connection settings correctly config back into the /Exchange directory we were able to get them working.
Thanks for any advise!
The only reason that I mention Autodiscover is that if you run the "Test E-mail Autoconfiguration" on an XP client, it fails at the "Autodiscover to https://mycompany.com/autodiscover/autodiscover.xml", where I can then run this on a Vista/7 machine at the same time with the same user configured through Outlook and I get a Success at the autodiscover.xml
We are not using SANs in our cert, and I know this could cause similar errors (though not for specific types of clients) but this was working OK before. We also have also had a similar permission problem on the /Exchange directory since the other day which prevented Entourage users from connecting... upon getting the credential connection settings correctly config back into the /Exchange directory we were able to get them working.
Thanks for any advise!
ASKER
Thanks for the comment, but let me clarify on the issue:
IE works just fine, in fact I dont think I mentioned any issues with IE....
We did however setup an http to https redirect for IE by means of creating a file and pointing the 403.4 error to this html file, which then would redirect the clients to an https URL. I have done this on another Exchange server no problem, however this time it did not seem to work right off of the bat and therefore a few people got there hands into IIS and we may have inadvertantly messed up some permissions on the Default Web Site in IIS.
The permission issues 1st caused Entourage clients to be unable to authenticate, however after a few hours of looking and testing some different senarios, we found the right combination of permission settings on the /Exchange directory (as this is where Entourage users point) by unchecking the "Integrated Windows Authentication" and then checking the "Basic Authentication" boxes. This fix was on Friday....
Then as of Monday, people internal and external began complaining of not seeing free/busy times or able to set OOO messages from Outlook. These do work from OWA. I began looking into it as a company wide issue, however then noticed that my Outlook worked OK.... I am running Windows 7. I then booted a Vista VM and it worked OK there too. I then booted an XP VM and could not view free/busy or set OOO just like the others have complained. With a little more testing it seems as though this is only a problem with XP users, but the problem is that everyone besides the IT department is running XP, therefore is a critical issue.
The reason that I beleive the permissions may be set wrong, is because when we set the 403.4 error in the "Custom Errors" tab on the Default Web Site and then clicked apply there was a box that we had never seen before which states:
" The following child noes also define the value of the "UNCPassword" property, which overrides the value you have just set. Please select from the list below those nodes which should use the new value"
It then will list various virtual directories such as Autodiscover, EWS, Public, etc. where you can select all, select some or select none and then OK.
My worry is that in playing with this, one of us may have "selected all" and hit OK, or maybe the problem is that we did not select all and went forward with it..... We have never seen this and honestly did not know what to do.
Since seeing this and in our troubleshooting we have tried to set everything back to what it was by means of changing the "custom errors" file back to the normal 403.4 file and then trying to either select all, or select none in the window mentioned above.... nothing seems to be fixing our issues though.
Can anyone verify what all of the permissions should be on each of the directories within the Default Web Site? -maybe that will help....
Thanks!
IE works just fine, in fact I dont think I mentioned any issues with IE....
We did however setup an http to https redirect for IE by means of creating a file and pointing the 403.4 error to this html file, which then would redirect the clients to an https URL. I have done this on another Exchange server no problem, however this time it did not seem to work right off of the bat and therefore a few people got there hands into IIS and we may have inadvertantly messed up some permissions on the Default Web Site in IIS.
The permission issues 1st caused Entourage clients to be unable to authenticate, however after a few hours of looking and testing some different senarios, we found the right combination of permission settings on the /Exchange directory (as this is where Entourage users point) by unchecking the "Integrated Windows Authentication" and then checking the "Basic Authentication" boxes. This fix was on Friday....
Then as of Monday, people internal and external began complaining of not seeing free/busy times or able to set OOO messages from Outlook. These do work from OWA. I began looking into it as a company wide issue, however then noticed that my Outlook worked OK.... I am running Windows 7. I then booted a Vista VM and it worked OK there too. I then booted an XP VM and could not view free/busy or set OOO just like the others have complained. With a little more testing it seems as though this is only a problem with XP users, but the problem is that everyone besides the IT department is running XP, therefore is a critical issue.
The reason that I beleive the permissions may be set wrong, is because when we set the 403.4 error in the "Custom Errors" tab on the Default Web Site and then clicked apply there was a box that we had never seen before which states:
" The following child noes also define the value of the "UNCPassword" property, which overrides the value you have just set. Please select from the list below those nodes which should use the new value"
It then will list various virtual directories such as Autodiscover, EWS, Public, etc. where you can select all, select some or select none and then OK.
My worry is that in playing with this, one of us may have "selected all" and hit OK, or maybe the problem is that we did not select all and went forward with it..... We have never seen this and honestly did not know what to do.
Since seeing this and in our troubleshooting we have tried to set everything back to what it was by means of changing the "custom errors" file back to the normal 403.4 file and then trying to either select all, or select none in the window mentioned above.... nothing seems to be fixing our issues though.
Can anyone verify what all of the permissions should be on each of the directories within the Default Web Site? -maybe that will help....
Thanks!
Sorry, its been a while since I used a Mac ... I was thinking browsers when you mentioned Entourage.
Check out this page ... http://technet.microsoft.com/en-us/library/bb201695.aspx
I don't know that it addresses your specific problem but it outlines the configuration steps for the autodiscovery piece of Exchange. It might give you enough to validate your configuration/setup and discover what is wrong.
Check out this page ... http://technet.microsoft.com/en-us/library/bb201695.aspx
I don't know that it addresses your specific problem but it outlines the configuration steps for the autodiscovery piece of Exchange. It might give you enough to validate your configuration/setup and discover what is wrong.
ASKER
OK, i have read through this already, as well as several others. Here is the problem: Autodiscover works just fine when setting up an outlook account or when using free busy in Outlook from a computer running anything but XP. In fact here is the output of the "Test e-mail autoconfiguration" from a computer running Vista:
Thread Tick Count Date/Time Description
3740 2637250 05/21/09 09:02:24 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
3740 2637250 05/21/09 09:02:24 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
3740 2644968 05/21/09 09:02:31 Autodiscover XML Received
---BEGIN XML---
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>my name</DisplayName>
<LegacyDN>/o=company/ou=Ex
<DeploymentId>abc795b3-ae8
</User>
<Account>
<AccountType>email</Accoun
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>email.my.company.c
<ServerDN>/o=company/ou=Ex
<ServerVersion>720180F0</S
<MdbDN>/o=company/ou=Excha
<PublicFolderServer>email.
<AD>email.my.company.com</
<ASUrl>https://email.my.company.com/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://email.my.company.com/EWS/Exchange.asmx</EwsUrl>
<OOFUrl>https://email.my.company.com/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://email.my.company.com/UnifiedMessaging/Service.asmx</UMUrl>
<OABUrl>http://email.my.company.com/OAB/000ae894-886d-49c9-bf3a-74ada89d7376/</OABUrl>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>email.my.company.c
<OABUrl>https://email.my.company.com/OAB/000ae894-886d-49c9-bf3a-74ada89d7376/</OABUrl>
</Protocol>
<Protocol>
<Type>WEB</Type>
<External>
<OWAUrl AuthenticationMethod="Fba"
</External>
<Internal>
<OWAUrl AuthenticationMethod="Basi
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://email.my.company.com/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
</Protocol>
</Account>
</Response>
</Autodiscover>
----END XML----
3740 2644984 05/21/09 09:02:31 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml succeeded (0x00000000)
And here is using the same user, at the same time, but on an XP box... these computers are both joined to the domain and neither have any group policies pushed to them:
2612 2252228 05/21/09 09:00:53 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
2612 2252228 05/21/09 09:00:53 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
2612 2252358 05/21/09 09:00:53 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml FAILED (0x80072F78)
2612 2252358 05/21/09 09:00:53 Autodiscover to https://company.com/autodiscover/autodiscover.xml starting
2612 2254631 05/21/09 09:00:55 Autodiscover to https://company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2612 2254631 05/21/09 09:00:55 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml starting
2612 2254631 05/21/09 09:00:55 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2612 2254631 05/21/09 09:00:55 Local autodiscover for company.com starting
2612 2254631 05/21/09 09:00:55 Local autodiscover for company.com FAILED (0x8004010F)
2612 2254631 05/21/09 09:00:55 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml starting
2612 2254631 05/21/09 09:00:55 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x80072EE7)
2576 2254682 05/21/09 09:00:56 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
2576 2254682 05/21/09 09:00:56 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
2576 2254772 05/21/09 09:00:56 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml FAILED (0x80072F78)
2576 2254772 05/21/09 09:00:56 Autodiscover to https://company.com/autodiscover/autodiscover.xml starting
2576 2257045 05/21/09 09:00:58 Autodiscover to https://company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2576 2257045 05/21/09 09:00:58 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml starting
2576 2257075 05/21/09 09:00:58 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2576 2257075 05/21/09 09:00:58 Local autodiscover for company.com starting
2576 2257075 05/21/09 09:00:58 Local autodiscover for company.com FAILED (0x8004010F)
2576 2257075 05/21/09 09:00:58 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml starting
2576 2257135 05/21/09 09:00:58 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x80072EE7)
2544 2258287 05/21/09 09:00:59 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
2544 2258287 05/21/09 09:00:59 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
2544 2258317 05/21/09 09:00:59 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml FAILED (0x80072F78)
2544 2258317 05/21/09 09:00:59 Autodiscover to https://company.com/autodiscover/autodiscover.xml starting
2544 2260590 05/21/09 09:01:01 Autodiscover to https://company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2544 2260590 05/21/09 09:01:01 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml starting
2544 2260590 05/21/09 09:01:01 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2544 2260590 05/21/09 09:01:01 Local autodiscover for company.com starting
2544 2260590 05/21/09 09:01:01 Local autodiscover for company.com FAILED (0x8004010F)
2544 2260590 05/21/09 09:01:01 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml starting
2544 2260590 05/21/09 09:01:01 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x80072EE7)
Thread Tick Count Date/Time Description
3740 2637250 05/21/09 09:02:24 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
3740 2637250 05/21/09 09:02:24 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
3740 2644968 05/21/09 09:02:31 Autodiscover XML Received
---BEGIN XML---
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>my name</DisplayName>
<LegacyDN>/o=company/ou=Ex
<DeploymentId>abc795b3-ae8
</User>
<Account>
<AccountType>email</Accoun
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>email.my.company.c
<ServerDN>/o=company/ou=Ex
<ServerVersion>720180F0</S
<MdbDN>/o=company/ou=Excha
<PublicFolderServer>email.
<AD>email.my.company.com</
<ASUrl>https://email.my.company.com/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://email.my.company.com/EWS/Exchange.asmx</EwsUrl>
<OOFUrl>https://email.my.company.com/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://email.my.company.com/UnifiedMessaging/Service.asmx</UMUrl>
<OABUrl>http://email.my.company.com/OAB/000ae894-886d-49c9-bf3a-74ada89d7376/</OABUrl>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>email.my.company.c
<OABUrl>https://email.my.company.com/OAB/000ae894-886d-49c9-bf3a-74ada89d7376/</OABUrl>
</Protocol>
<Protocol>
<Type>WEB</Type>
<External>
<OWAUrl AuthenticationMethod="Fba"
</External>
<Internal>
<OWAUrl AuthenticationMethod="Basi
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://email.my.company.com/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
</Protocol>
</Account>
</Response>
</Autodiscover>
----END XML----
3740 2644984 05/21/09 09:02:31 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml succeeded (0x00000000)
And here is using the same user, at the same time, but on an XP box... these computers are both joined to the domain and neither have any group policies pushed to them:
2612 2252228 05/21/09 09:00:53 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
2612 2252228 05/21/09 09:00:53 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
2612 2252358 05/21/09 09:00:53 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml FAILED (0x80072F78)
2612 2252358 05/21/09 09:00:53 Autodiscover to https://company.com/autodiscover/autodiscover.xml starting
2612 2254631 05/21/09 09:00:55 Autodiscover to https://company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2612 2254631 05/21/09 09:00:55 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml starting
2612 2254631 05/21/09 09:00:55 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2612 2254631 05/21/09 09:00:55 Local autodiscover for company.com starting
2612 2254631 05/21/09 09:00:55 Local autodiscover for company.com FAILED (0x8004010F)
2612 2254631 05/21/09 09:00:55 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml starting
2612 2254631 05/21/09 09:00:55 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x80072EE7)
2576 2254682 05/21/09 09:00:56 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
2576 2254682 05/21/09 09:00:56 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
2576 2254772 05/21/09 09:00:56 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml FAILED (0x80072F78)
2576 2254772 05/21/09 09:00:56 Autodiscover to https://company.com/autodiscover/autodiscover.xml starting
2576 2257045 05/21/09 09:00:58 Autodiscover to https://company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2576 2257045 05/21/09 09:00:58 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml starting
2576 2257075 05/21/09 09:00:58 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2576 2257075 05/21/09 09:00:58 Local autodiscover for company.com starting
2576 2257075 05/21/09 09:00:58 Local autodiscover for company.com FAILED (0x8004010F)
2576 2257075 05/21/09 09:00:58 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml starting
2576 2257135 05/21/09 09:00:58 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x80072EE7)
2544 2258287 05/21/09 09:00:59 Attempting URL https://email.my.company.com/autodiscover/autodiscover.xml found through SCP
2544 2258287 05/21/09 09:00:59 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml starting
2544 2258317 05/21/09 09:00:59 Autodiscover to https://email.my.company.com/autodiscover/autodiscover.xml FAILED (0x80072F78)
2544 2258317 05/21/09 09:00:59 Autodiscover to https://company.com/autodiscover/autodiscover.xml starting
2544 2260590 05/21/09 09:01:01 Autodiscover to https://company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2544 2260590 05/21/09 09:01:01 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml starting
2544 2260590 05/21/09 09:01:01 Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2544 2260590 05/21/09 09:01:01 Local autodiscover for company.com starting
2544 2260590 05/21/09 09:01:01 Local autodiscover for company.com FAILED (0x8004010F)
2544 2260590 05/21/09 09:01:01 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml starting
2544 2260590 05/21/09 09:01:01 Redirect check to http://autodiscover.company.com/autodiscover/autodiscover.xml FAILED (0x80072EE7)
ASKER
I guess my thought is that to me, Autodiscover seems to be configured just fine. Nothing here has changed recently either. The only issue seems to be that XP users cannot read the https://email.my.company.com/autodiscover/autodiscover.xml file.
This makes me think it is in the way that XP users pass their credentials. I have tried every permisson config that I can think of on the autodiscover directory and I cannot get it to work.
Here is an interesting point that further supports the idea of the XP permission thing. On XP if I type this URL in my browser I am presented with a credential window. If I put in my username of company\username and my password I am taken to a screen that gives me the following:
<?xml version="1.0" encoding="utf-8" ?>
- <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
- <Response>
- <Error Time="09:16:04.7908424" Id="2758232594">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData />
</Error>
</Response>
</Autodiscover>
However, if I go to the same URL in Vista or Windows 7, the credential window that pops up already has my username set within it and all that I need to enter is my password. This tells me that Vista and Windows 7 are passing my username, where XP is not.... Is that not what the Windows Intergrated Authentication checkbox in IIS should do for you? Why doesnt it do that on the XP machine?
This makes me think it is in the way that XP users pass their credentials. I have tried every permisson config that I can think of on the autodiscover directory and I cannot get it to work.
Here is an interesting point that further supports the idea of the XP permission thing. On XP if I type this URL in my browser I am presented with a credential window. If I put in my username of company\username and my password I am taken to a screen that gives me the following:
<?xml version="1.0" encoding="utf-8" ?>
- <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
- <Response>
- <Error Time="09:16:04.7908424" Id="2758232594">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData />
</Error>
</Response>
</Autodiscover>
However, if I go to the same URL in Vista or Windows 7, the credential window that pops up already has my username set within it and all that I need to enter is my password. This tells me that Vista and Windows 7 are passing my username, where XP is not.... Is that not what the Windows Intergrated Authentication checkbox in IIS should do for you? Why doesnt it do that on the XP machine?
One thought ... Check the time on the XP workstations and make sure they are sync'ing their time to the same source. If the time on the workstation is not in sync with the server then this will cause problems with authentication.
If there is some difference in the domain name on the workstation versus the server then this could affect the authentication also. It would force it to use the external as opposed to the internal authentication method. If you can change the autodiscover.xml file try setting the internal and external authentication protocols to the same thing ... i.e.
<Protocol>
<Type>WEB</Type>
<External>
<OWAUrl AuthenticationMethod="Basi
</External>
<Internal>
<OWAUrl AuthenticationMethod="Basi
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://email.my.company.com/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
</Protocol>
If this works then you know that there is a configuration difference between the workstations/server regarding domain references. Then its a matter of determining where the difference is.
If there is some difference in the domain name on the workstation versus the server then this could affect the authentication also. It would force it to use the external as opposed to the internal authentication method. If you can change the autodiscover.xml file try setting the internal and external authentication protocols to the same thing ... i.e.
<Protocol>
<Type>WEB</Type>
<External>
<OWAUrl AuthenticationMethod="Basi
</External>
<Internal>
<OWAUrl AuthenticationMethod="Basi
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://email.my.company.com/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
</Protocol>
If this works then you know that there is a configuration difference between the workstations/server regarding domain references. Then its a matter of determining where the difference is.
ASKER
Thanks for the suggestion. I am running the XP machine on a VM which I think pulls its time from the host machine... the machine that is working... But either way the time is the same. There is no difference in the domain names on the new workstation, or the existing workstations that have been functioning properly for the past year.
The external vs interal auth methods is a possibility I suppose, however again the domain names are the same. In fact, it shows that it found the URL for the Autodiscover site using SCP, therefore it is using the same name as the other right?
I really think this is a permission issue on the Autodiscover directory in the web site, but I am willing to look beyond this.... so far though nothing else makes since.
Currently on the Autodiscover properties under Directory Security and then Authentication and access control we have "integrated windows authentication" and "Basic Authentication" set along with the default domain specified. With this config it prompts my Vista and 7 boxes to enter a password each time when launching Outlook but I never had to do this before... therefore if I uncheck both "Integrated windows authentication" and "Basic Authentication" when I then launch Outlook on a Vista or 7 compter it no longer prompts me for a username and pw when opening..... Then however I start failing the "Test e-mail autoconfiguration" on Vista or 7. No matter what config I set in on the Autodiscover directory it never asks on a Outlook client on XP but the autodiscover always fails.
The external vs interal auth methods is a possibility I suppose, however again the domain names are the same. In fact, it shows that it found the URL for the Autodiscover site using SCP, therefore it is using the same name as the other right?
I really think this is a permission issue on the Autodiscover directory in the web site, but I am willing to look beyond this.... so far though nothing else makes since.
Currently on the Autodiscover properties under Directory Security and then Authentication and access control we have "integrated windows authentication" and "Basic Authentication" set along with the default domain specified. With this config it prompts my Vista and 7 boxes to enter a password each time when launching Outlook but I never had to do this before... therefore if I uncheck both "Integrated windows authentication" and "Basic Authentication" when I then launch Outlook on a Vista or 7 compter it no longer prompts me for a username and pw when opening..... Then however I start failing the "Test e-mail autoconfiguration" on Vista or 7. No matter what config I set in on the Autodiscover directory it never asks on a Outlook client on XP but the autodiscover always fails.
If Vista and 7 are working then this makes me think it is not a permissions issue on the directory itself as the OS should not matter when applying NTFS credentials, it is the logged on user. If the same user can access the files from another machine running a different OS then this should rule out directory level permissions.
BUT, along the lines of the permissions is a question of how the credentials are being passed to IIS and how IIS is then "translating" those credentials to make it possible to authenticate the user.
WIA and basic authentication would take the user credentials in clear text hence no translation would need to take place. You might want to back this up one step and just remove the WIA option. This should prompt for credentials and pass them in clear text ... this should be the best solution to troubleshoot with as it removes a number of complications.
If this is working then re-enable WIA, this will cause the browser to pass the credentials without prompting (well, it is supposed to). If this works, then try removing the basic. This will most likely break things for Entourage as IIS will now require both the IS and password to be passed in encrypted form.
Depending on what else breaks this can help narrow down where the problem is as only machines that are on the LAN will pass encrypted credentials. So, if this breaks the XP machines then for some reason the web functionality on the XP machines is not seeing the server as on its intranet and is not passing encrypted credentials. to check this, try adding the server to the list of trusted servers. If this resolves the problem then you have identified the problem as being a domain reference issue ... some where.
BUT, along the lines of the permissions is a question of how the credentials are being passed to IIS and how IIS is then "translating" those credentials to make it possible to authenticate the user.
WIA and basic authentication would take the user credentials in clear text hence no translation would need to take place. You might want to back this up one step and just remove the WIA option. This should prompt for credentials and pass them in clear text ... this should be the best solution to troubleshoot with as it removes a number of complications.
If this is working then re-enable WIA, this will cause the browser to pass the credentials without prompting (well, it is supposed to). If this works, then try removing the basic. This will most likely break things for Entourage as IIS will now require both the IS and password to be passed in encrypted form.
Depending on what else breaks this can help narrow down where the problem is as only machines that are on the LAN will pass encrypted credentials. So, if this breaks the XP machines then for some reason the web functionality on the XP machines is not seeing the server as on its intranet and is not passing encrypted credentials. to check this, try adding the server to the list of trusted servers. If this resolves the problem then you have identified the problem as being a domain reference issue ... some where.
ASKER
Does Vista and 7 use the same form of NTFS credentials? I guess I would assume so, so I will agree here.....
I have tried with WIA and Basic Auth, with just WIA, with just Basic Auth and with none of these selected already. -as well as several other combinations. NONE of these work and do not change on anything on the computers using XP. As mentioned above, these do change things for Vista users depending on the config and make it so that they have to then authenticate when opening Outlook.
That all said, are you referring to just the Autodiscover directory or the whole Web Site? I have only been making these changes on the Autodiscover directory and currently on the Default web site I have none of these checked but I am using "Enable Anonymous access"... this was how it was set before, or at least I have never changed it. Is that right?
Also, all of the directories accept the /Public are using SSL, 128bit encryption.... this is all correct too right?
I have tried with WIA and Basic Auth, with just WIA, with just Basic Auth and with none of these selected already. -as well as several other combinations. NONE of these work and do not change on anything on the computers using XP. As mentioned above, these do change things for Vista users depending on the config and make it so that they have to then authenticate when opening Outlook.
That all said, are you referring to just the Autodiscover directory or the whole Web Site? I have only been making these changes on the Autodiscover directory and currently on the Default web site I have none of these checked but I am using "Enable Anonymous access"... this was how it was set before, or at least I have never changed it. Is that right?
Also, all of the directories accept the /Public are using SSL, 128bit encryption.... this is all correct too right?
Try removing the Anonymous access.
This could be the difference. The browser will try that first and then respond to the server error stating that credentials are requested. Something might be difference in how Vista & 7 are handling this as opposed to XP. By removing the anonymous this will force the access to using credentials.
This could be the difference. The browser will try that first and then respond to the server error stating that credentials are requested. Something might be difference in how Vista & 7 are handling this as opposed to XP. By removing the anonymous this will force the access to using credentials.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'm glad you found the fix :)
Based on that I agree that this is a permissions issue, or possibly a settings issue.
If all of the other machines are working this makes me think it might be client OS related though.
Is there any chance that a GP was changed that is specific to the XP client?