owa Exchange 2010 verwijst naar andere website in IIS

[Anoniem: 552985]

Beste Forumleden,

Ik loop tegen het volgende aan:
De vorige beheerder heeft zitten knoeien met de webmail waarbij ik nu de boel een beetje overzichtelijk wil krijgen. (moet binnenkort een ssl certificaat verlengen)

Ik heb 2 DNS records die naar de zelfde ip adres verwijzen.

webmail.klant.nl
mail.klant.nl

Allebei verwijzen door naar de Exchangeserver 2010, is allemaal geregeld op de Firewall met Nat regels.

Wanneer ik surf naar webmail.klant.nl kom ik uit op de /OWA.
en wanneer ik surf naar mail.klant.nl kom ik uit op de /Remote directory van de IIS.

Nu wil ik de DNS record webmail.klant.nl binnenkort eruit halen zodat alleen mail.klant.nl overblijft.
Mijn vraag: Waar in IIS kan ik opgeven dat mail.klant.nl moet verwijzen naar de /owa directory en niet naar de /remote. Ik heb me suf zitten zoeken maar kan het niet vinden . Iemand enige idee?

Alvast bedankt!

[Hero of Time]

Worden de verzoeken niet gewoon 1:1 doorgestuurd naar de Exchange server en doet de IIS server voor dat domein gewoon reverse proxy spelen?

[Oogje]

Gokje, gaat het om een SBS server? Die /remote doet me namelijk denken aan Remote Web Workplace van SBS (aangezien het om dezelfde server als Exchange gaat)
Als het om een SBS gaat, niet onder water zelf in IIS dingen gaan doen maar netjes de wizards van SBS gebruiken.

[Anoniem: 552985]

@Hero of Time...... ik snap je vraag niet precies en wat bedoel je met reverse proxy?
if that is the case then whats the next step?

@Oogje is inderdaad een SBS server. Heb begrepen dat sommige wijzigingen automatisch op alle directory's toegepast wordt. Vandaar mijn terughoudendheid.

Ik zou zeggen ergens in IIS is opgegeven dat webmail.klant.nl naar de owa moet verwijzen.

Heb intern op het netwerk geen A record staan met webmail.klant.nl.

[Hero of Time]

Als je niet weet wat een reverse proxy is, wordt het tijd om je wat meer te gaan verdiepen in bepaalde materie en hier niet te veel aan komen.

Dat we te maken hebben met een SBS server is wel iets wat je had mogen noemen in je OP, want dan weten mensen zoals o.a. Oogje wat je moet doen en waar het probleem mogelijk zit. Ik heb er geen ervaring mee, dus meer dan dit kan ik je niet helpen.

[Brahiewahiewa]

Anoniem: 552985 schreef op zaterdag 05 november 2016 @ 16:50:
...De vorige beheerder heeft zitten knoeien met de webmail...

Weet je zeker dat het de vorige beheerder was?

...wanneer ik surf naar mail.klant.nl kom ik uit op de /Remote directory van de IIS...

En als je over port 25 connect naar mail.klant.nl? Staat er dan niet iets van SMTP server ready, ofzo?

[Oogje]

Ik ben lang uit de SBS dus weet t niet meer precies maar je moet iets gaan doen met de remote web workplace wizard en dergelijke. Vooral niets handmatig in IIS gaan wijzigen, dan maak je meer stuk dan je lief is.
Google maar eens op die term en naar SBS webmail. Dan krijg je genoeg leesvoer bij MS waarmee je je antwoord gaat krijgen

[Anoniem: 552985]

@Hero of time je hebt gelijk ik denk dat ik eerst alles goed moet aankaarten voordat ik de juiste antwoorden kan krijgen. Dus zal ik even opnieuw beginnen mijn excuses hiervoor. Ik ben zelf nog (junior systeembeheer) dus please go easy on me als ik sommige termen niet snap.

Het gaat om een Windows SBS 2008R2 met exchange 2010.
Met geknoei van de vorige eigenaar bedoel ik dat men iedere keer /owa erachteraan moest intikken wanneer ze maar webmail.klant.nl gingen. Dit heb ik kunnen oplossen door in iisstart.htm een redirect aan te maken naar /owa. Wel opgemerkt dat het niet meer hoeft in Exchange 2013 en 2016.

En dat er dan ook een mail.klant.nl bestaat, met een geldig certificaat van PositiveSSL CA2. en ook als intern extern url op de exchange staat ingesteld.
Dus ik snapte even niet van de vorige eigenaar waarom hij de DNS webmail.klant.nl heeft zitten gebruiken.

Daarnaast krijgen ze soms certificaat errors vanwege autodiscover. Waar ik overigens ook mee bezig ben en de oorzaak heb kunnen achterhalen). Ik wil eerst eigenlijk ervoor zorgen dat ik de webmail dns record er even uit krijg.
En dat wanneer ik surf naar mail.klant.nl dat hij dan direct de /owa pakt ipv /remote.

@Oogje nice tip! Zal er even in verdiepen.

[sanfranjake]

Bij SBS heb je als het volgens de voorschriften geconfigureerd is altijd met een enkele externe hostname voor alle services, die door de wizard altijd "remote" genoemd wordt.

Er is dus zeker handmatig geklust door je vorige beheerder.

Ik stelde zelf ook altijd redirects in voor de hostname, zodat gebruikers na de / niks meer in hoefden te vullen. Vaak was dat mail.klant.nl naar /owa en de remote.klant.nl naar /remote.

SBS is inmiddels erg lang geleden, maar je zou alles weer op orde kunnen stellen door de wizard voor externe toegang te draaien. Hoe die heet weet ik niet meer, dat is erg lang geleden. Als zich daarbij fouten voordoen zijn dat zeker fouten die de moeite waard zijn om op te lossen. Trek als je niet weet wat je doet eerst even een image en test het in een virtuele machine

Autodiscover is een hostname die je liever op je certificaat wil hebben, maar kan je ook met een srv-record afdwingen naar een andere hostname. Je kan autodiscover op externe clients ook leren zich op een bepaalde manier te gedragen in bepaalde omstandigheden, wat meer info (die je zelf wel even moet interpreteren) vind je hier: https://support.microsoft.com/en-us/kb/2212902

[ Voor 19% gewijzigd door sanfranjake op 05-11-2016 21:31 ]

[Anoniem: 552985]

Inderdaad ik las het.

https://blogs.technet.mic...ement-wizard-part-1-of-3/

ze draaien op esx dus denk dat ik eerst maar even een snapshot moet doen )

[sanfranjake]

En zorg dat je geen ruzie krijgt bij downtime, en het terugrollen van dat snapshot.

Internet e-mail en gebruikerstoegang lopen bij een snapshot gewoon door, dus mailtjes die gebruikers nu verzenden en mailtjes die vanaf internet binnen komen tijdens het klooien worden bij het terugdraaien van een snapshot weer verwijderd

[Hero of Time]

Best practise van Microsoft voor een domain controller (en dat is een SBS) als VM is dat je NOOIT snapshots gebruikt. Het terugdraaien naar een vorige staat kan een enorme bende en problemen veroorzaken. De sync tussen de clients en server kan hierdoor verloren raken. Computer accounts vernieuwen namelijk automatisch hun wachtwoord en bij het restoren verliezen ze de domain trust.

Als je dus wat wilt testen, dan zorg je voor een kopie in een volledig gescheiden omgeving. Wil je er een cliënt bij en wil je met snapshots werken, dan maak je die voordat je de cliënt bij het domein voegt en van beide machines die je ook tegelijk hersteld en weer opnieuw aan het domein toevoegt.

[sanfranjake]

Bij SBS niet zo'n grote ramp hoor snapshots in dat opzicht Heb ik de afgelopen 15 jaar zooo vaak gedaan. En SBS heeft maximaal 75 clients.

Die snapshothint is vooral vanwege dataverlies en omdat ik het idee heb dat topicstarter nou niet echt precies weet wat 'ie doet

[Hero of Time]

Hij is junior, zeg maar net in het vak begonnen. Natuurlijk weet je dan nog niet waar je mee bezig bent.

Dat het met SBS niet zo'n ramp is, is geen reden om het maar klakkeloos te doen. Zeker voor TS is het gewoon goed om een kloon te maken in een aparte omgeving om mee te 'spelen'. Wie weet wat er nog meer boven komt drijven van z'n voorganger.
Het is overigens ook gelijk een mooi moment om de eventuele oplossing te testen. Documenteren wat je doet, snapshot terugzetten en repliceren. Werkt dat, dan op productie uitvoeren. Werkt het niet, dan opnieuw proberen en nagaan wat je gemist hebt.

Leer je het meeste van.

[Dennism]

Hero of Time schreef op zaterdag 05 november 2016 @ 22:23:
Best practise van Microsoft voor een domain controller (en dat is een SBS) als VM is dat je NOOIT snapshots gebruikt. Het terugdraaien naar een vorige staat kan een enorme bende en problemen veroorzaken. De sync tussen de clients en server kan hierdoor verloren raken. Computer accounts vernieuwen namelijk automatisch hun wachtwoord en bij het restoren verliezen ze de domain trust.

Als je dus wat wilt testen, dan zorg je voor een kopie in een volledig gescheiden omgeving. Wil je er een cliënt bij en wil je met snapshots werken, dan maak je die voordat je de cliënt bij het domein voegt en van beide machines die je ook tegelijk hersteld en weer opnieuw aan het domein toevoegt.

Ik meende altijd dat dit alleen bij omgevingen optrad waar meerdere Domain Controllers aanwezig zijn vanwege USN en USN rollback. https://technet.microsoft...aspx#usn_and_usn_rollback

Ik heb bij SBS ook nog nooit vanuit een snapshot gerestored, maar eigenlijk ook nog nooit gehoord van grote issues bij het restoren van een SBS vanuit een snapshot enkel bij omgevingen met meer dan 1 DC.

Al is het natuurlijk altijd aan te raden om een volledig supported backup oplossing te gebruiken (hoop dat TS dit ook goed voor elkaar heeft voordat je bezig gaat met dit soort zaken).

[Hero of Time]

Dennism schreef op zaterdag 05 november 2016 @ 23:36:
[...]

Ik meende altijd dat dit alleen bij omgevingen optrad waar meerdere Domain Controllers aanwezig zijn vanwege USN en USN rollback. https://technet.microsoft...aspx#usn_and_usn_rollback

Correct. Maar ook met een enkele DC kan je dus issues krijgen als je een snapshot terugzet. Bij het domein aangemelde systemen houden ook met de DC een sync bij. En als je vandaag een snapshot maakt en over twee dagen herstel je die, terwijl er in de tussentijd een systeem z'n status heeft bijgewerkt (systeem wachtwoord), dan moet je die machine opnieuw toevoegen aan het domein (eerst eruit halen uiteraard). Afhankelijk van je omgeving kan dat al een probleem zijn.

Maar het grootste punt is Exchange. Je bent dan wel de mail van de tussentijd kwijt en dat wil je natuurlijk niet.

Al is het natuurlijk altijd aan te raden om een volledig supported backup oplossing te gebruiken (hoop dat TS dit ook goed voor elkaar heeft voordat je bezig gaat met dit soort zaken).

Daarom m'n tip voor een testomgeving dat volledig los staat. Bij voorkeur ook het internet niet op kan (ivm mail).

[Dennism]

Hero of Time schreef op zaterdag 05 november 2016 @ 23:42:
[...]

Correct. Maar ook met een enkele DC kan je dus issues krijgen als je een snapshot terugzet. Bij het domein aangemelde systemen houden ook met de DC een sync bij. En als je vandaag een snapshot maakt en over twee dagen herstel je die, terwijl er in de tussentijd een systeem z'n status heeft bijgewerkt (systeem wachtwoord), dan moet je die machine opnieuw toevoegen aan het domein (eerst eruit halen uiteraard). Afhankelijk van je omgeving kan dat al een probleem zijn.

Maar het grootste punt is Exchange. Je bent dan wel de mail van de tussentijd kwijt en dat wil je natuurlijk niet.


[...]

Daarom m'n tip voor een testomgeving dat volledig los staat. Bij voorkeur ook het internet niet op kan (ivm mail).

Klopt uiteraard, al is dat in de regel niet een enorm risico bij een SBS wat vaak enkel vrij kleine omgevingen betreft met vaak een standard inrichting betreffen, er zitten meestal geen enorme aantallen PC's op, en AD password changes staan vaak op de default 30 dagen, waardoor je in de regel niet snel een issue hebt bij SBS, al kan het inderdaad voorkomen bij een actie als deze dat een system (of misschien een paar) niet meer in sync zijn, maar die heb je normaliter binnen een paar minuten weer aangemeld in de regel (even de netwerkverbinding ontkoppelen / uitzetten bij Wifi, inloggen met cached credentials de in de regel ook standaard aanstaan en uit / in het domain aanmelden). Niet dathet handig is, maar een groot issue heb ik er nog nooit echt mee gezien moet ik eerlijk bekennen.

Zaken als Exchange, maar ook bijv SQL zijn dan inderdaad een groter risico, maar dat heb je ook als de machine uit zou vallen. Daarvoor wil je toch eigenlijk in alle gevallen een aparte backup oplossing hebben die exchange stores of eventuele SQL databases iedere 15 tot 30 min automatisch backupt, dat wil je eigenlijk niet alleen in je dagelijkse backup hebben zitten wanneer verlies van E-mail of eventuele database transacties belangrijk zijn voor de bedrijfsvoering. Als je dat soort zaken niet correct geregeld hebt moet je imho inderdaad niet snapshots gaan lopen rommelen.

[Jazzy]

Anoniem: 552985 schreef op zaterdag 05 november 2016 @ 21:12:
Ik wil eerst eigenlijk ervoor zorgen dat ik de webmail dns record er even uit krijg.
En dat wanneer ik surf naar mail.klant.nl dat hij dan direct de /owa pakt ipv /remote.

Wat is nu precies het probleem wat je probeert op te lossen? Want wat ik nu zie is dat je het standaard SBS gedrag wilt aanpassen en de gebruikers een nieuwe url voor webmail gaat geven. Met als extra risico dat je niet kunt overzien wat je aan het doen bent. Is dit allemaal om 100 euro voor een certificaat uit te sparen?

[Dennism]

Jazzy schreef op maandag 07 november 2016 @ 11:21:
[...]

Wat is nu precies het probleem wat je probeert op te lossen? Want wat ik nu zie is dat je het standaard SBS gedrag wilt aanpassen en de gebruikers een nieuwe url voor webmail gaat geven. Met als extra risico dat je niet kunt overzien wat je aan het doen bent. Is dit allemaal om 100 euro voor een certificaat uit te sparen?

duur certificaat wel een standaard 2 domeinen SAN certificaatje betaal je geloof ik een eurotje of 40 voor 3 jaar geldigheid

[Hero of Time]

Jazzy schreef op maandag 07 november 2016 @ 11:21:
[...]

Wat is nu precies het probleem wat je probeert op te lossen? Want wat ik nu zie is dat je het standaard SBS gedrag wilt aanpassen en de gebruikers een nieuwe url voor webmail gaat geven. Met als extra risico dat je niet kunt overzien wat je aan het doen bent. Is dit allemaal om 100 euro voor een certificaat uit te sparen?

Wat ik begrijp is dat hij twee DNS namen heeft om dezelfde interface te benaderen. Als hij webmail.klant.nl gebruikt, wordt hij netjes naar /owa gestuurd. Wordt er mail.klant.nl gebruikt, dan stuurt de SBS server je door naar /remote en dat wil de TS niet. Dat moet ook naar /owa gaan.

[Jazzy]

Het was eigenlijk een retorische vraag. Wat jij nu herhaalt is inderdaad wat de TS probeert te bereiken, maar mijn vraag is welk probleem hij hiermee probeert op te lossen. Mijn vermoeden is namelijk dat de business hier niet om gevraagd heeft en de TS denkt met een goedkoper certificaat af te kunnen als hij even IIS aan kan passen. Wat dus een uitermate slecht idee is.

Die forward naar /remote is onderdeel van een standaard feature van SBS 2011. Als je die feature stuk wilt maken dan moet je extreem goed begrijpen hoe deze in IIS geconfigureerd is en wat het gevolg is als je de server daarna blijft beheren met de SBS wizards. Die slimme integratie is altijd al de kracht van SBS geweest en de meeste problemen worden veroorzaakt doordat 'handige' beheerders handmatig aanpassingen maken of geen rekening houden met dat SBS op een andere manier beheerd wordt dan de losse serverproducten.

Technisch gezien is het verder geen probleem. Gewoon de IIS host headers configuratie aanpassen, AutoDiscover opnieuw configureren en nooit meer de SBS beheertools gebruiken. En dan wachten tot de volgende beheerder een topic opent waarin geklaagd wordt over het gepruts van de vorige beheerder.

[ Voor 36% gewijzigd door Jazzy op 07-11-2016 12:38 ]

[Hero of Time]

Ik denk dat de TS het een worst zal wezen als /remote op een andere naam te bereiken is, als ook mail.klant naar /owa gaat. Dat moet toch wel te regelen zijn met de wizards?

[Jazzy]

En wat vertel je dan tegen de gebruikers die nu nog Remote Web Workplace gebruiken op de bestaande url?

[Hero of Time]

TS heeft het er niet over gehad dat dat op die URL gebruikt wordt. En anders kunnen ze toch direct via /remote erheen, of is dat dan niet meer mogelijk?

[Brahiewahiewa]

Zou het niet zo kunnen zijn dat mail.klant.nl het mx-record is en als TS dat gaat wijzigen de mail niet meer binnenkomt?

[Hero of Time]

Je kan mx en A records gelijk hebben volgens mij, dat zou geen probleem moeten geven. Maar ik denk niet dat het de mx record is, aangezien er /remote achter hangt en als je handmatig /owa neerzet het gewoon werkt.