1

After this latest round of Windows updates (on 1/11/11, in fact) my Exchange 2007 server of course rebooted. This may have had the side effect of making any changes I'd inadvertently made take effect.

Since then, the Autodiscover service in Exchange 2007 from Outlook 2007 seems to reply with the User Principal Name (username@example-domain.com instead of firstname.lastname@externaldomain.com). I'm specifically seeing this from within the "Test Email AutoConfiguration" tool in Outlook (the UPN appears in the first text box labeled "E-mail") and when creating a new profile in Outlook. If I disregard the UPN and instead fill in my email address, Autodiscover works as expected and I can connect without issue.

I've confirmed using ADSI Edit that the SMTP email address is properly set for my users. I even went a bit crazy and set the UPN to the email address using ADSI Edit, to no avail. I've re-installed the Client Access role on the server in question.

Exchange server is Server 2008, 64-bit of course. Clients are mostly XP 32-bit, though the issue happens from a Windows 7 machine as well.

Output of "Test-OutlookWebServices -Identity:jeff.mcjunkin@external-domain.com" (real username, replaced domain):

Id : 1003 Type : Information Message : About to test AutoDiscover with the e-mail address jeff.mcjunkin@external-domain.com.

Id : 1012 Type : Warning Message : XML>Unknown Node:AutoDiscoverSMTPAddress AutoDiscoverSMTPAddress Line :http://schemas.microsoft.com/exchange/autodiscover/outlook/responses chema/2006a

Id : 1012 Type : Warning Message : XML>Object being deserialized: Microsoft.Exchange.Management.SystemCo nfigurationTasks.AutoDiscoverUser

Id : 1012 Type : Warning Message : XML>Element

Id : 1012 Type : Warning Message : XML>Unknown Element:System.Xml.XmlElement Line:8(8) jeff.mcjunkin@external-domain.com

Id : 1006 Type : Information Message : The Autodiscover service was contacted at https://cppmail02v.CPCH.ci. central-point.or.us/Autodiscover/Autodiscover.xml.

Id : 1016 Type : Success Message : [EXCH]-Successfully contacted the AS service at https://exchange01.active.directory.domain/EWS/Exchange.asmx. The elapsed time was 15 milliseconds.

Id : 1015 Type : Information Message : [EXCH]-The OAB is not configured for this user.

Id : 1014 Type : Success Message : [EXCH]-Successfully contacted the UM service at https://exchange01.active.directory.domain/UnifiedMessaging/Service.asmx. The elapsed time was 15 milliseconds.

Id : 1016 Type : Information Message : [EXPR]-The AS is not configured for this user.

Id : 1015 Type : Information Message : [EXPR]-The OAB is not configured for this user.

Id : 1014 Type : Information Message : [EXPR]-The UM is not configured for this user.

Id : 1013 Type : Error Message : When contacting https://exchange01.active.directory.domain/Rpc received the error The remote server returned an error: (404) Not Found .

Id : 1017 Type : Error Message : [EXPR]-Error when contacting the RPC/HTTP service at https://exchange01.active.directory.domain/Rpc. The elapsed time was 0 millisecon ds.

Id : 1006 Type : Success Message : The Autodiscover service was tested successfully.

Id : 1021 Type : Information Message : The following web services generated errors. Contacting server in EXPR Please use the prior output to diagnose and correct the errors.

Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
Jeff McJunkin
  • 1,372
  • 1
  • 8
  • 16
  • No known DC issues, all DC's are replicating properly. Changing the mail attribute via ADSI Edit or ADUC has no effect, nor does changing the primary SMTP address of a user. – Jeff McJunkin Jan 17 '11 at 20:06
  • Do you have a list of the MS KB numbers? – SLY Jan 17 '11 at 21:23
  • All of the latest. I use WSUS and applied all patches on Tuesday night. I may have to revisit that policy after this is resolved :) – Jeff McJunkin Jan 17 '11 at 22:47

4 Answers4

2

A lot of people had problems with the original version of this update http://support.microsoft.com/kb/2412171 It seemed that the best option was to uninstall it.

From the cached version of http://blogs.office.com/b/microsoft-outlook/archive/2011/01/13/fixes-for-issues-with-december-update-for-outlook-2007-have-been-released.aspx

janegilring 15 Jan 2011 11:23 AM Ive experienced problems with Autodiscover when setting up new Outlook-profiles after installing this update. Instead of pre-populating the E-mail address field with the user s primary SMTP-address, the user`s UPN was used. This of course caused Autodiscover to fail since the UPN was not an alias on the mailboxes.

After uninstalling the latest Outlook 2007 update the issue was resolved, and the primary SMTP-address was pre-populated.

I`ve also experienced the issue with Outlook 2010, removing the latest hotfix package resolved the issue.

The affected updates:

Description of the Outlook 2010 hotfix package: December 14, 2010

support.microsoft.com/.../2459115

Description of the Office Outlook 2007 update: January 11, 2011

support.microsoft.com/.../2412171

The Outlook 2007 update are released to Windows Update/WSUS, while the Outlook 2010 hotfix package must be requested afaik.

Is this a known issue, and is it due to be fixed in upcoming updates?

To Uninstall:

How to uninstall this update Click

Start, and then click Run. Type

appwiz.cpl, and then click OK. Use one

of the following procedures, depending

on the operating system that you are

running: Windows 7 and Windows Vista

Click View installed updates. In the

list of updates, locate and click

update 2412171, and then click

Uninstall. Windows XP Click to select

the Show updates check box. In the

list of updates, locate and click

update 2412171, and then click Remove.

Community
  • 1
SLY
  • 1,286
  • 1
  • 13
  • 28
  • That's an **Outlook** update, not an **Exchange** update. – Ben Pilbrow Jan 17 '11 at 21:25
  • I know it's an outlook update and not an exchange update, but it seems that it may be causing the symptoms. Might at least be worth a shot? – SLY Jan 17 '11 at 21:28
  • While your extra edit does certainly sound better (with the AutoDiscover problems), it still wouldn't explain the unusual output of `Test-OutlookWebServices` on the server. – Ben Pilbrow Jan 17 '11 at 21:31
  • As I read the output of Test-OutlookWebServices, everything is working except RPC over HTTP. – SLY Jan 17 '11 at 21:35
  • The XML errors shouldn't be there - it might be some weird corrupted autodiscover virtual directory – Ben Pilbrow Jan 17 '11 at 21:39
  • But if autodiscover was experiencing problems why would autodiscover work sometimes? As you say in your post "If I disregard the UPN and instead fill in my email address, Autodiscover works as expected and I can connect without issue." – SLY Jan 17 '11 at 21:46
  • Manually entering your email is not AutoDiscover, the pre-populating of that field is AutoDiscover (which I assume falls back to UPN on failure). – Ben Pilbrow Jan 17 '11 at 21:52
  • This is the technet article on Autodiscover http://technet.microsoft.com/en-us/library/bb232838(EXCHG.80).aspx . My sense is that in this image http://i.technet.microsoft.com/Bb232838.983defb2-7a4b-477c-b91e-31b89582561c(en-us,EXCHG.80).gif all of the communication between the server and client are working. However between 2 and 3, the client is sending the wrong information, UPN instead of e-mail address. – SLY Jan 17 '11 at 22:01
  • It's certainly possible (I'm not saying you're wrong by the way, I'm just interpreting it differently). The way I see it is all of the steps fail, so it does some sort of "sensible fallback" of UPN. If @Jeff McJunkin replies to my comment about out of office in my answer, that should answer whether or not autodiscover is fundamentally broken (as it relies on autodiscover). – Ben Pilbrow Jan 17 '11 at 22:09
  • Thanks for the discussion. A quick first try of uninstalling KB2412171 didn't seem to resolve the issue, but I'll look into it further (with original Outlook 2007 without patches, for example). I agree with the UPN being the fallback option, as it seems to have a bit of a delay (less than a second) before being filled in. I've taken Wireshark captures and can see a successful LDAP query and response. – Jeff McJunkin Jan 17 '11 at 22:41
  • An original installation of Outlook 2007 doesn't appear to have this issue. I think we're on the right track. I'll investigate further and post back. – Jeff McJunkin Jan 18 '11 at 17:33
  • Great. Let us know what happens. – SLY Jan 18 '11 at 18:38
  • 1
    Whew! It's a tough day to uninstall a patch on all domain-joined machines, even with scripting help. I've confirmed that particular patch was the issue. I had a false reading earlier because the patch was immediately reinstalled by WSUS (until I denied the patch, ran "wuauclt /detectnow" on all clients, and then uninstalled it again). Thanks for your help! – Jeff McJunkin Jan 18 '11 at 23:21
1

Uninstall KB2412171 on your client. This fixes the problem. To my knowledge, MS has yet to address this problem. Extremely frustrating...

Chuck
  • 11
  • 1
0

I've just done a little experiment on a virtual machine (I didn't have Exchange 2007 handy, so it was Exchange 2010, but I don't believe there's going to be much difference) and it's confirmed my suspicions.

The value comes from the E-mail field on the General tab of Active Directory Users and Computers, so if you change that field to something else, the Outlook AutoDiscover value should change to reflect that.

alt text

Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
  • That's where it *should* be coming from. In my case the E-mail attribute is set properly, but that portion of Autodiscover is still giving me the UPN instead of the email address for the user. – Jeff McJunkin Jan 17 '11 at 19:44
  • Are your Domain Controllers all functioning and replicating properly? Which attribute are you checking in Active Directory? It should be the `mail` attribute. – Ben Pilbrow Jan 17 '11 at 19:52
  • dcdiag /a returns all successes, with the exception of print driver errors from TS (in event log, not relevant). Confirmed through ADSI Edit on a DC that the mail attribute contains the correct email address, but Outlook returns the UPN. – Jeff McJunkin Jan 17 '11 at 19:59
  • OK, how about running `Test-OutlookWebServices -Identity first.last@acme-widgets.com |fl` in the Exchange Management Shell. Does that give anything useful? – Ben Pilbrow Jan 17 '11 at 20:16
  • Added sanitized output to question. Admittedly it doesn't make much sense to me, though I haven't dived into it yet. – Jeff McJunkin Jan 17 '11 at 20:33
  • Are all the required services running? Does `Test-ServiceHealth` report any required services are not started? Your output of `Test-OutlookWebServices` is definitely not right, and it might be as simple as a stopped service, but it could be something else. – Ben Pilbrow Jan 17 '11 at 20:55
  • Also, is the Out of office option in Outlook functioning correctly? – Ben Pilbrow Jan 17 '11 at 21:57
  • One more thing! If you fill in the details correctly on the Outlook Test autoconfiguration status and run the tool, does that give you any warnings/errors or other clues? – Ben Pilbrow Jan 17 '11 at 22:10
  • Test-ServiceHealth comes back clean. OOF options haven't been tested recently (though I'll give it a shot later today), and as originally stated when manually filling in details (really just email address) and walking through the wizard, Outlook runs as expected. – Jeff McJunkin Jan 17 '11 at 22:45
  • I think the OOF working (or not) will tell you whether Autodiscover is fundamentally broken, because it gets the OOF URL from Autodiscover, and Outlook gives some silly *server not available* error if it doesn't have a valid OOF URL. – Ben Pilbrow Jan 17 '11 at 22:47
  • I've confirmed OOF is working properly. It looks like user49995 had the correct solution, though this is obviously a *very* strange problem. In almost all Autodiscover issues your answer would've been correct. Thank you! – Jeff McJunkin Jan 18 '11 at 23:20
  • No worries, I've stuck a +1 on his answer too. That's the great thing about this site, everyone has a different idea, and often one of them is correct. – Ben Pilbrow Jan 18 '11 at 23:27
0

This may be a simple answer but if I'm not mistaken , the email address that Autodiscover uses (and the address that populates the email address field on the General tab of the user object properties) is the email address that's set as the Primary SMTP address. Is the UPN set as the Primary SMTP address for this user? Could that be what's causing the problem?

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • Unfortunately not. A few users have coincidentally had the UPN set as a valid email address, but none as primary. Additionally, this is affecting users that don't have the UPN set as a valid SMTP address, let alone the primary. Thanks for taking a shot though! – Jeff McJunkin Jan 17 '11 at 22:47
  • Glad to pitch in... – joeqwerty Jan 18 '11 at 00:12