Have had an Exchange 2007 SP1 running for more than 12 months. Outlook Anywhere (RPC/HTTP) has been working fine for our mobile users. Outlook Web Access also fine. Discovered last week that the server had no patches installed, so began the process of bringing it up to date. Somewhere in the patching process there were problems with .NET ... took us more than a day to uncover the root cause, which turned out to be related to .NET Framework v4.0 ... so we uninstalled .NET 4.0 and then was able to install .NET 3.5 SP1 ... and that is where the server is now at. Right at that time we starting having problems with Outlook Anywhere for people that were offsite. OWA was working, so for a couple of days people used that. We tried a lot of different fixes, but what eventually seemed to work was changing the Outlook Anywhere authentication mechanism in Exchange Management Console from NTLM to Basic, and then back again to NTLM. Now Outlook Anywhere is working fine, but all our Outlook users in the office are now being repeatedly prompted with a username/password dialog. Doesn't matter how many times they enter their credentials, it keeps on popping up. I discovered that if you run Outlook without cached mode being enabled, you don't get the error. Further investigation showed that the dialog was being triggered by Outlook trying to retrieve the Outlook Address Book (OAB). I found the path/GUID for our OAB and tried loading it in Internet Explorer. I was prompted repeatedly for my credentials, but it wouldn't load. When looking in the IIS logs everything relating to OAB showed a 401 error. Now here's the thing: when I look back about 2 weeks ago, the logs showed: unsuccessful attempts to load OAB files without any username being supplied; followed immediately by successful attempts to load the OAB files and provision of a username This tells me that the Outlook clients first tried anonymously, then when it failed, tried with username/password and succeeded. But in the last couple of days, all I see are unsuccessful anonymous attempts; its like the Outlook 2007 clients just gave up and never tried to authenticate with username/password. Or possibly that they just got rejected by the server. To get around this, I have temporarily allowed anonymous access to the OAB virtual and the errors have gone away. All the clients are now getting their OAB anonymously. But I need to understand: what are the correct settings (authentication, etc) for the OAB virtual some kind of plausible explanation of why this has happened Any suggestions deeply appreciated.

Hi, For OAB logging & trobleshooting have a look into this post : http://blogs.msdn.com/b/dgoldman/archive/2006/08/26/725860.aspx ask here is a nice posts that might solve the issue you are facing : http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/079163a7-232a-4f93-9a16-aeef8b2a5c93 http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/9d92a5c2-a143-46c1-9f68-fe1a766beff6Ripu Daman Mina | MCSE 2003 & MCSA Messaging

On Fri, 20 Aug 2010 05:40:55 +0000, Frosty at CBM wrote: [ snip ] >This tells me that the Outlook clients first tried anonymously, then when it failed, tried with username/password and succeeded. > >But in the last couple of days, all I see are unsuccessful anonymous attempts; its like the Outlook 2007 clients just gave up and never tried to authenticate with username/password. Or possibly that they just got rejected by the server. > >To get around this, I have temporarily allowed anonymous access to the OAB virtual and the errors have gone away. All the clients are now getting their OAB anonymously. But I need to understand: 1. what are the correct settings (authentication, etc) for the OAB virtual 2. some kind of plausible explanation of why this has happened > >Any suggestions deeply appreciated. What were the authentication methods that were on the OAB virtual directory? What methods are set on it now? Use this to get the information, not the IIS snapin: get-oabvirtualdirectory | fl *authen* You can set the authentication so it looks like this: BasicAuthentication : True WindowsAuthentication : True InternalAuthenticationMethods : {Basic, WindowsIntegrated} ExternalAuthenticationMethods : {Basic, WindowsIntegrated} --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks guys for the suggestions. After ummm-ung and ahhh-ing for a while, I decided to apply the latest Windows Server 2008 SP2 and also the latest Exchange Server 2007 SP3 service packs. We blocked all incoming mail, took a VMware snapshot, then applied the SP's, starting with the O/S first, then Exchange. As of this morning, all seems to have been fixed by the service packs. I ran the command suggested above and it returned this: InternalAuthenticationMethods : {WindowsIntegrated} ExternalAuthenticationMethods : {WindowsIntegrated} I have now manually removed the "Anonymous" authentication from the OAB folder in IIS and everything still seems to be working alright. But I will monitor for a few days and post again if still having problems, as I have yet to verify that external Outlook Anywhere access is still working properly.

Not quite fixed yet ... but we're close. I have done some testing with Outlook Anywhere this afternoon and we're getting an error in the Sync Issues folder in Outlook 2007 as follows: 12:38:59 Synchronizer Version 12.0.6529 12:38:59 Synchronizing Mailbox 'Stephen Frost' 12:38:59 Synchronizing Hierarchy 12:39:00 1 folder(s) updated in online store 12:39:01 Synchronizing server changes in folder 'Inbox' 12:39:01 Downloading from server 'MYSERVER.mydomain.org.au' 12:39:04 Downloading from server 'MYSERVER.mydomain.org.au' 12:39:04 Done 12:39:18 Microsoft Exchange offline address book 12:39:18 Not downloading Offline address book files. A server (URL) could not be located. 12:39:18 0X8004010F Outlook is working fine inside the office. The OAB is being generated okay. Some Googling has pointed at possible issues with the autodiscover functionality? Outlook Anywhere (generally speaking) is working fine, provided we specify "Basic Authentication" in the account setttings in Outlook (n.b. the connections are somehow mediated by an ISA 2006 server). So should I be getting the InternalAuthenticationMethods and ExternalAuthenticationMethods settings to {Basic,WindowsIntegrated} and not just {WindowsIntegrated} ??? Is that what's causing Outlook Anywhere access to the OAB to fail? If so, how do I add "Basic" without losing "WindowsIntegrated" ?

On Mon, 23 Aug 2010 03:57:40 +0000, Frosty at CBM wrote: [ snip ] >12:39:18 Microsoft Exchange offline address book >12:39:18 Not downloading Offline address book files. A server (URL) could not be located. >12:39:18 0X8004010F >Outlook is working fine inside the office. The OAB is being generated okay. Some Googling has pointed at possible issues with the autodiscover functionality? Get-OabVirtualDirectory|fl *url* >Outlook Anywhere (generally speaking) is working fine, provided we specify "Basic Authentication" in the account setttings in Outlook (n.b. the connections are somehow mediated by an ISA 2006 server). Is ISA using Forms Based Authentication? If it is, then basic authentication from the Internet is all that's possible. NTLM can't be proxied. You can use NTLM and it'll work if you don't use ISA to get to the OAB from *inside* your organization. >So should I be getting the InternalAuthenticationMethods and ExternalAuthenticationMethods settings to {Basic,WindowsIntegrated} and not just {WindowsIntegrated} ??? Is that what's causing Outlook Anywhere access to the OAB to fail? If so, how do I add "Basic" without losing "WindowsIntegrated" ? Get-OABVirtualDirectory | Set-OABVirtualDirectory -BasicAuthentication:$true -WindowsAuthentication:$true --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I feel like such a nuff-nuff with all this authentication stuff, as I have never had to work with ISA server before! OK, I now have the following: [PS] C:\>get-oabvirtualdirectory | fl *authen* BasicAuthentication : True WindowsAuthentication : True InternalAuthenticationMethods : {Basic, WindowsIntegrated} ExternalAuthenticationMethods : {Basic, WindowsIntegrated} [PS] C:\>get-oabvirtualdirectory | fl *URL* InternalUrl : https://webmail.mydomain.org.au/OAB ExternalUrl : https://webmail.mydomain.org.au/OAB Now when I connect from offsite and use the OAB "guid" to browse to the URL of the OAB.XML file using Internet Explorer, I can get the file to load OK ... but it does take me through an authentication screen delivered by the ISA proxy server first, and I have to manually type in my domain username+password ... then I see the OAB.XML file content just fine. But Outlook is still chucking the 0x8004010F error when using it with Outlook Anywhere. The Internal URL and External URL are correct, so I presume either that this issue is caused either by: (a) Outlook not being smart enough to get through the ISA proxy server (even though it seems to handle accessing my mailbox okay); or (b) some other obscure issue that I haven't gotten to the bottom of yet I will try to find out more about the ISA server. All I can say for sure right now is that it lives in our DMZ. I have no idea whether it is joined to our domain, or any other particulars of its configuration. Re-reading what you wrote above about NTLM, proxying and the OAB ... I am pretty sure that we connect to the Exchange server directly via NTLM from the inside of our network ... as the guys who installed and configured our Exchange server tried to set it up so that all connections were through the ISA server, but they couldn't get it working and we ended up with a non-optimal configuration. I also suspect our Autodiscover stuff is at least partially broken and I have no real idea how to go about fixing it. Its my intention to roll out a brand new Exchange 2010 server early next year and I will probably then take the opportunity of retiring the ISA server and publishing OWA, OAB and the RPC stuff directly off the Exchange box (for simplicity's sake).

On Tue, 24 Aug 2010 04:44:18 +0000, Frosty at CBM wrote: > > >I feel like such a nuff-nuff with all this authentication stuff, as I have never had to work with ISA server before! OK, I now have the following: > >[PS] C:\>get-oabvirtualdirectory | fl *authen* BasicAuthentication : True WindowsAuthentication : True InternalAuthenticationMethods : {Basic, WindowsIntegrated} ExternalAuthenticationMethods : {Basic, WindowsIntegrated} > >[PS] C:\>get-oabvirtualdirectory | fl *URL* InternalUrl : https://webmail.cbmi.org.au/OAB ExternalUrl : https://webmail.cbmi.org.au/OAB > >Now when I connect from offsite and use the OAB "guid" to browse to the URL of the OAB.XML file using Internet Explorer, I can get the file to load OK ... but it does take me through an authentication screen delivered by the ISA proxy server first, and I have to manually type in my domain username+password ... then I see the OAB.XML file content just fine. That's a good thing. You're using Forms Based Authentication so IIS has to accept basic authentication because that's what ISA is going to send to IIS. >But Outlook is still chucking the 0x8004010F error when using it with Outlook Anywhere. The Internal URL and External URL are correct, so I presume either that this issue is caused either by: While Outlook is running, find its icon in the system tray. Hold down the "Ctrl" key and right-click on the icon. Select "Test E-Mail AutoConfiguration". Put in your e-mail address and password. Then UN-check the two "Use Guessmart" boxes and click the "Test" button. Is the "OAB URL" in the "Results" tab the one you think it is? >(a) Outlook not being smart enough to get through the ISA proxy server (even though it seems to handle accessing my mailbox okay); or (b) some other obscure issue that I haven't gotten to the bottom of yet That generic 0x8004010f error is just that: generic. Have a look here: http://blogs.msdn.com/b/dgoldman/archive/2007/04/26/outlook-clients-receive-error-0x8004010f-when-downloading-the-offline-address-book.aspx >I will try to find out more about the ISA server. All I can say for sure right now is that it lives in our DMZ. I have no idea whether it is joined to our domain, or any other particulars of its configuration. I don't think you have a problem with ISA. The only reason I mentioned is is because it's the reason you have to enter your credentials. Once you're authenticated you should be okay. >Re-reading what you wrote above about NTLM, proxying and the OAB ... I am pretty sure that we connect to the Exchange server directly via NTLM from the inside of our network ... as the guys who installed and configured our Exchange server tried to set it up so that all connections were through the ISA server, but they couldn't get it working and we ended up with a non-optimal configuration. I also suspect our Autodiscover stuff is at least partially broken and I have no real idea how to go about fixing it. > >Its my intention to roll out a brand new Exchange 2010 server early next year and I will probably then take the opportunity of retiring the ISA server and publishing OWA, OAB and the RPC stuff directly off the Exchange box (for simplicity's sake). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich, that's given me something concrete to work on. You wrote: >> While Outlook is running, find its icon in the system tray. Hold down >> the "Ctrl" key and right-click on the icon. Select "Test E-Mail >> AutoConfiguration". Put in your e-mail address and password. Then >> UN-check the two "Use Guessmart" boxes and click the "Test" button. >> Is the "OAB URL" in the "Results" tab the one you think it is? Here's the result: Clearly an autodiscover issue, as was suspected. I've only been here a few months, so am still learning their network/domain configuration. Our email is using @MYDOMAIN.ORG.AU however our webmail and other servers are using a different domain name. Since learning this, I suspected that it would throw up anomalies in various places, and autodiscover seems to be one of them. Now I don't know much about autodiscover, but it would seem like we need to do some DNS work to fix this? I can see that it is looking for SRV records, and also that it first tries to find an AUTODISCOVER.MYDOMAIN.ORG.AU hostname. Have had a look at our ISP's DNS management application and it won't allow me to put SRV records in. Wondering whether I could set up an external DNS "A" entry for AUTODISCOVER.MYDOMAIN.ORG.AU and point it to the IP address of our webmail server? If using HTTPS it will throw a certificate error because the names are mis-matched, but maybe that would be enough to get it working?

OK, I tried out that last idea, as follows: added type "A" for AUTODISCOVER.MYDOMAIN.ORG.AU pointing to the external IP of the mail server (same as we use for webmail) added an entry for AUTODISCOVER.MYDOMAIN.ORG.AU into the config of the ISA server so that it would pass the traffic through When I tested this from outside, Outlook did some different things: it prompted me with several security alerts of "there is a problem with the site's security certificate" with the reason being "the name on the security certificate is invalid or does not match the name of the site" ... and the certificate details were of course the other domain name WEBMAIL.OTHERDOMAIN.ORG.AU I had to press "YES" to accept them both after that it connected to the server OK but ... It is still throwing an error on the OAB but the error code is now: 9:52:56 Microsoft Exchange offline address book 9:52:56 0X80072F06 which is certificate related? Do I need to get a 2nd certificate for the mail server / OWA which is for WEBMAIL.MYDOMAIN.ORG.AU as well? If this would work okay, I could publish the OAB and OWA to WEBMAIL.MYDOMAIN.ORG.AU instead of WEBMAIL.OTHERDOMAIN.ORG.AU ... would the server handle that config? Or is there another way to tell Outlook "when you autodiscover, don't use AUTODISCOVER.MYDOMAIN.ORG.AU, use WEBMAIL.OTHERDOMAIN.ORG.AU instead"?

On Wed, 25 Aug 2010 23:08:12 +0000, Frosty at CBM wrote: > > >Thanks Rich, that's given me something concrete to work on. You wrote: > >>> While Outlook is running, find its icon in the system tray. Hold down >> the "Ctrl" key and right-click on the icon. Select "Test E-Mail >> AutoConfiguration". Put in your e-mail address and password. Then >> UN-check the two "Use Guessmart" boxes and click the "Test" button. >> Is the "OAB URL" in the "Results" tab the one you think it is? > >Here's the result: > > > >Clearly an autodiscover issue, as was suspected. I've only been here a few months, so am still learning their network/domain configuration. Our email is using @CBM.ORG.AU however our webmail and other servers are using a different domain name. Since learning this, I suspected that it would throw up anomalies in various places, and autodiscover seems to be one of them. Nothing that can't be fixed. >Now I don't know much about autodiscover, but it would seem like we need to do some DNS work to fix this? I can see that it is looking for SRV records, and also that it first tries to find an AUTODISCOVER.CBM.ORG.AU hostname. Have had a look at our ISP's DNS management application and it won't allow me to put SRV records in. SRV records are used last. They were added to allow the use of a single-name SSL certificate instead of a SAN certificate. You don't need SRV records to make this work. >Wondering whether I could set up an external DNS "A" entry for AUTODISCOVER.CBM.ORG.AU and point it to the IP address of our webmail server? If using HTTPS it will throw a certificate error because the names are mis-matched, but maybe that would be enough to get it working? No, you'll continue to have problems unless the certificate name matches. Get yourself a SAN certificate with the full set of names you need and install it on the Exchange CAS and the ISA servers. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Wed, 25 Aug 2010 23:57:26 +0000, Frosty at CBM wrote: > > >OK, I tried out that last idea, as follows: added type "A" for AUTODISCOVER.CBM.ORG.AU pointing to the external IP of the mail server (same as we use for webmail) added an entry for AUTODISCOVER.CBM.ORG.AU into the config of the ISA server so that it would pass the traffic through If you don't have autodiscover.cbm.org.au in the certificate you'll have problems. >When I tested this from outside, Outlook did some different things: it prompted me with several security alerts of "there is a problem with the site's security certificate" with the reason being "the name on the security certificate is invalid or does not match the name of the site" ... and the certificate details were of course the other domain name WEBMAIL.CBMI.ORG.AU I had to press "YES" to accept them both after that it connected to the server OK but ... > >It is still throwing an error on the OAB but the error code is now: > >9:52:56 Microsoft Exchange offline address book > >9:52:56 0X80072F06 > >which is certificate related? > >Do I need to get a 2nd certificate for the mail server / OWA which is for WEBMAIL.CBM.ORG.AU as well? If this would work okay, I could publish the OAB and OWA to WEBMAIL.CBM.ORG.AU instead of WEBMAIL.CBMI.ORG.AU ... would the server handle that config? > >Or is there another way to tell Outlook "when you autodiscover, don't use AUTODISCOVER.CBM.ORG.AU, use WEBMAIL.CBMI.ORG.AU instead"? You should get a SAN SSL certificate, populated with the names you'll need, and install that on the CAS and ISA servers. SAN certs are more expensive than single name SSL certs but they'll make you life soooooo much easier. BTW, to get a good check on your configuration, visit https://testexchangeconnectivity.com and run through the various tests. If you want to verify that the cert you use is installed correctly, visit http://www.digicert.com/help. These guys are really good: http://www.digicert.com/unified-communications-ssl-tls.htm Even if you don't buy a cert from them, visit https://www.digicert.com/easy-csr/exchange2007.htm and use the form to generate the new-exchangecertificate cmdlet. It's a lot easier than doing it by hand. :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich, Thanks for the added certificate info. We'll definitely get a SAN SSL certificate when I run up my new Exchange 2010 server in a few months from now. In the meantime, one of my co-workers dug up the following helpful document: http://office.microsoft.com/search/redir.aspx?AssetID=AM102105061033 It talks about various ways of getting Outlook 2007 to use a customised autodiscovery process. We're going to try putting a custom AutoDiscovery.XML file on our public website (where we already have a valid SAN SSL certificate for both WWW.MYDOMAIN.ORG.AU and MYDOMAIN.ORG.AU) ... with a redirect from there to the WEBMAIL.OTHERDOMAIN.ORG.AU autodiscovery URL. We'll start by trying an HTTP 302 redirect configured in the web server, but if that doesn't work we can try putting the redirect into the .XML file itself: --------------- proposed custom AutoDiscover.XML file <?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"> <Account> <AccountType>email</AccountType> <Action>redirectUrl</Action> <RedirectUrl>https://webmail.otherdomain.org.au/autodiscover/autodiscover.xml</RedirectUrl> </Account> </Response> </Autodiscover> --------------- If it works, the Outlook users will get a first-time-used prompt warning them about the redirection, then if they click OK everything will hopefully be alright. I'll let you know how we get on with that in due course. It may keep us going until we get the new server.

Hmmm ... I also found this: [PS] C:\>get-autodiscovervirtualdirectory | fl *url* InternalUrl : ExternalUrl : Should these have values? Could I set them to the URL that I know is working (http://webmail.otherdomain.org.au/autodiscover/autodiscover.xml)? Don't want to risk upsetting connectivity for my internal users though! Found this: http://technet.microsoft.com/en-us/library/aa998601.aspx which says the syntax is: Set-AutodiscoverVirtualDirectory -Identity <VirtualDirectoryIdParameter> [-BasicAuthentication <$true | $false>] [-Confirm [<SwitchParameter>]] [-DigestAuthentication <$true | $false>] [-DomainController <Fqdn>] [-ExtendedProtectionFlags <MultiValuedProperty>] [-ExtendedProtectionSPNList <MultiValuedProperty>] [-ExtendedProtectionTokenChecking <None | Allow | Require>] [-ExternalUrl <Uri>] [-InternalUrl <Uri>] [-LiveIdBasicAuthentication <$true | $false>] [-LiveIdSpNegoAuthentication <$true | $false>] [-WhatIf [<SwitchParameter>]] [-WindowsAuthentication <$true | $false>] [-WSSecurityAuthentication <$true | $false>] So maybe this would work?: set-autodiscovervirtualdirectory -Identity "Autodiscover (Default Web Site)" -ExternalURL "https://webmail.otherdomain.org.au/autodiscover" Or does this make absolutely no difference once the user heads offsite anyway?

On Thu, 26 Aug 2010 04:37:13 +0000, Frosty at CBM wrote: > > >Hmmm ... I also found this: > >[PS] C:\>get-autodiscovervirtualdirectory | fl *url* InternalUrl : ExternalUrl : > >Should these have values? Could I set them to the URL that I know is working (http://webmail.otherdomain.org.au/autodiscover/autodiscover.xml)? Don't want to risk upsetting connectivity for my internal users though! Found this: > >http://technet.microsoft.com/en-us/library/aa998601.aspx > >which says the syntax is: > >Set-AutodiscoverVirtualDirectory -Identity <VirtualDirectoryIdParameter> [-BasicAuthentication <$true | $false>] [-Confirm [<SwitchParameter>]] [-DigestAuthentication <$true | $false>] [-DomainController <Fqdn>] [-ExtendedProtectionFlags <MultiValuedProperty>] [-ExtendedProtectionSPNList <MultiValuedProperty>] [-ExtendedProtectionTokenChecking <None | Allow | Require>] [-ExternalUrl <Uri>] [-InternalUrl <Uri>] [-LiveIdBasicAuthentication <$true | $false>] [-LiveIdSpNegoAuthentication <$true | $false>] [-WhatIf [<SwitchParameter>]] [-WindowsAuthentication <$true | $false>] [-WSSecurityAuthentication <$true | $false>] > >So maybe this would work?: > >set-autodiscovervirtualdirectory -Identity "Autodiscover (Default Web Site)" -ExternalURL "https://webmail.otherdomain.org.au/autodiscover" > >Or does this make absolutely no difference once the user heads offsite anyway? Set just the externalurl. Users inside your network should be using SCP objects in the AD to find this. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

We got our web developer to put a custom AUTODISCOVER.XML file up on our main website (https://mydomain.org.au/autodiscover/autodiscover.xml) with content as previously posted. This did not work with Outlook 2007. We then tried putting a redirect on that URL so that it served up an HTTP 301 pointing to https://webmail.otherdomain.org.au/autodiscover/autodiscover.xml ... and whilst this clearly worked in a web browse, as I was prompted to login by the ISA server, then I got the correct: <ErrorCode>600</ErrorCode> <Message>Invalid Request</Message> unfortunately Outlook 2007 simply behaved as before. When I <CTRL>right-clicked on the Outlook icon in my system tray, and ran the "Test Email Auto-Configuration", although I could see the 301 redirection occur, the test still failed. But when I tried testing the configuration using the www.testexchangeconnectivity.com website, the test completed successfully. I've also tried adding the -ExternalURL https://webmail.otherdomain.org.au/autodiscover/autodiscover.xml to the AutoDiscover configuration using the set-autodiscovervirtualdirectory command. This does not seem to have made any difference. So I'm now at a loss to know what else to try. So I've now removed the redirect of the autodiscover.xml file from our main website.

On Thu, 2 Sep 2010 23:03:29 +0000, Frosty at CBM wrote: > > >We got our web developer to put a custom AUTODISCOVER.XML file up on our main website (https://mydomain.org.au/autodiscover/autodiscover.xml) with content as previously posted. This did not work with Outlook 2007. We then tried putting a redirect on that URL so that it served up an HTTP 301 pointing to https://webmail.otherdomain.org.au/autodiscover/autodiscover.xml ... and whilst this clearly worked in a web browse, as I was prompted to login by the ISA server, then I got the correct: > > <ErrorCode>600</ErrorCode> <Message>Invalid Request</Message> > >unfortunately Outlook 2007 simply behaved as before. When I <CTRL>right-clicked on the Outlook icon in my system tray, and ran the "Test Email Auto-Configuration", although I could see the 301 redirection occur, the test still failed. > >But when I tried testing the configuration using the www.testexchangeconnectivity.com website, the test completed successfully. What service pack and build of Outlook 2007? You'll find that in the "Help | About" menu. This might be related. Check to see if it's applicable to your server: http://support.microsoft.com/kb/952883 What O/S is Exchange 2007 running on? If IIS7 is being used that redirection may be a problem: http://geekswithblogs.net/cajunmcse/archive/2010/02/05/offline-address-book-problems-with-exchange-2007-and-outlook-anywhere.aspx >I've also tried adding the -ExternalURL https://webmail.otherdomain.org.au/autodiscover/autodiscover.xml to the AutoDiscover configuration using the set-autodiscovervirtualdirectory command. This does not seem to have made any difference. > >So I'm now at a loss to know what else to try. So I've now removed the redirect of the autodiscover.xml file from our main website. Have you tried just creating a new Outlook profile? That's a WAG, but it's worth a shot. :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks for the quick reply Rich. In answer to your questions: -- Outlook 2007 (12.0.6535.5005) SP2 MSO (12.0.6535.5002) ... running on Windows 7 64-bit with all the latest patches ... hardware is a Dell Studio laptop with 8GB RAM -- Windows Server 2008 64-bit running SP2 and all latest patches/updates (server is a guest VM on VMware ESX 3.5 host) -- Exchange 2007 SP3 -- IIS v7.0.6000.16386 I had a look at the URL you mentioned above (http://support.microsoft.com/kb/952883) ... is that the right article? Also had a look at the IIS 7 blog article (http://geekswithblogs.net/cajunmcse/archive/2010/02/05/offline-address-book-problems-with-exchange-2007-and-outlook-anywhere.aspx) ... unfortunately doesn't fit my circumstances, though the symptoms were a pretty good match ... however my OAB stuff loads up okay in a web browser if I manually type in the URL to the OAB.XML file, so it doesn't look like that's the cause of my issue. I'll check with a few other users. If I'm the only one getting this OAB / autodiscover / sync issue, then I will try creating a new profile. But I suspect the problem is affecting all our notebook users.

On Fri, 3 Sep 2010 06:08:47 +0000, Frosty at CBM wrote: > > >Thanks for the quick reply Rich. In answer to your questions: > >-- Outlook 2007 (12.0.6535.5005) SP2 MSO (12.0.6535.5002) ... running on Windows 7 64-bit with all the latest patches ... hardware is a Dell Studio laptop with 8GB RAM > >-- Windows Server 2008 64-bit running SP2 and all latest patches/updates (server is a guest VM on VMware ESX 3.5 host) > >-- Exchange 2007 SP3 > >-- IIS v7.0.6000.16386 > >I had a look at the URL you mentioned above (http://support.microsoft.com/kb/952883) ... is that the right article? It is. It's fix to .Net, not to Exchange. >Also had a look at the IIS 7 blog article (http://geekswithblogs.net/cajunmcse/archive/2010/02/05/offline-address-book-problems-with-exchange-2007-and-outlook-anywhere.aspx) ... unfortunately doesn't fit my circumstances, though the symptoms were a pretty good match ... however my OAB stuff loads up okay in a web browser if I manually type in the URL to the OAB.XML file, so it doesn't look like that's the cause of my issue. > >I'll check with a few other users. If I'm the only one getting this OAB / autodiscover / sync issue, then I will try creating a new profile. But I suspect the problem is affecting all our notebook users. Well, I did say it was a WAG. :-) I don't recall if you said you removed and recreated the OAB virtual directory, but that my be your best shot at this point: http://technet.microsoft.com/en-us/library/bb123595(EXCHG.80).aspx --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP