How can I fix Autodiscover for local clients in on premise Exchange 2013
After following this guide:
https://acbrownit.com/2014/04/04/exchange-autodiscover-episode-2-attack-of-the-exchange-server/
My internal Outlook clients can't connect to Exchange 2013 server.
I was trying to get rid of a certificate error because of the DOMAIN.local not being included in the certificate.
I only changed ServiceBindingInformation attribute from:
https://autodiscover.DOMAIN.local/autodiscover/autodiscover.xml
to:
https://autodiscover.DOMAIN.com/autodiscover/autodiscover.xml
Since then, I've reverted back hoping it would resolve the issue with the internal Outlook clients but nothing changed. OWA is having issues too. After logging in, the page, 'Something went wrong' comes up.
Any help is much appreciated.
exchange
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
migrated from superuser.com Jan 18 at 21:59
This question came from our site for computer enthusiasts and power users.
add a comment |
After following this guide:
https://acbrownit.com/2014/04/04/exchange-autodiscover-episode-2-attack-of-the-exchange-server/
My internal Outlook clients can't connect to Exchange 2013 server.
I was trying to get rid of a certificate error because of the DOMAIN.local not being included in the certificate.
I only changed ServiceBindingInformation attribute from:
https://autodiscover.DOMAIN.local/autodiscover/autodiscover.xml
to:
https://autodiscover.DOMAIN.com/autodiscover/autodiscover.xml
Since then, I've reverted back hoping it would resolve the issue with the internal Outlook clients but nothing changed. OWA is having issues too. After logging in, the page, 'Something went wrong' comes up.
Any help is much appreciated.
exchange
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
migrated from superuser.com Jan 18 at 21:59
This question came from our site for computer enthusiasts and power users.
Did you create the appropriate DNS record in the correct DNS zone?
– joeqwerty
Jan 18 at 22:05
If I am reading that page correctly then you need to create the entire DNS zone, and then populate it with A records and an MX record. So you would need both DOMAIN.local and DOMAIN.com.
– Larryc
Jan 18 at 23:41
Yes, from the article: "Note, though, that like the SRV record you will be forcing your internal clients to go out of your network to the Internet to access your Exchange server. To keep this from happening, you will have to have an Internal version of your External DNS zone that has Internal IPs assigned in all the A records. There just is no way around that with private domain names any longer." So if the SCP now says DOMAIN.com then DOMAIN.com must exist in your internal DNS.
– Larryc
Jan 18 at 23:59
I've reverted back in any case so there's no need for the extra DNS records. SCP is now pointing back to DOMAIN.local and I still can't get any clients connected to Exchange.
– n00bAdmin
Jan 19 at 9:55
Hi, The “servicebindinginformation” attribute is related to “AutoDiscoverServiceInternalUri” value by “Get-ClientAccessServer”. What is your configuration now? Internal domain client will check the SCP first, get the URL, then try to connect. I think you need a domain.com DNS zone, and Autodiscover.domain.com record points to the Exchange server if using “autodiscover.domain.com...”.
– Shaw
Jan 21 at 8:12
add a comment |
After following this guide:
https://acbrownit.com/2014/04/04/exchange-autodiscover-episode-2-attack-of-the-exchange-server/
My internal Outlook clients can't connect to Exchange 2013 server.
I was trying to get rid of a certificate error because of the DOMAIN.local not being included in the certificate.
I only changed ServiceBindingInformation attribute from:
https://autodiscover.DOMAIN.local/autodiscover/autodiscover.xml
to:
https://autodiscover.DOMAIN.com/autodiscover/autodiscover.xml
Since then, I've reverted back hoping it would resolve the issue with the internal Outlook clients but nothing changed. OWA is having issues too. After logging in, the page, 'Something went wrong' comes up.
Any help is much appreciated.
exchange
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
After following this guide:
https://acbrownit.com/2014/04/04/exchange-autodiscover-episode-2-attack-of-the-exchange-server/
My internal Outlook clients can't connect to Exchange 2013 server.
I was trying to get rid of a certificate error because of the DOMAIN.local not being included in the certificate.
I only changed ServiceBindingInformation attribute from:
https://autodiscover.DOMAIN.local/autodiscover/autodiscover.xml
to:
https://autodiscover.DOMAIN.com/autodiscover/autodiscover.xml
Since then, I've reverted back hoping it would resolve the issue with the internal Outlook clients but nothing changed. OWA is having issues too. After logging in, the page, 'Something went wrong' comes up.
Any help is much appreciated.
exchange
exchange
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
asked Jan 18 at 21:30
n00bAdminn00bAdmin
61
61
migrated from superuser.com Jan 18 at 21:59
This question came from our site for computer enthusiasts and power users.
migrated from superuser.com Jan 18 at 21:59
This question came from our site for computer enthusiasts and power users.
Did you create the appropriate DNS record in the correct DNS zone?
– joeqwerty
Jan 18 at 22:05
If I am reading that page correctly then you need to create the entire DNS zone, and then populate it with A records and an MX record. So you would need both DOMAIN.local and DOMAIN.com.
– Larryc
Jan 18 at 23:41
Yes, from the article: "Note, though, that like the SRV record you will be forcing your internal clients to go out of your network to the Internet to access your Exchange server. To keep this from happening, you will have to have an Internal version of your External DNS zone that has Internal IPs assigned in all the A records. There just is no way around that with private domain names any longer." So if the SCP now says DOMAIN.com then DOMAIN.com must exist in your internal DNS.
– Larryc
Jan 18 at 23:59
I've reverted back in any case so there's no need for the extra DNS records. SCP is now pointing back to DOMAIN.local and I still can't get any clients connected to Exchange.
– n00bAdmin
Jan 19 at 9:55
Hi, The “servicebindinginformation” attribute is related to “AutoDiscoverServiceInternalUri” value by “Get-ClientAccessServer”. What is your configuration now? Internal domain client will check the SCP first, get the URL, then try to connect. I think you need a domain.com DNS zone, and Autodiscover.domain.com record points to the Exchange server if using “autodiscover.domain.com...”.
– Shaw
Jan 21 at 8:12
add a comment |
Did you create the appropriate DNS record in the correct DNS zone?
– joeqwerty
Jan 18 at 22:05
If I am reading that page correctly then you need to create the entire DNS zone, and then populate it with A records and an MX record. So you would need both DOMAIN.local and DOMAIN.com.
– Larryc
Jan 18 at 23:41
Yes, from the article: "Note, though, that like the SRV record you will be forcing your internal clients to go out of your network to the Internet to access your Exchange server. To keep this from happening, you will have to have an Internal version of your External DNS zone that has Internal IPs assigned in all the A records. There just is no way around that with private domain names any longer." So if the SCP now says DOMAIN.com then DOMAIN.com must exist in your internal DNS.
– Larryc
Jan 18 at 23:59
I've reverted back in any case so there's no need for the extra DNS records. SCP is now pointing back to DOMAIN.local and I still can't get any clients connected to Exchange.
– n00bAdmin
Jan 19 at 9:55
Hi, The “servicebindinginformation” attribute is related to “AutoDiscoverServiceInternalUri” value by “Get-ClientAccessServer”. What is your configuration now? Internal domain client will check the SCP first, get the URL, then try to connect. I think you need a domain.com DNS zone, and Autodiscover.domain.com record points to the Exchange server if using “autodiscover.domain.com...”.
– Shaw
Jan 21 at 8:12
Did you create the appropriate DNS record in the correct DNS zone?
– joeqwerty
Jan 18 at 22:05
Did you create the appropriate DNS record in the correct DNS zone?
– joeqwerty
Jan 18 at 22:05
If I am reading that page correctly then you need to create the entire DNS zone, and then populate it with A records and an MX record. So you would need both DOMAIN.local and DOMAIN.com.
– Larryc
Jan 18 at 23:41
If I am reading that page correctly then you need to create the entire DNS zone, and then populate it with A records and an MX record. So you would need both DOMAIN.local and DOMAIN.com.
– Larryc
Jan 18 at 23:41
Yes, from the article: "Note, though, that like the SRV record you will be forcing your internal clients to go out of your network to the Internet to access your Exchange server. To keep this from happening, you will have to have an Internal version of your External DNS zone that has Internal IPs assigned in all the A records. There just is no way around that with private domain names any longer." So if the SCP now says DOMAIN.com then DOMAIN.com must exist in your internal DNS.
– Larryc
Jan 18 at 23:59
Yes, from the article: "Note, though, that like the SRV record you will be forcing your internal clients to go out of your network to the Internet to access your Exchange server. To keep this from happening, you will have to have an Internal version of your External DNS zone that has Internal IPs assigned in all the A records. There just is no way around that with private domain names any longer." So if the SCP now says DOMAIN.com then DOMAIN.com must exist in your internal DNS.
– Larryc
Jan 18 at 23:59
I've reverted back in any case so there's no need for the extra DNS records. SCP is now pointing back to DOMAIN.local and I still can't get any clients connected to Exchange.
– n00bAdmin
Jan 19 at 9:55
I've reverted back in any case so there's no need for the extra DNS records. SCP is now pointing back to DOMAIN.local and I still can't get any clients connected to Exchange.
– n00bAdmin
Jan 19 at 9:55
Hi, The “servicebindinginformation” attribute is related to “AutoDiscoverServiceInternalUri” value by “Get-ClientAccessServer”. What is your configuration now? Internal domain client will check the SCP first, get the URL, then try to connect. I think you need a domain.com DNS zone, and Autodiscover.domain.com record points to the Exchange server if using “autodiscover.domain.com...”.
– Shaw
Jan 21 at 8:12
Hi, The “servicebindinginformation” attribute is related to “AutoDiscoverServiceInternalUri” value by “Get-ClientAccessServer”. What is your configuration now? Internal domain client will check the SCP first, get the URL, then try to connect. I think you need a domain.com DNS zone, and Autodiscover.domain.com record points to the Exchange server if using “autodiscover.domain.com...”.
– Shaw
Jan 21 at 8:12
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f949807%2fhow-can-i-fix-autodiscover-for-local-clients-in-on-premise-exchange-2013%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f949807%2fhow-can-i-fix-autodiscover-for-local-clients-in-on-premise-exchange-2013%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Did you create the appropriate DNS record in the correct DNS zone?
– joeqwerty
Jan 18 at 22:05
If I am reading that page correctly then you need to create the entire DNS zone, and then populate it with A records and an MX record. So you would need both DOMAIN.local and DOMAIN.com.
– Larryc
Jan 18 at 23:41
Yes, from the article: "Note, though, that like the SRV record you will be forcing your internal clients to go out of your network to the Internet to access your Exchange server. To keep this from happening, you will have to have an Internal version of your External DNS zone that has Internal IPs assigned in all the A records. There just is no way around that with private domain names any longer." So if the SCP now says DOMAIN.com then DOMAIN.com must exist in your internal DNS.
– Larryc
Jan 18 at 23:59
I've reverted back in any case so there's no need for the extra DNS records. SCP is now pointing back to DOMAIN.local and I still can't get any clients connected to Exchange.
– n00bAdmin
Jan 19 at 9:55
Hi, The “servicebindinginformation” attribute is related to “AutoDiscoverServiceInternalUri” value by “Get-ClientAccessServer”. What is your configuration now? Internal domain client will check the SCP first, get the URL, then try to connect. I think you need a domain.com DNS zone, and Autodiscover.domain.com record points to the Exchange server if using “autodiscover.domain.com...”.
– Shaw
Jan 21 at 8:12