Jak jsme se trápili s podporou Microsoft Office 365 (část 1/2): noční můra začíná

Naše „utrpení“ s Microsoft Office 365 se odehrálo v létě 2016. Už tehdy jsem věděl, že o něm chci jednou napsat. Od té doby čas utíkal a řešila se spousta jiných projektů. Nyní před Vánoci se objevila trocha volného času a já se dal do příprav článku. Musím se vám přiznat, že když jsem opět pročítal mailovou komunikaci s podporou, začali se mi vracet vzpomínky a vřít ve mně krev. Budu se však snažit v článku zůstat věcný a netrousit sarkastické poznámky.

Řešení našeho problému si vyžádalo přes 60 e-mailů, 80 hodin práce a měsíc času. Nakonec (stejně jako u případu Vodafone „Jak jsme pomáhali Vodafone: diagnostika problému (část 1/2))“ se příčinu problémů najít nepodařilo (… i když já vím, že Microsoft ví).

V květnu 2016 jsme se stali indirect CSP partnerem Microsoft Office 365

Je to program, který nám umožňuje přeprodávat veškeré služby Office 365 (nyní i MS Azure) s měsíční frekvencí. To ulehčuje pořizovaní těchto služeb. Zákazník dostává měsíčně jednu fakturu pouze od nás, kde už je i práce a odebraný HW/SW. Nemusí tak řešit platby kartou po internetu a faktury ze zahraniční (do té doby se dalo platit pouze kartou přes internet a faktury byly z irské pobočky Microsoftu), nebo kupovat roční licence z OLP programu (to nebylo moc flexibilní).

Díky tomu, že jsme měli možnost takto lehce přeprodávat Office 365, rozhodli jsme se začít používat službu „Exchange Online Protection“. Máme totiž řadu zákazníků, kteří mají svůj vlastní Microsoft Exchange server (zejména díky dříve levným SBS edicím Windows) a potřebovali problém spamů/virů nějak řešit. Zároveň máme dost zákazníků, kteří využívají „Exchange Online“, kde je tento antispam součástí. Vzhledem k naší „víře“ ve standardizaci (Standardizace – děláme IT jako Baťa cvičky) jsme se rozhodli používat toto řešení (samozřejmě nám vyhovovala jeho funkcionalita i cena a dá se použít i s jinými servery než jen s MS Exchange).

Popis problému

Na řešení jsme již měli převedeno více zákazníků a chystali jsme se převést dalšího (100+ licencí). Vše jsme nastavili a otestovali. Zákazník na řešení pár dní fungoval, když začal hlásit, že se mu náhodně zpožďují e-maily. Cca 5 % e-mailů chodilo se zpožděním od desítek minut až po hodiny. To byl dost velký problém, protože zákazník je na e-mailech značně závislý. Udělali jsme si „message tracking“ z EOP konzole (mají to pěkně udělané). A zjistili jsme (viz obrázek), že se e-mail zdržel na předávce mezi Office 365 a zákazníkovým Exchange serverem (u EOP je tok e-mailů následující: „e-mailový server odesílatele“ -> Office 365 -> „mailový server příjemce“).

Chyba při předávce byla „connection refused“ – tzn. čekal bych, že něco aktivně komunikaci odmítlo (odmítnutí e-mailovým serverem po navázání TCP spojení, RST v pokusu o TCP handshake, nebo ICMP TCP port unreachable). V log záznamech hraničního routeru však nebylo vidět, že by se v daném čase nějaké spojení z IP Microsoftu událo (to, jaký server se o doručení pokoušel, jsme měli z dalších výpisů EOP). Z toho jsme usoudili, že by mohla být chyba na straně Microsoftu a otevřeli jsme ticket.

Poměrně promptně se ozval někdo ze supportu Microsoft Office 365 (myslím, že cca do hodiny) a začal s námi problém řešit. To by byla ta pozitivnější část. To negativní je, že jsou to mistři v žádostech o více informací. Takže na každých 5 minut jejich času vychází cca 30 minut našeho času, při sbírání požadovaných informací. Často chtějí podle mne zbytečné věci, ale nepokračují dál, dokud je nedodáte. Je to nerovný boj s presumpcí chyby na vaší straně.

Startovní pozice

Po výměně cca 5 e-mailů byl stav následující:

• Problém: zákazníkovi se zpožďuje cca 5 % e-mailů o desítky minut až hodiny.
• Co jsme zjistili: e-maily se zdržují na předání mezi Office 365 a zákazníkovým Exchange serverem. S chybou „[{LED=450 4.4.316 Connection refused};{MSG=Socket error code 10061};{FQDN=dns_serveru};{IP=ip_zákazníka};{LRT=datum }]‘
• Co jsme dodali:
  • Tracking logy z EOP k náhodně zvoleným zpožděným e-mailům.
  • E-mailové hlavičky zpožděných e-mailů.
  • Logy z interního Exchange serveru.
  • Logy z hraničního routeru (obsahují informace o uskutečněných i odmítnutých spojeních na interní Exchange – port 25/TCP).
• Doplňující informace: router má synchronizovaný čas přes NTP, nový FW, stejný router se stejným nastavením máme i jinde a s EOP tam nejsou problémy, i MS Exchange je aktuální.
• Jak si stojíme: Microsoft stále pracuje pouze s variantou, že chyba je u nás ☹.

Logy z Exchange ani routeru neukazují, že by se ty neúspěšné pokusy o doručení dostaly alespoň na náš router (resp. že by viděl jejich spojení viz obrázek – čas v EOP je UTC v routeru je to UTC+2).

Další komunikace se supportem Microsoftu pak vypadala následovně:

• Microsoft náš žádá, abychom vypnuli na hraničním routeru firewall. Je to zbytečné, kdyby to blokoval FW, tak bychom viděli na routeru „rejected connections“. Avšak mlčíme a plníme jejich přání. Samozřejmě to problém nevyřešilo.
• Tentokrát si máme vypnout SMTP inspekci na routeru a zapnout detailnější logování na Exchange. Ok, ten nápad s tou inspekcí beru (i když ji zapnutou nemáme). Proč zapnout pokročilé logování na Exchange však nechápu, když se ta neúspěšná spojení ani na Exchange nedostanou. Vše plníme a posíláme logy.
• Abychom Microsoftu pomohli, domluvili jsme se s ISP. Ten nám udělal packet capture ze svého routeru (1 hop před routerem zákazníka). Ten obsahoval veškeré TCP SYN pakety na port 25 s přesným časem a zdrojovými IP. Následně jsme opět vybrali nějaké zpožděné e-maily v daném termínu a opatřili k nim veškeré logy (chvíli to zabere, bohužel je to potřeba dělat po každém kroku, co nám MS doporučí). Capture jsme prošli a opět v něm nebyly vidět pokusy o TCP spojení u těch neúspěšných předání. Z toho pro mne plyne, že problém nemůže být na straně zákazníka!
• Microsoft nám poděkoval a odepsal, že chyba „connection refused“ znamená, že na své straně aktivně odmítáme spojení a že to dělá zákazníkův router, nebo Exchange, který nezvládne více spojení. Hmm, na to není co říct. Předchozí krok jasně dokázal, že pokus o spojení nedorazil ani na routeru u ISP. Následovala má argumentace viz výše, nějaké telefonáty a zbytečné rozčilování.

Pokračování příště

Zde bych si dovolil článek přerušit. Chtěl jsem celý příběh vměstnat do jednoho dílu, ale když jsem se rozepsal, bylo ve mne tolik emocí, že se mi to nepodařilo. V příštím díle vám popíšu, jak jsme dále bojovali se supportem, ale ze zoufalosti jsme se pokusili tlačiti přes distributora.

Pokud máte nějaké osobní zkušenosti, určitě mi napište do komentářů.

(Pokračování Jak jsme se trápili s podporou Microsoft Office 365 (část 2/2): Microsoft má vždy pravdu)