Incorrect Outlook Anywhere Settings

Hi
We are using Exchange 2013 and everything seems to be working ok. However, if I look at any of our Outlook clients (2007 & 2010) there seems to be incorrect information in the Exchange Proxy Settings under the advanced account settings.
For some reason the Use this URL to connect to my proxy server for Exchange box is populated with the server name of our CAS server. I've checked on the Exchange 2013 admin centre and the internal and external hostnames for Outlook Anywhere are correct
but the setting in Outlook is always set to the server name.
I've even tried going into Outlook and manually amending the setting but as soon as I restart Outlook the setting automatically changes back. Am I missing something or is there another place where this setting could be picked up from?
Many thanks for your help.

Hi,
As far as I know, Outlook Exchange Proxy Settings dialog box always displays the internal host name as the Proxy server in an Exchange Server 2013 environment:
http://support.microsoft.com/kb/2754898/en-US
Thus, I’d like to confirm if the server name is the internal host name.
If you have any question, please feel free to let me know.
Thanks,
Angela Shi
TechNet Community Support

Similar Messages

Outlook anywhere settings, in Autodiscover?

So in Outlook, I got all my Outlook Anywhere settings configured, great! But where do I go to edit them on the server?
I don't have a GPO for any of this and I gather Outlook Anywhere is configured in Autodiscover? Is it EMS?

First, run set-outlookprovider -identity EXPR -Server servername and get-outlookanywhere |fl command in EMS. This command will let you know about the configuration of Outlook. You can edit the Outlook Anywhere configuration by using the custom installation
wizard. Autodiscover is simply the best way for managing Outlook configurations.
Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
You can run this powershell command to make connection with the Outlook Anywhere using TCP/IP.
You can easily change the OutlookProviderFlags to change/edit the Outlok anywhere seetings e.g. you can set the value to ServerExclusiveConnect or to None to clear the flag
Hi Blake - can you change the first line to be get-outlook provider -identity EXPR ? Its currently at "set-"
Not sure if I'd be recommending the serverExclusiveConnect option off the bat, most customers I see do not leverage that.   Do they want to do OA internally too? I don't see that mentioned above
The OutlookProviderFlags parameter specifies that Outlook 2010 clients should connect using RPC over HTTP (Outlook Anywhere) before trying RPC over TCP connections. This increases the speed at which Outlook 2010 clients will connect when clients
are primarily accessing Exchange over the Internet. The value can be set to
ServerExclusiveConnect or to None to clear the flags. For Outlook 2010 clients that access Exchange over both organization intranets and the Internet, the recommended value is
None, which is also the default setting.
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.

Outlook 2011 Outlook anywhere settings won't stick

We recently enabled Outlook Anywhere on our EX2010 Std server. When we tried testing with our Outlook 2011 for
Mac clients we can get AutoDiscover to work both externally and internally. The problem is AutoDiscover always puts the EWS URL to the internal one and not the external one. Externally it works for the initial session and then all subsequent session try contacting
the internal URL. Is there any way to stop that behavior or should I use the same External URL for the internal URL in EWS?

We have, here is a break down of all our settings:
[PS] E:\scripts>Get-AutodiscoverVirtualDirectory | fl identity,InternalURL,ExternalURL
Identity    : MAIL\Autodiscover (Default Web Site)
InternalUrl :
https://mail.voxmedica.net/Autodiscover/Autodiscover.xml
ExternalUrl :
https://webmail.voxmedica.com/Autodiscover/Autodiscover.xml
[PS] E:\scripts>Get-WebServicesVirtualDirectory | fl identity,InternalURL,ExternalURL
Identity    : MAIL\EWS (Default Web Site)
InternalUrl :
https://mail.voxmedica.net/EWS/Exchange.asmx
ExternalUrl :
https://webmail.voxmedica.com/ews/exchange.asmx
[PS] E:\scripts>Get-oabvirtualdirectory | fl identity,InternalURL,ExternalURL
Identity    : MAIL\OAB (Default Web Site)
InternalUrl : http://mail.voxmedica.net/OAB
ExternalUrl : https://webmail.voxmedica.com/OAB
[PS] E:\scripts>Get-owavirtualdirectory | fl identity,InternalURL,ExternalURL
Identity    : MAIL\owa (Default Web Site)
InternalUrl : https://mail.voxmedica.net/owa
ExternalUrl : https://webmail.voxmedica.com/owa
[PS] E:\scripts>Get-ecpvirtualdirectory | fl identity,InternalURL,ExternalURL
Identity    : MAIL\ecp (Default Web Site)
InternalUrl : https://mail.voxmedica.net/ecp
ExternalUrl : https://webmail.voxmedica.com/ecp
[PS] E:\scripts>Get-activesyncvirtualdirectory | fl identity,InternalURL,ExternalURL
Identity    : MAIL\Microsoft-Server-ActiveSync (Default Web Site)
InternalUrl :
https://mail.voxmedica.net/Microsoft-Server-ActiveSync
ExternalUrl :
https://webmail.voxmedica.com/Microsoft-Server-ActiveSync
[PS] E:\scripts>Get-clientaccessserver | fl identity,AutoDiscoverServiceInternalUri
Identity                       : MAIL
AutoDiscoverServiceInternalUri :
https://mail.voxmedica.net/Autodiscover/Autodiscover.xml
Here is the XML log from WIN7 running Outlook 2010 (can't seem to copy the results or regular log)
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
      <DisplayName>Creative Freelance01</DisplayName>
      <LegacyDN>/o=Email/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Creative Freelance01</LegacyDN>
      <AutoDiscoverSMTPAddress>[email protected]</AutoDiscoverSMTPAddress>
      <DeploymentId>c2ed12a3-7b97-45d5-b139-b57027ef78b5</DeploymentId>
    </User>
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <Protocol>
        <Type>EXCH</Type>
        <Server>MAIL.voxmedica.net</Server>
        <ServerDN>/o=Email/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL</ServerDN>
        <ServerVersion>738180DA</ServerVersion>
        <MdbDN>/o=Email/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL/cn=Microsoft Private MDB</MdbDN>
        <PublicFolderServer>MAIL.voxmedica.net</PublicFolderServer>
        <AD>DC02.voxmedica.net</AD>
        <ASUrl>https://mail.voxmedica.net/EWS/Exchange.asmx</ASUrl>
        <EwsUrl>https://mail.voxmedica.net/EWS/Exchange.asmx</EwsUrl>
        <EcpUrl>https://mail.voxmedica.net/ecp/</EcpUrl>
        <EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
        <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
        <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
        <EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
        <EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
        <OOFUrl>https://mail.voxmedica.net/EWS/Exchange.asmx</OOFUrl>
        <UMUrl>https://mail.voxmedica.net/EWS/UM2007Legacy.asmx</UMUrl>
        <OABUrl>http://mail.voxmedica.net/OAB/7923cd72-96a7-4ace-b3eb-3a3ca0fa305c/</OABUrl>
      </Protocol>
      <Protocol>
        <Type>EXPR</Type>
        <Server>webmail.voxmedica.com</Server>
        <SSL>On</SSL>
        <AuthPackage>Ntlm</AuthPackage>
        <ASUrl>https://webmail.voxmedica.com/ews/exchange.asmx</ASUrl>
        <EwsUrl>https://webmail.voxmedica.com/ews/exchange.asmx</EwsUrl>
        <EcpUrl>https://webmail.voxmedica.com/ecp/</EcpUrl>
        <EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
        <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
        <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
        <EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
        <EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
        <OOFUrl>https://webmail.voxmedica.com/ews/exchange.asmx</OOFUrl>
        <UMUrl>https://webmail.voxmedica.com/ews/UM2007Legacy.asmx</UMUrl>
        <OABUrl>https://webmail.voxmedica.com/OAB/7923cd72-96a7-4ace-b3eb-3a3ca0fa305c/</OABUrl>
      </Protocol>
      <Protocol>
        <Type>WEB</Type>
        <Internal>
          <OWAUrl AuthenticationMethod="Basic, Fba">https://mail.voxmedica.net/owa/</OWAUrl>
          <Protocol>
            <Type>EXCH</Type>
            <ASUrl>https://mail.voxmedica.net/EWS/Exchange.asmx</ASUrl>
          </Protocol>
        </Internal>
        <External>
          <OWAUrl AuthenticationMethod="Fba">https://webmail.voxmedica.com/owa/</OWAUrl>
          <Protocol>
            <Type>EXPR</Type>
            <ASUrl>https://webmail.voxmedica.com/ews/exchange.asmx</ASUrl>
          </Protocol>
        </External>
      </Protocol>
    </Account>
</Response>
</Autodiscover>

Outlook Anywhere settings in a Exchange 2013 coexistence scenario with Exchange 2007

I have exchange 2013 and 2007 set up in a coexist environment. At the moment, the few mailboxes I am testing on Exchange 2013 are getting multiple pop ups in outlook and cannot connect to items like Public Folders on 2007. I found an article
that told me to change the authentication method from Negotiate to NTLM and that broke some of my Lync 2013 compatibility issues on users on exchange 2007 (ie conversation history and they got outlook integration errors.) I would like someone to confirm
if the change I am about to make from doing research will help me in my situation.
Current Setup:
Exchange 2007 OA CAS Settings
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod: NTLM
IISAuthenticationMethods : {Basic, Ntlm}
Exchange 2013 OA CAS Settings
ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod: Negotiate
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
New Settings I am considering based on research:
Exchange 2007 OA CAS Settings
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod: Basic
IISAuthenticationMethods : {NTLM}
Exchange 2013 OA CAS Settings
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod: Basic
IISAuthenticationMethods : {Basic}
Will this work and eliminate my popups?

Hi,
The following TechNet article indicates that:
“In order to support access for Outlook Anywhere clients whose mailboxes are on legacy versions of Exchange, you will need to make some changes to your environment which are documented in the steps within the
Exchange Deployment Assistant. Specifically,
you will need to enable Outlook Anywhere on your legacy Client Access servers and enable NTLM in addition to basic authentication for the IIS Authentication Method.”
Client Connectivity in an Exchange 2013 Coexistence Environment
http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx
As for the Autodiscover service, please make sure the Autodiscover.domain.com is pointed to your Exchange 2013 in Internal and External DNS. For more detailed information about Exchange 2013 coexistence with Exchange 2007, please refer to:
http://blogs.technet.com/b/meamcs/archive/2013/07/25/part-3-step-by-step-exchange-2007-to-2013-migration.aspx
Regards,
Winnie Liang
TechNet Community Support

Outlook Anywhere office 2013 gets dissabled even though group pollicy is set to force proxy settings.

Domain joined laptops have outlook anywhere settings forced through group policy.
Running gpresult command shows correct group policy are applied.
GPO: Outlook Offsite Settings
Folder Id: Software\Policies\Microsoft\Office\12.0\Outlook\RPC\ProxyServerName
Value: 119, 0, 101, 0, 98, 0, 109, 0, 97, 0, 105, 0, 108, 0, 46, 0, 105, 0, 101, 0, 99, 0, 109, 0, 97, 0, 105, 0, 108,
0, 46, 0, 99, 0, 111, 0, 109, 0, 0, 0
State: Enabled
Outlook in safe mode shows no change.
Exchange server 2010.
What can be disabling this?
Thank you for your time.

Hi,
You are using Outlook 2013, right?
However, "Folder Id: Software\Policies\Microsoft\Office\12.0\Outlook\RPC\ProxyServerName" implies it's the setting for Outlook 2007.
As for Outlook 2013, it should be 15.0 instead of 12.0.
Please confirm that and change the settings to try again.
Regards,
Melon Chen
TechNet Community Support

Allow changing of Outlook anywhere options after applying GPO

Policy
Setting
Configure Outlook Anywhere user interface options
Enabled
All config UI enabled
I have used the outlook2010 GPO template to configure outlook anywhere settings. However after enabling these options, the user can no longer change the outlook anywhere settings (all greyed out). So I enabled the above GPO in outlook 2010 ADMX template.
"This policy setting allows you to determine whether users can view and change user interface (UI) options for Outlook Anywhere.If you enable this policy setting, users can view and change UI options for Outlook Anywhere.If you disable or do not configure
this policy setting, users will be able to use the Outlook Anywhere feature, but they will not be able to view or change UI options for it."
However after performing gpupdate, it has no effect, users still cannot change any of the outlook anywhere settings. Here are the download locations for the admx templates if anyone else would like to test and confirm this issue.
http://www.microsoft.com/en-us/download/details.aspx?id=18968
http://support.microsoft.com/kb/2426686
Anand_N

Hi,
Please check if the value of the following registry key has been set correctly by Group Policy:
HKEY_CURRENT_USER\Software\Policies\Microsoft\office\14.0\outlook\rpc
Value name: EnableRPCTunnelingUI
Type: REG_DWORD
To enable all configuration the value should be: 1
Sincerely
Rex Zhang
Rex Zhang
TechNet Community Support

Exchange 2013 & Exchange 2007 Co-exist - Problems with Outlook anywhere proxy

Hi,
Got EX13 and EX07 in co-exist. Pointed all the external URL to EX13. ActiveSync proxies to 2007 and OWA redirects to legacy url with SSO. Working perfectly!
But with Outlook Anywhere it does not work. Mailboxes on EX13 works good, but not for EX07 user.
Error message from MRCA:
Attempting to ping RPC endpoint 6001 (Exchange Information Store) on server "internalFQDN ofbackend EX07 server"
The RPC_S_SERVER_UNAVAILABLE error (0x6ba) was thrown by the RPC Runtime process.

Hi,
We need to change the Authenticaion on the Outlook Anywhere to NTLM
Set-OutlookAnywhere -Identity "xxx\Rpc (Default Web Site)" –InternalHostName mail.domain.com
-InternalClientsRequireSsl $True -ExternalHostName mail.domain.com
-ExternalClientsRequireSsl $True -InternalClientAuthenticationMethod NTLM
-ExternalClientAuthenticationMethod NTLM -IISAuthenticationMethods
Basic, NTLM, Negotiate
Please first backup the Outlook Anywhere settings then do the above changes.
Thanks,
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 Subscriber Support, contact
[email protected]
Simon Wu
TechNet Community Support

Outlook Anywhere proxy changed from Basic to NTLM for external users

I have a Exchange 2013 environment that is also running Exchange 2010 coexistence (migrating). What is happening is autodiscover is handing out NTLM for the proxy settings and not basic. However when it is using NTLM we seem to get the password prompt over
and over. If I manually changed it to Basic then it works fine, but when autodiscover goes again it changes back to NTLM and prompts that the Administrator made a change and you need to restart Outlook.
I checked Outlook Anywhere and all my servers have Basic set for external users and NTLM set for internal.
I only have a few mailboxes on 2013 and 2010 mailboxes seem not to have a problem.
Here is an output for Outlook Anywhere on all six servers:
Identity : CAS01\Rpc (Default Web Site)
ExchangeVersion : 0.10 (14.0.100.0)
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm}
Identity : CAS02\Rpc (Default Web Site)
ExchangeVersion : 0.10 (14.0.100.0)
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm}
Identity : CAS03\Rpc (Default Web Site)
ExchangeVersion : 0.10 (14.0.100.0)
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm}
Identity : EXCH2K13-01\Rpc (Default Web Site)
ExchangeVersion : 0.20 (15.0.0.0)
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
Identity : EXCH2K13-02\Rpc (Default Web Site)
ExchangeVersion : 0.20 (15.0.0.0)
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
Identity : EXCH2K13-03\Rpc (Default Web Site)
ExchangeVersion : 0.20 (15.0.0.0)
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}

Hi,
Please refer to the following KB to set the Outlook Anywhere settings on Exchange Server 2013 Client Access servers:
http://support.microsoft.com/en-us/kb/2834139
If it doesn’t work with the resolution above, please do the following checking in ADSI Edit:
1. In Adsiedit, expand Configuration-->CN=Services -> CN=Microsoft Exchange -> CN=domain -> CN=Administrative Groups -> CN=Exchange Administrative Group -> CN=Databases.
2. Right-click the listed database > Properties.
3. Check whether the msExchHomePublicMDB value is set to an available value. Please change the value to <not set>.
4. Click OK.
Then check whether the issue persists.
Regards,
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Winnie Liang
TechNet Community Support

Outlook anywhere in 2007/2013 coexistence

Hi!
I have a multitenant exchange 2007 at a single server setup and I’m trying to do migration to exchange 2013. I’m testing this in my lab environment before I go the production. I’m quite far and for example the owa redirection to exchange
2007 works. Also I can connect with outlook anywhere the exchange 2013 server when the mailbox is transferred.
Problem is that the exchange 2013 proxy redirection to 2007 server isn’t working. My Outlook 2010 just keeps asking username and password. Outlooks are configured to connect with basic authentication.
I have done a lot of googling about the issue and there is a lot of discussion about it. I have tried a lot of things and I’m quite lost now.
I have tried to configure the externalclientauthenticationmethod, internalauthenticationmethod and IISauthenticationmethods with different kind of setups but can’t get it to work. Also tried to change the internal and external hostnames.
My outlook anywhere setup at 2007 server is:
RunspaceId
: 714f0d1a-c0f0-4694-aefe-8cf6218521ea
ServerName
: EXCHANGE07
SSLOffloading
: False
ExternalHostname
: exchange07.xxx.fi
InternalHostname
: legacy.xxx.fi
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods
: {Basic, Ntlm}
XropUrl
ExternalClientsRequireSsl
   : True
InternalClientsRequireSsl
: True
MetabasePath
: IIS://wcn-exchange07.welcomnet.fi/W3SVC/1/ROOT/Rpc
Path
: C:\WINDOWS\System32\RpcProxy
ExtendedProtectionTokenChecking
: None
ExtendedProtectionFlags
ExtendedProtectionSPNList
AdminDisplayVersion
: Version 8.3 (Build 83.6)
Server
: WCN-EXCHANGE07
AdminDisplayName
ExchangeVersion
  : 0.1 (8.0.535.0)
Name
: Rpc (Default Web Site)
ObjectClass
: {top, msExchVirtualDirectory, msExchRpcHttpVirtualDirectory}
WhenChanged
: 14.5.2014 20:56:18
WhenCreated
             : 14.10.2008 12:33:07
WhenChangedUTC
: 14.5.2014 17:56:18
WhenCreatedUTC
: 14.10.2008 9:33:07
Exchange 2013 outook anywhere setup:
RunspaceId
: 714f0d1a-c0f0-4694-aefe-8cf6218521ea
ServerName
: EXCHANGE13
SSLOffloading
: False
ExternalHostname
: exchange07.xxx.fi
InternalHostname
: exchange07.xxx.fi
ExternalClientAuthenticationMethod : Basic
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods
: {Basic, Ntlm}
XropUrl
ExternalClientsRequireSsl
: True
InternalClientsRequireSsl
: True
MetabasePath
: IIS://exchange13.xxx.fi/W3SVC/1/ROOT/Rpc
Path
                             : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\rpc
ExtendedProtectionTokenChecking
: None
ExtendedProtectionFlags
ExtendedProtectionSPNList
AdminDisplayVersion
  : Version 15.0 (Build 847.32)
Server
: WCN-EXCHANGE13
AdminDisplayName
ExchangeVersion
: 0.20 (15.0.0.0)
Name
       : Rpc (Default Web Site)
ObjectClass
              : {top, msExchVirtualDirectory, msExchRpcHttpVirtualDirectory}
WhenChanged
: 14.5.2014 20:55:56
WhenCreated
: 2.4.2014 0:57:19
WhenChangedUTC
: 14.5.2014 17:55:56
WhenCreatedUTC
: 1.4.2014 21:57:19
Any help would be appreciated.

Hi,
Firstly, I'd like to explain, only in Exchange 2013, internal and external Outlook clients use Outlook Anywhere. Thus,in Exchange 2007, Outlook Anywhere settings can only include the external host name.
And based on my experience, the credential issue is related to connectivity issue, authentication issue or public folder access.
So I'd like to confirm the following information to understand more about the issue:
1. Does the issue happens on all users? users on Exhcange 2007 or 2013? internal users or external users?
As far as I know, redirection and proxy don't happen on Outlook clients:
http://technet.microsoft.com/en-us/library/bb310763(v=exchg.141).aspx
2. Which IP address do your host name points to? legacy.xxx.fi, exchange07.xxx.fi?
3. Check the Outlook Anywhere connectivity of the problematic users by ExRCA:
https://testconnectivity.microsoft.com/
If you have any question, please feel free to let me know.
Thanks,
If you have feedback for TechNet Subscriber Support, contact
[email protected]
Angela Shi
TechNet Community Support

Exchange msstd: setting in outlook connection for Outlook Anywhere

I currently have the Exchange Provider for EXPR set to $null, however I still seem to get msstd:mail.mydomain.com set in my Outlook connection string setting on all machines. Where is this setting coming from? We do push the Outlook Anywhere settings
via GPO and have the ProxyServer string defined set to mail.mydomain.com. The flags are set to ensure SSL is defined on the connection.
We are in the process of moving from Exchange 2007 to Echange 2013. Will it be a problem moving from a UCC cert with a friendly name of mail.mydomain.com to a wild card SSL cert on the 2013 servers with *.mydomain.com set, if the
"connect to proxy servers that have this principal name in their certificate is selected? I'm concerned that msstd:mail.mydomain.com does not match msstd:*.mydomain.com?
Thanks in advance

Hi,
We can run the following command to set with Ed’s suggestion:
Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.mydomain.com
Regards,
Winnie Liang
TechNet Community Support

Outlook Anywhere Issues and Questions

Exchange 2013 with 2 member DAG using round robin DNS. We seem to be having issues with exchange users on the local LAN. External users are working fine. We get:
I believe this is a autodiscover/CA error because external users are working fine. The active copy server has the following for outlook anywhere settings:
external users use hostname: oa.domain.tld
internal users use hostname: mail.domain.tld
Passive copy server has the following settings for outlook anywhere:
external users is blank
internal users has the server hostname.domain.tld
The settings on both the active and passive should be the same correct?
Now the CA; we have a godaddy cert and it is installed on the active server. However, on the passive server it is not installed. The godaddy cert should be installed on the passive copy server correct?

Exchange 2013 with 2 member DAG using round robin DNS. We seem to be having issues with exchange users on the local LAN. External users are working fine. We get:
I believe this is a autodiscover/CA error because external users are working fine. The active copy server has the following for outlook anywhere settings:
external users use hostname: oa.domain.tld
internal users use hostname: mail.domain.tld
Passive copy server has the following settings for outlook anywhere:
external users is blank
internal users has the server hostname.domain.tld
The settings on both the active and passive should be the same correct?
Now the CA; we have a godaddy cert and it is installed on the active server. However, on the passive server it is not installed. The godaddy cert should be installed on the passive copy server correct?
The cert needs to be installed on the CAS role servers.
I installed the godaddy cert and it does show in the certificates mmc. However, in ECP it still shows "pending request" and yes, I clicked on "complete" and completed the steps. Does it matter if the friendly name is exactly the same as
the friendly name on the active copy server? How about the outlook anywhere settings? Should they be the same as the active copy server?

Auth Package in Outlook Anywhere AutoDiscover is coming in incorrectly

Let me describe our situation and environment:
We have Exchange 2013 running in a 2008r2 level domain and are using Outlook Anywhere / AutoDiscovery to configure non-domain joined clients (this situation will change later, but our current priority is getting the Exchange server running and worrying and
joining machines to the domain afterwards). I had tried some configuration changes, which ultimately did not work, and I rolled back those changes. On the ECP under Servers -> Servers -> My Exchange Server -> Outlook AnyWhere, there is
a box that lets you choose between NTLM, Basic, and Negotiate authentication. Exchange 2013 default is negotiate, which was working initially. After rolling back my changes, however, my clients get repeated password prompts, and their passwords
are rejected, if I have Outlook Anywhere authentication set to negotiate. It works fine if I keep it set on NTLM.
Under Servers -> Virtual Directories -> AutoDiscover (Default Website) -> Authentication, the boxes for Basic Authentication and Integrated Windows Authentication are checked. These are the default values if I remember correctly.
Even when I have my Outlook Anywhere authentication set to Negotiate, I have a section of code in the AutoDiscover XML file that Outlook pulls that looks like this:
<Type>EXPR</Type>
<Server>exchange.mycompany.com</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
My research tells me that EXPR controls Outlook Anywhere (RPC over HTTP). The AuthPackage seems to be incorrect here. It's still giving me NTLM instead of Negotiate. When I change Outlook Anywhere's authentication back to NTLM, everything
works (after giving the server about fifteen minutes or so to update).
What is the problem here? Why does the autodiscover return the wrong auth package for Outlook Anywhere? Is there a time delay between changing the authentication for Outlook Anywhere and Exchange updating my Outlook clients so that their settings
match? I know that if I go into an Outlook client that is getting prompted for a password after Outlook Anywhere authentication has been changed to Negotiate, I can manually adjust their Exchange Proxy Server settings and get it to work, but I really
want the AutoDiscover to simply deliver the correct auth package to begin with.
I don't mind using NTLM authentication; it works. But I really need to know WHY this is happening and what to do to fix it. Today, it may not matter, but it may matter in the future as network topology changes, and I will be expected to have
the answer.
To further clarify:
When I run Get-OutlookAnywhere | fl name, *, my internal and external Client Authentication Methods are set to Negotiate, but I still get the entry I showed above in the AutoDiscover XML file that specifies NTLM.

Outlook ignores the EXPR/EXCH values when connected to Exchange 2013 for autodiscovery, rather it dynamically builds the EXHTTP values based on the AutoD server settings and uses those instead. You should reference those ExHTTP settings when you
look at the autodiscover results
Twitter!:
Please Note: My Posts are provided “AS IS” without warranty of any kind, either expressed or implied.
I also have the following bit of code in the autodiscover file
<Type>EXHTTP</Type>
<Server>mail.mycompany.com</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
This would seem to be the EXHTTP you were referencing. Again, this value is coming out as NTLM after I change my Outlook Anywhere Authentication method in ECP to Negotiate. Why? Is there a delay between changing that setting in ECP and when
it starts showing up in AutoDiscover queries? If so, what is that delay and how can I change it or force it to update immediately? Or is it that the setting in ECP does not change the auto discover setting and it has to be changed elsewhere?
If that's the case, what do I change, and where do I change it, to alter what autodiscover puts in for AuthPackage in the above snippet of code?

SSL/MSSTD settings Outlook anywhere

All,
just want to raise a question, as I noticed a strange behaviour.
I have Exchange 2013 with Outlook Anywhare configured in this way:
So external and internal hostname is the same, SSL required only from external.
Internal connection works just fine and Outlook doesn't set the flag and the MSSTD setting for SSL.
Externally, If I setup from scratch, it's working as well, and the msstd is flagged and setup.
Problems begin when I migrate mailboxes from an Exchange 2010 in coexistance, which will be decomissioned in the future. After migration, user's Outlook (connected from external AND not domain-joined) was properly reconfigured BUT for the msstd setting
which was missing.
As result the Outlook connection was totally flickering, up and down every now and then plus keep "connecting" for the directory service.
Setting up the msstd setting manually, everything is fine.
Now, we know that in EX2013 the Autodiscovery behaviour has changed:
http://support.microsoft.com/kb/2754898/en-us
Practically, it will try always the internal first host name first, regardless where you're connecting from.
I was wondering if: since the hostname is the same for both internal and external, would this lead autodiscovery in misinterpret the configuration (InternalClientRequireSSL is set to $False) and left the configuration unflagged in Outlook?
And, if so, why on migrated mailboxes only ?
Any suggestion, answer and comment will be hughly appreciated!
Thanks!

In the Autodiscover.xml that is returned to the client, there is
two EXHTTP sections with settings. Outlook will try the first block (internalSettings) and in your case it will be successfull since you are using the same name for both internal- and externalhostname. So with that, SSL will not be required.
Example:
<Type>EXHTTP</Type>
        <Server>mail.domain.com</Server>
        <SSL>Off</SSL>
        <AuthPackage>Ntlm</AuthPackage>
   <Type>EXHTTP</Type>
        <Server>mail.domain.com</Server>
        <SSL>On</SSL>
        <AuthPackage>Ntlm</AuthPackage>
Personally, I always configure the same name for both internal- and externalhostname, use the authentication method NTLM AND
InternalClientsRequireSSL=True.
Not a good idea to disable Outlook Anywhere on Exchange 2010 when running in co-existence.
Can you also confirm that autodiscover is pointing to your Exchange 2013 Server?
Martina Miskovic
Hi Martina,
thanks for the clear answer! I had kind-of the same idea, wodering if Exchange could possibly mess up using the same name - sort of bug.
I'll try to set for both internal and external to require SSL.
I'm not clear, however, how set the authentication. NTLM only? NTLM + Basic + Negotiate? And same auth method for both int and ext? Ultimately, how would you setup the IISAuthenticationMethods?
Ah! What whoud you mean by: "confirm that autodiscover is pointing to your Exchange 2013 Server?"
Thanks in advance!
Ale.

Outlook Anywhere losing proxy settings, Autodiscover issue?

I have Exchange Server 2010 in Small Business Server 2011. I have several remote clients that are not part of the SBS domain, but they use Outlook Anywhere to connect to Exchange.
We originally started with a self-signed and eventually added a GoDaddy SSL certificate. Some of the remote clients lose the settings for Outlook Anywhere randomly. The proxy checkbox is unchecked and the MSSTS settings have all disappeared.
I investigated this and it seems to point to autodiscover. Our DNS is hosted externally so I created an A-Host record at Netowork Solutions called autodiscover and resolved it to the static IP address of the server. When I did this the remote
clients started to get certificate security warnings.
Next I tried to create a CNAME called _autodiscover for mail.mydomain.com and this didn't work either, certificate security erros
Is my Outlook Anywhere issue an 'autodiscover' problem and if it is, what amI doing wrong? Here are some additional details:
Self-signed certificate is mail.mydomain.com. GoDaddy Class 2 certificate authority has identified this site as mail.mydomain.com. The connection to the server is encrypted.

Testing RPC/HTTP connectivity.
The RPC/HTTP test failed.
Additional Details
Elapsed Time: 3221 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to test Autodiscover for
[email protected].
Autodiscover was tested successfully.
Additional Details
Elapsed Time: 3219 ms.
Test Steps
Attempting each method of contacting the Autodiscover service.
The Autodiscover service was tested successfully.
Additional Details
Elapsed Time: 3218 ms.
Test Steps
Attempting to test potential Autodiscover URL
https://pickardconstruction.com/AutoDiscover/AutoDiscover.xml
Testing of this potential Autodiscover URL failed.
Additional Details
Elapsed Time: 835 ms.
Test Steps
Attempting to resolve the host name pickardconstruction.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 205.204.84.106
Elapsed Time: 464 ms.
Testing TCP port 443 on host pickardconstruction.com to ensure it's listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 164 ms.
Testing the SSL certificate to make sure it's valid.
The SSL certificate failed one or more certificate validation checks.
Additional Details
Elapsed Time: 205 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server pickardconstruction.com on port 443.
The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
Additional Details
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
Elapsed Time: 156 ms.
Attempting to test potential Autodiscover URL
https://autodiscover.pickardconstruction.com/AutoDiscover/AutoDiscover.xml
Testing of this potential Autodiscover URL failed.
Additional Details
Elapsed Time: 609 ms.
Test Steps
Attempting to resolve the host name autodiscover.pickardconstruction.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 205.204.84.106
Elapsed Time: 222 ms.
Testing TCP port 443 on host autodiscover.pickardconstruction.com to ensure it's listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 185 ms.
Testing the SSL certificate to make sure it's valid.
The SSL certificate failed one or more certificate validation checks.
Additional Details
Elapsed Time: 200 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover.pickardconstruction.com on port 443.
The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
Additional Details
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
Elapsed Time: 151 ms.
Attempting to contact the Autodiscover service using the HTTP redirect method.
The Autodiscover service was successfully contacted using the HTTP redirect method.
Additional Details
Elapsed Time: 1770 ms.
Test Steps
Attempting to resolve the host name autodiscover.pickardconstruction.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 205.204.84.106
Elapsed Time: 21 ms.
Testing TCP port 80 on host autodiscover.pickardconstruction.com to ensure it's listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 100 ms.
The Microsoft Connectivity Analyzer is checking the host autodiscover.pickardconstruction.com for an HTTP redirect to the Autodiscover service.
The redirect (HTTP 301/302) response was received successfully.
Additional Details
Redirect URL:
https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml HTTP Response Headers: Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Length: 0 Content-Type: application/xml Date: Fri, 28 Feb 2014 01:49:00 GMT Location:
https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4
FrontPage/5.0.2.2635 PHP/5.3.21
Elapsed Time: 184 ms.
Attempting to test potential Autodiscover URL
https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml
Testing of the Autodiscover URL was successful.
Additional Details
Elapsed Time: 1463 ms.
Test Steps
Attempting to resolve the host name cpanelemaildiscovery.cpanel.net in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 208.74.124.130, 208.74.124.133, 208.74.125.50, 208.74.125.51, 208.74.123.82
Elapsed Time: 109 ms.
Testing TCP port 443 on host cpanelemaildiscovery.cpanel.net to ensure it's listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 135 ms.
Testing the SSL certificate to make sure it's valid.
The certificate passed all validation requirements.
Additional Details
Elapsed Time: 358 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server cpanelemaildiscovery.cpanel.net on port 443.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
Additional Details
Remote Certificate Subject: CN=*.cpanel.net, OU=Domain Control Validated, O=*.cpanel.net, Issuer: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona,
C=US.
Elapsed Time: 278 ms.
Validating the certificate name.
The certificate name was validated successfully.
Additional Details
The host name that was found, cpanelemaildiscovery.cpanel.net, is a wildcard certificate match for common name *.cpanel.net.
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=*.cpanel.net, OU=Domain Control Validated, O=*.cpanel.net.
One or more certificate chains were constructed successfully.
Additional Details
A total of 2 chains were built. The highest quality chain ends in root certificate OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US.
Elapsed Time: 30 ms.
Analyzing the certificate chains for compatibility problems with versions of Windows.
No Windows compatibility problems were identified.
Additional Details
The certificate chain has been validated up to a trusted root. Root =
[email protected], CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network.
Elapsed Time: 4 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 = 8/18/2011 6:11:10 PM, NotAfter = 10/18/2016 5:19:12 AM
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: 349 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: 509 ms.
Test Steps
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL
https://cpanelemaildiscovery.cpanel.net/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>[email protected]</DisplayName> </User> <Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>IMAP</Type> <Server>have02b.have1.com</Server>
<Port>993</Port> <DirectoryPort>0</DirectoryPort> <ReferralPort>0</ReferralPort> <SSL>on</SSL> <DomainRequired>off</DomainRequired> <SPA>off</SPA> <AuthRequired>on</AuthRequired>
<LoginName>[email protected]</LoginName> </Protocol> <Protocol> <Type>SMTP</Type> <Server>have02b.have1.com</Server> <Port>465</Port> <DirectoryPort>0</DirectoryPort> <ReferralPort>0</ReferralPort>
<SSL>on</SSL> <DomainRequired>off</DomainRequired> <SPA>off</SPA> <AuthRequired>on</AuthRequired> <LoginName>[email protected]</LoginName> </Protocol> </Account> </Response>
</Autodiscover> HTTP Response Headers: Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Length: 1362 Content-Type: text/xml Date: Fri, 28 Feb 2014 01:49:02 GMT Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.5
Perl/v5.8.8
Elapsed Time: 509 ms.
Autodiscover settings for Outlook Anywhere are being validated.
The Microsoft Connectivity Analyzer wasn't able to validate Outlook Anywhere Autodiscover settings.
Tell me more about this issue and how to resolve it
Additional Details
The EXCH provider section is missing from the Autodiscover response.
Elapsed Time: 0 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

Incorrect Outlook Anywhere Settings

Similar Messages

Maybe you are looking for