markfurey
asked on
Exchange 2013
We have a site that has multiple companies with the same building; some of the offices have their own SBS domains for a handful of users. One of the users from the main network had been moved to an SBS domain and is accessing the local SBS/Exchange Server, they would like this user to have access to the original Exchange Server but he account setup fails, but the PC has network (ping) and DNS resolution to the Exchange Server in the other domain. This PC already has access to another Exchange 2010 server using outlook anywhere through a public IP address.
So to summarize, a PC in an SBS domain already has access to the local exchange account and another using outlook anywhere, but when they try to connect the client to the exchange 2013 server in another AD domain it fails, any ideas please?
So to summarize, a PC in an SBS domain already has access to the local exchange account and another using outlook anywhere, but when they try to connect the client to the exchange 2013 server in another AD domain it fails, any ideas please?
James H
How are you setting up the connection to the 2010 server? OL Anywhere? Or internal?
ASKER
Hello,
I believe he's just using the normal method of adding an internal outlook/exchange client, but because its exchnage 2013 I'm assuming its using outlook anywhere anyway as it was my undersatnding that all clients, both local and external connect using https/outlook anywhere even on local networks.
I believe he's just using the normal method of adding an internal outlook/exchange client, but because its exchnage 2013 I'm assuming its using outlook anywhere anyway as it was my undersatnding that all clients, both local and external connect using https/outlook anywhere even on local networks.
That's correct, Exchange 2013 uses Outlook Anywhere exclusively. If you are trying to connect to an Exchange server in another domain, you need to make sure that he can successfully connect to the server using both the server's Host name and autodiscover.domain.com. So try to ping autodiscover.company.com, where company.com is the domain name of the exchange server he's trying to reach. If it doesn't resolve to an IP address, then you'll need to make sure that there is an A record for Autodiscover in the DNS zone on the server he's using for DNS.
ASKER
Hello, thanks for your comment, we have a couple of Exchange 2013 servers out there now and I don’t think we've needed to setup an autodiscover DNS record yet, I guess its more relevant here because the user is connected to another AD/Domain? Just to clarify, if the server's fqdn was server1.test.com, I would need to setup a DNS record to point to autodiscover.test.com?
You always need an Autodiscover record unless you have no external access to the server.
Without Autodiscover you are unable to access free/busy information, or have out of office work correctly. Autodiscover should not be considered an optional feature.
With Exchange 2013 Autodiscover is mandatory, because each user has a unique endpoint for their Exchange server. That is found by running an Autodiscover query. Therefore you need to sort out Autodiscover, either by adding Autodiscover.example.com to the SSL certificate or configuring SRV records.
Simon.
Without Autodiscover you are unable to access free/busy information, or have out of office work correctly. Autodiscover should not be considered an optional feature.
With Exchange 2013 Autodiscover is mandatory, because each user has a unique endpoint for their Exchange server. That is found by running an Autodiscover query. Therefore you need to sort out Autodiscover, either by adding Autodiscover.example.com to the SSL certificate or configuring SRV records.
Simon.
ASKER
Cheers Simon,
I appreciate what you’re saying but the fact remains that we have Exchange 2013 working in a number of environments without an autodiscover record; I think you’re suggesting that the record is required for remote/external access? In this scenario the user has internal routing access to the Exchange Server located on another internal subnet, its just the user is connected to another subnet with its own SBS domain. I have seen scenarios where the autodiscover process fails when the Outlook client is initially setup, here you can normally just add the outlook anywhere/HTTP Proxy settings and it then connects.
I’m just looking for a “quick fix” solution for one client.
I appreciate what you’re saying but the fact remains that we have Exchange 2013 working in a number of environments without an autodiscover record; I think you’re suggesting that the record is required for remote/external access? In this scenario the user has internal routing access to the Exchange Server located on another internal subnet, its just the user is connected to another subnet with its own SBS domain. I have seen scenarios where the autodiscover process fails when the Outlook client is initially setup, here you can normally just add the outlook anywhere/HTTP Proxy settings and it then connects.
I’m just looking for a “quick fix” solution for one client.
The fact that you have it working elsewhere without it does not mean that is the correct thing to do. The most common questions on this site will all come down to a lack of Autodiscover records being the root cause. If you are deploying that for customers then, being blunt, you are aren't doing a proper job if you are allowing remote access but are not setting up Autodiscover records. If you don't have Autodiscover then you have to do manual setup, but with Exchange 2013 that isn't possible because you cannot enter manual details for the server configuration because the end point is unique - look in Outlook, you will see that the server name is actually a GUID.
If there is another Exchange server on the same LAN and the client is a member of that domain, then you have an additional complication. Autodiscover internally will query the internal domain first, before it looks at DNS records. As you have no external Autodiscover information the client then gets confused.
You need to sort out Autodiscover - it is NOT just for the one time client configuration. The client will query Autodiscover at regular intervals.
Simon.
If there is another Exchange server on the same LAN and the client is a member of that domain, then you have an additional complication. Autodiscover internally will query the internal domain first, before it looks at DNS records. As you have no external Autodiscover information the client then gets confused.
You need to sort out Autodiscover - it is NOT just for the one time client configuration. The client will query Autodiscover at regular intervals.
Simon.
ASKER
OK Simon,
Think I get your point, no one at this site connects to the Exchange 2013 Server from the internet, only internal users, are you saying that there isn’t a method of connecting the PC through the internal network whilst it’s a member of another domain? I'm wondering if there's a method of adding a DNS record to the local SBS server which may help resolve the autodiscover address of the other Exchange Server?
Think I get your point, no one at this site connects to the Exchange 2013 Server from the internet, only internal users, are you saying that there isn’t a method of connecting the PC through the internal network whilst it’s a member of another domain? I'm wondering if there's a method of adding a DNS record to the local SBS server which may help resolve the autodiscover address of the other Exchange Server?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.