Outlook 2016 en autodiscover probleem

[HellBeast]

De eerste laptop met Office 2016 is uitgerold en nu wil Outlook 2016 niet met de Exchange 2010 server connecten. Ik heb wat gelezen en het blijkt dat Outlook 2016 alleen via Autodiscover kan worden ingesteld. Dat is nog helemaal niet geimplementeerd, dus ik heb het volgende gedaan:

Situatie (fictieve IP en naam):

voorbeeld.nl DNS beheer ligt bij een externe partij
Er worden self signed certificates gebruikt.

Mail.voorbeeld.nl wordt eerst naar een bedrijf gestuurd die de spam afvangt en daarna wordt het doorgestuurd naar het IP adres van de mailserver (60.1.1.1) fictief

Wat heb ik gedaan:

Ik heb een autodiscover.voorbeeld.nl A Host record laten aanmaken naar 60.1.1.1 fictief
De hosting provider heeft een SRV record aangemaakt:

_autodiscover
_tcp
poort: 443
host : autodiscover.voorbeeld.nl

Ik kan nu autodiscover.voorbeeld.nl pingen en die komt nu op onze mailserver uit. Daar draait ook OWA op (die het wel gewoon doet). De Microsoft Remote Connectivity Analyzer geeft nog steeds aan dat autodiscover niet werkt;

"Bezig met het uitproberen van elke methode om de service Automatisch opsporen te contacteren.
Er kon op geen enkele manier contact worden gemaakt met de Autodiscover-service. "

"Testen TCP-poort 443 op host voorbeeld.nl om de garanderen dat deze reageert en beschikbaar is.
De gespecificeerde poort wordt geblokkeerd, reageert niet of reageert niet zoals verwacht.
Bijkomende details
Er is een netwerkfout opgetreden tijdens het communiceren met de externe host."

Dit snap ik dus niet, omdat er ook OWA al op draait (https). Zou hij naar het voorbeeld.nl domein kijken of daar een autodiscover op zit?

Ik heb sowieso de indruk dat ik iets ben vergeten, maar ik weet niet wat.

Kan iemand me een zetje in de juiste richting geven? Kan ik dit ook bijvoorbeeld op een andere manier aan de praat krijgen?

[Dromer]

Ligt het niet gewoon aan je self signed certificaat?

[HellBeast]

Dat zou kunnen, ik ga dat na! thx

[Dennism]

Als je autodiscover niet 100% geimplementeerd hebt kan je Outlook ook met local autodiscover file inrichten. maar wel een boel "handwerk" dus eigenlijk alleen geschikt voor tests e.d., dus handiger is om z.s.m. Autodiscover goed in te richten.

Zie ook http://www.howto-outlook....discoverconfiguration.htm

[HellBeast]

Dankje, ik ga lezen!

[Razwer]

EN een SRV record EN een autodiscover.domein.xx niet niet best practise.
Lees deze aub eens door: https://technet.microsoft.com/en-us/library/bb332063.aspx
wanneer je @foo.nl gebruikt en autodiscover.foo.nl hebt aangemaakt zal de SRV record _autodiscover nooit en te nimmer opgepakt worden.
Beter gebruik je iets als mail.foo.nl als A record/cname voor je externe CAS (Outlook Anywhere/OWA/ActiveSync etc) en verwijst jouw _autodiscover SRV record naar die hostname.
Overigens werkt niet alles even jovel met SRV records. Een deel Android toestellen bijvoorbeeld.

[HellBeast]

Dat is nou juist het probleem mail.foo.nl staat naar een externe partij die eerst de mail afvangt en vervolgens doorstuurt naar de mailserver.

[Jazzy]

Mail heeft hier helemaal niets mee te maken. Autodiscover clients (Outlook, ActiveSync, etc.) gebruiken een vaste volgorde om de AutoDiscover service te vinden en doen dat via HTTP en HTTPS. Het is heel gebruikelijk dat een aantal van die stappen mislukken, als er uiteindelijk maar eentje lukt.

Vervolgens krijgt de client van de AutoDiscover service een XML met daarin de gegevens om de client te configureren.

Als je nu naar de output van de Remote Connectivity Analyzer kijkt dan zal de eerste poging mislukken (https://domein.nl/autodiscover/autodiscover.xml omdat deze hoogstwaarschijnlijk niet bij je mailserver uitkomt maar doorgaans bij een hoster waar de website draait.

De tweede poging gaat naar https://autodiscover.domein.nl/autodiscover/autodiscover.xml. De test zal eerst kijken of het dns-record autodiscover.domein.nl geresolved kan worden (wat lukt, want je hebt deze aan laten maken), controleert dan of poort 443 open staat, of de hostnaam autodiscover.domein.nl op het certificaat staat, of hij kan authenticeren, etc. Als er in deze stap dus iets mis gaat dan zal je dat moeten oplossen.

Zoals gezegd is het aanmaken van het SRV-record in dit geval overbodig omdat de tweede methode al werkt. Clients zullen het SRV-record nooit op gaan zoeken, als ze dit al ondersteunen.

Je bent lekker op tijd trouwens, AutoDiscover is er sinds Exchange 2007 en Outlook 2007.

[ Voor 3% gewijzigd door Jazzy op 27-11-2015 15:50 ]

[Razwer]

HellBeast schreef op vrijdag 27 november 2015 @ 15:41:
Dat is nou juist het probleem mail.foo.nl staat naar een externe partij die eerst de mail afvangt en vervolgens doorstuurt naar de mailserver.

dan noem je het mail2,foo.nl of hier.foo.nl of sjakie.foo.nl. Alles behalve autodiscover

[ Voor 5% gewijzigd door Razwer op 27-11-2015 22:30 ]

[Jazzy]

Waarom niet autodiscover? En als je dan toch voor een SRV-record kiest zie ik nog steeds niet in waarom je niet mail.foo.nl als hostnaam zou gebruiken.

[ Voor 71% gewijzigd door Jazzy op 27-11-2015 22:42 ]

[Razwer]

Jazzy schreef op vrijdag 27 november 2015 @ 22:41:
Waarom niet autodiscover? En als je dan toch voor een SRV-record kiest zie ik nog steeds niet in waarom je niet mail.foo.nl als hostnaam zou gebruiken.

Het kan, maar niet in de toepassing van de TS die een SRV record wil gebruiken. Vandaar mijn antwoord.

[Jazzy]

Ah, ik snap het. Maar volgens mij hadden we ook al vastgesteld dat het SRV-record nooit gebruikt gaat worden als je autodiscover.foo.nl als hostnaam gebruikt. En het alternatief, dus wel voor een SRV-record gaan, kan nog steeds prima met mail.foo.nl als hostnaam. Dat er voor MX-records en mailflow een andere route gebruikt wordt is totaal niet relevant. Jij weet dat wel, maar hopelijk de TS inmiddels ook.

[webgangster]

Ik breek even in, ik zit namelijk met hetzelfde probleem in mijn speelomgeving.
Volgens https://testconnectivity.microsoft.com werkt mijn SRV prima, wordt er netjes een XML gegenereerd.
Echter in de client komt de volgende melding naar voren: Kan de server niet vinden.

Ik heb hier al vanalles geprobeerd, van excas10.xx.domein.nl tot email.domein.nl
Het is mij 1 keer gelukt om een certificaat melding te krijgen, daarna nooit meer gezien.
Er is een wildcard SSL certificaat geinstalleerd, ondanks dat dit niet netjes is zou hij wel gewoon moeten werken, intern op een domein computer werkt het immers ook door de certificaat meldingen te negeren.

Alle virtuale mappen zijn goed ingesteld (intern/extern).
Is er iemand die een idee heeft waar het bij mij mis gaat?

[Jazzy]

Dat is dus niet hetezelfde probleem. Wat is het resultaat als je niet de Autodiscover maar de Outlook Connectivity test uitvoert? Gebruik je Outlook Anywhere of MAPI over HTTP? Wat heb je ingesteld als InternalURL en ExternalURL en bij Outlook Anywhere? Heb je de authenticatie instellingen aangepast of staan die nog standaard? Intern krijg je certificaatmeldingen? Welke melding?

[webgangster]

Jazzy schreef op dinsdag 01 december 2015 @ 22:35:
Dat is dus niet hetezelfde probleem. Wat is het resultaat als je niet de Autodiscover maar de Outlook Connectivity test uitvoert? Gebruik je Outlook Anywhere of MAPI over HTTP? Wat heb je ingesteld als InternalURL en ExternalURL en bij Outlook Anywhere? Heb je de authenticatie instellingen aangepast of staan die nog standaard? Intern krijg je certificaatmeldingen? Welke melding?

Het resultaat als ik de Outlook Connectivity test uitvoer is geslaagd, instellingen worden automatisch opgespoord. Netjes de melding: Aanmelden bij het postvak is geslaagd.

Ik gebruik voor zowel intern als extern de URL: email.domein.nl
Zowel in de interne als externe DNS zijn de externe IP adressen toegevoegd.

Ik krijg intern de melding dat de naam van het certificaat niet overeenkomt met de bron die ik wil opvragen. Dat klopt want ik heb een wildcard certificaat, en dat mag niet op een CAS?

Authenticatie staat op Basis ingesteld op de Outlook Anywhere, maar hier heb ik mee lopen spelen de afgelopen tijd. Volgens de Outlook Connectivity test wordt er gebruik gemaakt van MAPI over HTTP.

[ Voor 9% gewijzigd door webgangster op 01-12-2015 22:58 ]

[Jazzy]

webgangster schreef op dinsdag 01 december 2015 @ 22:51:
Ik krijg intern de melding dat de naam van het certificaat niet overeenkomt met de bron die ik wil opvragen. Dat klopt want ik heb een wildcard certificaat, en dat mag niet op een CAS?

Waarom mag dat niet? Als je hostnaam mail.domein.nl is en je certificaat voor *.domein.nl dan is er niets aan de hand. Wat is exact de melding die je krijgt, want de url die Outlook aanroept wijkt dus blijkbaar af van het subject op je certificaat.

[webgangster]

Jazzy schreef op woensdag 02 december 2015 @ 08:51:
[...]

Waarom mag dat niet? Als je hostnaam mail.domein.nl is en je certificaat voor *.domein.nl dan is er niets aan de hand. Wat is exact de melding die je krijgt, want de url die Outlook aanroept wijkt dus blijkbaar af van het subject op je certificaat.

Op de manier zoals jij dat beschrijft mag dat uiteraard wel, maar *.xx.domein.nl niet.
Intern krijg ik de melding van bij beide Client Access Servers naar voren welke voldoen aan *.xx.domein.nl.

Kortom, ik gok zo dat ik intern en extern dezelfde URL's moet gebruiken.
Als ik binnen Office 2016 de URL van mijn CAS invul krijg ik dezelfde certificaat melding.

Ik komt denk ik wel verder met het command Set-IMAPSettings en Set-POPSettings om de wildcard certificaat te koppelen aan de IMAP en POP services.

[ Voor 9% gewijzigd door webgangster op 02-12-2015 11:46 ]

[Jazzy]

Je schrijft hierboven:

Ik gebruik voor zowel intern als extern de URL: email.domein.nl

Waarom begin je nu dan over *.xx.domein.nl en verschil tussen intern en extern?

[webgangster]

Jazzy schreef op woensdag 02 december 2015 @ 11:56:
Je schrijft hierboven:
[...]

Waarom begin je nu dan over *.xx.domein.nl en verschil tussen intern en extern?

Ik zat zelf op dat moment te denken aan de Outlook Anywhere instellingen, deze staan inderdaad intern en extern hetzelfde. De virtuele mappen heb ik zojuist aangepast.

Ik krijg dus bij het starten van Outlook nu 2 meldingen van mijn 2 CAS'en.
Zie foto:


Als excas30 nu email.domein.nl was geweest was er niets aan der hand geweest...
Moet ik misschien zelf ondertekende certificaten verwijderen?

Laatste bewerking: Na herstart van de CAS'en geen certificaat melding meer voorbij zien komen.

[ Voor 59% gewijzigd door webgangster op 02-12-2015 13:15 ]

[Jazzy]

Dat was hem dus. Controleer dan ook gelijk je SCP nog even om te zien of daar de goede url staat: Get-ClientAccessServer | fl name,*uri*

[webgangster]

Jazzy schreef op woensdag 02 december 2015 @ 13:47:
Dat was hem dus. Controleer dan ook gelijk je SCP nog even om te zien of daar de goede url staat: Get-ClientAccessServer | fl name,*uri*

Daar staat excas10 / excas30.xx.domein.nl
Dat verklaard natuurlijk wel het een en ander.

Direct aangepast met Set-ClientAccessServer

[ Voor 11% gewijzigd door webgangster op 02-12-2015 15:00 ]

[Jazzy]

Mooi dat het werkt. Moet wel zeggen dat je werkelijk alle esseintiele stappen om Autodiscover te configureren overgeslagen had, zowel de configuratie om de AutoDiscover service te localiseren als het ervoor zorgen dat de juiste gegevens uitgedeeld worden. En aan je servernaam te zien heb je de Exchange-rollen ook nog eens op aparte servers geïnstalleerd.

Misschien kun je beter de Exchange Deployment Assistant gebruiken en een paar architectuur sessies op Channel9 bekijken, bijvoorbeeld die van Ignite. Dan ken je tenminste de basics en hoef je niet dit soort dingen achteraf nog een keer te gaan troubleshooten.

[Monkeybrains]

Dennism schreef op donderdag 26 november 2015 @ 19:58:
Als je autodiscover niet 100% geimplementeerd hebt kan je Outlook ook met local autodiscover file inrichten. maar wel een boel "handwerk" dus eigenlijk alleen geschikt voor tests e.d., dus handiger is om z.s.m. Autodiscover goed in te richten.

Zie ook http://www.howto-outlook....discoverconfiguration.htm

Dank voor het delen van deze link, het lost een probleem op wat ik bij onze omgeving heb met autodiscover. Primair mailadres (laten we het remotedomain.com noemen) wordt afgehandeld door een exchange server in een ander land/AD domain. Deze mail server forward de mail naar ons toe. Wij hebben zelf ook een AD/Exchange omgeving. De gebruikers hebben dus remotedomain.com als primair email adres, en oa localdomain.nl en een paar andere domains als additionele mail adressen.

Don't ask, het is een houtje touwtje oplossing, maar het is momenteel nou eenmaal zo (migratie naar Office 365 zit er gelukkig aan te komen).

Probleem in deze situatie is echter dat Outlook uiteraard naar remotedomain.com gaat lopen autodiscoveren, met alle gevolgen vandien. De Local XML redirect lijkt een mooie oplossing hiervoor, ik ga hier eens verder mee testen.