CAS Array and Outlook anywhere profiles

Hello !
I'm planning to set up a CAS array from an existing CAS server. I red that after changing RpcClientAccessServer parameter, users Outlook profiles would not be updated automatically for internal users, but I was wondering if it could work for external users
using Outlook Anywhere ? We have no internal user (since our Exchange environment is in a datacenter).
Thanks

Hi,
After changing the RpcClientAccessServer parameter, all clients including Outlook Anywhere users will lose connection without any configuration update.
For more information, you can refer to the following article:
http://blogs.technet.com/b/aljackie/archive/2013/11/14/outlook-rpc-end-point-and-pf-the-microsoft-exchange-administrator-has-made-a-change-that-requires-you-quit-and-restart-outlook.aspx
“To add further on the CAS array, the Outlook clients with an existing Outlook profile would continue to use the old RPC endpoint rather than the new RPC endpoint (even though Autodiscover detected the change). This is because the old RPC endpoint does not
return an ecWrongServer response to the client. The RPC endpoint accepts the connection; therefore, Outlook ignores the Autodiscover response because it has a working connection.”
We can recreate profile or move database to resolve the issue.
Best regards,
Angela Shi
TechNet Community Support

Similar Messages

  • Some Outlook clients getting internal FQDN of newly installed Exchange 2013 CAS server as Outlook Anywhere Proxy address

    Hello Folks,
    I have this problem and is making me crazy if anyone have any idea please shed some light on this:-
    1. Working Outlook 2010 and 2013 clients with webmail.xyz.com as Outlook Anywhere proxy address.
    2. Installed new Exchange 2013 server (server02)with CAS and Mailbox role, Exchange install wizard finished and server is rebooted.
    3. Server came up online started changing internal and external FQDN's of Virtual Directories and Outlook Anywhere to webmail.xyz.com
    4. As soon as Fqdn's changed some outlook clients create support request that Outlook suddenly white's out and after reopening it is giving error  cannot connect to exchange. upon checking Clients Exchange Proxy address is set to http://server02.xyz.com,
    even though OA/OWA/ECP/OAB/EWS/Autodiscover/ActiveSync FQDN's Point to webmail.xyz.com, on all servers if i create new outlook profile for same user it picks up correct settings through autodiscover and connects fine, this is happening to about 20% of outlook
    clients every time i am introducing new Exchange 2013 server in Organization. we have around 2000 users and planning on installing 4 exchange servers to distribute load and everytime changing outlook profile of close to 150-200 users is not possible.
    Any help is greatly appreciated.
    Thanks
    Cool

    Here are the EXCRA results
    Here IP (x.x.x.x) returned is my Load Balancer IP (Webmail.xyz.com).    
    Connectivity Test Successful with Warnings
    Test Details
         Testing Outlook connectivity.
         The Outlook connectivity test completed successfully.
              Additional Details
         Elapsed Time: 9881 ms.
              Test Steps
              The Microsoft Connectivity Analyzer is attempting to test Autodiscover for [email protected].
         Autodiscover was tested successfully.
              Additional Details
         Elapsed Time: 2063 ms.
              Test Steps
              Attempting each method of contacting the Autodiscover service.
         The Autodiscover service was tested successfully.
              Additional Details
         Elapsed Time: 2063 ms.
              Test Steps
              Attempting to test potential Autodiscover URL https://xyz.com:443/Autodiscover/Autodiscover.xml
         Testing of this potential Autodiscover URL failed.
              Additional Details
         Elapsed Time: 186 ms.
              Test Steps
              Attempting to resolve the host name xyz.com in DNS.
         The host name couldn't be resolved.
           Tell me more about this issue and how to resolve it
              Additional Details
         Host xyz.com couldn't be resolved in DNS InfoNoRecords.
    Elapsed Time: 186 ms.
         Attempting to test potential Autodiscover URL https://autodiscover.xyz.com:443/Autodiscover/Autodiscover.xml
         Testing of the Autodiscover URL was successful.
              Additional Details
         Elapsed Time: 1876 ms.
              Test Steps
              Attempting to resolve the host name autodiscover.xyz.com in DNS.
         The host name resolved successfully.
              Additional Details
         IP addresses returned: x.x.x.x
    Elapsed Time: 338 ms.
         Testing TCP port 443 on host autodiscover.xyz.com to ensure it's listening and open.
         The port was opened successfully.
              Additional Details
         Elapsed Time: 173 ms.
         Testing the SSL certificate to make sure it's valid.
         The certificate passed all validation requirements.
              Additional Details
         Elapsed Time: 318 ms.
              Test Steps
              The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover.xyz.com on port 443.
         The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
              Additional Details
         Remote Certificate Subject: CN=webmail.xyz.com, Issuer: CN=VeriSign Class 3 Secure Server CA - G3, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US.
    Elapsed Time: 219 ms.
         Validating the certificate name.
         The certificate name was validated successfully.
              Additional Details
         Host name autodiscover.xyz.com was found in the Certificate Subject Alternative Name entry.
    Elapsed Time: 1 ms.
         Certificate trust is being validated.
         The certificate is trusted and all certificates are present in the chain.
              Test Steps
              The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=webmail.xyz.com, OU=Terms of use at www.verisign.com/rpa (c)05,.
         One or more certificate chains were constructed successfully.
              Additional Details
         A total of 1 chains were built. The highest quality chain ends in root certificate CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign,
    Inc.", C=US.
    Elapsed Time: 36 ms.
         Analyzing the certificate chains for compatibility problems with versions of Windows.
         Potential compatibility problems were identified with some versions of Windows.
              Additional Details
         The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature
    isn't enabled.
    Elapsed Time: 5 ms.
         Testing the certificate date to confirm the certificate is valid.
         Date validation passed. The certificate hasn't expired.
              Additional Details
         The certificate is valid. NotBefore = 1/3/2013 12:00:00 AM, NotAfter = 11/16/2015 11:59:59 PM
    Elapsed Time: 0 ms.
         Checking the IIS configuration for client certificate authentication.
         Client certificate authentication wasn't detected.
              Additional Details
         Accept/Require Client Certificates isn't configured.
    Elapsed Time: 289 ms.
         Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
         The Microsoft Connectivity Analyzer successfully retrieved Autodiscover settings by sending an Autodiscover POST.
              Additional Details
         Elapsed Time: 756 ms.
              Test Steps
              The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.xyz.com:443/Autodiscover/Autodiscover.xml for user [email protected].
         The Autodiscover XML response was successfully retrieved.
              Additional Details
         Autodiscover Account Settings
    XML response:
    <?xml version="1.0"?>
    <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
    <DisplayName>Test Exch1</DisplayName>
    <LegacyDN>/o=DOMAIN/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=add423106fbb47d5bf237462f52b8dab-Test Exch1</LegacyDN>
    <DeploymentId>4ec753c9-60d9-4c05-9451-5b24e2d527a7</DeploymentId>
    </User>
    <Account>
    <AccountType>email</AccountType>
    <Action>settings</Action>
    <Protocol>
    <Type>EXCH</Type>
    <Server>[email protected]</Server>
    <ServerDN>/o=DOMAIN/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/[email protected]</ServerDN>
    <ServerVersion>73C0834F</ServerVersion>
    <MdbDN>/o=DOMAIN/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/[email protected]/cn=Microsoft Private MDB</MdbDN>
    <ASUrl>https://webmail.xyz.com/ews/exchange.asmx</ASUrl>
    <OOFUrl>https://webmail.xyz.com/ews/exchange.asmx</OOFUrl>
    <OABUrl>https://webmail.xyz.com/OAB/6a6a06ad-4717-4636-bd98-0b4fa3aaf4a5/</OABUrl>
    <UMUrl>https://webmail.xyz.com/ews/UM2007Legacy.asmx</UMUrl>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <PublicFolderServer>webmail.xyz.com</PublicFolderServer>
    <AD>DC-03.domain.xyz.com</AD>
    <EwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EwsUrl>
    <EmwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EmwsUrl>
    <EcpUrl>https://webmail.xyz.com/ecp/</EcpUrl>
    <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-um>
    <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-aggr>
    <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=domain.xyz.com</EcpUrl-mt>
    <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-ret>
    <EcpUrl-sms>?rfr=olk&amp;p=sms/textmessaging.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-sms>
    <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-photo>
    <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tm>
    <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmCreating>
    <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmEditing>
    <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-extinstall>
    <ServerExclusiveConnect>off</ServerExclusiveConnect>
    </Protocol>
    <Protocol>
    <Type>EXPR</Type>
    <Server>webmail.xyz.com</Server>
    <ASUrl>https://webmail.xyz.com/ews/exchange.asmx</ASUrl>
    <OOFUrl>https://webmail.xyz.com/ews/exchange.asmx</OOFUrl>
    <OABUrl>https://webmail.xyz.com/OAB/6a6a06ad-4717-4636-bd98-0b4fa3aaf4a5/</OABUrl>
    <UMUrl>https://webmail.xyz.com/ews/UM2007Legacy.asmx</UMUrl>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <SSL>On</SSL>
    <AuthPackage>Ntlm</AuthPackage>
    <EwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EwsUrl>
    <EmwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EmwsUrl>
    <EcpUrl>https://webmail.xyz.com/ecp/</EcpUrl>
    <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-um>
    <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-aggr>
    <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=domain.xyz.com</EcpUrl-mt>
    <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-ret>
    <EcpUrl-sms>?rfr=olk&amp;p=sms/textmessaging.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-sms>
    <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-photo>
    <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tm>
    <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmCreating>
    <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmEditing>
    <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-extinstall>
    <ServerExclusiveConnect>on</ServerExclusiveConnect>
    <EwsPartnerUrl>https://webmail.xyz.com/ews/exchange.asmx</EwsPartnerUrl>
    <GroupingInformation>Default-First-Site-Name</GroupingInformation>
    </Protocol>
    <Protocol>
    <Type>WEB</Type>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <Internal>
    <OWAUrl AuthenticationMethod="Basic, Fba">https://webmail.xyz.com/owa/</OWAUrl>
    <Protocol>
    <Type>EXCH</Type>
    <ASUrl>https://webmail.xyz.com/ews/exchange.asmx</ASUrl>
    </Protocol>
    </Internal>
    <External>
    <OWAUrl AuthenticationMethod="Fba">https://webmail.xyz.com/owa/</OWAUrl>
    <Protocol>
    <Type>EXPR</Type>
    <ASUrl>https://webmail.xyz.com/ews/exchange.asmx</ASUrl>
    </Protocol>
    </External>
    </Protocol>
    <Protocol>
    <Type>EXHTTP</Type>
    <Server>webmail.xyz.com</Server>
    <ASUrl>https://webmail.xyz.com/ews/exchange.asmx</ASUrl>
    <OOFUrl>https://webmail.xyz.com/ews/exchange.asmx</OOFUrl>
    <OABUrl>https://webmail.xyz.com/OAB/6a6a06ad-4717-4636-bd98-0b4fa3aaf4a5/</OABUrl>
    <UMUrl>https://webmail.xyz.com/ews/UM2007Legacy.asmx</UMUrl>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <SSL>On</SSL>
    <AuthPackage>Ntlm</AuthPackage>
    <EwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EwsUrl>
    <EmwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EmwsUrl>
    <EcpUrl>https://webmail.xyz.com/ecp/</EcpUrl>
    <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-um>
    <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-aggr>
    <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=domain.xyz.com</EcpUrl-mt>
    <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-ret>
    <EcpUrl-sms>?rfr=olk&amp;p=sms/textmessaging.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-sms>
    <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-photo>
    <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tm>
    <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmCreating>
    <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmEditing>
    <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-extinstall>
    <ServerExclusiveConnect>On</ServerExclusiveConnect>
    </Protocol>
    <Protocol>
    <Type>EXHTTP</Type>
    <Server>webmail.xyz.com</Server>
    <ASUrl>https://webmail.xyz.com/ews/exchange.asmx</ASUrl>
    <OOFUrl>https://webmail.xyz.com/ews/exchange.asmx</OOFUrl>
    <OABUrl>https://webmail.xyz.com/OAB/6a6a06ad-4717-4636-bd98-0b4fa3aaf4a5/</OABUrl>
    <UMUrl>https://webmail.xyz.com/ews/UM2007Legacy.asmx</UMUrl>
    <Port>0</Port>
    <DirectoryPort>0</DirectoryPort>
    <ReferralPort>0</ReferralPort>
    <SSL>On</SSL>
    <AuthPackage>Ntlm</AuthPackage>
    <EwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EwsUrl>
    <EmwsUrl>https://webmail.xyz.com/ews/exchange.asmx</EmwsUrl>
    <EcpUrl>https://webmail.xyz.com/ecp/</EcpUrl>
    <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-um>
    <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-aggr>
    <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=domain.xyz.com</EcpUrl-mt>
    <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-ret>
    <EcpUrl-sms>?rfr=olk&amp;p=sms/textmessaging.slab&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-sms>
    <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-photo>
    <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tm>
    <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmCreating>
    <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-tmEditing>
    <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=domain.xyz.com</EcpUrl-extinstall>
    <ServerExclusiveConnect>On</ServerExclusiveConnect>
    </Protocol>
    </Account>
    </Response>
    </Autodiscover>HTTP Response Headers:
    request-id: 9d325a80-f1fd-4496-ac48-2be6bb782c28
    X-CalculatedBETarget: Server01.domain.xyz.com
    X-DiagInfo: Server01
    X-BEServer: Server01
    Persistent-Auth: true
    X-FEServer: Server01
    Content-Length: 11756
    Cache-Control: private
    Content-Type: text/xml; charset=utf-8
    Date: Mon, 25 Aug 2014 19:12:25 GMT
    Set-Cookie: X-BackEndCookie=S-1-5-21-1293235207-2459173341-1304346827-14544=u56Lnp2ejJqBypqcnsfJx5nSy8ucnNLLnJzP0sfKz8/Sy5nHmsiamZrMyZrLgYHPxtDNy9DNz87L387Gxc7Nxc3J; expires=Thu, 25-Sep-2014 00:12:26 GMT; path=/Autodiscover; secure; HttpOnly
    Server: Microsoft-IIS/8.5
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET
    Elapsed Time: 756 ms.
         Autodiscover settings for Outlook connectivity are being validated.
         The Microsoft Connectivity Analyzer validated the Outlook Autodiscover settings.
              Additional Details
         Elapsed Time: 0 ms.
         Testing RPC over HTTP connectivity to server webmail.xyz.com
         RPC over HTTP connectivity was verified successfully.
              Additional Details
         HTTP Response Headers:
    request-id: 835acf95-78b7-40ae-b232-117318d1577e
    Server: Microsoft-IIS/8.5
    WWW-Authenticate: Basic realm="webmail.xyz.com",Negotiate,NTLM
    X-Powered-By: ASP.NET
    X-FEServer: Server01
    Date: Mon, 25 Aug 2014 19:12:26 GMT
    Content-Length: 0
    Elapsed Time: 7817 ms.
              Test Steps
              Attempting to resolve the host name webmail.xyz.com in DNS.
         The host name resolved successfully.
              Additional Details
         IP addresses returned: x.x.x.x
    Elapsed Time: 107 ms.
         Testing TCP port 443 on host webmail.xyz.com to ensure it's listening and open.
         The port was opened successfully.
              Additional Details
         Elapsed Time: 180 ms.
         Testing the SSL certificate to make sure it's valid.
         The certificate passed all validation requirements.
              Additional Details
         Elapsed Time: 303 ms.
              Test Steps
              The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server webmail.xyz.com on port 443.
         The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
              Additional Details
         Remote Certificate Subject: CN=webmail.xyz.com, OU=Terms of use at www.verisign.com/rpa (c)05, Issuer: CN=VeriSign Class 3 Secure Server CA - G3, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign,
    Inc.", C=US.
    Elapsed Time: 224 ms.
         Validating the certificate name.
         The certificate name was validated successfully.
              Additional Details
         Host name webmail.xyz.com was found in the Certificate Subject Common name.
    Elapsed Time: 0 ms.
         Certificate trust is being validated.
         The certificate is trusted and all certificates are present in the chain.
              Test Steps
              The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=webmail.xyz.com, OU=Terms of use at www.verisign.com/rpa (c)05,
         One or more certificate chains were constructed successfully.
              Additional Details
         A total of 1 chains were built. The highest quality chain ends in root certificate CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign,
    Inc.", C=US.
    Elapsed Time: 34 ms.
         Analyzing the certificate chains for compatibility problems with versions of Windows.
         Potential compatibility problems were identified with some versions of Windows.
              Additional Details
         The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature
    isn't enabled.
    Elapsed Time: 5 ms.
         Testing the certificate date to confirm the certificate is valid.
         Date validation passed. The certificate hasn't expired.
              Additional Details
         The certificate is valid. NotBefore = 1/3/2013 12:00:00 AM, NotAfter = 11/16/2015 11:59:59 PM
    Elapsed Time: 0 ms.
         Checking the IIS configuration for client certificate authentication.
         Client certificate authentication wasn't detected.
              Additional Details
         Accept/Require Client Certificates isn't configured.
    Elapsed Time: 298 ms.
         Testing HTTP Authentication Methods for URL https://webmail.xyz.com/rpc/[email protected]:6002.
         The HTTP authentication methods are correct.
              Additional Details
         The Microsoft Connectivity Analyzer found all expected authentication methods and no disallowed methods. Methods found: Basic, Negotiate, NTLMHTTP Response Headers:
    request-id: 835acf95-78b7-40ae-b232-117318d1577e
    Server: Microsoft-IIS/8.5
    WWW-Authenticate: Basic realm="webmail.xyz.com",Negotiate,NTLM
    X-Powered-By: ASP.NET
    X-FEServer: Server01
    Date: Mon, 25 Aug 2014 19:12:26 GMT
    Content-Length: 0
    Elapsed Time: 296 ms.
         Attempting to ping RPC proxy webmail.xyz.com.
         RPC Proxy was pinged successfully.
              Additional Details
         Elapsed Time: 454 ms.
         Attempting to ping the MAPI Mail Store endpoint with identity: [email protected]:6001.
         The endpoint was pinged successfully.
              Additional Details
         The endpoint responded in 0 ms.
    Elapsed Time: 1007 ms.
         Testing the MAPI Address Book endpoint on the Exchange server.
         The address book endpoint was tested successfully.
              Additional Details
         Elapsed Time: 2177 ms.
              Test Steps
              Attempting to ping the MAPI Address Book endpoint with identity: [email protected]:6004.
         The endpoint was pinged successfully.
              Additional Details
         The endpoint responded in 906 ms.
    Elapsed Time: 918 ms.
         Testing the address book "Check Name" operation for user [email protected] against server [email protected].
         The test passed with some warnings encountered. Please expand the additional details.
           Tell me more about this issue and how to resolve it
              Additional Details
         The address book Bind operation returned ecNotSupported. This typically indicates that your server requires encryption. The Microsoft Connectivity Analyzer will attempt the Address Book test again with encryption.
    NSPI Status: 2147746050
    Elapsed Time: 825 ms.
         Testing the address book "Check Name" operation for user [email protected] against server [email protected].
         Check Name succeeded.
              Additional Details
         DisplayName: Test Exch1, LegDN: /o=DOMAIN/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=add423106fbb47d5bf237462f52b8dab-Test Exch1
    Elapsed Time: 433 ms.
         Testing the MAPI Referral service on the Exchange Server.
         The Referral service was tested successfully.
              Additional Details
         Elapsed Time: 1808 ms.
              Test Steps
              Attempting to ping the MAPI Referral Service endpoint with identity: [email protected]:6002.
         The endpoint was pinged successfully.
              Additional Details
         The endpoint responded in 953 ms.
    Elapsed Time: 949 ms.
         Attempting to perform referral for user /o=DOMAIN/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=add423106fbb47d5bf237462f52b8dab-Test Exch1 on server [email protected].
         We got the address book server successfully.
              Additional Details
         The server returned by the Referral service: [email protected]
    Elapsed Time: 858 ms.
         Testing the MAPI Address Book endpoint on the Exchange server.
         The address book endpoint was tested successfully.
              Additional Details
         Elapsed Time: 626 ms.
              Test Steps
              Attempting to ping the MAPI Address Book endpoint with identity: [email protected]:6004.
         The endpoint was pinged successfully.
              Additional Details
         The endpoint responded in 156 ms.
    Elapsed Time: 154 ms.
         Testing the address book "Check Name" operation for user [email protected] against server [email protected].
         Check Name succeeded.
              Additional Details
         DisplayName: Test Exch1, LegDN: /o=DOMAIN/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=add423106fbb47d5bf237462f52b8dab-Test Exch1
    Elapsed Time: 472 ms.
         Testing the MAPI Mail Store endpoint on the Exchange server.
         We successfully tested the Mail Store endpoint.
              Additional Details
         Elapsed Time: 555 ms.
              Test Steps
              Attempting to ping the MAPI Mail Store endpoint with identity: [email protected]:6001.
         The endpoint was pinged successfully.
              Additional Details
         The endpoint responded in 234 ms.
    Elapsed Time: 228 ms.
         Attempting to log on to the Mailbox.
         We were able to log on to the Mailbox.
              Additional Details
         Elapsed Time: 326 ms.

  • Autodiscover and Outlook Anywhere return http status 401

    Hi, I'm having issues with Autodiscovery (externally) and Outlook Anywhere for some users on our Exchange 2010 (SP3, RU2) setup. Just for information, we have Exchange servers at two AD sites (same forest / domain) with each site having 2 combined client
    access / hub transport servers and 3 mailbox servers (with 2 stretched DAG's across both sites). Site A is internet facing, but site B isn't.
    Autodiscovery
    Internally, it's working fine (using the Test E-mail AutoConfiguration option within Outlook 2010). But externally (using the Microsoft TestConnectivity site), autodiscovery fails, returning the following:
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
    Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
    +Additional Details
       Elapsed Time: 1783 ms.
       + Test Steps
     The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL   https://autodiscover.company.com/AutoDiscover/AutoDiscover.xml
    for user [email protected].
     The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
      +Additional Details
      An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you    are attempting to log onto an Office 365 service, ensure you are using your
    full User Principal Name (UPN).
      Headers received:
      Content-Type: text/html
      Server: Microsoft-IIS/7.5
      WWW-Authenticate: Negotiate,NTLM,Basic realm="autodiscover.company.com"
    The odd thing is, if I browse to the autodiscover file location (externally), then I'm prompted for credentials. When I enter the same credentials that I input into the Microsoft connectivity analyser, I do actually get the correct https status 600 response.
    Also, within EMS, when I run "Test-OutlookWebServices" on Client Access servers in site B, I see the following results...
    RunspaceId : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
    Id         : 1104
    Type       : Error
    Message    : The certificate for the URL https://ExchServer.domain.local/autodiscover/autodiscover.xml is incorrect. For SSL to work, the certificate
    needs
                  to have a subject of ExchServer.domain.local, but the subject that was found is webmail.Company.com. Consider correcting service discovery,
                 or installing a correct SSL certificate.
    RunspaceId : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
    Id         : 1113
    Type       : Error
    Message    : When contacting https://ExchServer.domain.local:443/autodiscover/autodiscover.xml received the error The remote server returned
    an error:
     (500) Internal Server Error.
    RunspaceId : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
    Id         : 1123
    Type       : Error
    Message    : The Autodiscover service couldn't be contacted.
    However - I can't see where Exchange has pulled the "...domain.local" address from for Autodiscovery. Both Get-AutodiscoveryVirtualDirectory and Get-ClientAccessServer both report the correct URLs/URIs with the FQDN of Company.Com (which are on
    the GoDaddy certificate we use both internally and externally).
    Outlook Anywhere
    Whether my issues with Outlook Anywhere are related to Autodiscover, I'm not sure. Users who's mailbox is located at Site A (internet facing) are fine, and Outlook Anywhere works great. But users who's mailbox is at Site B, can't use Outlook Anywhere (Starting
    Outlook in RPCDiag mode shows that it tries to connect, and sometimes establishes a connection for a couple of seconds, then disconnects completely).
    Running "Test-OutlookConnectivity -Protocol:http" on a Client Access server at Site B, passes all but the last scenario (Mailbox::Logon), which throws up the following error:
    RunspaceId                  : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
    ServiceEndpoint             : ExchServer.domain.local
    Id                          : MailboxLogon
    ClientAccessServer          : ExchServer.domain.local.ad.local
    Scenario                    : Mailbox::Logon.
    ScenarioDescription         :
    PerformanceCounterName      : Mailbox: Logon latency
    Result                      : Failure
    Error                       :
    UserName                    : ad.local\extest_a91a4b4076f24
    StartTime                   : 14/01/2014 16:33:27
    Latency                     : -00:00:00.0010000
    EventType                   : Error
    LatencyInMillisecondsString : -1.00
    Identity                    :
    IsValid                     : True
    Testing Outlook Anywhere using Microsoft RCA throws up the error:
    RPC Proxy can't be pinged.
    An HTTP 401 error was received...
    Any help is greatly appreciated. Let me know if I've missed any info!
    Thanks
    Tony

    Hi Guys,
    My first chance today to respond!
    Firstly - thanks for all the information. I really appreciate it.
    Well, the good news is that Outlook Anywhere is now working at Site B. It looks like a combination of disabling Outlook Anywhere at Site B (thanks
    Jon), and then being patient and allowing replication to do its stuff (thanks Rhoderck).
    However RCA is still showing ‘Failed’ with the following error. If it helps to have the full output, please let me know. Just for info, I chose
    the option to test using autodiscovery (rather than manually enter it), which passed fine.
    Attempting to ping RPC proxy webmail.company.com.
    RPC Proxy can't be pinged.
    Additional Details
    An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password.
    If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN). Headers received: Content-Type: text/html Server: Microsoft-IIS/7.5 WWW-Authenticate: Negotiate,NTLM X-Powered-By: ASP.NET Date: Tue, 21 Jan
    2014 09:55:41 GMT Content-Length: 58
    Elapsed Time: 1063 ms.
    RPCProxy - ValidPorts
    Thanks for the 'SoundTrackOfMyLife' link... that looks to be almost identical to my scenario (with the exception of the Kemp LoadMasters). Following
    through the troubleshooting, my CAS servers at Site A (Internet Facing) are showing the registry key 'ValidPorts' as...
    SiteB-ExchCasSvr01:593;SiteB-ExchCasSvr01:49152-65535
    So - should this be...
    SiteB-ExchMbxSvr01:6001-6002;SiteB-ExchMbxSvr01:6004;SiteB-ExchMbxSvr01.domain.local:6001-6002;SiteB-ExchMbxSvr01.domain.local:6004;
    i.e. I only add ports 6001,6002 and 6004 for mailbox servers only? If so, which sites mailbox servers should I put in here?
    SSL Off Loading
    We've only really implemented SSL Offloading on the advice from Kemp (it's built in to their Exchange 2010 template). Apparently, the advantage
    is the LoadMasters have a dedicated hardware processor for decryption/encryption of SSL traffic, thus taking the load off the Exchange servers. Exactly how much of a load this would normally be for our Exchange servers is unknown. We've followed Kemp's documentation
    on unchecking 'Require SSL' for the IIS directories on Site A, and also configured Outlook Anywhere with SSL Offloading through the EMC. This was required as the Kemp's are not re-encrypting traffic to the CAS servers (which are on the same site / LAN
    segment), and we're not a bank... so don't need encryption between the LoadMasters and the client access servers.
    However, Site B (non internet facing) has 'Require SSL' enabled on IIS directories, since (I guess) traffic is encrypted when performing CAS-CAS
    proxying?
    I am, as ever, open to suggestions on this design... since our original design was to use TMG for reverse proxy. It was only the end-of-life issue
    with TMG, and the fact that we opted for the Kemp LoadMasters (which offered ESP as a replacement to TMG) that swung us down this path.
    ESP and SSO are implements on the LoadMaster at Site A (internet facing), which is (was!) not the problem site.
    Thanks again for your time and assistance guys. We’re almost there!
    Tony

  • Migration Exchange 2010 to Exchange 2013 with CAS Array and DAG

    Dear All,
    I am starting the migration of Exchange 2010 2 servers (CAS/Mailbox) with DAG no CAS Array to Exchange 2013 with 2 servers CAS array and 2 Mailbox servers with DAG. I read on some blogs that no requirement of CAS array on Exchange 2013. My concern how to
    configure NLB on CAS servers for the client to connect.
    Please guide and have any deployment guide for this, kindly share.
    Thanks

    Hi ,
    As you said there is no use and meaning of having the cas array in exchange 2013 and also thanks a lot to Microsoft for introducing an single namespace facility in exchange 2013.
    My suggestion and Microsoft recommendation should be to go with hardware load balancers for exchange 2013 rather than using the windows NLB and round robin method.
    Why we need to go for HLB ?
    Disadvantages
    of some load balancing methods :
    Windows
    NLB :-
    If you use Windows NLB then it can provide redundancy on server level failure and not on application level.
    DNS
    round robin :-
    In case if we use the windows round robin method for load balancing then it wouldn't provide server level
    and application level redundancy during the failures.At the Same time we need to manually adjust the DNS records during the server failure but on the client end dns caches will create the issues.
    Configuring NLB for exchange 2013 : 
    http://msexchangeguru.com/2013/08/14/windowsnlb/
    NLB configurations for exchange 2010 and 2013 will be same.
    Configuring round robin for exchange 2013 : 
    http://exchangeserverpro.com/exchange-2013-client-access-server-high-availability/
    Advisable method is to have the CAS and MBX roles on the same box if NLB not comes it to play.Because windows failover clustering and NLB cannot be configured on the same box.In exchange 2013 cas role is a stateless server role so there is no need to have
    that role on a separate box.
    Thanks & Regards S.Nithyanandham

  • CAS Array and DAG Site Resiliency (2 Remote Sites via Point to Point Protocol)

    Hi, we are planning to deploy Exchange HA and Site Resiliency but i had some troubles understanding some concepts.
    Out current configurations settings:
    Datacenter A:
    1 MB/CAS/HT (MB01)
    1 CAS (CAS01)
    1 Point to Point link between Datacenter A and Datacenter B (We create a VLAN in the remote datacenter pointing to the Active Directory site where our Exchange server is).
    1 Active Directory Site with 2 Domain controllers (with VLAN 192.1.3.x in Datacenter A and VLAN 192.1.20.x in Datacenter B)
    Datacenter B:
    We want to install a new Exchange CAS Server (CAS02) in VLAN 192.1.20.x, is it posible to create a CAS Array with this configuration considering the replication network for the cluster in the MS Windows Server NLB, so that our Virtual IP of the cluster points
    to 192.1.3.x VLAN? What are the network considerations to the replication and MAPI network between VLANs? Does we need some third party NLB or this could be achieved with MWS2008R2?
    Same configuration for the DAG, with a new server (MB02) just for the MB role. The idea is to remove the CAS role from MB01 and have 2 Exchange Mailbox servers members of the DAG and 2 Exchange CAS Servers members of the CAS Array, so in case of a disaster
    in Datacenter A our clients automatically failover to Datacenter B in this case all of our clients will be pointing to the CAS Array in their Outlook.
    Hope you can help me with this, i don't know if this is possible with our actual infraestructure.
    Best Regards,
    Gerardo

    Thanks Ed, 
    So in that case we will need at least 4 servers in Datacenter A (2 MB members of DAG and 2 CAS/HUB members of the CAS Array) to get a decent HA solution, Am I correct?
    What about the other server in Datacenter B for DR, it will be a passive node or just another multirole server. So in case of DR (Let's say our Datacenter A is totally wrecked) I will need to switchover manually with my DB backups and switchover the user
    mailbox and outlook clients to point to the DR server? I didn´t get the point of the DR server in Datacenter B, can you explain a little bit more?
    I'm totally agree with you about the false positive failovers because our network doesn't meet that requeriments at all.
    Hope you can help me to clear my mind.
    Best Regards,
    Gerardo

  • Autodiscover and outlook anywhere for multiple domains

    Hello
     I have exchange 2010 SP3 environment  which is currently in production. We have multiple domain names added to accepted domain and it’s working fine.
    I have two different public IP Address for MX (SMTP ) and OWA.
    following DNS records are created with ISP DNS Servers. Below find the example.
    MX Records
    Smtp.abc.com (10.1.202.10) (SMTP /MX)
    Smtp.zxc.com  (10.1.202.10) (SMTP /MX)- new domain
    Smtp.qwe.com  (10.1.202.10) (SMTP /MX) - new domain
    OWA and Autodiscover
    Mail.abc.com (10.1.202.2) (owa)
    Autodiscover.abc.com (10.1.202.2)
    Currently outlook anywhere and  outlook autodiscover  working for (mail.abc.com) domain without having any issues. All the other domain are failing errors when I’m testing the Remote connectivity Analyzer. When I’m trying configure the outlook
    profile it’s not resolving the domain name.
    OWA working for domain they also using the same url to access the OWA (https://Mail.abc.com/owa)
    Any idea how to resolve this issue.
    Aucsna

    Hi,
    Agree with Ed, generally, all names autodicover.SMTPAddressSuffix should be added in the certificate and Public DNS entries.
    Alternatively, you can refer to the following article to simplify the namespace in certificate:
    http://www.msexchange.org/articles-tutorials/exchange-server-2010/mobility-client-access/using-autodiscover-large-numbers-accepted-domains-part1.html
    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make
    sure that you completely understand the risk before retrieving any suggestions from the above link.
    Thanks,
    Angela Shi
    TechNet Community Support

  • Windows Server 2008 R2 Terminal Server and Outlook 2013 Profile

    Really hoping someone can offer some advice on this one as I have wasted far to many cycles trying to figure this out.
     Company I work for recent purchased another company and we are in the process of bringing them into our network.  They currently run a a 2008 R2 terminal server where all users connect to for there day to day work.  A number of applications
    are installed including Office 2013.
    All users have Outlook 2013 configured to access their exchange server for email and this works fine.
    The first step in bringing them into our fold is to add an email account for Our Exchange  server without removing their existing exchange configuration or Outlook Profile.  So the one profile will have both exchange accounts listed and they can
    continue to get email from their server but as well email from our domain.
    I created a MSP file and tested pushing this out using PDQ Deploy to a few workstations here in our office and it works fine.  I then started to work on deploying in their environment.  PDQ Deploy will not work as they are all terminal Services
    Clients.  So I tried to push out via GPO.  I created the GPO Initially wanting to use a package and apply that GPO to an AD group.  However it will not let me deploy a MST as a package.  So I then tried moving it to a script that would
    run at logon.  That too is not working.
    I know I could enter install mode then run the MSIEXEC.EXE \config.MSP but that takes away the ability to control the role out.
    Any other ideas on how to get this done.

    Hi,
    Your issue seems to be out of the scope of this forum. We only focus on issue about RDS/VDI deployment, management and operations. For Oultook related issue you can ask to our MS Office Forum:
    https://social.technet.microsoft.com/Forums/office/en-US/home?category=officeitpro
    Thanks.
    Dharmesh Solanki
    TechNet Community Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

  • CAS Array created but Outlook 2007 still points to first CAS Server

    Hi All,
    I just created a DAG between two servers and CAS Array between two other servers.
    DAG:-       EX01 -Mailbox, CAS,HT (First Exchange Server)
                    EX02-Mailbox
    CAS Array:     CA-HT01 (CAS & HT Role)
                          CA-HT02 (CAS & HT Role)
    I created CAS Array and assigned an FQDN for that array but It does not get changed in outlook 2007 it still uses old server EX01.So when I am shutting down server ex01 for testing all outlook 2007 client
    get disconnected.
    Does this required to change profile for all outlook 2007 users? I am more than 1600 users I am not sure how many users using outlook 2007.
    Please guide.I already configure Autodiscover service as it is suggested somewhere online but no luck.
    Thanks

    Mike,
    I tried with shutdown original RPCCLientAccessServer for two days but still that old value did not
    chnaged to new one.Can you guide me what is the exact method of creating Autodiscover so that outlook 2007 will point to new RPCCLientAccessServe value when
    existing is down/not accessible.
    Thanks
    If the  RPCCLientClientAccess Server referenced in the Outlook profile is not accessible, then Outlook should have found the new one at some point or failed to connect to Exchange entirely. Are you saying the Outlook clients continue to connect to Exchange
    even though the server defined in Outlook was not accessible? 
    If you close and re-open Outlook does it show the new RPCCLientAccessServer value in the profile?
    Twitter!: Please Note: My Posts are provided “AS IS” without warranty of any kind, either expressed or implied.

  • Creating a cas array for exising prd mailbox servers

    Hi
    one of the production site in current environment , mbx databases  rpcclientaccess server  set as individual cas servers .
     we want to point these databases to a cas array ,NLB is already created now remaining is cas array and point the database to cassarry fqdn.
    I just want  to know when we do this change , any client re-configuration is required or automatically redirection will happen to cas arary from outlook client.
    Regards

    I just want  to know when we do this change , any client re-configuration is required or automatically redirection will happen to cas arary from outlook client.
    Hi,
    I'm afraid that you need to manual re-configuration from outlook client.
    I recommend you refer to the following article:
    Demystifying the CAS Array Object - Part 2
    5.A CAS array object should not be configured after creating Exchange Server 2010 databases
    The profile will not update itself because the client will not receive an
    ecWrongServer response from CAS. It will not receive this response because any CAS is a valid connection point for any mailbox database via RPC (over TCP) so clients can survive datacenter switchover/failover events without being reconfigured and all
    an admin has to do is flip the CAS array object DNS record to point to a surviving pool of CAS. Currently the only way to fix mailbox profiles would be a manual profile repair within Outlook, by publishing an Office PRF file via GPO (not going to work for
    non-domain joined machines), or by decommissioning the CAS server named in the users’ profiles so the endpoint is no longer available. This last option should (test test test!!) trigger a full profile repair by Autodiscover in Outlook 2007 or Outlook 2010.
    Outlook 2003 is only repairable with a profile repair or a PRF file. Autodiscover will not as of this article’s writing update a profile to a new server name as part of the normal Autodiscover process which updates the Outlook Anywhere configuration and discovers
    EWS URLs for other features such as OOF Management, Free/Busy, and Inbox Rules management.
    Hope this helps!
    Thanks.
    Niko Cheng
    TechNet Community Support

  • ISA 2006 publish Exchange 2010 Outlook Anywhere with Kerberos Constrained Delegation

    Hi,
    I have two Exchange 2010 Sp1 CAS with Windows Network Loadbalancing. I set up an alternate Serviceaccount and mapped the http,ExchangeMDB,PRF and ExchangeAB SPNs.
    Then i published the Exchange Services via ISA 2006. OWA is working using Internet -> via NTLM -> ISA(webmail.domain.com) -> via KCD -> CAS-Array(ex2010.domain.com)
    I tried the same with Outlook Anywhere (RPC over HTTP) without success.
    Authentication to the ISA via NTLM works fine, but i think the isa server cannot delegate the Credentials successfully to the CAS-Server.
    The ISA Log looks like:
    Allowed Connection ISA 24.11.2011 15:50:40
    Log type: Web Proxy (Reverse)
    Status: 403 Forbidden
    Rule: Exchange 2010 RPC
    Source: Internal (172.16.251.33)
    Destination: (172.18.10.182:443)
    Request: RPC_OUT_DATA
    http://webmail.domain.com/rpc/rpcproxy.dll?ex2010.domain.com:6001
    Filter information: Req ID: 108b89d8; Compression: client=No, server=No, compress rate=0% decompress rate=0%
    Protocol: https
    So i always get a 403 Forbidden from the CAS.
    I the IIS logfile from the cas server i see this entry:
    2011-11-24 15:51:37 172.18.10.182 RPC_OUT_DATA /rpc/rpcproxy.dll ex2010.domain.com:6001 443 - <ISA IP> MSRPC 401 1 2148074254 203
    I use the same Listener for OWA and Outlook Anywhere. Authentication Methods are Basic and Integrated. I forward the request to a webfarm which exists of the two physical CAS. Internal Site Name is set to the NLB name ex2010.domain.com, SPN is set to http/ex2010.domain.com
    Thanks for your support

    Hi, i ran into the same Problem.
    the steps above solved mine too (Creating a custom AppPool which runs under LocalSystem).
    I wonder why they included only the Script: convertoabtovdir.ps1
    http://social.technet.microsoft.com/Forums/en-US/Forefrontedgegeneral/thread/dc24ccd3-378a-47cc-bbbf-48236f8fe5b0
    Ist this a supported configuration (changing AppPool of RPC)?

  • CAS array internal DNS IP address best practice

    Hi, Just a question about a best practice approach for DNS and CAS arrays.
    I have an Exchange 2010 Org. I have two CAS/HUB servers and two MBX servers. My external DNS (mail.mycompany.biz) host record points to a public IP address which is NAT'd to the internal IP address of my NLB CAS cluster. I maintain a split brain
    DNS. Should the internal DNS entry for mail.mycompany.biz also point to the public IP address or should it point to the internal IP address of the NLB cluster?

    A few comments:
    The reason you have split DNS is to do exactly these sort of things: inside users hit the inside IP and outside users hit the outside IP.  You'll have to look at your overall network design to see if it makes sense for users to take this shortest route
    to the services, or if there is value in knowing all users simply take the same path.
    You should not be using the same DNS name for your web services (e.g. OWA) as you are for your CAS array.  This can cause very long connection delays on Outlook clients, not to mention overall confusion in your design.  Many orgs will use something
    like "outlook.domain.com" for the Client Access Array and "mail.domain.com" for the web services.  Only the later of these two need to be exposed to the internet.
    Keep in mind, Exchange 2013 dramatically changes this guidance.  There is no more CAS array, and the
    recommended design is to use dedicated namespaces for each web service.
    Mike Crowley | MVP
    My Blog --
    Planet Technologies

  • Troubleshooting for RPC over https (Outlook Anywhere) connection issue

    RPC over https (ROH), well known as Outlook Anywhere, is more frequently used. Even in Exchange 2013, Outlook no longer connects CAS server via MAPI.
    In this thread, we will discuss about the troubleshoot checklist about the RPC over https (Outlook Anywhere) connection issue. In order to make it more logical, I’d like to divide the whole troubleshooting to the following processes:
    1. Client side to CAS side
    2. CAS side to MBX side
    [Issues between Client side to CAS side]
    In Exchange 2013, Outlook Anywhere is enabled by default. Different from this, Outlook Anywhere in Exchange 2007 and 2010 need to be manually enabled. Thus, please firstly check if the RPC over HTTP component has been installed:
    Click Start, and then click Control Panel.
    Double-click Programs and Features.
    In the left pane of Server Manager, click Features.
    In the right pane, click Add Features.
    Check if the RPC over HTTP component has been selected.
    If the ROH connectivity issue only happens on certain users, the property MAPIBlockOutlookRpcHTTP can be checked: 
    Get-CASMailbox  name | fl MAPIBlockOutlookRpcHttp
    2. Confirm if Exchange server is blocked. Ping the Exchange server FQDN on client machine and confirm if it can return the proper IP address.
    3. Check if the RPC Proxy server is responding correctly:
     rpcping -t ncacn_http -s ExchServer -o RpcProxy=RPCProxyServer -P "user,domain,*" -I "user,domain,*" -H 2 -u 10 -a connect -F 3 -v 3 -E -R none
    If 200 code returns, the test is successful.
    4. Check if Outlook Anywhere host names are added in the certificate:
    To get host names, the following command can be used: get-outlookanywhere |fl *hostname
    5. To use the Shell to test Outlook Anywhere connectivity, use the
    Test-OutlookConnectivity cmdlet.
    [Issues between CAS side to Mailbox side][RZ1] 
    A. Check if it can connect to store’s port:
    RpcPing –t ncacn_http –s ExchangeMBXServer -o RpcProxy=RpcProxyServer -P "user,domain,password" -I "user,domain,password" -H 1 –F 3 –a connect –u 10 –v 3 –e 6001
    If it returns as following: Completed 1 calls in 60 ms  16 T/S or 60.000 ms/T, it means the RPC Ping Utility test succeeds.
    B. Check if it can Connect to DsProxy Service:
    RpcPing –t ncacn_http –s ExchangeMBXServer -o RpcProxy=RpcProxyServer -P "user,domain,password" -I "user,domain,password" -H 2 –F 2 –a connect –u 10 –v 3 –e 6004
    If it returns as following: Completed 1 calls in 60 ms  16 T/S or 60.000 ms/T, it means the RPC Ping Utility test succeeds.
    C. Check the following registries:
    [Disable the auto update]
    1).Open Regedit and navigate to:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\RpcHttpConfigurator
    2).Set the PeriodicPollingMinutes value to 0.
    [Check the RpcProxy ValidPorts]
    1).On the RPC proxy server, start Registry Editor (Regedit).
    2). In the console tree, locate the following registry key:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy
    3). In the details pane, right-click the ValidPorts subkey, and then click Modify.
    4). In Edit String, in the Value data box, type the following information:
    ExchangeServer :6001-6002; ExchangeServerFQDN :6001-6002; ExchangeServer :6004; ExchangeServerFQDN :6004
    Note:
    ExchangeServer is the NetBIOS name of your Exchange server. ExchangeServerFQDN is the fully qualified domain name (FQDN) of your Exchange server. If the FQDN that is used to access the server from the Internet differs from the internal FQDN, you must use
    the internal FQDN.
    [Check the 6004 port settings in registry]
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
    Value name: HTTP Port
    Value type: REG_DWORD
    Value data: 0x1772 (Decimal 6002)
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
    Value name: Rpc/HTTP NSPI Port
    Value type: REG_DWORD   
    Value data: 0x1774 (Decimal 6004)
    D. Check if the RPC ports are used by other applications instead of Exchange by using : netstat –o
     Then it will return all active TCP connections and the process ID (PID) for each connection.
     After that, please check the application based on the PID on the Processes tab in Windows Task Manager and confirm if it’s Exchange server.
    Additionally, ExRCA is a perfect tool to test the whole connection between client side and Mailbox side:
    https://testconnectivity.microsoft.com/
    1. On the ExRCA website, under Microsoft Office Outlook Connectivity Tests, select Outlook connectivity, and then select Next at the bottom of the page.
    2. Enter the required information on the next screen, including email address, domain and user name, and password.
    3. Choose whether to use Autodiscover to detect server settings or to manually specify server settings.
    4. Accept the disclaimer, enter the verification code, and then select Verify.
    5. Select Perform Test.
    <Resource for reference>
    How does Outlook Anywhere work (and not work):
    http://blogs.technet.com/b/exchange/archive/2008/06/20/3405633.aspx
    How to use the RPC Ping utility to troubleshoot connectivity issues with the Exchange over the Internet feature in Outlook 2007 and in Outlook 2003:
    http://support.microsoft.com/kb/831051
    Test Outlook Anywhere Connectivity:
    http://technet.microsoft.com/en-us/library/ee633453(v=exchg.150).aspx
     [RZ1]It’s part, please re-layout
    Please click to vote if the post helps you. This can be beneficial to other community members reading the thread.

    I've just restored the M11 to Windows XP with the disks provided and Outlook Anywhere connected without issue. As strange as it sounds, this looks to be isolated to this particular model of laptop and Windows 7.
    I've used the same Enterprise copy of Windows 7 and Office on a variety of laptops and pc's and none have come across this problem. The only commonality I can see is the hardware and OS.
    Aftery trying to troubleshoot this unsuccessfully with Microsoft tech support for a few hours, they eluded to the fact that this +could+ be a hardware related problem. (driver, adapter properties, etc)

  • Exchange 2010 Outlook Anywhere issues

    I have an Exchange 2010 cas server that works fine with OWA internally and over the internet, and Outlook Anywhere works fine internally. When I try to access it outside the office though, the authentication prompt just keeps coming up for any user I try
    it on. I have used the connectivity analyzer, and it gives me what I've pasted below. I have disabled OA and uninstalled the RPC, rebooted and installed again and set it back up, with no luck. I've also tried both NTLM and Basic setups on the server side,
    and they both give the same error from outside the office. I also have checked my firewall settings, and everything is good. The only thing I can think of is that my reverse proxy is causing an issue. We have RHEL 5 with apache doing reverse proxy. Everything
    else works though, so I'm not sure why OA wouldn't?
    RPC Proxy can't be pinged.
    Additional Details
    An unexpected network-level exception was encountered. Exception details:
    Message: The remote server returned an error: (501) Not Implemented.
    Type: Microsoft.Exchange.Tools.ExRca.Extensions.MapiTransportException
    Stack trace:
       at Microsoft.Exchange.Tools.ExRca.Extensions.MapiRpcTestClient.PingProtocolProxy(String endpointIdentifier)
       at Microsoft.Exchange.Tools.ExRca.Tests.MapiPingProxyTest.PerformTestReally()
    Exception details:
    Message: The remote server returned an error: (501) Not Implemented.
    Type: System.Net.WebException
    Stack trace:
       at System.Net.HttpWebRequest.GetResponse()
       at RpcPingLib.RpcPing.PingProxy(String internalServerFqdn, String endpoint)
       at Microsoft.Exchange.Tools.ExRca.Extensions.MapiRpcTestClient.PingProtocolProxy(String endpointIdentifier)
    Elapsed Time: 198 ms.

    Hello
    501 is an internal server error.
    Please browse RPC virtual directory from outside, and see if you are getting a default response - Which should be a blank page.
    If you are not getting a blank page, then you need to troubleshoot that first - May be re-install RPC over HTTP.
    Let me know if you need any help
    AkashG || For any further queries, please mark an email to [email protected] ||

  • Exchange 2013 mailbox added to the CAS array

    We are upgrading to Exchange 2013 from Exchange 2010. Following the development guide, we have
    installed the first mailbox server in the Exchange 2010 environment which has 3 Exchange 2010 CAS server
    in the array. When installing the mailbox role, we did not choose the client access role but after
    the installation we can see that the Exchange 2013 Mailbox server is added to the CAS array and yet
    we did not choose the client access role. How does this happen, and to proceed ?

    I see the same thing in my lab:
    Get-ClientAccessArray | FL
    RunspaceId        : 16b992b3-270f-4ae1-a3c3-fa9e2ea73d69
    ExchangeLegacyDN  : /o=Wingtiptoys/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=Ou
                        tlook.wingtiptoys.ca
    Fqdn              : Outlook.wingtiptoys.ca
    Site              : wingtiptoys.ca/Configuration/Sites/Default-First-Site-Name
    SiteName          : Default-First-Site-Name
    Members           : {EXCH-2010, EXCH-2013}
    AdminDisplayName  :
    ExchangeVersion   : 0.1 (8.0.535.0)
    Name              : Outlook.wingtiptoys.ca
    DistinguishedName : CN=Outlook.wingtiptoys.ca,CN=Arrays,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administr
                        ative Groups,CN=Wingtiptoys,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=wingtiptoys,DC=ca
    Identity          : Outlook.wingtiptoys.ca
    Guid              : 27968af1-1624-4ff3-85c8-e38e68183afe
    ObjectCategory    : wingtiptoys.ca/Configuration/Schema/ms-Exch-Client-Access-Array-2
    ObjectClass       : {top, server, msExchExchangeServer, msExchClientAccessArray}
    WhenChanged       : 4/12/2014 12:51:18 PM
    WhenCreated       : 4/12/2014 12:51:18 PM
    WhenChangedUTC    : 4/12/2014 7:51:18 PM
    WhenCreatedUTC    : 4/12/2014 7:51:18 PM
    OrganizationId    :
    OriginatingServer : DC-1.wingtiptoys.ca
    IsValid           : True
    Cheers,
    Rhoderick
    Microsoft Senior Exchange PFE
    Blog:
    http://blogs.technet.com/rmilne 
    Twitter:   LinkedIn:
      Facebook:
      XING:
    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

  • Default Outlook Anywhere Connections

    I'm using an Exchange 2013 SP1 environment with almost no customization. Only 2 servers exists - one holding CAS+MBX, and a second one being an MBX. No DAGs, balancers, etc. Mapi over HTTP is not enabled. The default self-signed certificates are used
    (no new certificate was installed, nor any self-signed certificate manually installed on any server/client). A mailbox is provisioned on a database located on the first server. Outlook is configured for the corresponding user on a client machine and started.
    Everything works just fine, with the 'Outlook Connection status' window showing 2 Exchange Directory + 2 Exchange Mail connections. Authentication is NTLM. Ports for all 4 connections are 6001 - which hint that Outlook Anywhere is indeed used.
    From time to time, the familiar "Security Alert" comes up warning about the self-signed certificate, but this is usually traced in my experience to the various services Outlook is using, that are running on HTTPS (OAB, EWS, Availability...). 
    Here we find that in Exchange 2013 "Outlook Anywhere is enabled by default, because all Outlook connectivity takes place via Outlook Anywhere". Then
    here it's stated that "Outlook Anywhere won't work with a self-signed certificate on the Client Access server". I remember the latter being true against Exchange 2010
    instances, but seems not to be the case in Exchange 2013 anymore. Unless I'm missing something, from the standpoint of a default installation, the 2 articles contradict each other. 
    Second issue - even though Outlook is set for "Negotiate" in its Security setting, it looks like the Kerberos preferred option is never chosen. Would it have to do with the self-signed certificate and Outlook Anywhere ?

    First article says "[...]In Exchange 2013, Outlook Anywhere is enabled by default, because all Outlook connectivity takes place via Outlook Anywhere.[...]". A simple Exchange 2013 SP1 setup, using defaults - including the built-in self-signed certs
    - can be reached with no problems with a regular Outlook client. Since RPC over TCP is now defunct, and MAPI over HTTP isn't enabled (it's a regular installation, hence this feature is disabled) it can only be Outlook Anywhere being used by the Outlook client
    to connect to the vanilla Exchange 2013 SP1 installation. Hence we can conclude that Outlook Anywhere works by default.
    Second article comes around and says "[...] Outlook Anywhere won't work with a self-signed certificate on the Client Access server.[...]". Yet this is contrary to what I'm experiencing - since Outlook Anywhere is working (what other method of connecting
    is left, right ? plus even the connections over :6001 in the Connection Status window hint at this) and there hasn't been any CA-emitted certificate installed on that stock CAS server.
    So either the sentence in the second article is flat wrong (ONLY for 2013, Exchange 2010 NEEDS trusted certs), or it's missing a clause. Am I missing something ?
    Hi,
    Yes, Outlook Anywhere is enabled by default. Because all Outlook connectivity from Internal and External are using Outlook Anywhere.
    For your second question, "[...] Outlook Anywhere won't work with a self-signed certificate on the Client Access server.[...]".  Based on my knowledge, the Self-signed certificate which is installed with Exchange 2013 installation is not issued
    by any CA. It is issued by the Exchange server.
    Outlook Anywhere won't work with a self-signed certificate on the Client Access server because there would be a certificate untrusted issue on every user's clients. If you don't install the untrusted certificate in your trusted root certificate store on
    the client computer, the client will be always prompted for the certificate error even through you can work with Exchange services after clicking Yes when the Security Alert asking you “Do you want to proceed”.
    Regards,
    Winnie Liang
    TechNet Community Support

Maybe you are looking for