Not your average Autodiscover Q - Outlook 2010 works perfectly, Outlook 2007 does not work at all?
Hi everyone, I'm hoping that you'll be able to help me with a problem we've struggled with for quite some time, and we're now no closer to resolving. It's becoming more problematic, as we're just finalising our migration from Win XP / Office 2003 up to Win 7 / Office 2007. Previously we have used PRF files to create outlook profiles, but want to use Autodiscover from now on. Currently we need IT Support to assist users every time they log into a new PC / have a new user start / have any sort of profile trouble, and it's becoming a big headache for us. I've spent a lot of tie searching and experimenting, but have come to the end of my teather, so I'm hoping that someone will be able to offer some fresh pointers for me. As is normal with my posts, this is going to contain a huge amount of (probably useless) information in the hope that some of it is relevant. Please feel free to ask for any other details that I've missed that you think may be relevant. The back end Exchange is a single Exchange 2007 Standard server (BNEEXCHANGE07) that has just been upgraded to SP3 Rollup 1, running on Windows Server 2008 x64. Three information stores, this same server hosts all Exchange roles (CAS, HT, MBX). This server hosts our OWA and Activesync. This server uses a commercial UCC certificate covering all internal and external hostnames (Server, Server.internaldomain, autodiscover.internaldomain, mail.externaldomain, autodiscover.externaldomain). This Exchange is NOT an AD server, or a GC. OWA and Activesync work fine, and have no permission or certificate problems. Clients are a mixture of Windows XP running Office 2003, Windows 7 running Office 2007, and Windows 7 running Office 2010. All are kept updated to latest patches / SPs via our internal WSUS. The Outlook 2007 clients are running SP2 (12.0.6550.5003 - SP2 MSO - 12.0.6545.5004). Client are all domain-joined. Clients have the "Automatically configure profile based on Active Directory Primary SMTP address" group policy option set, and the user's email address within AD (verified via ADSIEdit) is correct. Clients also have "Use Cached Exchange Mode for new and existing Outlook profiles" option set via group policy. The problem : The Outlook 2007 clients cannot automatically configure an outlook profile when a new user logs onto the PC. If a new user logs onto a PC with Outlook 2010 installed, their profile is configured instantly and Outlook logs them on straight away with no user interaction required. Running the Test Email Autoconfiguration tool on either PC (once the user account has been manually configured on Outlook 2007) returns success, and shows the correct information consistently. Once the profile is set up and working, the actual XML file returned is perfect. It's as if Outlook 2007 isn't even trying to use Autoconfigure. When logging a new user onto an Outlook 2007 PC, the following process is what we currently do to get the profile set up and working: * Outlook opens, stops responding for ~90 seconds. * Outlook opens a dialog box - "The Connection to Microsoft Exchange is unavailable. Outlook must be online or connect to complete this action". Click OK. * Outlook opens up a "Microsoft Exchange" window, showing the Microsoft Exchange server and Mailbox (with the Check Name button). The fields are pre-populated - the Microsoft Exchange server field contains the full CN path of the exchange server, NOT it's DNS or NETBIOS name. IE, for us, this is "/o=<<domain>>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=BNEEXCHANGE07". The mailbox field shows the user's correct AD name. * We change the Microsoft Exchange Server field to the name of the local GC server. It also works if you put the IPv4 address of the exchange server itself in here, but our process is to use the local GC. Click the Check Name button next to the Mailbox field. * Pretty much immediately the Microsoft Exchange Server field changes to the internal FQDN of the exchange server, and is underlined - BNEEXCHANGE07.internaldomain. The mailbox field becomes underlined. IE, it's successfully connected to the mailbox. Click OK. * After a couple of seconds, Outlook will prompt with another error dialog box - "The name cannot be resolved. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action". Click OK, and the same Microsoft Exchange window, with the same pre-populated fields, is presented. * change the Microsoft Exchange Server field to the local GC, click Check Name, verify the Microsoft Exchange Server field is changed from the CG to the FQDN of the Exchange server and underlined, as is the mailbox name, and click OK. * Outlook proceeds to set up the user's mailbox, and everything works well from there on in - no further problems at all for that user logged on to that PC. Their OOF works perfectly, their availability info is faultless, they have no certificate errors, and if you then run the Test Email Autoconfiguration tool, with only Autodiscover selected, it works fine and returns the correct information. Most of the troubleshooting info I've been able to find centres on the Autodiscover website not working correctly, or the permissions being wrong, or the certificate being incorrect - things like that. I'm not going to say at this point that those things are all 100% correct, but I'm pretty certain I've been through them enough times at this point to have them right. Also, the fact that Outlook 2010 works straight up seems to point me away from an Exchange problem and back to a client-related problem. Our Outlook 2007 install is not customised at all - it's a standard install with only a very small number of group policies deployed against it. But I can't find *anything* that indicates that it's an issue with Outlook 2007 - the general consensus seems to be that Outlook 2007 post SP1 works with Autodiscover quite well. It can be a pain to get the Exchange end set up with the certs correctly, but once done, it all just works. OK - here's some more information about what DOESN'T work, in case it's useful. New user logging onto Outlook 2007 PC. * Outlook opens, stops responding for ~90 seconds. * Outlook opens a dialog box - "The Connection to Microsoft Exchange is unavailable. Outlook must be online or connect to complete this action". Click OK. * Outlook opens up a "Microsoft Exchange" window, showing the Microsoft Exchange server and Mailbox (with the Check Name button). The fields are pre-populated - the Microsoft Exchange server field contains the full CN path of the exchange server, NOT it's DNS or NETBIOS name. IE, for us, this is "/o=<<domain>>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=BNEEXCHANGE07". The mailbox field shows the user's correct AD name. * Change the Microsoft Exchange server field to "BNEEXCHANGE07.internaldomain". (This is the exact same FQDN that is returned by the GC in the above process and underlined and works, it's just this time we're typing it in ourselves.) Click Check Name button. * Outlook returns an error dialog box - "The name cannot be resolved. The connection to Microsoft Exchange is unavailable. Outlook must be online or connect to complete this action". No good, no underlining - it can't talk to the exchange server through the FQDN. DNS queries from the client resolve the name instantly, and full connectivity is available. This can be confirmed by straight away entering the local GC's name and clicking the Check Name button, and the Microsoft Exchange server field will instantly change to the BNEEXCHANGE07.internaldomain FQDN, and be underlined (along with the mailbox name). * If you error the Microsoft Exchange window enough times, Outlook will switch to the "Add New Email Account" wizard - the first screen is the "Auto Account Setup" screen that pick up the user's name from AD. It also picks up the Email address ("Example: barbara@contoso.com"). However, in this case it's populating the Email Address field as username@<<internalDomain>>, instead of username@<<externaldomain>> . I have NO idea where it's getting this from. I've been through this user's account properties in AD and Exchange looking for perhaps an incorrect reference, but it does not exist. The user's Email field in AD is set correctly - username@externaldomain. The email addresses in Exchange are all set correctly - there's only one SMTP address, it's set as the primary, and it's the correct username@externaldomain one. I can only surmise that Outlook is making this up itself, instead of actual grabbing it from somewhere in AD/autodiscover. *If you correct this Email Address to what it should be, and click Next on the Add New Email Account screen, then the wizard progresses fine through the "online search for your server settings", and shows green ticks for "Establish Network Connectivity" and "Search for <<emailaddress>> server settings". When it gets to the "Log on to server" step, it throws a "The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action" popup. * From there we go back to the Microsoft Exchange window, with the Microsoft Exchange server field pre-populated with the FQDN of the exchange server (but not underlined), and the Mailbox field pre-populated with "=SMTP:<<emailaddress>>". Pressing the Check Name button throws the same error. *If you change the Microsoft Exchange server field to the GC and click Check name, you get the same error again. * You need to also remove the "=SMTP:" from the Mailbox field and leave just the SMTP email address (or change to just the username), then click Check Name. As above, this changes the Microsoft Exchange server field back to the underlined FQDN of the Exchange server (BNEEXCHANGE07.internaldomain) and sets the Mailbox to be the underlined user's account. * Click OK to this, and you are returned to the Add New Email Account wizard, with a green tick next to the "Log On To Server" step, and a notification showing that "Your email account is successfully configured to use Microsoft Exchange". Click the Finish button, and it all works. Running Test-OutlookWebServices on the server returns Success for every test. Address book downloads perfectly fine, OOF and Free/Busy work perfectly fine. No cert errors, no prompting for authentication/credentials from within Outlook. It seems, when searching through other threads for help, that most people's problems with Outlook 2007 and Autodiscover are tied into these problems, and stem from misconfigured IIS vdirs, misconfigured permissions, or wrong certificates. From the looks of things, all of that is working well on my server. Within the next 3 months we're looking up upgrade to an Exchange 2010 back end, but I really need to get this resolved before then. It's impacting on the user acceptance of our Win7 desktop deployment, and is driving our poor helpdesk folk around the bend. Up till recently it's just been something that they've been taking care of and they haven't mentioned it as a real problem. But it's a significant drain on their time, as well as a problem for the users, especially since it's something that should Just Work. It seems that others have good results in getting Outlook 2007 Autodiscover to work against an Exchange 2007 server, so I'm hopeful that someone here will be able to point me in the right direction. I know it sounds like a client issue, but I can't for the life of me work out why. I would like to completely rule out the server as the cause if we could, so any help would be much appreciated. Many thanks in advance, Matt Russell Cairns, QLD, AUS.
March 1st, 2011 1:42am

Hi, I would like to confirm if the problem happens on all the PCs which have outlook 2007 installed on? To further research, please help me to capture the network traffic when running outlook auto configuration: 1. On a client PC , run Netmon and start capturing. You can download the netmon from here. 2. Launch outlook 2007 and perform new user profile configuration as you described in your post. 3. Stop capturing after successfully configuring to use Microsoft Exchange. Save the CAP file and ZIP it. Please send it to me at v-genli#microsoft.com In your email, please also provide the following informaiton: FQDN of the roles Internal IP Address GC xxx.xxx.xxx Exchange CAS server xxx.xxx.xxx Mailbox Server xxxx.xxx.xxx This outlook PC xxx.xxx.xxx Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks Gen Lin-MSFT
Free Windows Admin Tool Kit Click here and download it now
March 2nd, 2011 5:20am

Hi Gen Lin, Thanks for helping. I'll run those netmon traces for you today, and email them off as soon as I can. Hopefully it will shed some light on the problem. I can confirm that this is happening on all PCs with Outlook 2007 installed. However, I must clarify that the only PCs that we have Outlook 2007 on are Windows 7 PCs. We have PCs running our older Windows XP SOE image, but they are all running Outlook 2003. The only exception to this is a Windows Server 2008 R2 terminal server, running Outlook 2007, which exhibits the same symptoms as the Windows 7 PCs. I've just realised that I've omitted a very important piece of information. Our network consists of roughly 30 sites spread across Australia, all fully connected and routed over an internal private IP network. Each site has full connectivity to every other site. Each site has a local server acting as an AD controller, which is also a Global Catalog server. This server also provides local DNS and other services to the clients in that office. The one Exchange server is located in our main Head Office site, and has 3 AD/GC servers that it talks to / refers to. There is full connectivity between all remote clients and all central servers - there are no firewalls on the internal network between these systems. This problem is affecting clients located in every site, including the main Head Office site on that are on the same subnet as the Exchange server and it's GC servers. I'll run those traces for you shortly, and email them off along with the other information that you have requested. I look forward to seeing what you can find. Many thanks, Matt Russell Cairns, QLD, AUS.Matt Russell Cairns, QLD, AUS
March 2nd, 2011 6:00pm

Hi Matto, Do you have outlook 2007 GPO's under user configuration > admin templates? Internal clients lookup the "Service Connection Point" to obtain the autodiscover URL's that are used to autoconfigure the mail client. Can you confirm that the service connection point is correct? You can locate it in a few ways but easiest may be through AD sites and services > services... Kind Regards GBF
Free Windows Admin Tool Kit Click here and download it now
March 2nd, 2011 8:33pm

Hi GBF, Thanks for helping. We are using the Outlook 2007 ADMX templates in our GPOs. They're set at our base "All Staff" OU level. To be honest, we don't have many GP options set for Outlook - we try to leave as much in it's default state as possible, and only set the ones that we really feel we need to. I've had a look at the SCP settings through Sites and Services, and it looks OK to me. One thing that does jump out at me is that the Name and ServiceDNSName attributes are both just the hostname of the server, not the FQDN. IE, both those attributes are set to BNEEXCHANGE07, instead of what I would have expected - BNEEXCHANGE07.internaldomain . Of course, I don't have a second server to compare them to to see if that's normal or not. What I CAN tell you is that when I run the Test Email AutoConfiguration utility, with just Autodiscover selected, it returned immediately with the correct information. When you check the log tab, it looks like this: Attempting URL https://BNEEXCHANGE07.internaldomain/Autodiscover/Autodiscover.xml found through SCP Autodiscover to https://BNEEXCHANGE07.internaldomain/Autodiscover/Autodiscover.xml starting Autodiscover to https://BNEEXCHANGE07.internaldomain/Autodiscover/Autodiscover.xml succeeded (0x000000000) Which seems to indicate to me that the SCP is all good? Anything else that you'd like me to check? Thanks! Matt Russell Cairns, QLD, AUS.Matt Russell Cairns, QLD, AUS
March 2nd, 2011 10:00pm

Hello Gen Lin, I've run the netmon trace, and have just emailed it off to you now as requested, along with the other information. Please let me know if you don't receive it, or if you require anything else at all. I've never used Netmon before, but it certianly looks like a powerful tool - I'll need to spend some time to learn it.I hope the capture files makes more sense to you than it does to me though! Thanks again for offering to take a look at it. I hope to hear from you soon. Please let me know if there's any other details or information that you would like. Thanks, Matt Russell.Matt Russell Cairns, QLD, AUS
Free Windows Admin Tool Kit Click here and download it now
March 3rd, 2011 1:13am

Hi Matt, Thanks for the information. I am concerned that outlook is still trying to use the internal email addresses rather than the external/default user email address. If they exist please try removing these hot fixes from the client machine which have been said to cause these types of issues. KB2412171 & KB2405793. Then restart and try the process all over again. Also, with outlook open hold down CTRL and right click the outlook icon by the clock and check "connection status" and advise what value you have under the "Conn" column? Kind Regards GBF
March 3rd, 2011 2:30am

Hi, Agree with GBF. Please first try to uninstall the update KB2412171 & KB2405793 in a client machine and test to see if the issue persists. I will reply once finishing analyzing the network traffics. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks Gen Lin-MSFT
Free Windows Admin Tool Kit Click here and download it now
March 3rd, 2011 3:43am

If they exist please try removing these hot fixes from the client machine which have been said to cause these types of issues. KB2412171 & KB2405793. Then restart and try the process all over again. Hi GBF, Looking at the client machine, it had KB2412171 installed. I uninstalled that updated, rebooted the machine and logged in a new user, and the Autodiscover worked perfectly! I tried it again in case it was just a fluke, but nope - perfect run through the second time as well. I've found the update in our WSUS server, and have changed it's approval status from "Approved for install" to "Approved for removal", so hopefully after this weekend all our clients will automatically uninstall this update from themsevles. I'll ask our Support team in Brisbane to troubleshoot this in a bit more depth, since I'm out of the office fo rthe next few days, but for now I'm quietly optimistic that it's resolved our issue. I'll post back here with conslusive results early next week once we've had the chance to test it a bit more widely than just one machine. Many thanks to both yourself and Gen Lin for your assistance on this - there is no way I would have found that KB as a potential cause myself. Thanks to Gen Lin for analysing the network captures for me - I know that this would have taken considerable time to go through and to understand our infrastructure, so thankyou very much for your assistance. I'll post back with a definitive result early next week, but for now, it's looking pretty good! Thanks! Matt Russell Cairns, QLD, AUSMatt Russell Cairns, QLD, AUS
March 3rd, 2011 9:36pm

Happy to help, well done. Will look out for your post next week. Kind Regards G,
Free Windows Admin Tool Kit Click here and download it now
March 4th, 2011 3:57am

I'm having the exact same problem and it's been driving me nuts! Unfortunately I don't seem to have the same luck as simply removing KB2412171. On an XP sp3 machine atleast, removing this update, restarting, deleting and starting with a fresh mail profile and even local computer account (or different user) profile does not solve the issue. Uninstalling Office 2007 and reinstalling (slipstream sp2) works, but when I re-apply all updates (minus KB2412171) the same symptoms return. If I get a profile up and running just after reinstalling Office then it works fine however after I delete it and re-create the mail profile, symptoms return. Yet to try on a freshly imaged computer which has never had KB2412171 installed. Also testing on some Win7 x64 SP1 machines.
March 4th, 2011 4:35am

Hi Everyone, I'm happy to report that the removal of update KB2412171 has resolved our Autodiscover problems for Outlook 2007. Over the weekend I re-imaged ~30 PC's in two of our regional offices, and every one logged on the users perfectly, setting up the new Outlook profiles immediately without any problems.I was not expecting this to happen, since the image file was captured with the KB update installed, but I'm guessing the PCs must have had sufficient time to contact their local WSUS server and detect the removal notification for the update between the time the image finished applying, and when we logged the users onto the PCs. Many thanks to both GBFraser and Gen Lin for their assistance with this issue - it has been driving us mad for over a year now, and you cannot imagine how happy our Helpdesk staff are that it's now been resolved. Thanks again for your assistance. PCAU - unfortunately I don't have much that I can suggest for your situation, other than to advise that from what you've described, it does sound to me very much like an update is the cause of your problem as well. IE, a clean install of Office 2007 + SP2 works, install the updates, and it breaks. Have you tried removing update KB2405793 as well if it's present? About the only thing I could suggest (and you're REALLY not going to like this) is to step through and apply the updates in batches, to see which "batch" breaks your autodiscover. IE, apply the first half of your updates, and see if the Autodiscover still works. If it does, apply half of the remaining ones, and slowly narrow it down that way. When it stops working, you know the offending update is in that last section. Either re-image the PC and start again, or roll back to a previous system restore point, and work through the suspect batch with a bit more granularity. That's a pretty manual, time intensive process, but it sounds like you've already narrowed it down to a misbehaving update, so now it's just a matter of identifying which one. I wish I could be more helpful. Good luck with your resolution! Matt Russell Cairns, QLD, AUS.Matt Russell Cairns, QLD, AUS
Free Windows Admin Tool Kit Click here and download it now
March 7th, 2011 6:54pm

PCAU, It may be nothing, but a quick bit of googling led me to this article: http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/8af15eba-2616-4e5f-b08a-42fd671c9e9e/ Which seems to indicate that simply removing KB2412171 from an XP machine doesn't fix the problem. Can you try on a freshly imaged XP workstation, applying all the patches WITHOUT applying that specific KB? See if that helps it? If you're using WSUS, you should be able to set that KB to "Approve for Removal", which worked for me and prevents new installations. Also, from that same article, this hotfix might be worth trying: http://support.microsoft.com/kb/2475891 From right down the bottom of that hotfix description: Consider the following scenario: * Your user principle name (UPN) differs from your SMTP address in Office Outlook 2007. * You install the hotfix package that is described in Knowledge Base article 2412171. * You use the Autodiscover service. In this scenario, the Autodiscover service fails. Good luck - I know how annoying this problem is, I wish you all the best with resolving it! Matt RussellMatt Russell Cairns, QLD, AUS
March 7th, 2011 7:03pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics