Windows XP Prompting for credentials on Exchange 2013

OK, so you’ve just installed Exchange 2013. Everything is working fine untill you find that windows XP clients with both outlook 2007 & 2010 are prompting you for passwords.

Both versions of outlook are fully supported as is windows XP & windows 7 clients are working fine so what gives?

The answer as it turns out is quite simple. The Exchange Certificate common name must match the exchange server name. Even if the Exchange server name is listed in the SAN (subject alternative names) windows XP will prompt for credentials. SO you can either make sure that when you create the SAN certificate that the Exchange name is the common name or run the following command:
Set-OutlookProvider EXPR -CertPrincipalName:””
After running the command issue “iisreset”.
Hope this helps anyone with the same issue.

Take note here: If you have windows xp clients that are connecting both internally and externally using Outlook anywhere your going to have to set up split DNS and use the same namespace for both internal & external clients or set up a Proxy (Microsoft TMG or UAG) and issue seperate certificates with seperate common names.


11 thoughts on “Windows XP Prompting for credentials on Exchange 2013

  1. Hello I think this is the same problem I have.
    My certificate is a wildecard.
    I’m in a middle of migration from Exc2007 to exc20013.
    I have done get-outlookprovider on 2007 and 2013, both are empty.

    I’m not so confidant about the command. Now if I want to try your suggest, if I have problem how can I roll back?
    I don’t want to risk to have all client blocked.

    • The trouble is that windows XP doesn’t really support wildcard certificates. Your going need to purchase a UUC certificate and make sure that the common name is the name that your Windows XP clients use to connect to Exchange services.

  2. So what goes in instead of “”??

    • The FQDN defined for users to use for outlook anywhere.
      When you edit the server settings in the ECP one of the options is Outlook Anywhere. The FQDN that is defined for outlook anywhere should be defined instead of

  3. I have used Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:* and it worked very well.

  4. Does this also affect Exchange 2010? I have a couple XP users having this exact problem. I am not the Exchange admin, so I would need forward this post to them if it applies.

    • Possbily, depends on deployment. Exchange 2010 works RPC internally not https over RPC. However free/busy does work https. So yes this could also apply to Exchange 2010 in specific cases.

  5. Thanks for your help getting past this. I made sure the MSSTD: setting matched the name in the Exchange certificate and that worked!

  6. How does this work if we’re running Office 365 in a hybrid environment? Our certificate has as the common name, and SAN & I tried “Set-OutlookProvider -Identity EXCH -CertPrincipalName” but this didn’t resolve the issue.

    • If your in Hybrid mode everything is still the same.
      If the users mailbox is located on your On-Prem Exchange then you need the common name of your cert to match the name used for external access.
      If the mailbox has been migrated to Office 365 then Autodiscover will redirect the user and then certificate management is out of your hands. it is important to note that office 365 still supports Windows XP.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s