Firewire2002
Registered User
Vorwort
Ich bin selbst in der Hosting-Branche als Admin tätig und kenne die Hintergedanken, beim Bau von Produkten in unterschiedlichen Preissegmenten. Das ich mich für OVH und nicht meinen Arbeitgeber entschieden habe, ist 2 Gründen geschuldet
3,50 Euro pro Monat sind für einen Hosted Exchange ein sehr ordentlicher Dumping-Preis. Der großteil der Konkurenz liegt beim 3 bis 5-fachen für vergleichbare Produktspezifikationen. Ich bin diesen Vertrag ohne irgendwelche Kulanz-Erwartungen eingegangen und war zuvor bereits über die schlechte Supportqualität als auch Reaktionsgeschwindigkeiten informiert. Wozu brauch man schließlich Support bei einem Hosted Exchange, wenn man mit Exchange und Outlook selbst bestens umgehen kann? Auch dazu später mehr.
Testzeitraum:
Von Dezember 2014 bis Januar 2016
Der Kernbestandteil - Microsoft Exchange 2013
Wie zu erwarten war, hat OVH dort ein klassisches Exchange Cluster stehen. Auf die Features davon hat OVH keinen direkten Einfluss und die Software macht genau das was man erwartet: Mails, Kalender, Kontakte, Aufgaben und Notizen verwalten.
Alle Besonderheiten die man hier feststellt, sind Microsoft und nicht OVH anzulasten und finden sich entsprechend bei jedem Exchange Cluster. Daher gehe ich hier nicht weiter darauf ein. Aus Sicht zwischen Hosting-Kunde und Hoster: alles okay.
Die Erreichbarkeit
Im Testzeitraum konnte ich kenne andauernden Ausfälle feststellen. Laut Info-Mail von OVH soll es am 09.12.2015 größere Probleme gegeben haben. Die Mail führte auch sehr detailiert auf, welche Maßnahmen sie in wann ergriffen haben und wie erfolgreich diese waren. Für mich als Admin war das recht amüsant zu lesen, weil man parallelen zur eigenen Arbeit zieht. Bei technisch-unversierte Kunden könnte dies aber unbehagen auslösen, weil es ein Bild von Hilflosigkeit deutet, wenn man nicht aus eigenen Kenntnissen heraus die Notwendigkeiten zwischen den ganzen Misslungenen Maßnahmen sieht. Aus fachlicher Sicht ist OVH bei dem Ausfall aber kein Vorwurf zu machen, alle Maßnahmen sind nachvollziehbar.
Im Nachgang wurde den Kunden eine Gutschrift für Neubestellungenen weiterer Hosted Exchange Postfächer angeboten. Kann man nicht meckern. Wer interesse an dieser Mail hat, möge sich einfach melden. Das würde sonst den hier eh schon längeren Beitrag völlig sprengen.
Aber:
Von einem Netcologne-Anschluss (Cable/DOCSIS/Multikabel) waren immer wieder Verbindungsunterbrechungen zum OVH Exchange zu verzeichnen. Dank einem Bug im MS Outlook führt dies zum Einfrieren des Outlooks, weil die Anwendung mit der nicht mehr existenten TCP Session nicht zurecht kommt. Dieses Phänomen trat bei meinen Tests ausschließlich zwischen Netcologne und OVH auf. Es gab keine Probleme aus dem Netz von PlusServer zu OVH und keine Probleme von Netcologne zu Exchange Servern von Microsoft (Office365) und PlusServer.
Beim sniffen ist aufgefallen, dass nach erfolgreichem Verbindungsaufbau und Bestand der Verbindung über mehrere Stunden plötzlich TCP-RST anstatt ACK Pakete zurückkamen. Die Verbindungen bestanden teils nur wenige Minuten, manchmal mehrere Stunden.
Ich habe das Problem zwischen Netcologne und OVH nicht an den OVH Support geleitet. Weil ich genau weiß, dass sie bei solchen spezifischen Problemen ebenso wenig machen können, wie ich. Die Ursachenforschung ist für OVH bei einem Produkt in diesem Preissegement nicht lohnenswert. Insbesondere wenn sich am Ende rausstellen könnte, dass Netcologne und nicht OVH schuld ist.
Der Spam-Filter
Beworben wird das gute Stück einfach nur mit "Anti-Spam". Das OVH hier eine ganz eigene Definition von "Anti" hat, überraschte mich dann doch gewaltig.
Eingehend hat man die Wahl ob man seine Mails direkt ohne Spam-"Filter" an den Exchange zustellen möchte oder via alternativen MX Record über den von OVH eingekauften Spamfilter "Vade-Retro". OVH weist in der Hilfe explizit darauf hin, dass sie dabei keine Mails löschen - soweit so gut - allerdings nehmen sie auch jeden Schrott an. Über den Einsatz von DNSBLs kann man sich streiten und das man Mails nur abweist, wenn die einliefernde IP auf mehreren Blacklisten steht, ist schon seit jahren gelebte Best-Practice. Aber bei der Config die OVH auf dem Vade-Retro "Filter" fährt, werden weder dynamische Dialin IPs noch IPs gefiltert, welche auf den 15 größten und verbreitesten Blacklists stehen. Die Mails werden stumpf angennommen und als Spam getaggt.
Sorry OVH, aber das ist weder ein Spam-Filter, noch irgendein "Anti"-Spam Feature. Das ist schlicht und ergreifend ein automatischer Spam-Tagger. Mehr aber auch nicht. Was tatsächlich dann mit den Mails passieren soll, muss jeder Postfachnutzer für sich selbst individuell mit Postfachregeln nachbauen. Weil sich damit ja auch so wahnsinnig gut Spam-Scorings bewerten lassen ...
Ich habe mir deswegen ein eigenes Postfix-Setup davor gebaut und den MX Record darauf gesetzt. Mit einfachen Tests auf RFC-Konformität und ein paar DNSBLs habe ich 99% des Spams direkt abgelehnt ohne auch nur ansatzweise tiefer in die Mail hinein schauen zu müssen. Danach ging es direkt zum OVH Exchange ohne Umweg über Vade-Retro.
Bei ausgehenden Mails setzt OVH dann tatsächlich auf die gemeinübliche Definition von "Anti": Eine von meinem Monitoring generierte Mail, welche im gesamten Testzeitraum um die 20-30 Mal aufgetreten sein dürfte, wurde an mein Exchange Postfach bei OVH zugestellt. Wegen vorrübergehenden Tests von Office365 (Bei MS, nicht bei OVH), gab es eine Postfachregel, welche alle eingehenden Mails zu meinem Office365 Postfach weiterleitete. Dabei wurde meine Monitoring Mail ausgehend als Spam bewertet und nach der _ZWEITEN_ ausgehenden Mail mit fälschlicher Spam-Deklaration wurde mein Postfach für den Versand von E-Mails gesperrt. Was darauf folgte, war die Krönung meiner gesamten OVH Erfahrung und führte dazu, dass ich mein Postfach schnellstmöglich von OVH weggezogen habe. Ein Abriss:
Die AGB Rücktrittklausel
Unter https://www.ovh.de/support/agb/Besondere_Vertragsbedingungen_Hosted_Exchange.pdf sind die Erweiterungen der AGB speziell für die Hosted Exchange Produkte zu finden. Das Dokument ist mit 5 von 5 Seiten ausgewiesen und der letzte Absatz am Ende von Seite 5 endet mit einem unvollständigen Satz. Als Kunde mit erwartbaren Deutsch-Kenntnissen muss ich davon ausgehen, dass der Text unvollständig ist und mir somit nicht alle Informationen zur Verfügung stehen. Damit ist die Rücktrittsklausel als unvollständig anzusehen und in der Form nicht anwendbar.
Update - 13.01.2016:
Irgendwann zwischen 08.01.2016 und jetzt (13.01.2016) wurde die veröffentlichte Ergänzung der AGB für Hosted Exchange Produkte korrigiert. Die Rücktrittklausel ist nun vollständig. Datum des Dokuments ist nach wie vor der 28. Oktober 2015.
Im OVH Ticketsystem ändert sich das Update-Datum des Tickets hin und wieder. Ich vermute Ticketsystem interne Kommentare, Ticket anderen Personen zugewiesen, oder was man sonst so mit Tickets veranstalten könnte.
Eine Antwort mir gegenüber gab es bislang nicht. Aber sind ja auch erst 5 Tage vergangen.
Update - 31.01.2016:
Die OVH API für PST Exports des Postfachs
Diese API war das Killerkriterium, weshalb ich zu OVH gegangen bin: Automatisierbare Offsite-Backups des Postfaches.
Die API selbst ist gut dokumentiert, aber die Authentifizierung ist in meinen Augen unnötig komplex implementiert. Da man sich mit sowas nicht jeden Tag rumärgern muss, sondern im Normalfall nur einmal, ist das zu vernachlässigen.
Für den PST Export sind mehrere API Requests notwendig. Wer sich mit der Administration von Exchange Servern via Powershell ein wenig auskennt, wird viele Schritte wiedererkennen. Die API macht also im wesentlichen nichts weiter, als die einzelnen PowerShell-Befehle als API Requests nach vorn durch zu reichen:
Bevor ich anfing, meinen Hosted Exchange Account "produktiv" (privat) zu nutzen, habe ich dieses Backup Script gebaut und gegen ein leeres Postfach getestet. Aboslut leer, keine einzige Mail oder Änderung darin.
Der Export wuchs mit jedem Script-Lauf um rund 250KB und ich habe OVH darauf hingewiesen:
Upgrade auf Exchange 2016
Auf der Website wurde im Dezember 2015 beworben, dass Exchange 2016 bald kommt. Da im Dezember für mich auch die Verlängerung des Vertrages anstand, eröffnete ich ein Ticket mit Frage, wann Exchange 2016 zu erwarten ist und ob es eine Migration seitens OVH geben wird.
Das es eine automatische Migration geben wird, muss schon am 18.12.2015 bekannt gewesen sein, wenn man es bis zum 07.01.2016 bereits fertig implementiert hat. Wann genau das Feature dem Kunden zur Verfügung gestellt wurde, kann ich nicht sagen, irgendwann in diesem Zeitraum. Offizielle Nachricht gab es nicht darüber.
Für Planung und Implementierung so eines Features in Unternehmen der Größenordnung OVH gehen schon ein paar Tage drauf. Das geschieht nicht mal eben so in paar Stunden.
Das dabei nun das rauskommt, hat im wesentlichen 2 mögliche Ursachen:
Die Alternative
Da das OVH Exchange Produkt alles andere als frustfrei war, habe ich mich entschlossen Office365 Exchange Online zu testen. Mit MwSt ist das Produkt ca. 0,70 Euro teurer als bei OVH. Vorsicht bei den Preisangaben: Das Angebot von Microsoft richtet sich vorrangig an Gewerbetreibende. Die Preise auf der Website enthalten keine MwSt.
Ich habe meinen Account dort deutlich als Privat kenntlich gemacht (Unternehmensname "Privat") und hatte einige Fragen per Ticket an den Microsoft Support gestellt, im wesentlichen ging es um unterschiedliche Test-Szenarios und ganz konkrete Funktionen, weil aus der Produktbeschreibung nicht genau hervor ging, in welchen Produkten nun einzelne Features tatsächlich enthalten sind. Marketingüblich werden nur Feature-Gruppen beschrieben. Nach weniger als 12 Stunden rief mich ich eine freundliche Support-Dame von Microsoft an und beantwortete mir alle meine Fragen fachgerecht und ausführlich. Einige ganz spezielle Automatisierungsgeschichten, welche so nicht Teil des Produktes sind, sollte ich bitte im Community-Forum von Microsoft stellen.
Auch im Community-Forum erhielt ich in weniger als 24 Stunden eine hilfreiche Antwort direkt von Microsoft.
Die administrativen Möglichkeiten sind bei MS Exchange Online deutlich umfassender, als was OVH anbietet. Stabil und der Support ist grandios. Mein automatisiertes Backup habe ich hinten angestellt. Nach der Erfahrung wie oben, ist es mir lieber, eine Terminserie im Kalender für das Backup zu haben.
Fazit
Von einem Hoster dieser Größe wie OVH erwartet man schon etwas mehr. Schaut man sich die Beschwerden im OVH eigenen Kundenforum an, wird deutlich, dass ich kein Einzelfall bin. Das hat Persistenz über Jahre und das gesamte Produktportfolio hinweg. Wie man an den obigen Beispielen sieht, bedeutet Support eben nicht nur dummen Kunden zu helfen, sondern auch Fehler des Hosters zu beseitigen. Wenn das derartige Reaktionen und Verzögerungen mit sich bringt, ist das für den ernsthaften Einsatz einfach unbrauchbar.
Wer allerdings getrost längere Zeit auf sein Postfach verzichten kann, keinen Wert auf Datenkonsistenz legt und mehr Geduld hat, als die Vertragslaufzeit vorsieht, kann gefahrlos zugreifen.
Ich bin selbst in der Hosting-Branche als Admin tätig und kenne die Hintergedanken, beim Bau von Produkten in unterschiedlichen Preissegmenten. Das ich mich für OVH und nicht meinen Arbeitgeber entschieden habe, ist 2 Gründen geschuldet
- Ich will meine privaten Mails abseits des unbeaufsichtigten Zugriffes meines Arbeitgebers. (Bei Shared-Plattformen immer ein Problem)
- OVH hat eine Backupmöglichkeit via API. Dazu später mehr.
3,50 Euro pro Monat sind für einen Hosted Exchange ein sehr ordentlicher Dumping-Preis. Der großteil der Konkurenz liegt beim 3 bis 5-fachen für vergleichbare Produktspezifikationen. Ich bin diesen Vertrag ohne irgendwelche Kulanz-Erwartungen eingegangen und war zuvor bereits über die schlechte Supportqualität als auch Reaktionsgeschwindigkeiten informiert. Wozu brauch man schließlich Support bei einem Hosted Exchange, wenn man mit Exchange und Outlook selbst bestens umgehen kann? Auch dazu später mehr.
Testzeitraum:
Von Dezember 2014 bis Januar 2016
Der Kernbestandteil - Microsoft Exchange 2013
Wie zu erwarten war, hat OVH dort ein klassisches Exchange Cluster stehen. Auf die Features davon hat OVH keinen direkten Einfluss und die Software macht genau das was man erwartet: Mails, Kalender, Kontakte, Aufgaben und Notizen verwalten.
Alle Besonderheiten die man hier feststellt, sind Microsoft und nicht OVH anzulasten und finden sich entsprechend bei jedem Exchange Cluster. Daher gehe ich hier nicht weiter darauf ein. Aus Sicht zwischen Hosting-Kunde und Hoster: alles okay.
Die Erreichbarkeit
Im Testzeitraum konnte ich kenne andauernden Ausfälle feststellen. Laut Info-Mail von OVH soll es am 09.12.2015 größere Probleme gegeben haben. Die Mail führte auch sehr detailiert auf, welche Maßnahmen sie in wann ergriffen haben und wie erfolgreich diese waren. Für mich als Admin war das recht amüsant zu lesen, weil man parallelen zur eigenen Arbeit zieht. Bei technisch-unversierte Kunden könnte dies aber unbehagen auslösen, weil es ein Bild von Hilflosigkeit deutet, wenn man nicht aus eigenen Kenntnissen heraus die Notwendigkeiten zwischen den ganzen Misslungenen Maßnahmen sieht. Aus fachlicher Sicht ist OVH bei dem Ausfall aber kein Vorwurf zu machen, alle Maßnahmen sind nachvollziehbar.
Im Nachgang wurde den Kunden eine Gutschrift für Neubestellungenen weiterer Hosted Exchange Postfächer angeboten. Kann man nicht meckern. Wer interesse an dieser Mail hat, möge sich einfach melden. Das würde sonst den hier eh schon längeren Beitrag völlig sprengen.
Aber:
Von einem Netcologne-Anschluss (Cable/DOCSIS/Multikabel) waren immer wieder Verbindungsunterbrechungen zum OVH Exchange zu verzeichnen. Dank einem Bug im MS Outlook führt dies zum Einfrieren des Outlooks, weil die Anwendung mit der nicht mehr existenten TCP Session nicht zurecht kommt. Dieses Phänomen trat bei meinen Tests ausschließlich zwischen Netcologne und OVH auf. Es gab keine Probleme aus dem Netz von PlusServer zu OVH und keine Probleme von Netcologne zu Exchange Servern von Microsoft (Office365) und PlusServer.
Beim sniffen ist aufgefallen, dass nach erfolgreichem Verbindungsaufbau und Bestand der Verbindung über mehrere Stunden plötzlich TCP-RST anstatt ACK Pakete zurückkamen. Die Verbindungen bestanden teils nur wenige Minuten, manchmal mehrere Stunden.
Ich habe das Problem zwischen Netcologne und OVH nicht an den OVH Support geleitet. Weil ich genau weiß, dass sie bei solchen spezifischen Problemen ebenso wenig machen können, wie ich. Die Ursachenforschung ist für OVH bei einem Produkt in diesem Preissegement nicht lohnenswert. Insbesondere wenn sich am Ende rausstellen könnte, dass Netcologne und nicht OVH schuld ist.
Der Spam-Filter
Beworben wird das gute Stück einfach nur mit "Anti-Spam". Das OVH hier eine ganz eigene Definition von "Anti" hat, überraschte mich dann doch gewaltig.
Eingehend hat man die Wahl ob man seine Mails direkt ohne Spam-"Filter" an den Exchange zustellen möchte oder via alternativen MX Record über den von OVH eingekauften Spamfilter "Vade-Retro". OVH weist in der Hilfe explizit darauf hin, dass sie dabei keine Mails löschen - soweit so gut - allerdings nehmen sie auch jeden Schrott an. Über den Einsatz von DNSBLs kann man sich streiten und das man Mails nur abweist, wenn die einliefernde IP auf mehreren Blacklisten steht, ist schon seit jahren gelebte Best-Practice. Aber bei der Config die OVH auf dem Vade-Retro "Filter" fährt, werden weder dynamische Dialin IPs noch IPs gefiltert, welche auf den 15 größten und verbreitesten Blacklists stehen. Die Mails werden stumpf angennommen und als Spam getaggt.
Sorry OVH, aber das ist weder ein Spam-Filter, noch irgendein "Anti"-Spam Feature. Das ist schlicht und ergreifend ein automatischer Spam-Tagger. Mehr aber auch nicht. Was tatsächlich dann mit den Mails passieren soll, muss jeder Postfachnutzer für sich selbst individuell mit Postfachregeln nachbauen. Weil sich damit ja auch so wahnsinnig gut Spam-Scorings bewerten lassen ...
Ich habe mir deswegen ein eigenes Postfix-Setup davor gebaut und den MX Record darauf gesetzt. Mit einfachen Tests auf RFC-Konformität und ein paar DNSBLs habe ich 99% des Spams direkt abgelehnt ohne auch nur ansatzweise tiefer in die Mail hinein schauen zu müssen. Danach ging es direkt zum OVH Exchange ohne Umweg über Vade-Retro.
Bei ausgehenden Mails setzt OVH dann tatsächlich auf die gemeinübliche Definition von "Anti": Eine von meinem Monitoring generierte Mail, welche im gesamten Testzeitraum um die 20-30 Mal aufgetreten sein dürfte, wurde an mein Exchange Postfach bei OVH zugestellt. Wegen vorrübergehenden Tests von Office365 (Bei MS, nicht bei OVH), gab es eine Postfachregel, welche alle eingehenden Mails zu meinem Office365 Postfach weiterleitete. Dabei wurde meine Monitoring Mail ausgehend als Spam bewertet und nach der _ZWEITEN_ ausgehenden Mail mit fälschlicher Spam-Deklaration wurde mein Postfach für den Versand von E-Mails gesperrt. Was darauf folgte, war die Krönung meiner gesamten OVH Erfahrung und führte dazu, dass ich mein Postfach schnellstmöglich von OVH weggezogen habe. Ein Abriss:
- 04.01.2016 01:10 Uhr - Automatische Info-Mail über Account Sperrung und Erstellung eines geschlossenen Support-Tickets mit gleichem Inhalt - Ich sollte unteranderem folgende Frage beantworten: Haben Sie eine Weiterleitungsregel auf eine andere E-Mail-Adresse?
- 04.01.2016 20:03 Uhr - Wiedereröffnung des Support-Tickets durch mich, mit Hinweis darauf, dass deren Automatismus sich die Frage ob eine Weiterleitungsregel existiert, selbst beantworten könnte, denn die kann man Exchange-Serverseitig einfach via Powershell auslesen. Ich gab einen weiteren Hinweis darauf, dass der Spamfilter mangelhaft ist und es sich hier nicht um Spam handelt und es eine bewusst gesetzte Weiterleitungsregel war
- 05.01.2016 19:30 Uhr - Bisher keine Reaktion von OVH - Ich habe angerufen. Der Supporter erzählte mir das er für Tickets nicht zuständig sei, er es aber gerade mal raussucht und an die passenden Kollegen weiter gibt. Warum sich um solche Fälle niemand priorisiert drum kümmert, konnte er mir nicht beantworten. Ich habe die Weiterleitungsregel an diesem Abend aus eigener Initiative entfernt, weil mein Test von Office365 abgeschlossen war.
- 06.01.2016 11:12 Uhr - Reaktion von OVH im Ticket, sie können mein Postfach nicht entsperren, solang die Weiterleitungsregel existiert. Ich solle sie bitte entfernen. Ernsthaft? Wenn OVH diesen Fakt prüfen würde, dann hätten sie längst gesehen, das die Regel bereits entfernt wurde. Wenn sie es sowieso nicht prüfen, brauch ich sie auch nicht entfernen sondern es nur behaupten. (Ticket wurde geschlossen)
- <Pause, weil ich die Antwort von OVH nicht bemerkt habe. Es gab keine Mail-Benachrichtigung>
- 08.01.2016 22:22 Uhr - Wiedereröffnung des Support-Tickets durch mich, mit Hinweis darauf, dass ihr Automatismus in dieser Form weder Teil der Produktbeschreibung, noch der AGB ist und sich von mir nicht konfigurieren lässt. Der vermeintliche Spam ist keiner. Ich beuge mich nicht den Fehlimplementierungen seitens OVH. Ich verzichte bewusst auf den Hinweis, dass die Weiterleitungsregel bereits entfernt wurde. Ich ergänze, dass die Rücktrittklausel in den AGB unvollständig ist, ich sie damit als nichtig betrachte und fordere auf meinem Rücktritt von der Vertragsverlängerung zuzustimmen.
Die AGB Rücktrittklausel
Unter https://www.ovh.de/support/agb/Besondere_Vertragsbedingungen_Hosted_Exchange.pdf sind die Erweiterungen der AGB speziell für die Hosted Exchange Produkte zu finden. Das Dokument ist mit 5 von 5 Seiten ausgewiesen und der letzte Absatz am Ende von Seite 5 endet mit einem unvollständigen Satz. Als Kunde mit erwartbaren Deutsch-Kenntnissen muss ich davon ausgehen, dass der Text unvollständig ist und mir somit nicht alle Informationen zur Verfügung stehen. Damit ist die Rücktrittsklausel als unvollständig anzusehen und in der Form nicht anwendbar.
Update - 13.01.2016:
Irgendwann zwischen 08.01.2016 und jetzt (13.01.2016) wurde die veröffentlichte Ergänzung der AGB für Hosted Exchange Produkte korrigiert. Die Rücktrittklausel ist nun vollständig. Datum des Dokuments ist nach wie vor der 28. Oktober 2015.
Im OVH Ticketsystem ändert sich das Update-Datum des Tickets hin und wieder. Ich vermute Ticketsystem interne Kommentare, Ticket anderen Personen zugewiesen, oder was man sonst so mit Tickets veranstalten könnte.
Eine Antwort mir gegenüber gab es bislang nicht. Aber sind ja auch erst 5 Tage vergangen.
Update - 31.01.2016:
- 22.01.2016 Abends - Anruf durch mich, um nachzufragen, wie es mit meinem Rücktritt ausschaut - Antwort von OVH: Der Fall liegt beim Abteilungsleiter, der Supporter will ihn nochmal darauf hinweisen, damit der Abteilungsleiter sich bei mir meldet.
- 25.01.2016 12:23 Uhr - Antwort vom normalen Supporter, das er es an die zuständigen Kollegen weiterleitet und sich nochmal meldet.
- 31.01.2016 12:40 Uhr - Ticket wurde durch OVH geschlossen. Antwort gab es keine mehr. Bearbeitet ist der Rücktritt selbstverständlich auch nicht.
- 31.01.2016 15:10 Uhr - Wiederöffnung des Tickets durch mich und Hinweis auf diesen Thread hier.
Die OVH API für PST Exports des Postfachs
Diese API war das Killerkriterium, weshalb ich zu OVH gegangen bin: Automatisierbare Offsite-Backups des Postfaches.
Die API selbst ist gut dokumentiert, aber die Authentifizierung ist in meinen Augen unnötig komplex implementiert. Da man sich mit sowas nicht jeden Tag rumärgern muss, sondern im Normalfall nur einmal, ist das zu vernachlässigen.
Für den PST Export sind mehrere API Requests notwendig. Wer sich mit der Administration von Exchange Servern via Powershell ein wenig auskennt, wird viele Schritte wiedererkennen. Die API macht also im wesentlichen nichts weiter, als die einzelnen PowerShell-Befehle als API Requests nach vorn durch zu reichen:
- Export Task für Exchange (Exchange Powershell Aktion)
- Download-URL generieren (OVH kopiert die PST Datei vom Exchange Server in ihre eigene File-Cloud. Dort ist sie mit einer Random-URL für ein kurzes Zeitfenster (24 Stunden wenn ich mich recht entsinne) ohne weitere Authentifizierung abrufbar)
- (PST Datei herunterladen - nicht für API relevant)
- Löschen des Export Tasks für Exchange (Exchange Powershell Aktion) - Löscht nur den Job im Exchange, nicht den PST-Export auf der Platte
- Methode zum prüfen ob noch ein Export Task besteht (da ich das Script regelmäßig ausführe, nutze ich dies, um den Exchange nicht unnötig voll zu müllen)
Bevor ich anfing, meinen Hosted Exchange Account "produktiv" (privat) zu nutzen, habe ich dieses Backup Script gebaut und gegen ein leeres Postfach getestet. Aboslut leer, keine einzige Mail oder Änderung darin.
Der Export wuchs mit jedem Script-Lauf um rund 250KB und ich habe OVH darauf hingewiesen:
- 29.12.2014 - Ticketerstellung mit ausführlicher Beschreibung, was ich mit meinem Backup-Script mache (deutlich detailierter, als hier) und welche Folgen dies hat
- 31.12.2014 - Support informiert, dass ich zum Debuggen den Backup-Intervall für das leere Postfach auf 2 Stunden gesenkt habe und ihnen die Liste an PST-Dateien und ihrer anwachsenden Größe mitgeschickt.
- 06.01.2015 - OVH Support hat es an Exchange Admins weitergeleitet, 2 Stunden später: Nachfrage ob sich auch die Größe des Postfaches im OWA verändert, es folgt an dem Tag weiteres Debugging-Info-Sammeln ohne größere Bedeutung
- 07.01.2015 - Ich weise OVH darauf hin, dass die Exports seit letzter Nacht nicht mehr anwachsen und nun mit jedem export eine gleichbleibende Größe behalten (die mit mehren Megabyte für ein leeres Postfach aber immernoch viel zu viel war) - OVH Antwortet am gleichen Tag, dass die Kollegen noch dran seien.
- 08.01.2015 - Keine Ticketinteraktion - Backups wachsen wieder an
- 13.01.2015 - Keine Ticketinteraktion - Backups sind von 55MB auf 1MB geschrumpft
- 14.01.2015 - Nachfrage von mir, wie der aktuelle Stand sei - OVH antwortet, sie seien noch dran
- 19.01.2015 - OVH meldet sich, Anpassung der API steht auf der ToDo, mein 2-Stunden Intervall sei aber viel zu kurz, sie würden maximal täglich supporten, weil die Last für den Exchange zu groß würde. - Ich habe den Intervall für das immernoch leere Postfach auf täglich gesetzt und bemängelt, dass immernoch nicht erklärt wurde, warum der Export überhaupt anwächst. Ich habe ebenfalls ausgeführt, dass ich eigene Tests an separaten Exchange Servern mit der Export Funktion durchgeführt habe und dies offenbar kein Bug im Exchange ist, sondern vermutlich durch OVH verschuldet wird.
- 29.01.2015 - OVH gesteht eigenen Fehler ein, kann aber keinen Zeitrahmen zur Behebung nennen.
- <Das Ticket ruhte eine ganze Weile und ich hatte zwischenzeitlich angefangen gehabt den Account produktiv zu nutzen.>
- 17.07.2015 - Ich wollte in dem alten Ticket nachfragen, aber das Ticket war geschlossen und lies sich von mir nicht wieder öffnen. Ich eröffnete ein neues Ticket und verwies auf das alte. Zusätzlich wies ich darauf hin, dass der Export Mails beinhaltete die im Postfach längst gelöscht waren und über die Retention Period der Recoverable Items weit hinaus gingen. Was eine logische Erklärung wäre, dass der Export anwächst, wenn sie immer nur anfügen, anstatt sauber neu zu exportieren.
- 28.07.2015 - Das neue Ticket wurde Kommentarlos geschlossen
- 31.07.2015 - Erneutes Ticket mit Bezug auf die 2 vorherigen
- August 2015 - Alle bisherigen Tickets sind vollständig verschwunden. Von meiner Seite gibt es nur noch Screenshots aller Tickets. Im OVH Manager sind sie nicht mehr einsehbar.
- 04.01.2016 - erneute Nachfrage, wie es mit dem Problem aussieht
- 08.01.2016 - Ticket von mir geschlossen - Ich habs satt und will weg von OVH.
Upgrade auf Exchange 2016
Auf der Website wurde im Dezember 2015 beworben, dass Exchange 2016 bald kommt. Da im Dezember für mich auch die Verlängerung des Vertrages anstand, eröffnete ich ein Ticket mit Frage, wann Exchange 2016 zu erwarten ist und ob es eine Migration seitens OVH geben wird.
- 14.12.2015 - Erstellung des Tickets
- 18.12.2015 - Antwort von OVH, dass Exchange 2016 bereits bestellbar ist. Es aber keine Automatische Migration auf Exchange 2016 für Bestandsverträge gibt. Man solle also Neubestellen und selbst migrieren.
- 21.12.2015 - Ich traue dem Braten nicht und verlängere meinen alten Vertrag
- 07.01.2016 - Entdecke ich im OVH Manager, dass es eine automatische Migration der Bestandsverträge gibt
Das es eine automatische Migration geben wird, muss schon am 18.12.2015 bekannt gewesen sein, wenn man es bis zum 07.01.2016 bereits fertig implementiert hat. Wann genau das Feature dem Kunden zur Verfügung gestellt wurde, kann ich nicht sagen, irgendwann in diesem Zeitraum. Offizielle Nachricht gab es nicht darüber.
Für Planung und Implementierung so eines Features in Unternehmen der Größenordnung OVH gehen schon ein paar Tage drauf. Das geschieht nicht mal eben so in paar Stunden.
Das dabei nun das rauskommt, hat im wesentlichen 2 mögliche Ursachen:
- Unternehmensinterne Kommuniktion ist mangelhaft - Supporter antwortet nach aktuellem Wissensstand, der aber nicht mehr der aktuellen Unternehmensplanung entspricht
- Umsatzsteigerung, weil der Kunde ja für Zeitraum X 2 Accounts gleichzeitig benötigt. Anrechnung der Vertragsmonate war natürlich nicht möglich. Da die Preise zwischen monatlicher und jährlicher Abrechnung sehr drastisch von einander abweichen, werden vermutlich die meisten die jährliche Variante wählen.
Die Alternative
Da das OVH Exchange Produkt alles andere als frustfrei war, habe ich mich entschlossen Office365 Exchange Online zu testen. Mit MwSt ist das Produkt ca. 0,70 Euro teurer als bei OVH. Vorsicht bei den Preisangaben: Das Angebot von Microsoft richtet sich vorrangig an Gewerbetreibende. Die Preise auf der Website enthalten keine MwSt.
Ich habe meinen Account dort deutlich als Privat kenntlich gemacht (Unternehmensname "Privat") und hatte einige Fragen per Ticket an den Microsoft Support gestellt, im wesentlichen ging es um unterschiedliche Test-Szenarios und ganz konkrete Funktionen, weil aus der Produktbeschreibung nicht genau hervor ging, in welchen Produkten nun einzelne Features tatsächlich enthalten sind. Marketingüblich werden nur Feature-Gruppen beschrieben. Nach weniger als 12 Stunden rief mich ich eine freundliche Support-Dame von Microsoft an und beantwortete mir alle meine Fragen fachgerecht und ausführlich. Einige ganz spezielle Automatisierungsgeschichten, welche so nicht Teil des Produktes sind, sollte ich bitte im Community-Forum von Microsoft stellen.
Auch im Community-Forum erhielt ich in weniger als 24 Stunden eine hilfreiche Antwort direkt von Microsoft.
Die administrativen Möglichkeiten sind bei MS Exchange Online deutlich umfassender, als was OVH anbietet. Stabil und der Support ist grandios. Mein automatisiertes Backup habe ich hinten angestellt. Nach der Erfahrung wie oben, ist es mir lieber, eine Terminserie im Kalender für das Backup zu haben.
Fazit
Von einem Hoster dieser Größe wie OVH erwartet man schon etwas mehr. Schaut man sich die Beschwerden im OVH eigenen Kundenforum an, wird deutlich, dass ich kein Einzelfall bin. Das hat Persistenz über Jahre und das gesamte Produktportfolio hinweg. Wie man an den obigen Beispielen sieht, bedeutet Support eben nicht nur dummen Kunden zu helfen, sondern auch Fehler des Hosters zu beseitigen. Wenn das derartige Reaktionen und Verzögerungen mit sich bringt, ist das für den ernsthaften Einsatz einfach unbrauchbar.
Wer allerdings getrost längere Zeit auf sein Postfach verzichten kann, keinen Wert auf Datenkonsistenz legt und mehr Geduld hat, als die Vertragslaufzeit vorsieht, kann gefahrlos zugreifen.
Last edited by a moderator:
