[Exchange 2010] Autodiscovery met verschillende CAS servers

Pagina: 1
Acties:

Vraag


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Zoals verwacht: na mijn succesvolle migratie van Exchange 2007 naar 2013 ben ik gepromoveerd tot Exchange expert. Zucht.

Maar goed, ik heb tijdens die migratie inderdaad veel geleerd en bij een andere klant heb ik een hoop Exchangeproblemen opgelost. Wat mij echter niet duidelijk is, is onder andere dit: gegeven

mail1.tweakers.com
mail2.tweakers.com
mail3.tweakers.com

autodiscovery verwijst op mail1. Eigenlijk wil ik - hoop ik - dat mail1 doorverwijst naar een andere CAS als de mailbox daar niet ligt.

Maar sowieso werkt de autodiscovery extern niet:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
    Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
    
    Additional Details
    
Elapsed Time: 382 ms.
    
    Test Steps
    
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.tweakers.com:443/Autodiscover/Autodiscover.xml for user yellowonline@tweakers.com.
    The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
    
    Additional Details
    
An HTTP 403 forbidden response was received. The response appears to have come from Unknown. Body of the response: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /Autodiscover/Autodiscover.xml on this server.<br /> </p> </body></html> HTTP Response Headers:
Connection: close
Content-Length: 238
Content-Type: text/html; charset=iso-8859-1
Date: Tue, 01 Nov 2016 15:25:30 GMT
Server: Apache
Elapsed Time: 382 ms.


Ik ben aan het prutsen met de authenticatie, maar als iemand meteen weet 'ja, natuurlijk, oen, je moet XYZ': zeg maar hoor.

Beste antwoord (via YellowOnline op 16-11-2016 15:51)


  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Negeer de mail appliance, die doet helemaal niets wat met Autodiscover te maken heeft. Het gaat direct al fout in de eerste stap waar mail3 antwoordt met een 302. Focus je daar op. Het zelfde gebeurt op de mail7 trouwens, ook die geeft een 302 redirect naar een index.php pagina op je mail appliance.

Dit is het enige wat je hoeft uit te zoeken, waarom je web request wordt geredirect naar een pagina op je mail appliance. Ik herhaal nog maar een keer, dit heeft niets met Autodiscover te maken. Een Autodiscover request op https zal nooit een 302 tot gevolg hebben, en al helemaal niet naar een server die niet eens iets met Exchange te maken heeft.

Edit: Open IIS op die server en probeer uit te zoeken wat iemand ingesteld heeft wat die redirect tot gevolg heeft. Ik heb dit gisteren als eerst al gezegd en blijf dit herhalen totdat je de oorzaak van de 302 op je servers gevonden hebt. :)

[ Voor 15% gewijzigd door Jazzy op 16-11-2016 14:09 ]

Exchange en Office 365 specialist. Mijn blog.

Alle reacties


Acties:
  • +1 Henk 'm!

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Weet je zeker dat DNS etc van autodiscover.tweakers.com naar de juiste server wijst, aangezien er Apache onder staat. Reverse proxy bij deze klant?

Daarnaast, autodiscover geeft als het goed is gewoon je CAS/MBX terug, waar die dan ook in de organisatie is. Daar hoef je niks speciaals voor te doen.

[ Voor 34% gewijzigd door wagenveld op 01-11-2016 16:46 ]


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
wagenveld schreef op dinsdag 01 november 2016 @ 16:43:
Weet je zeker dat DNS etc van autodiscover.tweakers.com naar de juiste server wijst, aangezien er Apache onder staat. Reverse proxy bij deze klant?

Daarnaast, autodiscover geeft als het goed is gewoon je CAS/MBX terug, waar die dan ook in de organisatie is. Daar hoef je niks speciaals voor te doen.
Goed gezien die Apache d:)b - de proxy die er tussen zat blokkeerde de boel. Door die te laten forwarden naar de juiste server werkt alles gewoon, yay. Soms is het niet ingewikkeld.

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Wat ontzettend zonde dat je geen externe kennis in kunt huren en alles door trial and error moet leren. :|

Wat je normaal gesproken doet is één namespace gebruiken voor je CAS-servers, bijvoorbeeld mail.domein.nl. Die komt uit bij de load balancer die de connecties vervolgens verdeeld over je drie CAS-servers. Vervolgens configureer je autodiscover om op het zelfde endpoint uit te komen en pas je ook de SCP voor die drie CAS-servers aan zodat de url https://mail.domein.nl/autodiscover/autodiscover.xml is. Nu gaan alle connecties naar dezelfde namespace. Laatste stap is dan dat je de urls op de virtual directories aanpast naar dezelfde hostnaam zodat Autodiscover de juiste gegevens uitdeelt aan je clients.

De individuele servernamen zijn dus helemaal niet relevant meer en als je een mailbox verplaatst naar een andere server dan maakt dat ook niet uit, er verandert niets. Sterker nog, zelfs bij een upgrade naar een nieuwere versie blijft alles gelijk.

Edit: of heb ik je vraag verkeerd begrepen?

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Members only:
Alleen zichtbaar voor ingelogde gebruikers. Inloggen
Jazzy schreef op dinsdag 01 november 2016 @ 17:02:
Wat ontzettend zonde dat je geen externe kennis in kunt huren en alles door trial and error moet leren. :|

Wat je normaal gesproken doet is één namespace gebruiken voor je CAS-servers, bijvoorbeeld mail.domein.nl. Die komt uit bij de load balancer die de connecties vervolgens verdeeld over je drie CAS-servers. Vervolgens configureer je autodiscover om op het zelfde endpoint uit te komen en pas je ook de SCP voor die drie CAS-servers aan zodat de url https://mail.domein.nl/autodiscover/autodiscover.xml is. Nu gaan alle connecties naar dezelfde namespace. Laatste stap is dan dat je de urls op de virtual directories aanpast naar dezelfde hostnaam zodat Autodiscover de juiste gegevens uitdeelt aan je clients.

De individuele servernamen zijn dus helemaal niet relevant meer en als je een mailbox verplaatst naar een andere server dan maakt dat ook niet uit, er verandert niets. Sterker nog, zelfs bij een upgrade naar een nieuwere versie blijft alles gelijk.

Edit: of heb ik je vraag verkeerd begrepen?
Members only:
Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Acties:
  • +1 Henk 'm!

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Voor die mailboxen waar je die 302 krijgt, hebben die toevallig een shared mailbox oid open op een 2013 server? Dat zou het wel uitleggen namelijk.

Je weet overigens dat je bij coexistence DNS naar de nieuwe servers moet verwijzen? En de juiste namespaces op de nieuwe servers configureren uiteraard zodat alles netjes matched met 2010.

[ Voor 39% gewijzigd door wagenveld op 15-11-2016 17:08 ]


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
wagenveld schreef op dinsdag 15 november 2016 @ 17:04:
Voor die mailboxen waar je die 302 krijgt, hebben die toevallig een shared mailbox oid open op een 2013 server? Dat zou het wel uitleggen namelijk.
Op die 2013 liggen enkel Room en Equipment Mailboxes - en die zijn niet geopend (wel aanwezig in de lijst natuurlijk).

Voorbeeld van zo-even: ik heb net een nieuwe user in AD aangemaakt en via de 2010 console een mailbox toegewezen. De bedoeling is dat deze gebruiker een bestaande kalender vervangt (die nog van een 2003 public folder komt). Mijn idee was om iedereen leesrechten op die kalender te geven en een bepaalde groep mensen ook schrijfrechten. Wanneer ik echter bij iemand die (2010) kalender toevoeg krijg ik dit:

Afbeeldingslocatie: https://tweakers.net/ext/f/xkZHpq7ZjBfFb1C12slY9CZg/full.png

In de logging zie ik eigenlijk hetzelfde als in de test-interface:
5132 ---BEGIN XML---
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>DummyUser, My</DisplayName>
<LegacyDN>/o=tweakers/ou=ERSTE ADMINISTRATIVE GRUPPE/cn=RECIPIENTS/cn=FDummyUser</LegacyDN>
<AutoDiscoverSMTPAddress>My.DummyUser@tweakers.de</AutoDiscoverSMTPAddress>
<DeploymentId>1aacb656-50cf-47c0-b062-62d7b908d4c4</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>KI00N80C.tweakers.world</Server>
<ServerDN>/o=tweakers/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=KI00N80C</ServerDN>
<ServerVersion>7383807B</ServerVersion>
<MdbDN>/o=tweakers/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=KI00N80C/cn=Microsoft Private MDB</MdbDN>
<PublicFolderServer>KI00N80C.tweakers.world</PublicFolderServer>
<AD>KI00N91L.iz.tweakers.world</AD>
<ASUrl>https://mail5.tweakers.com/EWS/exchange.asmx</ASUrl>
<EwsUrl>https://mail5.tweakers.com/EWS/exchange.asmx</EwsUrl>
<EcpUrl>https://mail5.tweakers.com/ecp/</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
<OOFUrl>https://mail5.tweakers.com/EWS/exchange.asmx</OOFUrl>
<UMUrl>https://mail5.tweakers.com/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>https://mail5.tweakers.com/OAB/1c4819fd-fd57-473a-bb5a-bcd0924e9417/</OABUrl>
<CertPrincipalName>msstd:*.tweakers.com</CertPrincipalName>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>mail5.tweakers.com</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl>https://mail5.tweakers.com/EWS/exchange.asmx</ASUrl>
<EwsUrl>https://mail5.tweakers.com/EWS/exchange.asmx</EwsUrl>
<EcpUrl>https://mail5.tweakers.com/ecp/</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
<OOFUrl>https://mail5.tweakers.com/EWS/exchange.asmx</OOFUrl>
<UMUrl>https://mail5.tweakers.com/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>https://mail5.tweakers.com/OAB/1c4819fd-fd57-473a-bb5a-bcd0924e9417/</OABUrl>
<CertPrincipalName>msstd:*.tweakers.com</CertPrincipalName>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Ntlm, Fba, WindowsIntegrated">https://mail5.tweakers.com/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://mail5.tweakers.com/EWS/exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://mail5.tweakers.com/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://mail5.tweakers.com/EWS/exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
</Account>
</Response>
</Autodiscover>
5132 ----END XML----

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
OOF niet in kunnen stellen duidt inderdaad op AutoDiscover die niet bereikt kan worden of de verkeerde gegevens uitdeelt.

Verder heb je een aantal problemen. Om te beginnen zou mail3 nooit een 302 mogen geven als een client een AutoDiscover lookup wil doen. Je zou eens moeten kijken of iemand in IIS gerommeld heeft. Ga maar eens in een browser naar https://servernaam.domain/autodiscover/autodiscover.xml. Je moet dan een basic authentication pop-up krijgen en na inloggen een http error 600. In geen geval een redirect naar een andere server. En al helemaal niet een redirect naar een andere server die niet eens Exchange draait. :) Maar de enige reden dat een client voor AutoDiscover op die appliance uitkomt is dus doordat iemand een redirect op de eerste Exchange 2010 gemaakt heeft.

Anyway, de client waarop je de test uitvoerde kijkt dus als eerste in AD voor het SCP en vindt daar de url naar mail3. Als mail3 gezond functioneerde dan was dat geen probleem, de autodiscover service gaat vervolgens kijken op welke server de database met de mailbox van deze gebruiker actief is. Vervolgens antwoord hij de client met een XML met daarin de confguratiedata die jij op die server geconfigureerd hebt. De Outlook Anywhere gegevens, de urls voor EWS, etc. Volgende stap is dat de client die gegevens gaat gebruiken om daadwerkelijk verbinding te maken met zijn mailbox.

Denk dat het een stuk logischer is als je die redirect van mail3 kunt weghalen.

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Dnak voor jullie reacties alvast.

@Jazzy
Ik kan al zeggen dat het inloggen op mail3 wel degelijk een 600 geeft en niet redirect als ik per http verbind.

@wagenveld
Zodra mijn chef annex collega zich meldt maak ik DNS-namen aan intern en extern voor de nieuwe 2013 servers en configureer ik die ook. En autodiscover verwijs ik dan naar een van de nieuwe servers ipv een van de oude.

Dat zal ik allemaal vandaag niet meer voor mekaar krijgen daar mijn chef in een fabriek in Tapei is deze week - 't is daar al wat later :)

Acties:
  • +1 Henk 'm!

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Volgens mij gaat het goed inrichten van de coexistence je probleem al oplossen. Die redirect komt als je het mij vraagt van de resources die op 2013 staan.

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
De AutoDiscover service op de Exchange 2010 server zou het request toch gewoon moeten beantwoorden? Ik zou niet weten waarom die een 302 zou geven, en al helemaal niet naar een non-Exchange server.

Verder valt er aan coexistence tussen Exchange 2010 en 2013 niet zoveel te configureren. Belangrijk is dat de gebruikers een 2013 CAS server gaan gebruiken voordat je hun mailboxen gaat moven. Exchange 2010 CAS kan namelijk geen proxying doen naar Exchange 2013, andersom wel.

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • +1 Henk 'm!

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Wel als er iets als een gedeelde agenda wordt geopend die op 2013 staat, autodiscover gaat dan als het goed is proberen de SCP van die resource te vinden. Dan zou de 2013 SCP nu op de Sophos moeten staan, dat wel.

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Heb je daar documentatie van? Want in dat geval moet er eerste een daadwerkelijke post gedaan worden voordat de Autodiscover service weet om welke mailbox het gaat. Maar zelfs dan gebeurt dat niet, Exchange 2010 kan gewoon de Autodiscover informatie geven van een mailbox die op Exchange 2013 staat.

Een voorbeeld van zo'n redirect is als het targetAddress attribuut gevuld is, zoals bijvoorbeeld in een hybride opstelling. Maar ook dan ziet de flow er anders uit, de client gaat het proces gewoon herhalen maar dan voor het nieuwe mailadres.

Verder is dit een test die uitgevoerd wordt met het email adres wat ingevoerd is, er wordt niets gedaan met extra mailboxen die in het profiel geboden zouden zijn.

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • +1 Henk 'm!

  • Qwerty-273
  • Registratie: Oktober 2001
  • Laatst online: 15:04

Qwerty-273

Meukposter

***** ***

Je zegt dat op de 2013 de autodiscover nog niet is geconfigureerd?
Maar die wijst default toch naar zich zelf (als je een get-clientaccessserver doet wat er staat bij AutoDiscoverServiceInternalUri voor die 2013 servers?) die waarden van je cas worden ook geschreven in AD, en dan afhankelijk van je AD sites/subnets kunnen clients in een bepaalde richting worden gestuurd.

https://blogs.technet.mic...-coexistence-environment/
http://o365info.com/autod...existence-environment-24/

[ Voor 25% gewijzigd door Qwerty-273 op 15-11-2016 18:15 ]

Erzsébet Bathory | Strajk Kobiet | You can lose hope in leaders, but never lose hope in the future.


Acties:
  • +1 Henk 'm!

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Jazzy schreef op dinsdag 15 november 2016 @ 18:08:
Heb je daar documentatie van? Want in dat geval moet er eerste een daadwerkelijke post gedaan worden voordat de Autodiscover service weet om welke mailbox het gaat. Maar zelfs dan gebeurt dat niet, Exchange 2010 kan gewoon de Autodiscover informatie geven van een mailbox die op Exchange 2013 staat.

Een voorbeeld van zo'n redirect is als het targetAddress attribuut gevuld is, zoals bijvoorbeeld in een hybride opstelling. Maar ook dan ziet de flow er anders uit, de client gaat het proces gewoon herhalen maar dan voor het nieuwe mailadres.

Verder is dit een test die uitgevoerd wordt met het email adres wat ingevoerd is, er wordt niets gedaan met extra mailboxen die in het profiel geboden zouden zijn.
Nee, dat niet. Maar gezien het scenario lijkt dat wel wat er gebeurd.
Als er een 2013 SCP rondwandelt die naar br00l91v wijst dan weten we het toch?

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Afgezien van sites gebruikt de client gewoon de eerste SCP die hij uit AD terugkrijgt, door de manier waarop AD werkt is dat doorgaans de oudste. En in dit geval antwoordt de server die in het SCP staat, de client gaat dan niet een andere server proberen waarvoor ook een SCP bestaat. Nog los van het feit dat die url waar de 302 naar verwijst geen Exchange-server is maar een appliance. Dat zie je ook aan de url, die is /index.php.

Dit is geen native autodiscovergedrag.

[ Voor 45% gewijzigd door Jazzy op 15-11-2016 19:20 ]

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Zo, DNS namen zijn aangelegd en de Virtual Directories etc zijn in orde op de Exchange 2013. De autodiscovery is nu helemaal stuk :+ / :( Daar lijkt een of andere redirect loop aan de gang te zijn:

Afbeeldingslocatie: https://tweakers.net/ext/f/AJiiwsRuXP6NCy1aU9DZU5Qa/full.png

Gelukkig werken de basics nog met manuele configuratie. Ik moet eens uitvinden hoe die mail appliance geconfigureerd is, want die lijkt hier toch nogal tussen te zitten.

Ik zoek verder...

Edit: Misschien relevant voor autodiscovery is dat het certificaat voor .com is, de interne naam echter .world is en de gebruikers van een stuk of 20 TLDs komen (@tweakers.be, @tweakers.nl, @tweakers.it, @tweakers.fr ... en enkele ook van @mytweak.net en @mytweak.com).

[ Voor 35% gewijzigd door YellowOnline op 16-11-2016 14:07 ]


Acties:
  • Beste antwoord
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Negeer de mail appliance, die doet helemaal niets wat met Autodiscover te maken heeft. Het gaat direct al fout in de eerste stap waar mail3 antwoordt met een 302. Focus je daar op. Het zelfde gebeurt op de mail7 trouwens, ook die geeft een 302 redirect naar een index.php pagina op je mail appliance.

Dit is het enige wat je hoeft uit te zoeken, waarom je web request wordt geredirect naar een pagina op je mail appliance. Ik herhaal nog maar een keer, dit heeft niets met Autodiscover te maken. Een Autodiscover request op https zal nooit een 302 tot gevolg hebben, en al helemaal niet naar een server die niet eens iets met Exchange te maken heeft.

Edit: Open IIS op die server en probeer uit te zoeken wat iemand ingesteld heeft wat die redirect tot gevolg heeft. Ik heb dit gisteren als eerst al gezegd en blijf dit herhalen totdat je de oorzaak van de 302 op je servers gevonden hebt. :)

[ Voor 15% gewijzigd door Jazzy op 16-11-2016 14:09 ]

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Jazzy schreef op woensdag 16 november 2016 @ 14:07:
Negeer de mail appliance, die doet helemaal niets wat met Autodiscover te maken heeft. Het gaat direct al fout in de eerste stap waar mail3 antwoordt met een 302. Focus je daar op. Het zelfde gebeurt op de mail7 trouwens, ook die geeft een 302 redirect naar een index.php pagina op je mail appliance.

Dit is het enige wat je hoeft uit te zoeken, waarom je web request wordt geredirect naar een pagina op je mail appliance. Ik herhaal nog maar een keer, dit heeft niets met Autodiscover te maken. Een Autodiscover request op https zal nooit een 302 tot gevolg hebben, en al helemaal niet naar een server die niet eens iets met Exchange te maken heeft.

Edit: Open IIS op die server en probeer uit te zoeken wat iemand ingesteld heeft wat die redirect tot gevolg heeft. Ik heb dit gisteren als eerst al gezegd en blijf dit herhalen totdat je de oorzaak van de 302 op je servers gevonden hebt. :)
Hmz, heb je een mening over dit artikel?

http://enterpriseit.co/mi...hange/2013/http-redirect/

Acties:
  • +1 Henk 'm!

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Dat is mijn theorie in elk geval in het water. Dan zal iemand toch waarschijnlijk een lelijke redirect op de root van de Default website hebben geklust?

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Ja. Dat gaat over het redirecten van http://mail3.domein.de/ naar https://mail3.domein.de/owa. Dus van een url zonder de /owa virtual directory op poort 80 naar de url met de virtual directory en nu op 443.

In jouw geval heeft iemand een redirect geconfigureerd die https://mail3.domain.de/autodiscover/autodiscover.xml redirect naar https://mailappliance.domein.de/index.php.

[ Voor 40% gewijzigd door Jazzy op 16-11-2016 14:16 ]

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Jazzy schreef op woensdag 16 november 2016 @ 14:15:
[...]

Ja. Dat gaat over het redirecten van http://mail3.domein.de/ naar https://mail3.domein.de/owa. Dus van een url zonder de /owa virtual directory op poort 80 naar de url met de virtual directory en nu op 443.

In jouw geval heeft iemand een redirect geconfigureerd die https://mail3.domain.de/autodiscover/autodiscover.xml redirect naar https://mailappliance.domein.de/index.php.
Als we over hetzelfde spreken dan moet ik toch dieper op zoek naar de oorzaak van die redirect, want:

Afbeeldingslocatie: https://tweakers.net/ext/f/vJC0zuCgGe1GSw3fmMSGV4xM/full.png

(dit is mail3)

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Kan van alles zijn, gebruik je niet een webproxy toevallig? Daar kan het ook nog in geregeld zijn. Of één of andere truuk in IIS, ik ben zelf geen expert in IIS helaas.

Je zit nu trouwens op een andere server dan de mail3, toch? Of is mail3 een DNS alias voor de hostnaam die in dat screenshot staat?

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Jazzy schreef op woensdag 16 november 2016 @ 14:24:
Kan van alles zijn, gebruik je niet een webproxy toevallig? Daar kan het ook nog in geregeld zijn. Of één of andere truuk in IIS, ik ben zelf geen expert in IIS helaas.

Je zit nu trouwens op een andere server dan de mail3, toch? Of is mail3 een DNS alias voor de hostnaam die in dat screenshot staat?
Ja, BR00N58R.tweakers.world heeft een alias mail3.tweakers.com omdat het certificaat voor *.tweakers.com is.

Maareuh, er is inderdaad een webproxy aanwezig. Ik ga eens uitvissen of die misschien een rol speelt.

[ Voor 3% gewijzigd door YellowOnline op 16-11-2016 14:27 ]


Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Verder zei je dat je zelf een keer geprobeerd had om die autodiscover url aan te roepen. Was dat op dezelfde computer als waar je die Outlook tests op uitvoert? Met een IE als browser zodat je zeker weet dat die dezelfde proxy gebruikt als Outlook?

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Jazzy schreef op woensdag 16 november 2016 @ 14:31:
Verder zei je dat je zelf een keer geprobeerd had om die autodiscover url aan te roepen. Was dat op dezelfde computer als waar je die Outlook tests op uitvoert? Met een IE als browser zodat je zeker weet dat die dezelfde proxy gebruikt als Outlook?
Top gezien. Ik heb die test vanop een server gedaan. De client waarvan ik test geeft helemaal geen 600 maar een inlogpagina van de Sophos Appliance - wat steek houdt als we naar de AutoConfiguration Test kijken.

Acties:
  • 0 Henk 'm!

  • Qwerty-273
  • Registratie: Oktober 2001
  • Laatst online: 15:04

Qwerty-273

Meukposter

***** ***

Aangezien die sophos appliance voornamelijk security doet op je mailflow (antivirus/spam, dlp, encryptie) zal die er inderdaad tussen uit moeten (van je Outlook connecties). Maar hebben gebruikers bij deze klant toegang tot hun spam box op die appliance? Gebruiken jullie de bijbehorende Outlook plugin (al lijkt die niet te babbelen met de appliance zelf)?

In een omgeving met veel geknutsel ;) is het soms raadzaam om eerst op papier te hebben hoe het wel moet, en dan puntje voor puntje afstrepen wat wel goed staat en wat niet. Als je bijvoorbeeld op sites lokale dns gebruikt (ie standalone) dan kan het soms ook handig zijn om te kijken of de records wel correct zijn. En inderdaad die proxy bekijken ;)

Erzsébet Bathory | Strajk Kobiet | You can lose hope in leaders, but never lose hope in the future.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Qwerty-273 schreef op woensdag 16 november 2016 @ 14:58:
Aangezien die sophos appliance voornamelijk security doet op je mailflow (antivirus/spam, dlp, encryptie) zal die er inderdaad tussen uit moeten (van je Outlook connecties). Maar hebben gebruikers bij deze klant toegang tot hun spam box op die appliance? Gebruiken jullie de bijbehorende Outlook plugin (al lijkt die niet te babbelen met de appliance zelf)?

In een omgeving met veel geknutsel ;) is het soms raadzaam om eerst op papier te hebben hoe het wel moet, en dan puntje voor puntje afstrepen wat wel goed staat en wat niet. Als je bijvoorbeeld op sites lokale dns gebruikt (ie standalone) dan kan het soms ook handig zijn om te kijken of de records wel correct zijn. En inderdaad die proxy bekijken ;)
Vergeet die Mail Appliance: die speelt helemaal niet mee. Ik ben er iets te lichtzinnig vanuit gegaan dat het de Sophos Mail Appliance was, maar het was de hele tijd de Sophos Web Appliance :X

Acties:
  • +1 Henk 'm!

  • Qwerty-273
  • Registratie: Oktober 2001
  • Laatst online: 15:04

Qwerty-273

Meukposter

***** ***

Aha, dus die 302 redirect komt dus niet van je Exchange af, maar van je web appliance die al het verkeer door zich heen laat gaan?

Erzsébet Bathory | Strajk Kobiet | You can lose hope in leaders, but never lose hope in the future.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Qwerty-273 schreef op woensdag 16 november 2016 @ 15:20:
Aha, dus die 302 redirect komt dus niet van je Exchange af, maar van je web appliance die al het verkeer door zich heen laat gaan?
Inderdaad - ook intern verkeer blijkbaar.




Edit
't Is om te huilen. Iemand had op die testmachine de proxy helemaal anders ingesteld. Op een andere testmachine - met de gewone proxy - werkt het gewoon.

Afbeeldingslocatie: https://tweakers.net/ext/f/AuywmaeHorfDqNho2OfDLQkF/full.png
(die OAB moet ik nog nakijken of dat een typfout is)

Geen idee hoeveel tijd ik verloren ben met zoeken naar een onbestaand probleem. |:(

Nou ja, dat ik nu de 2013 netjes geconfigureerd heb is natuurlijk geen verloren tijd.

Dank iedereen voor jullie meedenken en aanbieden van oplossingen!

[ Voor 50% gewijzigd door YellowOnline op 16-11-2016 15:52 ]


Acties:
  • 0 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
En een Autodiscover deep dive op zijn tijd is altijd leuk, niet waar? :) Resultaat ziet er inderdaad prima uit zo. Ik denk dat het OAB ook gewoon om de mail3 gehost wordt trouwens, dat kan inderdaad wel eens een foutje zijn.

Bij dat het werkt nu!

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Jazzy schreef op woensdag 16 november 2016 @ 16:09:
En een Autodiscover deep dive op zijn tijd is altijd leuk, niet waar? :) Resultaat ziet er inderdaad prima uit zo. Ik denk dat het OAB ook gewoon om de mail3 gehost wordt trouwens, dat kan inderdaad wel eens een foutje zijn.

Bij dat het werkt nu!
Zoals je zelf zei had het uiteindelijk weinig met autodiscover zelf te maken:-/

Toch zie ik er nog een aantal waar het niet werkt. Voorbeeldje:

Afbeeldingslocatie: https://tweakers.net/ext/f/N9xYApYxMGJ1FLOedgIwM1Jj/full.png

Ik moet toegeven dat het mij ook niet duidelijk is hoe een @tweakers.de account uitvindt dat de autodiscover op @tweakers.com staat. Vermoeden: aan AD wordt gewoon gevraagd welke Exchange voorhanden is. De TLD maakt dan niet meer uit (zoals gezegd heb ik er 20) en zelfs de domeinnaam niet (heb ik er ook een aantal).

Bovenstaande voorbeeld is van een VPN gebruiker. Misschien gaat de discovery daar - ondanks de VPN - langs de buitenzijde en blijft hij daar op steken.

Morgen uit te checken (want nu moet ik naar een andere klant).

Acties:
  • +1 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Het hangt er van af hoe je Autodiscover op basis van DNS hebt geconfigureerd. Ik zeg bewust niet extern, want het kan prima zijn dat de VPN client de interne DNS-servers gebruikt.

In het voorgaande voorbeeld ging het om AD-member computers die het domein konden bereiken. Die kijken in het SCP en gaan die url gebruiken voor hun Autodiscover request. Het voorbeeld hier slaat die stap over, waarschijnlijk omdat de computer heen lid van het AD-domein is. Dan valt hij terug op de DNS-methode, die vaste volgorde van een stuk of 5 manieren waarop hij een server met de Autodiscover service probeert te vinden. In dit voorbeeld mislukken alle pogingen. Om te weten waar het mis gaat moeten we eerst weten hoe je Autodiscover in DNS hebt ingeregeld voor externe clients en interne clients die geen lid van het domain zijn.

Veel organisaties maken een DNS-record autodiscover.domein.de aan maar het nadeel van deze methode is dat je dan de naam autodiscover.<domein.tld> voor alle domeinen op je certificaat moet hebben staan. Er zijn alternatieven om dit te omzeilen.

Als ik jou was zou ik hier eens goed doorheen lezen: MSDN: Implementing an Autodiscover Client in Microsoft Exchange Dit is informatie voor developers om een client te bouwen die Autodiscover gebruikt om zijn configuratiegegevens op te vragen, maar het legt goed uit welke stappen de client moet nemen en wat het gewenste resultaat kan zijn.

Dit is echt extreem belangrijk voor beheer of support bij Exchange, zorg dat je dit proces goed tussen de oren krijgt.

Exchange en Office 365 specialist. Mijn blog.


  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Jazzy schreef op woensdag 16 november 2016 @ 16:52:
Het hangt er van af hoe je Autodiscover op basis van DNS hebt geconfigureerd. Ik zeg bewust niet extern, want het kan prima zijn dat de VPN client de interne DNS-servers gebruikt.

In het voorgaande voorbeeld ging het om AD-member computers die het domein konden bereiken. Die kijken in het SCP en gaan die url gebruiken voor hun Autodiscover request. Het voorbeeld hier slaat die stap over, waarschijnlijk omdat de computer heen lid van het AD-domein is. Dan valt hij terug op de DNS-methode, die vaste volgorde van een stuk of 5 manieren waarop hij een server met de Autodiscover service probeert te vinden. In dit voorbeeld mislukken alle pogingen. Om te weten waar het mis gaat moeten we eerst weten hoe je Autodiscover in DNS hebt ingeregeld voor externe clients en interne clients die geen lid van het domain zijn.

Veel organisaties maken een DNS-record autodiscover.domein.de aan maar het nadeel van deze methode is dat je dan de naam autodiscover.<domein.tld> voor alle domeinen op je certificaat moet hebben staan. Er zijn alternatieven om dit te omzeilen.

Als ik jou was zou ik hier eens goed doorheen lezen: MSDN: Implementing an Autodiscover Client in Microsoft Exchange Dit is informatie voor developers om een client te bouwen die Autodiscover gebruikt om zijn configuratiegegevens op te vragen, maar het legt goed uit welke stappen de client moet nemen en wat het gewenste resultaat kan zijn.

Dit is echt extreem belangrijk voor beheer of support bij Exchange, zorg dat je dit proces goed tussen de oren krijgt.
Ik heb het eens getest: de VPN gebruikers gebruiken wel degelijk de interne DNS. Daar heb ik ook een autodiscover.tweakers.com aangemaakt. Probleem is natuurlijk dat alle gebruikers een andere TLD hebben - de .com wordt eigenlijk niet gebruikt voor e-mailadressen. Ik kan dan wel een autodiscover.tweakers.de (bijvoorbeeld) A record maken dat naar de juiste server verwijst, maar daar zal het .com certificaat vast niet gelukkig mee zijn.

Dus nu ben ik inderdaad op zoek naar een mechanisme dat ik ik implementeren kan dat .de, .be, .it etc. eenvoudigweg doorverwijst naar .com.

  • Dennism
  • Registratie: September 1999
  • Nu online
Jazzy schreef op woensdag 16 november 2016 @ 16:52:


Veel organisaties maken een DNS-record autodiscover.domein.de aan maar het nadeel van deze methode is dat je dan de naam autodiscover.<domein.tld> voor alle domeinen op je certificaat moet hebben staan. Er zijn alternatieven om dit te omzeilen.
Moet zeggen dat ik dit vaak wel een kosten effectieve methode vind. Certificaten kosten tegenwoordig spreekwoordelijk geen drol meer voor Exchange implementaties en alternatieve oplossingen kosten naar mijn ervaring vaak meer qua tijd (en dus geld, zeker als je van een externe partij bent die bij een klant zit) om te implementeren en te testen dan simpel weg de interne en externe DNS op orde maken en de benodigde domeinen op een certificaat zetten.

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
YellowOnline schreef op donderdag 17 november 2016 @ 13:16:
[...]
Dus nu ben ik inderdaad op zoek naar een mechanisme dat ik ik implementeren kan dat .de, .be, .it etc. eenvoudigweg doorverwijst naar .com.
Gelukkig heb je inmiddels dat document gelezen en zelf wat verder onderzoek gedaan zodat je een keuze kunt maken tussen meerdere namen op het SAN-certifictaat, een HTTP-redirect maken of een SRV-record in DNS. Toch? ;)

Exchange en Office 365 specialist. Mijn blog.


  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Jazzy schreef op donderdag 17 november 2016 @ 14:22:
[...]
Gelukkig heb je inmiddels dat document gelezen en zelf wat verder onderzoek gedaan zodat je een keuze kunt maken tussen meerdere namen op het SAN-certifictaat, een HTTP-redirect maken of een SRV-record in DNS. Toch? ;)
Eigenlijk wel ja ;) Dat eerste is geen optie, waardoor ik naar dat tweede en het derde aan het kijken ben :p En naar een vierde eigenlijk: een .com SMTP alias voor alle gebruikers - iets wat ik in de toekomst sowieso wil wanneer ik hen van het idee afbrengen kan dat klanten een TLD van hun land belangrijk vinden. Als dat echt zo is, dan is het nog erger gesteld met de wereld dan ik dacht.

[ Voor 24% gewijzigd door YellowOnline op 17-11-2016 14:26 ]


  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Die HTTP redirect kun je dan weer mooi op je webproxy doen ;)

[ Voor 4% gewijzigd door wagenveld op 17-11-2016 14:31 ]


Acties:
  • +2 Henk 'm!

  • YellowOnline
  • Registratie: Januari 2005
  • Laatst online: 28-03-2023

YellowOnline

BEATI PAVPERES SPIRITV

Topicstarter
Ik heb het uiteindelijk met SRV records gedaan. Nou ja, ik heb het voor .de al gedaan. En het werkt *O*

Nu nog voor de 28 andere DNS zones :+

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 13:47

Jazzy

Moderator SSC/PB

Moooooh!

(jarig!)
Goed bezig!

Exchange en Office 365 specialist. Mijn blog.

Pagina: 1