• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3014
  • Last Modified:

Outlook Clients Popup AutoDiscover redirect warning

We have Exchange server 2013 and Outlook 2010/2013 clients. All client services are published via Kemp Load balancer.

Problem is all outlook clients are popup the Autodiscover direct warning. I want to stop this without editing the REG.

Please see attached file. Autodiscover warning
0
ucguy
Asked:
ucguy
  • 3
  • 3
  • 2
  • +3
1 Solution
 
MadHatterAdminCommented:
Is your kemp pointed to a host object backend by a NLB & CAS array? More info about the architecture would help. Of recent that's how I deployed a solution and havent had an auto discover problem.

Have you reference the kemp deployment guide? A quick google will pull it up.
0
 
ucguyAuthor Commented:
Ex2013 does not have CAS Array
0
 
tshearonCommented:
Make sure you have the correct Autodiscover record. You should have your Autodiscover.domain.com pointed to the correct IP. Also make sure you check the SRV DNS records and ensure they point to the current environment and not an older one.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
Gareth GudgerCommented:
Hey ucguy,

Just wanted to confirm. Because of the changes between 2010 and 2013, did you use Kemp's Exchange 2013 template to set all this up? Just wanted to make sure you didn't use their 2010 template.
0
 
BMardenCommented:
Domain name is blotted but I suspect you are getting Autodiscover from external (hosted domain).

The autodiscover on internal DNS should point to the exchange server, if you do not have an internal autodiscover you should create one.

BM
0
 
Gareth GudgerCommented:
The autodiscover on internal DNS should point to the exchange server, if you do not have an internal autodiscover you should create one.

This is not entirely correct BMarden. The internal autodiscover record should point to the Kemp VIP.
0
 
Adam FarageEnterprise ArchCommented:
Ah Gareth, how I missed ya :)

Alright so lets clarify a few things.. mainly on how the KEMP is setup. I am pretty well versed in the KEMP as I have set these up for the last four years.

- DNS.. on both internal and external where does autodiscover.company.com go to? In theory the CAS should have the AutoDiscoverInternalUri set (Get-ClientAccessServer | Select Name, AutoDiscoverInternalUri) to autodiscover.company.com, and then you should have an A record pointing to the VIP. For external clients the A record should point to the NAT that does TCP 443 to the KEMP itself.

- In Exchange does the SSL certificate contain autodiscover.company.com? If not I would recommend grabbing a SAN and throw this along with your OWA URL on there.

- This can also be a KEMP issue. Are you doing Layer 7 or Layer 4 load balancing? Are you doing SSL offloading or SSL Bridging? In most cases for Layer 7 to work you should be doing SSL bridging so the KEMP can decrypt the packet, figure out the route and then re-encrypt it (at least if you followed the guide, which I am not saying you didnt.. but it does go over context rules and such). If you are using the template you are most likely doing persistence using L4 which would use Source IP (Layer 7 uses Super HTTP usually - requires some type of SSL bridging/offloading). Make sure the SSL certificate is valid on the KEMP device along with the intermediate certificate

Last but not least.. what does the SSL certificate located at? If you look at the details on what the Outlook client gets you can probably figure out the location.

@BMarden, you are absolutely wrong..

Internal AutoDiscover in Exchange 2010 on is automatically enabled (you can disable it through the registry, but its unsupported and will not work for Exchange 2013). To define internal, this is for domain joined clients who are using the Outlook client. What happens is when Outlook opens up and is a domain joined machine it looks at the local Active Directory server for the AutoDiscover SCP (defined by the CAS attribute AutoDiscoverInternalUri). That URL returned should be pointed only to an Exchange server if only a single CAS exists. Since the client is using a KEMP load balancer he would have this pointed in via a DNS A record to the VIP of the KEMP device.
0
 
ucguyAuthor Commented:
hello Adam,

Please note below answers.

 - DNS.. on both internal and external where does autodiscover.company.com go to? In theory the CAS should have the AutoDiscoverInternalUri set (Get-ClientAccessServer | Select Name, AutoDiscoverInternalUri) to autodiscover.company.com, and then you should have an A record pointing to the VIP. For external clients the A record should point to the NAT that does TCP 443 to the KEMP itself.

1) Both External and Internal Autodiscover.company.com pointed to Kemp VIP. Created the A record for it as well.

2)   - In Exchange does the SSL certificate contain autodiscover.company.com? If not I would recommend grabbing a SAN and throw this along with your OWA URL on there.
In SSL certificate has Autodiscover.company.com as SAN.

3) I have certificate stored on the Kemp. when i check OWA, i cannot see any certificate errors.

4)  Internal AutoDiscover in Exchange 2010 on is automatically enabled (you can disable it through the registry, but its unsupported and will not work for Exchange 2013). To define internal, this is for domain joined clients who are using the Outlook client. What happens is when Outlook opens up and is a domain joined machine it looks at the local Active Directory server for the AutoDiscover SCP (defined by the CAS attribute AutoDiscoverInternalUri). That URL returned should be pointed only to an Exchange server if only a single CAS exists. Since the client is using a KEMP load balancer he would have this pointed in via a DNS A record to the VIP of the KEMP device.

I changed the internal autodiscoveruri to autodiscover.company.com and pointed to VIP.
0
 
Adam FarageEnterprise ArchCommented:
when you changed the AutoDiscoverServiceInteralUri did the errors stop?
0
 
ucguyAuthor Commented:
I have done all the changes before post this question.
0
 
Adam FarageEnterprise ArchCommented:
Run the following and post the results below:

Get-WebServicesVirtualDirectory | FL *URL*

That could also be from a misconfigured InternalURL for Exchange Web Services.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 3
  • 3
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now