[Exchange 2016] Outlook Web App "Still working on it"

[Stefan26]

Voor een on premises Exchange 2016 server loop ik tegen het volgende probleem aan:

Enkele gebruikers kunnen vanuit verschillende externe locaties de Outlook Web App niet benaderen. Zij krijgen of een blanco webpagina of de volgende melding die blijft draaien:



Andere gebruikers kunnen vanuit de verschillende locaties OWA wel gewoon bereiken en inloggen.
Een IISReset los het probleem niet.
Indien de mailserver wordt herstart werkt het tijdelijk voor alle gebruikers, maar na enkele uren niet meer.

De mailserver is bijgewerkt met Cumulative Update 4 for Exchange Server 2016 (KB3177106) en tevens is de firewall bij de klant opnieuw geconfigureerd, zonder succes.
In de Windows logboeken is geen foutmelding te vinden met betrekking tot dit probleem.

Iemand verder een idee?

[ro3lie]

Gezien het na een reboot weer even goed gaat is dat een richting van bv. bepaalde limieten. Cache. Etc.

Werkte het voor CU4 wel goed? En wanneer is deze geinstalleerd?

[Stefan26]

Voor CU4 was het probleem ook aanwezig. Deze is anderhalf week geleden geïnstalleerd. Aan welke bepaalde limieten, cache zit je dan te denken?

[GioStyle]

Genoeg (ram)geheugen?

[ro3lie]

Niks specifieks eerlijk gezegd. Ooit een ander probleem gehad met Exchange 2013 welke na een herstart pas na 1-1.5u liet zien. Tot die tijd werkte alles goed.

Is toen opgelost door Microsoft support, is ook mijn advies voor jou.
Er is nog weinig te vinden over Exchange 2016, zonder verdere foutmeldingen e.d. heb je weinig om mee te werken/zoeken.

Edit:
Toch nog paar vragen:
- Gebruikers intern hebben die er last van? Je hebt het nu alleen over externe locaties/gebruikers.
- Indien nee. Wat is het verschil met de externe gebruikers? Mogelijk dit hierin je issue. Gebruik je load balancing? URL redirectors? Microsoft TMG? Etc.

[ Voor 29% gewijzigd door ro3lie op 05-03-2017 23:39 ]

[Stefan26]

GioStyle schreef op zondag 5 maart 2017 @ 20:58:
Genoeg (ram)geheugen?

De server heeft intern 16GB geheugen en 4vCPU's.

ro3lie schreef op zondag 5 maart 2017 @ 23:36:
Niks specifieks eerlijk gezegd. Ooit een ander probleem gehad met Exchange 2013 welke na een herstart pas na 1-1.5u liet zien. Tot die tijd werkte alles goed.

Is toen opgelost door Microsoft support, is ook mijn advies voor jou.
Er is nog weinig te vinden over Exchange 2016, zonder verdere foutmeldingen e.d. heb je weinig om mee te werken/zoeken.

Edit:
Toch nog paar vragen:
- Gebruikers intern hebben die er last van? Je hebt het nu alleen over externe locaties/gebruikers.
- Indien nee. Wat is het verschil met de externe gebruikers? Mogelijk dit hierin je issue. Gebruik je load balancing? URL redirectors? Microsoft TMG? Etc.

Alleen sommige externe gebruikers hebben er last van, interne gebruikers niet.
Er zit verder geen load balancer of iets dergelijks voor. Het is een mailserver welke op poort 25 en 443 beschikbaar is gesteld.
Externe gebruikers gaan of naar de OWA webadres of openen Outlook lokaal op hun laptop / mobile device.
Indien de gebruiker het probleem heeft kan ik wel succesvol een telnet uitvoeren op poort 443 vanuit de laptop. Verschillende browsers getest en hetzelfde probleem.

[ Voor 10% gewijzigd door Stefan26 op 06-03-2017 09:34 ]

[Question Mark]

Stefan26 schreef op maandag 6 maart 2017 @ 08:47:
[...]


De server heeft intern 16GB geheugen en 4vCPU's.

Dat was de vraag niet. Er werd gevraagd of dit genoeg memory is.

Zonder informatie over aantallen gebruikers en verdere inrichting kunnen wij hier niets over roepen. Let ook op de virtualisatie guidelines die gehanteerd worden voor Exchange 2016.

[Stefan26]

Question Mark schreef op maandag 6 maart 2017 @ 14:01:
[...]

Dat was de vraag niet. Er werd gevraagd of dit genoeg memory is.

Zonder informatie over aantallen gebruikers en verdere inrichting kunnen wij hier niets over roepen. Let ook op de virtualisatie guidelines die gehanteerd worden voor Exchange 2016.

De mailserver heeft 35 mailboxen. Het advies van Microsoft is 8GB voor de mailbox role (welke de enige rol is op de server) met één mailboxdatabase. Hiervoor hebben zij de volgende formule:

{min memory + {number of mailboxes * 5MB RAM)}

Dit lijkt mij dus genoeg memory voor de mailserver.

[Verwijderd]

Alleen sommige externe gebruikers hebben er last van, interne gebruikers niet.

Dan lijkt me de conclusie duidelijk: Het probleem zit in de firewall.
Misschien een sessie die afgebroken wordt?
Valideer deze stelling uiteraard maar de dader lijkt me duidelijk.
Het kan natuurlijk ook nog aan de ISP liggen maar dit is minder waarschijnlijk.

[Stefan26]

Verwijderd schreef op donderdag 9 maart 2017 @ 16:34:
Alleen sommige externe gebruikers hebben er last van, interne gebruikers niet.

Dan lijkt me de conclusie duidelijk: Het probleem zit in de firewall.
Misschien een sessie die afgebroken wordt?
Valideer deze stelling uiteraard maar de dader lijkt me duidelijk.
Het kan natuurlijk ook nog aan de ISP liggen maar dit is minder waarschijnlijk.

Dat dacht ik namelijk eerst ook, maar als ik de firewall herstart hebben de gebruikers het probleem nog. Herstart ik de Exchange server dan kunnen ze er weer tijdelijk bij.

[Joenino]

Je laat ze rechtstreeks connecten op de mailbox server? Die tevens ook Webaccess (webmail) staat te doen?
En dan maar 16GB? Voor alles? Beetje karrig lijkt me.

Waarom ik dit zegt is omdat de mailboxserver al minimaal 8 GB pakt en de Webacces minimaal 4. Tel daar Windows 2012R2 of 2016 nog bij op en je zit al erg krap. Vervolgens wilt Exchange graag zo veel mogelijk cache data hebben. Ook komen daar je 35 mailboxen nog bovenop.

Persoonlijk zou ik beide rollen scheiden of gooi er eens wat meer geheugen (minste werk) in zeker omdat je 4 vCPU noemt ga ik ervan uit dat je VMWare of Hyper-V draai dus geef hem eens 24 GB en check het nog eens.

Wij hebben toen ook gesized via de guide en die zei ook dat 16GB genoeg was..... We hebben toen in stapjes naar de 32 GB moeten gaan om te zorgen dat de machine niet meer ging swappen en traag werd waardoor ook functionaliteit weg viel. Wij draaien dan wel in een DAGcluster maar je vergist je al gauw aan de specs die nodig zijn voor Exchange.

[Stefan26]

Joenino schreef op maandag 13 maart 2017 @ 16:07:
Je laat ze rechtstreeks connecten op de mailbox server? Die tevens ook Webaccess (webmail) staat te doen?
En dan maar 16GB? Voor alles? Beetje karrig lijkt me.

Waarom ik dit zegt is omdat de mailboxserver al minimaal 8 GB pakt en de Webacces minimaal 4. Tel daar Windows 2012R2 of 2016 nog bij op en je zit al erg krap. Vervolgens wilt Exchange graag zo veel mogelijk cache data hebben. Ook komen daar je 35 mailboxen nog bovenop.

Persoonlijk zou ik beide rollen scheiden of gooi er eens wat meer geheugen (minste werk) in zeker omdat je 4 vCPU noemt ga ik ervan uit dat je VMWare of Hyper-V draai dus geef hem eens 24 GB en check het nog eens.

Wij hebben toen ook gesized via de guide en die zei ook dat 16GB genoeg was..... We hebben toen in stapjes naar de 32 GB moeten gaan om te zorgen dat de machine niet meer ging swappen en traag werd waardoor ook functionaliteit weg viel. Wij draaien dan wel in een DAGcluster maar je vergist je al gauw aan de specs die nodig zijn voor Exchange.

Bedankt voor deze tip! De server heeft nu 24GB intern geheugen (inderdaad VMWare) en tot op heden kan iedereen de OWA-site zonder problemen benaderen en hier inloggen. Blijft wel vreemd dat dit alleen voor enkele gebruikers problemen gaf.

[Joenino]

Stefan26 schreef op woensdag 15 maart 2017 @ 13:39:
[...]


Bedankt voor deze tip! De server heeft nu 24GB intern geheugen (inderdaad VMWare) en tot op heden kan iedereen de OWA-site zonder problemen benaderen en hier inloggen. Blijft wel vreemd dat dit alleen voor enkele gebruikers problemen gaf.

Exchange kan een echte geheugen slurper zijn ondanks dat je het niet verwacht. Meestal zijn Exchange performance problemen zoals het niet beschikbaar zijn van OWA (te traag reageren) een geheugen probleem. Exchange wilt namelijk zovele mogelijk cachen om snel te blijven echter zijn de minimale specs daar gewoon niet voldoende voor. Zo hebben wij dus omdat we in DAG cluster draaien alleen al 64GB in gebruik voor 2 exchange servers. Totaal bizar in mijn ogen .

Maar hou het geheugen eens in de gaten zou ik zeggen. Krijg je weer problemen kijk dan eerst eens hoeveel er in gebruik is.

[Stefan26]

Joenino schreef op woensdag 15 maart 2017 @ 13:57:
[...]


Exchange kan een echte geheugen slurper zijn ondanks dat je het niet verwacht. Meestal zijn Exchange performance problemen zoals het niet beschikbaar zijn van OWA (te traag reageren) een geheugen probleem. Exchange wilt namelijk zovele mogelijk cachen om snel te blijven echter zijn de minimale specs daar gewoon niet voldoende voor. Zo hebben wij dus omdat we in DAG cluster draaien alleen al 64GB in gebruik voor 2 exchange servers. Totaal bizar in mijn ogen .

Maar hou het geheugen eens in de gaten zou ik zeggen. Krijg je weer problemen kijk dan eerst eens hoeveel er in gebruik is.

Net de melding gehad dat het probleem toch helaas weer terug is.
Memory gebruik op de server is nu 12GB van de dus totaal 24GB.

[wagenveld]

Dat je na een server restart overal weer bij kan hoeft niet per se te betekenen dat het probleem niet bij de firewall ligt. Kan ten slotte best dat bestaande sessies afgebroken worden door de firewall maar dat nieuwe sessies weer even werken.
Heb je de IIS logs er al eens bijgepakt? Al wil je dan ideaal gezien het probleem kunnen repliceren als het wat rustiger is op de server.
NAT je rechtstreeks naar je Exchange server of zit er iets tussen?

[ Voor 8% gewijzigd door wagenveld op 15-03-2017 16:09 ]

[Stefan26]

wagenveld schreef op woensdag 15 maart 2017 @ 16:07:
Dat je na een server restart overal weer bij kan hoeft niet per se te betekenen dat het probleem niet bij de firewall ligt. Kan ten slotte best dat bestaande sessies afgebroken worden door de firewall maar dat nieuwe sessies weer even werken.
Heb je de IIS logs er al eens bijgepakt? Al wil je dan ideaal gezien het probleem kunnen repliceren als het wat rustiger is op de server.
NAT je rechtstreeks naar je Exchange server of zit er iets tussen?

De IIS logs heb ik al eerder bekeken. Indien het probleem zich voordoet voor de bepaalde gebruiker(s) en het externe IP adres van een gebruiker opzoek zie ik daar de aanvraag voor de connectie niet terug in de log. Na het uitvoeren een een telnet vanuit de lokale client naar de mailserver komt deze aanvraag wel terug in de IIS log.
NAT wordt via de firewall (SonicWALL) uitgevoerd naar de mailserver.
Indien ik de firewall herstart blijft het probleem. Pas na de herstart van de mailserver kan iedereen er weer bij.

[Vorkie]

Dat lijkt eerder erop of er tcp connecties open blijven staan.

Als je een netstat bekijkt, hoe ziet deze er dan uit?

[nielsl]

Ik heb hetzelfde issue, Exchange 2016 CU4, extra informatie: Server staat achter een 2008R2 reverse proxy, de /owa wordt gewoon doorgelust, en er vindt SSL offloading plaats.

Als ik in chrome/firefox naar https://server.domein.nl/owa ga blijft de boel laden, als ik naar https://server.domein.nl/owa/ ga laden bepaalde .JS componenten wel in. Kijk anders in Chrome met F12 of je ook last hebt van .JS files die niet worden ingeladen.

Mijn uitdaging zit nu om in de ARR de trailing slash standaard toe te voegen, maar das een hobby actie voor op de achtergrond

[wagenveld]

Ook een Sonicwall toevallig?

[nielsl]

wagenveld schreef op woensdag 15 maart 2017 @ 17:07:
Ook een Sonicwall toevallig?

Ik wil het topic niet kapen, maar als je vraag aan mij gericht is, nee, geen sonicwall. de reverse proxy is geNAPT.

[Stefan26]

Uiteindelijk is het probleem opgelost door een laatst beschikbare firmware update van de firewall.

[RoRoo]

Stefan26 schreef op woensdag 29 maart 2017 @ 20:43:
Uiteindelijk is het probleem opgelost door een laatst beschikbare firmware update van de firewall.

Het zal ook eens niet.
Ik hou deze maar gewoon in gedachten...

[ Voor 7% gewijzigd door RoRoo op 31-03-2017 10:44 ]