The Ultimate Guide– Exchange 2013 and Outlook Password Prompt Mystery

During Exchange migration (2007 –> 2013) in one of my customers I was faced into frustrating issue. Although this basic issue isn’t new, the resolution of this issue required multiple resolution steps. In addition, during my research I couldn’t find a full guide that cover all the required resolution steps, although the Outlook Password Prompt issue was reported by multiplies customers.

In this article I will cover the common issues that I was faced into. In addition, I would cover a few resolution options:

A. Supported Outlook Version

First, its recommended to verify that the Outlook version (and build number) is supported by Exchange 2013.

Exchange 2013 system requirements

B. Incorrect Network Interfaces Binding Order

In case that the Exchange server/s belong to a DAG, the public (users faced network interface) network interface should obtain a higher preference.

In addition,  the following settings should be set in the private (replication faced network interface) network interface:

-Disallow – “Register this connection’s address in DNS”

-Disallow – “Client for Microsoft networks”

-Allow – “Disable NetBIOS over TCP/IP”

-DNS and WINS Servers IP address should be blank

-Default Gateway IP address should be blank

Furthermore, please use “iismgr.msc” and verify that the correct digital certificate is binding to the public (users faced network interface) network interface.

C. Incorrect DNS Records Settings / Duplicate DNS Records

Please verify that all the Exchange servers (legacy and 2013) and clients can “see” the correct IP address / DNS names and the Servers FQDN.

The DNS records may use SRV (e.g. Autodiscovery), A, PTR records, so its recommended to check the correctness of all this records.

Note: Some customers may use Host file. Due this you may need to check the Host file content.

D. Incorrect Active Directory Sites Settings

Please verify that the correct Network Subnets are binding to the correct Active Directory Sites.

E. Incorrect Exchange External/Internal Virtual Directory URL’s

Exchange Virtual Directories should be set to the correct external and internal URL’s.

You can use the following nice guide so set the required URL’s:

Configure External and Internal URL in Exchange 2013,  Bipin Giri

For advanced users, I would recommended to use Power Shell commands:

“$HostName = “Ex2013CAS”

Set-EcpVirtualDirectory “$HostName\ECP (Default Web Site)” -InternalUrl ((Get-EcpVirtualDirectory “$HostName\ECP (Default Web Site)”).ExternalUrl)

Set-WebServicesVirtualDirectory “$HostName\EWS (Default Web Site)” -InternalUrl ((get-WebServicesVirtualDirectory “$HostName\EWS (Default Web Site)”).ExternalUrl)

Set-ActiveSyncVirtualDirectory “$HostName\Microsoft-Server-ActiveSync (Default Web Site)” -InternalUrl ((Get-ActiveSyncVirtualDirectory “$HostName\Microsoft-Server-ActiveSync (Default Web Site)”).ExternalUrl)

Set-OabVirtualDirectory “$HostName\OAB (Default Web Site)” -InternalUrl ((Get-OabVirtualDirectory “$HostName\OAB (Default Web Site)”).ExternalUrl)

Set-OwaVirtualDirectory “$HostName\OWA (Default Web Site)” -InternalUrl ((Get-OwaVirtualDirectory “$HostName\OWA (Default Web Site)”).ExternalUrl)

Set-PowerShellVirtualDirectory “$HostName\PowerShell (Default Web Site)” -InternalUrl ((Get-PowerShellVirtualDirectory “$HostName\PowerShell (Default Web Site)”).ExternalUrl)”

Note 1: In case of MAC computers, please set the correct the Exchange Web Services (EWS) virtual directory URL’s.

Note 2: The URL’s should be set only by using FQDN.

Note 3: Please that during the migration you may need to point the AutoDiscovery URL’s (service connection point (SCP)) to the Exchange 2013 environment, before migrating the mailboxes to the new Exchange server/s. However, in practice you may need to delay the shifting of the AutoDiscovery URL’s (service connection point (SCP))  of the legacy environment to the new one, until all the old mailbox’s would migrated  successfully to the Exchange 2013 environment.

F. Missing Folders / XML configuration files

The first scenario: The autodiscover folder is missing / autodiscover.xml file is corrupt or missing.

Resolution: Please use the following commands according your environment settings :

Remove-AutodiscoverVirtualDirectory and New-AutodiscoverVirtualDirectory

Example:

Remove-AutodiscoverVirtualDirectory -Identity “ServerName\Autodiscover (Default Web Site)”
New-AutodiscoverVirtualDirectory -WebSiteName “ServerName\\Autodiscover (Default Web Site)” -WindowsAuthentication $true -BasicAuthentication $true

The second scenario: The /oab is corrupt or missing.

Resolution: Please use the following commands according your environment settings :

Remove-OabVirtualDirectory and New-OabVirtualDirectory

In addition, its recommended to review the XML file (e.g. autodiscover.xml) content and verify that it represent you environment settings.

G. NTFS Permissions Issue

Please verify that the “Authenticated Users” group has a Read and Execute NTFS permission to the folder and file:

“C:\Program Files\Microsoft\Exchange Server\V15\Client Access\OAB\web.config”

For advanced investigation, you can use Microsoft Process Monitor tool

H. Digital Certificate Issue

Please verify that all the Exchange Servers is using a Digital Certificate that contain all the required Internal/External URL names.

In addition, its recommended to set the “Common Name” to the external Outlook AnyWhere URL name

Furthermore, all the servers and end users computers (including the workgroup computers) should trust the Root Certificate Authority (CA).

In case that you are using a Certificate Authority (CA) hierarchy, in addition to the above requirement, all the servers and end users computers (including the workgroup computers) should trust the “Intermediate Certificate Authority”.

I. Certificate Principal Mismatch

In this scenario, the end users may see the “incorrect” Principal Name:

image

The resolution require the set the Exchange Provider to use the digital certificate “Common Name” as EXPR.

As said before, its recommended that the “Common Name” of the digital certificate point the the External Outlook Anywhere URL (in the legacy Exchange servers and the Exchange 2013 server/s).

Test Outlook Anywhere Connectivity

Certificate Principal Mismatch

After applying the changes please initiate Active Directory replication and verify that the msExchAutoDiscoverCertPrincipalName attribute was set to the correct value:

image

I would like to thank to Mr. Netanel Ben Shushan for this tip (“msstd:” Smile)

K. Outlook Network Connectivity / Encryption

In this case, you may need verify that the Outlook Settings answer to your environment settings. Failing to setup the correct settings may fail outlook to use the incorrect connection mechanism:

image

 

image

RPC Client Encryption in Exchange 2013, Jeff Guillet  (MVP)

Note: You can use Office Administrative Template (GPO) for this task.

L. Authentication Issue

Verify that the Exchange servers was set to use the correct authentication methods:

“Get-OutlookAnywhere | fl ServerName,IISAuthenticationMethods,InternalClientAuthenticationMethod,ExternalClientAuthenticationMethod,SSLOffloading”

ServerName                         : Old-2007
IISAuthenticationMethods           : {Basic, Ntlm}
InternalClientAuthenticationMethod : Ntlm
ExternalClientAuthenticationMethod : Ntlm
SSLOffloading                      : False

ServerName                         : New1-2013
IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}
InternalClientAuthenticationMethod : Ntlm
ExternalClientAuthenticationMethod : Ntlm
SSLOffloading                      : False

ServerName                         : New2-2013
IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}
InternalClientAuthenticationMethod : Ntlm
ExternalClientAuthenticationMethod : Ntlm
SSLOffloading                      : False

Note 1: Changing the authentication settings may require changing the Outlook settings.

Note 2: Using “IISAuthenticationMethods” “Negotiate” settings as a single authentication method is supported only in a native Exchange 2013 environment that using RPC Over HTTP. Please note that using MAPI over HTTP (disabled by default in Exchange 2013 SP1 CU5) remove this restriction. MAPI over HTTP

Note 3: Using external load balancer may require to enable SSLOffloading. Its highly recommended to review the load balancer documentation for further information.

Note 4: After completing the migration its recommended to remove lower authentication methods. However, this changes require a carful planning and testing. Due this this changes aren’t cover in this article.

M. Incorrect ExternalClientsRequireSSl / InternalClientsRequireSSl Settings

Users Constantly Prompted for Credentials after Being Migrated to Exchange 2013

N. Incorrect “LegacyExchangeDN” in the DatabaseName Attribute

How to change the RPCClientAccessServer for Exchange 2013, Percy McNab

O. Incorrect Credentials Vault Content

Solution: Outlook (2007,2010,2013,365) prompts me for credentials each time I open, Shaun Cassells

P. Antivirus / Security Software

Some Antivirus / Security Software may block Outlook connection (e.g. Outlook Anywhere proxy traffic / Redirection traffic, etc.). From my point of view it recommended to remove the Antivirus / Security Software, complete the migration and then deploy the Antivirus / Security Software according the vendor and Microsoft best practices. However, removing the Antivirus / Security Software may expose the Exchange server/s to risk so its highly recommended to review this recommendation answer to your company policy.

Q. Windows XP Clients

In case of Windows XP clients, I recommended to upgrade to a officially supported operating system version.

In the past I was covered some of the common issues: Connecting To Exchange 2013 Server By Using Outlook Client From a Windows XP Workstation May Result a Password Prompt .

In addition, you may use the solutions in: http://social.technet.microsoft.com/Forums/exchange/en-US/a7c25d6a-7cfc-40a1-a17e-a1f05f637d53/exchange-2010outlook-anywherewindows-xp-not-working-together?forum=exchange2010 but please aware that I didn’t use it by practice, so you will use it on you on risk.

R. “Exchange Back End” Autodiscover Virtual Directory Providers

Due GPO (Group Policy Object) settings, the “Negotiate” provider may automatically removed or may become less preference then NTLM.

After resolving the GPO (Group Policy Object) issue, you may need to re-configure the “Exchange Back End” Autodiscover Virtual Directory according to the following settings:

Capture

Archives