Exchange server intern niet bereikbaar middels autodiscover

[Verwijderd]

Ik heb een probleem, waar ik compleet vast loop.

Ik heb intern 2x een DC (192.168.230.100 & 192.168.230.101) en 2x een Exchange 2013 server.
(192.168.230.200 & 192.168.230.201)
(overige IP info voor deze servers: subnet 255.255.254.0, gateway, 192.168.230.1,
DNS 192.168.230.100 & 192.68.230.101 op de DC's staan forwarders aan in de DNS naar OpenDNS)

Deze zijn extern middels autodiscover perfect bereikbaar. (via Outlook)

Dit werkt allemaal top!

De servers (VM's) hangen achter een Sonicwall.
Nu heb ik een VM welke in vlan 15 hangt deze heeft IP 192.168.18.100
de subnet 255.255.255.0 en gateway 192.168.18.1
De DNSen gaan gewoon naar OpenDNS 208.67.222.222 & 208.67.220.220

Vanaf deze server wil ik graag via de autodiscover met de Exchange server connecten,
welke in de LAN hangt. Helaas vind hij deze niet.
Ik geef gewoon het mailadres + wachtwoord, helaas vind Outlook niets.
(terwijl dit extern wel het geval is)

De poorten welke nodig zijn voor OutlookAnyWhere, staan middels NAT policy's open in de Sonicwall.
Ik wil dus via de VM connecten naar de Exchange op zijn externe IP.

Overigens heb ik het ook op een servertje welke in de 192.168.230.x range hangt geprobeerd.
Deze heeft IP 192.168.230.20, subnet 255.255.254.0 gateway 192.168.230.1
DNS ook weer OpenDNS. Helaas verbindt hij daar ook niet.

Ik moet de OutlookAnyWhere functie ook intern hebben op de VM.
Deze VM mag absoluut niet bij het LAN netwerk, daarom hangt deze in aparte VLAN 15.
Hoe kan ik er voor zorgen dat OutlookAnyWhere ook hier werkt.
Websites van interne webservers (ook in 230 range) die ook middels extern IP worden benaderd functioneren wel.
Dat is toch vreemd?

[Kompaan]

Je hebt split DNS (resolve domeinnaam naar interne IP) of NAT Loopback (NAT ook verkeer naar het externe IP als het van LAN naar LAN gaat) nodig.

[Verwijderd]

Dat werkt helaas niet. De dns resolved ook al goed naar het externe IP dat is dus niet het probleem.
Als ik de hostfile op de VM aanpas in de VLAN 15 dan vind hij de server wel.
Ik pas de hostfile dan aan naar de interne IP's van de Exchange server. (had dit liever niet)
Maar het servertje in de 192.168.230.x range werkt alles dan perfect.

Maar op de server met IP 192.168.18.100 krijg ik dan een foutmelding: naam komt niet overeen met naam in de adreslijst

En hierna gaat hij niet verder.
Toch vreemd dat hij dit alleen op de servers in de vlans geeft.

[Ethirty]

Moet eerst zeggen dat ik met Exchange 2013 nog geen ervaring heb, maar het concept zal niet veel verschillen met 2010.

Als je vanaf een pc in een ander VLAN interrn blijft zal je DNS moeten resolven naar je interne IP, niet naar je externe. De meeste, zo niet alle, firewalls snappen niet goed hoe ze verkeer op die manier moeten afhandelen.

Als een computer in hetzelfde subnet zit als de Exchange server wordt volgens mij de voorkeur gegeven voor RPC terwijl buiten het subnet RPC over HTTPS gebruikt wordt. Hoe dat proces technisch precies werkt kan ik je niet meer vertellen, maar ik vermoed dat hij uit je AD of DNS anders afleid wat je Exchange server is (mijn kennis daarin zakt verbazingwekkend snel weg als je er eventjes niet meer mee bezig bent).

Advies is om, mede ingegeven door SSL richtlijnen, intern de server.domein.local te vervangen door mail.domein.nl. Dit doe je zowel in je interne DNS (extra zone met je domeinnaam aanmaken en daarin verwijzingen voor mail en autodiscover) als binnen de configuratie voor Exchange.

Het is eenmalig wat werk, maar daarna werkt het als een trein. Zodra je nu vanuit je VLAN Outlook instelt zal de autodiscover resolven naar je interne IP van je server en buiten je netwerk netjes naar je externe IP.

[Kompaan]

Verwijderd schreef op donderdag 25 april 2013 @ 00:10:
Dat werkt helaas niet. De dns resolved ook al goed naar het externe IP dat is dus niet het probleem.

Dat moet dus op alle interne netwerken (op alle VLANs dus) het interne IP zijn.

[Verwijderd]

Kompaan, ik heb het zojuist ingesteld.
De loopback werkt.

Echter doet het nu helemaal niets meer...
In de hostfile deed het nog iets.

Maar ik zie dat hij netjes naar de interne server gaat, toch werkt het vanaf de VLAN nog niet.

[ Voor 78% gewijzigd door Verwijderd op 25-04-2013 01:32 ]

[Linke Loe]

Ethirty schreef op donderdag 25 april 2013 @ 00:35:
Als een computer in hetzelfde subnet zit als de Exchange server wordt volgens mij de voorkeur gegeven voor RPC terwijl buiten het subnet RPC over HTTPS gebruikt wordt. Hoe dat proces technisch precies werkt kan ik je niet meer vertellen, maar ik vermoed dat hij uit je AD of DNS anders afleid wat je Exchange server is (mijn kennis daarin zakt verbazingwekkend snel weg als je er eventjes niet meer mee bezig bent).

In Exchange 2013 wordt alleen maar via HTTPS verbinding gemaakt met de CAS servers. RPC wordt dus niet meer gebruikt...

Ik neem aan dat poort 443 wel gewoon open staat tussen de verschillende VLAN's? Met andere woorden: kun je wel vanaf VLAN 18 naar "https://exchangeserver/owa" browsen?

[ Voor 5% gewijzigd door Linke Loe op 25-04-2013 12:03 ]

[Verwijderd]

Yep dat gaat gewoon inderdaad. Ik was er inderdaad van op de hoogte, dat Ex2013 alleen nog HTTPS gebruikt.

[Ethirty]

Doe eens een ping vanuit je VLAN naar de externe fqdn van je mailserver. Krijg je dan netjes 192.168.230.x terug?

[Verwijderd]

Het lijkt nu te werken. Ik zit nog met wat certificaat issues, maar hij maakt verbinding.
Ik heb alle loops weg gehaald, alle DNSen uit de hostfile, alles weer netjes dicht gezet.

Dit was de oplossing.
De connectivity tester, zei mij de msstd aan te passen, echter heb ik een wildchard cerificaat.

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:mail.domein.nl

Moest worden

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.domein.nl

Nu werkt het wel goed.

Alleen krijg ik nu nog een certificaatfoutje, ik heb namelijk een certificaat met daar achter meerdere domeinen. (middels redirect, zou dat goed moeten gaan, doet het nog niet)

[ElCondor]

Heb je wel degelijk een wildcard of een multiple domain name certificaat? Als het gaat om een multiple domain name certificate dan moet het DNS record waarmee het inkomend request bij de server komt één van de namen gebruiken die op het certificaat staan.

Wat je nu doet met je OutlookProvider is het zetten naar een wildcard certificate. Dan moet je denk ik ook een wildcard certificate op je server hebben staan. Dat is een dure grap. Kun je de asterisk in je call hierboven niet vervangen door een rijtje met namen die allen op je certificaat staan?

[Verwijderd]

ElCondor, ik heb inderdaad een wildcard certificaat.
Uiteindelijk bleek dat ik de redirect in IIS dezelfde ip adressen als de DAG had gegeven, dit veroorzaakte de problemen. Stom, maar het is gelukkig opgelost :-)!

[Verwijderd]

Het werkt momenteel extern goed, het werkt goed op een server in het zelfde lan.
(met andere DNSen, en die niet in het domein hangt)
Maar het werkt niet op een server in een VLAN, tevens loopbacks gemaakt in de router etc.

Ik krijg dan bij het laatste vinkje de melding dat hij de gebruiker niet overeen komt met een naam op de adreslijst.
Server is netjes te benaderen, inloggen via de OAB link werkt ook perfect van het VLAN.
Alle exchange servers zijn tevens perfect te pingen.

Het vreemde is dat ik een andere VLAN server heb waar alles netjes draait, maar ik kan daar ook geen nieuwe mailboxen toegevoegd krijgen. (verschillende boxen geprobeerd, meerdere malen profiel opnieuw aangemaakt)

[Verwijderd]

Iemand een idee?

[Equator]

Zou je een tekeningetje van de omgeving kunnen plaatsen met de belangrijke zaken erin? (IP adressen, Gateway's, AD, Mailbox Servers en andere rollen etc..)
Dat helpt mij meestal veel beter om inzicht te krijgen.

[Ethirty]

Dat zou inderdaad wel helpen, want ik begrijp niet helemaal meer hoe eea nu in elkaar zit. Het lijkt op een aantal punten dusdanig af te wijken van hoe ik gewend ben te werken dat ik het overzicht kwijt ben.

Gewoon even iets simpels met Visio ofzo

[ Voor 9% gewijzigd door Ethirty op 15-05-2013 10:17 ]

[Verwijderd]

Ik heb even snel een plaatje in elkaar gezet.
Op de VLAN 1 laag werkt het dus perfect, maar op de VLAN 15 laag niet.
(alles werkt behalve dus het verbinden met Exchange, terwijl hij de rest van Exchange wel ziet, etc.)

[Ethirty]

No offense, maar die tekening maakt het niet veel duidelijker dan je omschrijving

Enige is, en dat had ik al eerder aangegeven, dat je DNS van je server in je VLAN moet wijzen naar je DC. Daar heb je dus kennelijk nog niks mee gedaan. Je zal dan ook nog wel niet de juiste DNS records op zijn plek hebben.

[ Voor 57% gewijzigd door Ethirty op 15-05-2013 18:59 ]

[Verwijderd]

Ethirty, dat heb ik uiteraard al lang geprobeerd, maar aangezien dit geen verschil maakt het weer terug gedraaid.

Ik had de DNS naar 192.168.1.100 en 192.168.1.101 gezet, en daar juiste DNS records aangemaakt.
Autodiscover.domein.nl, webmail.domein.nl, etc.

De omgeving is niet zo complex. Als je iets mist op de tekening, geef het gerust aan dan voeg ik het toe.

[Ethirty]

Hoe doe je überhaupt aan AD authenticatie op een TS als deze met zijn DNS niet eens naar zijn eigen DC's verwijst? Volgens mij is dat zo'n beetje regel numero uno in een AD domein.

DNS is de hoeksteen van een Windows netwerk en als dat niet goed werkt, dan kan je de meest rare problemen krijgen. Ook met bijvoorbeeld een programma als Outlook. Dat heb ik de afgelopen jaren vaker meegemaakt dan ik zou willen

[Verwijderd]

Je moet het zo zien. De server in VLAN 15 is een losstaande server, deze mag niet in het domein.
Ik wil hier gewoon via Outlook met Exchange verbinding maken via OutlookAnyWhere.
Ik kan ook prima vanaf een PC elders met deze opstelling perfect verbinding maken, dit werkt goed.
Dus waarom zou een servertje welke intern in een VLAN hangt spontaan in het domein moeten?
Dit is toch onzin. Sterker nog op een andere server in het VLAN draait het ook perfect, echter is dat denk ik toeval (of ik heb iets aangepast wat ik weer heb terug gedraaid) maar daar werken de reeds geconfigureerde accounts perfect.

De VM's staan op dezelfde server, maar de bedoeling is dus dat de server in VLAN 15 via OutlookAnyWhere/Autodiscover over het externe IP naar de Exchange server kijkt (gaat naar buiten via de Sonicwall en komt weer terug naar binnen naar de andere server)

Ik hoop dat je nu begrijpt wat mijn doel is.

-->> Overigens klopt het niet wat je zegt. Ik heb ook een server in de VLAN 1 tevens met de OpenDNS als dns. (208.67.222.222, 208.67.220.220) Deze is ook niet aangemeld op het domein, maar deze connecteert wel perfect met de Exchange 2013 server. Hieraan kun je dus zien dat het niet uitmaakt dat deze DNS wordt gebruikt.

-->> Ik heb zojuist de server in VLAN15 naar VLAN1 gezet, en een IP in die range.
Wel de OpenDNS, DNSen behouden omdat dit op de server in de VLAN1 ook prima werkt.
Helaas krijg ik toch nog dezelfde melding... "de naam komt niet overeen met de naam in de adreslijst"
Terwijl ik dit dus met dezelfde gegevens op de server die al in VLAN1 hing niet krijg,
en extern ook niet... toch vreemd. Ik draai gewoon Outlook 2010 de laatste versie SP1
14.0.629.1000

-->> Als ik de OutlookAnywhere verbinding handmatig configureer, dan vraagt hij continu om de gebruikersnaam en wachtwoord. Als ik het extern handmatig doe, dan werkt het perfect. (andere PC buiten het netwerk via public adres connecten)

[ Voor 36% gewijzigd door Verwijderd op 16-05-2013 03:16 ]

[Equator]

Oké, dus dit is even snel de opstelling:



Vraagje:
- Welke Exchange server heeft de CAS role.
- Naar welk IP adres wordt er intern geresolved voor autodiscover.domein.ext
- welke poorten laat je nu door vanaf VLAN15 naar VLAN1?
- Wat zegt de logging op je firewall.
- kloppen overal de gateway's / netmaskers?
- Staat de tijd overal goed?
- wat is de uitkomst van de exchangeconnectivitytest.com ?

[ Voor 25% gewijzigd door Equator op 16-05-2013 08:03 ]

[TeGek]

zit de terminal server in hetzelfde domein als de exchange servers?(is er b.v. alleen LDAP comminicatie tussen de 2?) dan zou ik kijken naar het Exchange-Autodiscover SCP in ADSI Edit. Deze wordt tijdens installatie van 2013 op de interne FQDN gezet en veranderd daarna niet meer mee als je de OutlookAnywhere settings aanpast.

[Verwijderd]

Equator, dat is een nette tekening. Maar dat is inderdaad de opstelling :-)

- Welke Exchange server heeft de CAS role.
Beide, ik heb ook een DAG tussen beide Exchange servers.
(beide servers hebben dezelfde rollen)

- Naar welk IP adres wordt er intern geresolved voor autodiscover.domein.ext
Deze gaat naar 192.168.1.120, dit is een HA Proxy balancer, deze ben ik helemaal vergeten in de
tekening. Maar het ligt niet aan deze balancer, want ik heb ze ook rechtstreeks naar de Exchange servers laten kijken.

- welke poorten laat je nu door vanaf VLAN15 naar VLAN1?
Alle, alles staat open tussen beide. Maar de bedoeling is dat alles dicht staat.
Ik heb ook alles dicht gehad, maar dat gaf dus het zelfde als alles open.

- Wat zegt de logging op je firewall.
Ik kan daar helaas niets over terug vinden in de logging.

- kloppen overal de gateway's / netmaskers?
Op de VLAN 1 is overal de subnet 255.255.254.0 en de gateway 192.168.1.1
En op VLAN 15 is dit 255.255.255.0 en gateway 192.168.15.1

- Staat de tijd overal goed?
Ik heb dit net gecheckt, overal staat de tijd het zelfde.

- wat is de uitkomst van de exchangeconnectivitytest.com ?
Deze geeft het volgende:

Analyseregel voor AutoDiscover
UserMessage: We konden met succes verbinding maken met Autodiscover
Analyseregel voor OutlookAnywhere
UserMessage: We konden met succes verbinding maken met uw e-mailserver via de Outlook Anywhere-functie.

Metagegevens connectiviteitstests
Symptoom: Ik kan me niet aanmelden bij Office Outlook
Parameters
AutodiscoverUserPassword : System.Security.SecureString
AutodiscoverEmailAddress : [e-mail]
OlaUseAutodiscover : True
ManualSettings : False
UsingSSO : False
AutodiscoverUserDomain : [e-mail]
UiCulture : nl-NL
ConnectivityTest: OutlookAnywhere, OutlookAnywhereMonitoring

@ TeGek, de server hangt niet in het zelfde domein als de Exchange servers, dit is ook niet de bedoeling.

[Ethirty]

Mag ik nog even vragen wat er in de tussentijd nog meer is veranderd dat het nu VLAN 15 is en in het begin VLAN 18?

[Verwijderd]

Mijn excuus heb het nu aangepast naar VLAN 15.
Echter al zou ik een VLAN 18 aanmaken met een extra server en het daar proberen,
dan werkt het ook niet. Dus z'n big issue is dat niet.

Maar heb zojuist de eerste post aangepast en er VLAN 15 van gemaakt...

[Ethirty]

Maakt me verder niet uit hoor welke vlan, maar ik was in de veronderstelling dat er misschien iets veranders was wat we nog niet wisten.

Je wijkt in mijn optiek nogal af van standaard werkwijzes, dus ik probeer even te kijken of ik goed snap wat er anders is dan normaal en of dat een oorzaak van het probleem zou kunnen zijn.

[Verwijderd]

Wat is volgens jou dan de standaard werkwijze? Misschien kan ik die toepassen zodat ik van dit probleem af ben?

[Ethirty]

Dat was niet mogelijk volgens jou. Ik heb servers en zeker terminal servers altijd ín een AD domein zitten met huns DNS allemaal intern. Dan heb je ook geen gedoe met accounts en werkt Outlook eigenlijk altijd. Hiemee wordt oa automatisch gekeken op welke server de mailbox staat, dat is in AD bekend onder je accountgegevens.

Verder volg ik, waar mogelijk, zo veel mogelijk de best practices van MS bij het inrichten van een nieuwe omgeving. Maar Exchange kent daarin nogal wat variaties en een bestaande installatie troubleshooten is vaak vele malen lastiger dan een nieuwe bouwen volgens de regels. Tijdens het troubleshooten probeer je op een gegeven moment zo veel dingen dat je niet meer weet of het nu beter of slechter wordt. Dat ervaar jij nu ook volgens mij

Verder maakt de proxy balancer eea nog een tikkeltje lastiger. Ik heb daar niet veel ervaring mee, maar toen ik daar onderzoek naar deed voor een opdracht leek het SSL certificaat op de proxy te moeten staan en de config van Exchange daarop aangepast te worden.

Mag ik vragen hoeveel Exchange installaties je al hebt gedaan?

[Verwijderd]

Alles is mogelijk. Maar het is niet de opstelling zoals ik hem wens.
Het moet ook gewoon werken, want ik kan thuis prima met mijn laptopje ook via Outlook verbinden zonder dat ik in dat domein hang en met compleet andere DNSen. (Dat noemen ze nou... Outlookanywhere) Dus waarom zou het niet in een VLAN kunnen werken.

Het SSL certificaat hoeft niet op de proxy te staan, dit is een 'domme' balancer deze stuurt al het http en https verkeer netjes door. En het werkt ook perfect, ook met certificaat, echter dus alleen niet in de VLAN.

De afgelopen 15 jaar heb ik ca. 750 Exchange installaties gedaan.
(gemiddeld 50 per jaar) Vanwaar de vraag? Maar ik denk niet dat het probleem in Exchange zit.

Maar dit is toch niet het theeleut forum?

[Ethirty]

Sorry hoor als je denkt dat ik probeer te theeleuten. Probeer op basis van beperkte info een beeld te vormen van de situatie en hoe ervaren je bent met Exchange. Je vraagt zelf om wat een standaard werkwijze van MS is. Sorry hoor, djeez.

Succes!

[Equator]

Maar dit is toch niet het theeleut forum?

Neen, dat is het niet, maar gebaseerd op je plaatje, en het feit dat je niet zo scheutig bent met het informatie verstrekken vind ik het niet zo vreemd dat er navraag wordt gedaan over je ervaring.

We proberen je te helpen met vragen, mogelijke oplossingen en zelfs een fatsoenlijk plaatje.

---

Je zegt dat je met een laptop extern wel gewoon verbinding kan maken. Wat gebeurt er als je deze laptop in het VLAN15 steekt? Werkt het dan wel?

[Ethirty]

Equator verwoord het iets netter dan ik en ik ben ook de slechtste niet. Probeer eens of je hier wat zinnigs uit kan halen.

Ik kreeg genoeg links met de kreten "exchange 2013 outlook 2010 internal autodiscover"

[Jazzy]

Start Outlook op die server eens, met een bestaand profiel of desnoods een leeg profiel zonder account. Houdt CRTL ingedrukt en klik met rechts op het Outlook SyTray icoontje van Outlook. Kies Automatische emailconfigratie testen. Vul het mailadres en wachtwoord in, haal de vinkjes voor de twee Guessmart opties weg. Klik nu op Testen.

Slaagt deze test?

[Verwijderd]

@ Jazzy, die test slaagt gewoon. Dat is vreemd toch.

@ Ethirty, de links die je geeft gaan over een interne DNS.
Ik wil het liefst dat mijn server in de VLAN hier helemaal niet naar kijkt.
Deze moet compleet los staan van de rest van het netwerk, en gewoon lekker via de WAN
naar buiten koekeloeren en zo verbinding maken met de Exchange.
Ofwel het zelfde zoals bijv. op een laptopje.

Overigens kan ik wel een laptop in het zelfde VLAN hangen, ik moet
dan wel even wat tijd inplannen om naar het datacenter te gaan.
Maar ik weet nu al dat hij het dan ook niet zal doen.

[ Voor 83% gewijzigd door Verwijderd op 17-05-2013 18:05 ]

[Ethirty]

Ik zou me ook nog kunnen voorstellen dat Outlook de verkeerde credentials meestuurt aangezien je op de TS lokale accounts gebruikt en Outlook met die gegevens probeert te connecten.

Dat laptopje hangt waarschijnlijk wel in AD met account gegevens die matchen met Exchange. Ik heb op mijn laptop (buiten het domein) genoeg moeten klooien om dat werkend te krijgen: lokale username en password matchen met die in de AD, anders werkt het niet of nauwelijks.

[ Voor 43% gewijzigd door Ethirty op 17-05-2013 19:17 ]

[Equator]

Het zou ook gewoon kunnen zijn dat je firewall er niet tegen kan dat een interne client probeert te connecten aan zijn externe IP wat dan weer terug naar binnen is geNAT naar het IP adres van je HA Proxy. (NAT loopback).
Er zijn heel veel huis, tuin en keuken routers die dat ook niet kunnen. Dan zal je toch echt moeten verwijzen naar de interne IP adressen. Wil je niet dat de server in VLAN15 zijn DNS uit VLAN1 haalt, dan zal je een DNS server moeten plaatsen in je VLAN15 en deze voorzien met de juiste gegevens met verwijzingen naar IP adressen uit je interne netwerk.

[Ethirty]

Dat had ik ook al opgemerkt, maar heb daar geen reactie op gezien.

[Verwijderd]

@ Erhity, ik connect via de TS gewoon naar externe IP's.
En het laptopje hangt niet in het domein. Heb je nooit van Outlook Anywhere gehoord?
(bijv. net als Office 365 dan connect je in principe op de zelfde manier met je Exchange server, dan stel je ook echt niet de DNS van Microsoft op je laptopje in)
Maar dat werkt dus perfect.

Wat Equator bedoeld, komt meer in de buurt.
Maar het VMetje in de VLAN moet in principe gewoon lekker naar buiten gaan over de WAN en dan weer terug naar binnen over de WAN om naar de exchange te kijken.
Ik heb daarvoor ook loopbacks ingesteld.

Het is geen huis tuin en keuken routertje, er zit een Sonicwall NSA 2400
tussen. (deze kost ca. € 3500,-) Daarmee zou dat toch wel moeten lukken?
Sterker nog een ander servertje in een ander VLAN pakt voor één domein wel netjes de juiste mailboxen op, alleen test ik daar met een andere domein dan werkt het niet.
Ik denk dat hij ergens nog iets heeft onthouden, en dat ik een setting goed had staan die ik nu telkens over het hoofd zie.

[Zoetjuh]

Hoe staat je exchange ingesteld als het gaat om internal URL's vs external URL's?
Geeft hij andere of de zelfde URL's terug afhankelijk van interne of externe verbindingen?

Verder, als je Outlook handmatig configureert (dus servername, proxy servername en SSL Principal name op geeft); wat doet hij dan? En VOORAL niet vergeten om ook het vinkje bij "Bij snelle netwerk blahdieblah" aan te vinken.

Welke info geeft Outlook je daarna als je hem vraagt om de om de Automatische email configuratie te testen (CTRL + klikken op het Outlook icoontje).

Dan zou je verder altijd nog kunnen testen of het zinvol is om de hostfile bij te werken; dus de proxy-server.

[Ethirty]

Verwijderd schreef op zaterdag 18 mei 2013 @ 02:39:
@ Erhity, ik connect via de TS gewoon naar externe IP's.
En het laptopje hangt niet in het domein. Heb je nooit van Outlook Anywhere gehoord?
(bijv. net als Office 365 dan connect je in principe op de zelfde manier met je Exchange server, dan stel je ook echt niet de DNS van Microsoft op je laptopje in)
Maar dat werkt dus perfect.

Wat Equator bedoeld, komt meer in de buurt.
Maar het VMetje in de VLAN moet in principe gewoon lekker naar buiten gaan over de WAN en dan weer terug naar binnen over de WAN om naar de exchange te kijken.
Ik heb daarvoor ook loopbacks ingesteld.

Het is geen huis tuin en keuken routertje, er zit een Sonicwall NSA 2400
tussen. (deze kost ca. € 3500,-) Daarmee zou dat toch wel moeten lukken?
Sterker nog een ander servertje in een ander VLAN pakt voor één domein wel netjes de juiste mailboxen op, alleen test ik daar met een andere domein dan werkt het niet.
Ik denk dat hij ergens nog iets heeft onthouden, en dat ik een setting goed had staan die ik nu telkens over het hoofd zie.

Als ik niet wist wat Outlook Anywhere was zou ik je niet proberen te helpen. Het door mij aangehaalde artikel verteld ook nog eens duidelijk hóe het AutoDiscover deel werkt en afhankelijk is van juiste DNS.

En Office365 erbij halen heeft compleet geen nut (los van het verschil in schaal en configuratie en de specialisten die dat gebouwd hebben) zolang jij je laptop niet bij MS in een intern VLAN mag prikken

Wat Equator bedoeld was al aangekaart, helemaal aan het begin. Of een router nu 5 of 5000 euro kost, loopback NAT blijft voor mij een "dirty" oplossing. En als daar een foutje in de config zit komen we daar op deze manier in ieder geval nooit achter. Je had bijvoorbeeld allang even het relevante gedeelte uit de config hier kunnen plaatsen.

Wij moeten er alsmaar vanuit gaan dat jij weet wat je doet, maar je bent niet zo scheutig met enige informatie. Dus ik krijg een beetje het gevoel dat we alles eruit moeten trekken. En ik stel kennelijk de vragen dusdanig dat ik je lijk te irriteren, maar ik heb de beste bedoelingen

Dat stukje over in een ander VLAN een domein wel oppikken en de rest niet ben ik ook ergens tegen gekomen via mijn vermelde google zoektermen. Zal even kijken of ik het artikel voor je terug kan vinden. Had met DNS en wildcard SSL te maken.

[ Voor 5% gewijzigd door Ethirty op 18-05-2013 10:18 ]

[Powermage]

* Powermage vraagt zich af of de TS nu graag advies wilt of niet...
de toon van de reacties lijkt niet echt uitnodigend om verder te helpen...

Overigens zegt het bedrag van de firewall niet veel, ik heb ook wel eens met 10.000 euro kostende kastjes gespeeld die toch niet goed deden wat ze moesten doen...
maar mijn centjes zet ik op de routing/loopback config binnen de sonicwall.
een eigen dns draaien met interne ip resolving voor de gebruikte domeinen zou dit dan kunnen oplossen.

[PeeCee]

Recentelijk hebben wij met het zelfde "probleem" gezeten.

Gezien je het eerste hebt opgelost met het msstd verhaal begrijp ik hier uit dat je te maken hebt met Windows XP/Server 2003. Dit gezien vanaf Vista er geen "patch" meer nodig is voor het werken met een wildcart certificaat i.c.m outlook.

Nu heb ik lang niet alles gelezen in deze topic. Maar wij kwamen er snel achter dat Microsoft met Exchange 2013, af wil van de scheiding tussen extern/intern.

Voor de Exch2013 hebben we in de DNS SRV records gemaakt die werken op het externe domein van de CAS en deze intern verwezen naar de juiste server. Dit loste alle "problemen" op.
Hierbij ga ik er wel vanuit dat je de DNS severs die op DS 1 en 2 draaien gebruikt op je client computers.

Het gebruik van de DNS servers voorkomt ook dat een "loopback" nodig zou zijn. Want dit houdt in dat wanneer je sonicbak offline is voor onderhoudt of storing je hele interne netwerk plat ligt. Dat lijkt mij niet helemaal de bedoeling.

PS. Waarom draai je 2x ADS op de zelfde VM host? Wat is hier het nut van als ik vragen mag?

[ Voor 18% gewijzigd door PeeCee op 19-05-2013 21:15 . Reden: Toevoeging. ]

[Verwijderd]

Ik draai 2008 R2, niet 2003. Ik draai 2x de Active Directory Services, voor een stukje redundantie.
(overigens heb ik meer hosts)

Maar prik mij maar lek, als ik de account aanmaak via het onderdeel Mail in het configuratiescherm dan krijg ik de fout. Ik doe dat altijd op die manier. Open ik Outlook en ik voeg de account toe, dan werkt het wel perfect. Als ik het daarna weer via mail probeer dan werkt dat ook.
Heel vreemd.. maar het probleem lijkt hiermee opgelost. Ik, en iedereen hier zat het dus veel te ver te zoeken.

[PeeCee]

Verwijderd schreef op maandag 20 mei 2013 @ 11:56:
Ik draai 2008 R2, niet 2003. Ik draai 2x de Active Directory Services, voor een stukje redundantie.
(overigens heb ik meer hosts)

Maar prik mij maar lek, als ik de account aanmaak via het onderdeel Mail in het configuratiescherm dan krijg ik de fout. Ik doe dat altijd op die manier. Open ik Outlook en ik voeg de account toe, dan werkt het wel perfect. Als ik het daarna weer via mail probeer dan werkt dat ook.
Heel vreemd.. maar het probleem lijkt hiermee opgelost. Ik, en iedereen hier zat het dus veel te ver te zoeken.

Haha, ik dacht al dat je niet een host zou hebben.

En verder bedoelde ik de Client computer Windows XP/ of server 2003. Niet de server(s). Of is mijn aanname hierin fout?

Verder is een handmatige handeling niet de oplossing lijkt mij? Ik persoonlijk hoor mijn collega's liever niet dan wel.