Erzungener Tarifwechsel 64-Bit Webhosting

[000100101]

Ich habe am Montag ein Ticket (9821304, 09.05.2022 11:28) eröffnet, mit Bitte um Umstellung meines von Ihrer Seite zum 14.05.2022 gekündigten VS BS in den MH 64 Basic und Übertragung der in meinem Account verbliebenen beiden Domänen in den neuen Tarif. Für den Fall, dass die Umstellung von Ihrer Seite aus nicht vor dem 14.05.2022 erfolgen kann, habe ich darum gebeten, den VS BS bis zur Umstellung weiterzubetreiben. Ich habe dazu bisher keinerlei Rückmeldung erhalten. Das Ticket steht auf "in Bearbeitung". Heute ist Donnerstag und das Wochenende naht. Am Samstag läuft der VS BS aus. Ich bitte um Rückmeldung!

[Nils Dornblut]

Das von mir Geschriebene steht nicht im Widerspruch zur Leistungsbeschreibung des Tarifs oder dazu "dass Inklusiv-Domains im Tarif enthalten sind".

Doch schon, da die Inklusiv-Domains im Tarif enthalten sind und nur in diesem einkalkuliert sind. Wird der Tarif gewechselt, werden die Domains direkt berechnet, weil sie eben nicht mehr Teil des Tarifs sind. Wenn zum Zeitpunkt des Wechsels noch im Voraus bezahlte Leistungen offen sind, werden diese anteilig erstattet und enden damit. Auch die im Tarif eingerechneten Domainkosten werden anteilig erstattet und die Leistung endet damit. Auch durch die angesprochenen 0-Euro-Rechnungen bleiben die Inklusiv-Domains dem Tarif untergeordnet und es entsteht nicht ein wie auch immer gearteter zusätzlicher Anspruch. Es gilt die entsprechende Leistungsbeschreibung, wo diese eindeutig als Tarifleistung ausgezeichnet sind. Anders wäre es auch zu kalkulieren.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Ich habe am Montag ein Ticket (9821304, 09.05.2022 11:28) eröffnet, mit Bitte um Umstellung meines von Ihrer Seite zum 14.05.2022 gekündigten VS BS in den MH 64 Basic und Übertragung der in meinem Account verbliebenen beiden Domänen in den neuen Tarif. Für den Fall, dass die Umstellung von Ihrer Seite aus nicht vor dem 14.05.2022 erfolgen kann, habe ich darum gebeten, den VS BS bis zur Umstellung weiterzubetreiben. Ich habe dazu bisher keinerlei Rückmeldung erhalten. Das Ticket steht auf "in Bearbeitung". Heute ist Donnerstag und das Wochenende naht. Am Samstag läuft der VS BS aus. Ich bitte um Rückmeldung!

Leider konnte Ihnen erst heute geantwortet werden. Wir haben Ihrem Wunsch vom 14.05.2022 entsprochen. Tut uns leid, wenn das sich entsprechend verzögerte.

Mit freundlichen Grüßen

Nils Dornblut

[000100101]

Leider konnte Ihnen erst heute geantwortet werden. Wir haben Ihrem Wunsch vom 14.05.2022 entsprochen. Tut uns leid, wenn das sich entsprechend verzögerte.

Ich gebe meinen Wunsch vom 14.05.2022 zur Information der hier mitlesenden Personen auch gerne hier wieder:

Da ich über die gesamte Woche hinweg und nun über den Kündigungstermin des VS BS hinaus in dieser Sache nichts von Ihnen gehört habe, widerrufe ich hiermit die Bitte um Tarifumstellung.

Hintergrund:

Nach mühsamstem und sich unnötig und elendig hinziehendem Schriftverkehr mit ihrem technisch in weiten Teilen völlig inkompetenten Kundensupport (siehe vorangegangen Beiträge bezügl. Details), konnte ich letztlich festhalten, dass ein Wechsel in den DomainManager mit zugebuchtem E-Mail-Addon für mich keine funktionierende Alternative zur Umstellung in den MH 64 Basic darstellen würde.

Daraufhin habe ich am Montag, dem 09.05.2022 ein Ticket mit Bitte um Umstellung meines von Ihrer Seite zum 14.05.2022 gekündigten VS BS auf den MH 64 Basic und Transfer der verbliebenen beiden Domänen in den neuen Tarif eröffnet.

Dieses Ticktet wurde seitens DF am 09.05.2022 bearbeitet (Status auf "in Bearbeitung" gesetzt). Darüberhinaus war über die gesamte Woche und das Wochenende im dem Ticket keine Bearbeitung ersichtlich.

Am Donnerstag, dem 12.05.2022, habe ich im Forum darauf hingewiesen, dass ich bisher keine Rückmeldung diesbezüglich erhalten habe, mit Hinweis auf die Dringlichkeit des Anliegens und Bitte um ein Update. Keine Reaktion.

Am Freitag, dem 13.05.2022, um 11:38 Uhr, kontaktierte ich den DF-Support bezüglich des Tickets telefonisch:

Supportmitarbeiter X erklärt, er könne mir hinsichtlich des Bearbeitungsstandes keine Auskünfte erteilen, die über ein "Ticket ist in Bearbeitung" hinausreichen. Er legt großen Wert darauf, mir mitzuteilen, das Ticket sei nicht am Montag bearbeitet worden sondern vielmehr erst jetzt am Wochenende in Bearbeitung gegangen sei, als sei das eine gute Neuigkeit. Ich erkläre, dass ich dem nicht widersprechen möchte, das aber in der Form im Ticketsystem als Kunde nicht nachvollziehen kann und hier nur eine Bearbeitung am Monat um 17:09 Uhr sehen kann, und so oder so heute eine verlässliche Auskunft zum Bearbeitungsstatus benötige, mit der ich arbeiten kann.
Mitarbeiter X schlägt vor, ich solle die (seitens DF ausgesprochene) Kündigung zurücknehmen. Das entsprechende Formular könne ich in meinem Kundeninterface generieren. Ich melde erhebliche Zweifel an der Möglichkeit an, meinerseits eine seitens DF ausgesprochene Kündigung zurücknehmen zu können, und weise zusätzlich darauf hin, dass ich auch nicht damit rechne, dass ein entsprechendes am Freitag Mittag eingereichtes Formular rechtzeitig bearbeitet würde.
Der Mitarbeiter erklärt mit Hinblick auf die von mir am Montag, dem 09.05.2022, beauftragte Tarifumstellung weiter, es sei ja noch nicht einmal 12 Uhr und ich mögen dem bearbeitenden Team doch erst mal etwas Zeit gewähren. Ich erwidere, dass ich dies bereits eine Woche lange getan hätte und am Freitag Mittag vor einer zu erwartenden Abschaltung des VS BS am Samstag nicht einfach die Hände falten und in den Schoß legen könne, ohne eine brauchbare Information dazu, ob der Tarif heute noch umgestellt werde, alternativ der VS BS vorerst weiter aufrecht erhalten werden könne; alternativ die Domänen kurzfristig in den DomainManager verlagert werden könnten, um sie notfallmäßig per DNS auf einen externen Hoster umzuleiten; oder ich die Domänen notfallmäßig wegportieren müsse. Supportmitarbeiter X wiederholt nur, dass das Ticket gerade erst in Bearbeitung gegangen sei und er mir sonst keine Auskunft erteilen könne. Ich bitte darum, mich mit einem für die Umstellung zuständigen Mitarbeiter zu verbinden, um zu einer sinnvollen Auskunft zu kommen. Dies wird verweigert. Ich bitte darum, mit der Geschäftsführung zu sprechen, um zu einer sinnvollen Auskunft zu kommen. Auch das wird verweigert. Ich könne der Geschäftsführung eine E-Mail schreiben.

Nach dem Telefonat bestätigte sich meine Vermutung, dass ich die von DF ausgesprochene Kündigung im Kundeninterface nicht zurücknehmen und kein entsprechendes Formular generieren kann. Ein am Freitag nach dem Telefonat eröffnetes Beschwerdeticket mit Schilderung der Situation und Bitte um eine sinnvolle Auskunft sowie Eilvermerk im Betreff bleibt am Freitag ebenso wie über den Rest des Wochenendes unbeantwortet.

Am Freitag, dem 13.05.2022, um 15:12 Uhr, kontaktierte ich erneut telefonisch den DF-Support mit Bitte um ein Statusupdate:

Supportmitarbeiter Y ist deutlich freundlicher und hilfsbereiter als Mitarbeiter X, kann im Endeffekt aber auch keine Auskunft über ein "Ticket ist in Bearbeitung" hinaus geben oder mit der Fachabteilung verbinden. Das Ticket sei von jemandem mit einem deutlich höheren Gehaltslevel als dem seinigen übernommen worden, mehr könne er nicht einsehen und sagen. Er gibt an, zumindest einige interne Eilvermerke zu setzen und zeigt zumindest Verständnis für das Problem. Auf die kurzfristige Notlösung einer Übertragung der beiden Domänen in den DomainManager angesprochen, erklärt Mitarbeiter Y überraschenderweise, eine solche werde bei den beiden zum Transfer gekündigten Domänen zu keinem Zeitpunkt möglich sein. Diese könnten ausschließlich wegtransferiert werden. Ich melde Zweifel an der Richtigkeit dieser Auskunft an, der Mitarbeiter besteht jedoch darauf, diese Domänen könnten auf keinen Fall in den DomainManager verlagert werden.

Am Freitag, dem 13.05.2022, um 21:48 Uhr kontaktierte ich letztmalig telefonisch den DF-Supuport mit neuerlicher Bitte um ein Statusupdate:

Erneut spreche ich mit Mitarbeiter Y, der keine neuen Informationen hat. Ich habe zwischenzeitlich einen DomainManager in meinem Kundenkonto angelegt und spreche erneut einen Transfer der Domänen in diesen an. Wiederum betont der Mitarbeiter, ein solcher sei ausgeschlossen. Ich erkläre nochmals, dass ich mir nicht vorstellen kann, dass v.a. die bis 01/2023 bezahlte und erst zu diesem Termin von Ihrer Seite zum Transfer gekündigte .at-Domäne in meinem Kundenkonto nicht in den DomainManager verlegbar sein soll. Der Mitarbeiter scheint sich nun nicht mehr ganz so sicher zu sein, betont aber, eine solche Verlegung käme zumindest vor Anfang nächster Woche nicht mehr in Frage.

Ich habe daraufhin am Abend des 13.09.2022 beide Domänen gezwungenermaßen notfallmäßig von DF wegportiert, um einen größeren Ausfall über das Wochenende zu verhindern.

Dieses Vorgehen Ihrerseits ist meiner Auffassung nach entweder Ausdruck eines völlig letztklassigen und inkompetenten Supports oder Ausdruck eines malignen Verhaltens.

Nachdem ich den Aussagen von Mitarbeiter Y Glauben schenken musste, dass DF mir eine Verwaltung der bis 01/2023 bezahlten .at-Domäne über den DomainManager verweigert, gehe ich davon aus, dass die anteiligen Registrierungsgebühren für den Zeitraum 06/2022-01/2023 in Höhe von 15,92EUR unverzüglich auf mein hinterlegtes Bankkonto zurückerstattet werden. Dies inbesondere auch vor dem Hintergrund ihrer bizarren Argumentationen zu Neuberechnungen von Domänen durch DF im Rahmen von Tarifwechseln.

Mehr möchte ich dazu gar nicht mehr sagen. Sicher werden Sie, Herr Dornblut, hier aber noch betonen, warum das alles in dieser Form ganz normal gelaufen und völlig in Ordnung sei und unmöglich hätte besser gemacht werden können, und auch nirgendwo sonst in der Branche besser gelöst worden wäre; falls irgendwo im Detail aber etwas völlig Unwichtiges doch nicht ganz perfekt gelaufen sein sollte, möge der Kunden doch bitte Verständnis zeigen, und es sei ja eigentlich auch alles nur der Kunde schuld. Das kennt man als langjähriger DF-Kunden ja schon.

[wecotec]

Bewundernswert wie viel Zeit du in die Sache steckst (ich hätte es, allein schon aus Prinzip aber vermutlich auch getan). Zieh deine Konsequenzen und mach für dich die Baustelle DF zu. Ist besser fürs Nervenkostüm :-)

Ich habe heute auch einmal kurz durchgeatmet als ich eine nicht ganz so nette Antwort vom Support bekam als ich drauf hinwies dass es im Bestellprozess für .com-Domains 2 verschiedene Preise gibt. Es sind auch nur Menschen am anderen Ende der Leitung.

[Nils Dornblut]

Mehr möchte ich dazu gar nicht mehr sagen. Sicher werden Sie, Herr Dornblut, hier aber noch betonen, warum das alles in dieser Form ganz normal gelaufen und völlig in Ordnung sei und unmöglich hätte besser gemacht werden können, und auch nirgendwo sonst in der Branche besser gelöst worden wäre; falls irgendwo im Detail aber etwas völlig Unwichtiges doch nicht ganz perfekt gelaufen sein sollte, möge der Kunden doch bitte Verständnis zeigen, und es sei ja eigentlich auch alles nur der Kunde schuld. Das kennt man als langjähriger DF-Kunden ja schon.

Ich möchte das eigentlich gar nicht auseinander nehmen und einzeln kommentieren. Es tut mir leid, dass Sie in dem Fall mit uns anscheinend keine guten Erfahrungen gemacht haben! In jedem Fall viel Erfolg für die Zukunft.

Allen Mitlesern sei angeboten, dass wir gerne auch weiterhin nach der jeweils besten Lösung schauen möchten und Sie sich gerne an die Kollegen im Support aber auch im Beschwerdemanagement wenden können. Leider dauern manchen Lösungen auch mal etwas länger, wir geben uns aber große Mühe den Ansprüchen gerecht zu werden

Mit freundlichen Grüßen

Nils Dornblut

[sovok]

Jetzt trifft es mich auch?

Bei der ersten mail habe ich geantwortet, dass ich nicht von perl auf php umstellen kann, da das Monate an Arbeit ist.

Jetzt kam die zweite mail, dass die Umstellung trotzdem stattfindet.

Kann man das noch verzögern bis perl auf der neuen Plattform zur Verfügung steht?

[Nils Dornblut]

Jetzt trifft es mich auch?

Bei der ersten mail habe ich geantwortet, dass ich nicht von perl auf php umstellen kann, da das Monate an Arbeit ist.

Jetzt kam die zweite mail, dass die Umstellung trotzdem stattfindet.

Kann man das noch verzögern bis perl auf der neuen Plattform zur Verfügung steht?

Zu individuellen Aufträgen können wir hier leider nichts sagen. Gerne schauen wir uns das an, wenn Sie uns eine Anfrage über das Kundenmenü senden. Was für Perl-Skripte setzen Sie denn ein? Sind das eigene Skripte?

Mit freundlichen Grüßen

Nils Dornblut

[sovok]

Ok, habe es doch noch einigermaßen geschafft das perl forum auf ein php forum zu portieren. (Ikonboard -> phpbb2)

Mal gucken was die Umstellung sonst noch so verursacht 😅

[Nils Dornblut]

Ok, habe es doch noch einigermaßen geschafft das perl forum auf ein php forum zu portieren. (Ikonboard -> phpbb2)

Mal gucken was die Umstellung sonst noch so verursacht 😅

Danke für den Bericht. Forensoftware ist denke ich ein gutes Beispiel, wo eine Migration möglich ist aufgrund der Verbreitung und entsprechender Assistenzskripten.

Besondere Überraschungen wird es denke ich nicht geben, wage ich mal zu orakeln.

Mit freundlichen Grüßen

Nils Dornblut

[sovok]

Scheint soweit alles funktioniert zu haben, nur alte perl scripte werden jetzt jedem besucher raw angezeigt, das heißt jeder könnte dortige passwörter lesen. Scheint mir eine relevante Sicherheitslücke zu sein. Lösche ich mal lieber.

[sovok]

Noch zwei weitere Dinge:

default-charset von iso-8859-1 ging verloren bei der Umstellung, bzw php.inis gib es jetzt gar nicht mehr.
cronjobs laufen jetzt parallel wenn sie auf die selbe Zeit gesetzt wurde und nicht mehr nacheinander.

[sovok]

php scripte werden gecached und man muss Ctrl+F5 drücken um die aktualisierten Daten zu sehen. Aber das könnte schon vorher kaputt gewesen sein. Ich musste jetzt überall:

header('Cache-Control: no-cache, no-store, max-age=0, must-revalidate');
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT'); // Date in the past
header('Pragma: no-cache'); 

einfügen.

und header charset ist utf8, also musste ich überall:

header('Content-Type: text/html; charset=iso-8859-1'); 

einfügen

edit: das war doch nix da dann die texte aus der Datenbank kaputt sind, also muss man jede php datei mit Notepad++ "Convert to utf-8" machen.