Vista x86_64 fehlerfrei?

Laut Microsoft ist das Betriebssystem ja inzwischen ausgereift. Warum passieren dann aber immernoch seltsame Dinge?

Eben gerade habe ich meinen Browser minimiert, und anstelle des Dream Scene Wasserfalls war ein sehr sehr kleiner Desktop oben links zu sehen. Der rest des Bildschirms war Grau. Die Taskleiste wurde komischerweise richtig angezeigt. Aber schaut es euch selbst an. So sollte das normalerweise nicht sein. Was mich wundert, ich habe nicht einmal ein Spiel oder andere 3D Programme gestartet. Die Umschaltung zwischen 3D und GDI/Aero hat mir schon bei meinem letztem Versuch mit Vista vor etwa einem Jahr immer wieder Probleme gemacht.

Das zweite Problem das mich sehr oft stört, ist die falsche Farbdarstellung in der Windows Fotogalerie. Unter XP konnte die Bild und Faxanzeige alle Bilder/Fotos usw. problemlos anzeigen. Unter Vista werden mir die Farben extrem verzerrt. Komischerweise sind an den Bildern keine ICC Profile angehängt oder komische Farbräume. Ja selbst einfach Bitmap´s wie dieser Screenprint werden verzerrt. Öffnet man die gleiche Datei in einem anderem Program, sieht alles normal aus. In einer testweise installierten Vista x86_32 Edition sieht die selbe Datei normal aus. Ist das etwa der gewollte WOW-Effekt?

Nachtrag:

Das Farbproblem bekommt man in den Griff, indem man das standard sRGB-Farbprofil für alle Monitore hinterlegt. Sobald man den PC neustartet, sollten die Farben richtig dargestellt werden.

DNS-Problem öffentlich … und nun?

Ja, gute Frage. Das neuste Cache-Poisoning Problem könnte die Records im Cache eines DNS-Servers innerhalb weniger Sekunden umbiegen. Soweit bekannt, haben die meisten Provider, Domainhoster und größere Firmen ihre Systeme bereits gefixt um Angriffe deutlich zu erschwehren. Aber was ist mit den ganzen kleineren Serverbetreibern deren DNS-Zonen auf die Bind9.1.x Server von 2005 Delegiert wurden? ich schätze mal, das 30% dieser Systeme definitiv angreifbar sind. Was passiert, wenn einer dieser Server zb. von einer Gemeinde oder einem Onlineshop betrieben wird? Tickende Zeitbombe. Wurde der DNS-Cache manipuliert, könnte der FQDN sales.domain.tld direkt auf einen Phishing-server zeigen ohne das der Nutzer irgendetwas merkt. Oder wer startet schon für jede IP die er währen einer Browsersession auflöst einen traceroute um herauszufinden wo der eigentliche Server steht? So genau kann man das aber auch nicht sehen. Manche Firmen haben ja zb. dateitausch.firma.tld auf die eigenen Server umgeleitet. Ich kann nur jedem, der in irgend einer Weise DNS nutzt raten, die Patches für sein Betriebssystem schnellstmöglich einzuspielen. Früher oder später wird es sicher prominente Fälle von Cache-Poisoning mithilfe dieser Technik geben.

Details findet ihr hier:
http://www.isc.org/sw/bind/docs/Vulnerability_Discussion.pdf

Datensicherung mit BackupExec 12 – Fehlerhafte Funktionen, massive Probleme und schlechter Support

Das Produkt enthält ziemlich viele Features, allerdings, so kommt es mir zumindest vor, enthält jedes Feature mindestens 2 Fehler die zum Abbruch der Sicherung führen können. So stellt man bereits bei der Installation fest, das BE12 anscheinend NetBIOS over TCP/IP benötigt, was eigentlich in den meisten größeren Netzwerken nicht mehr verwendet wird. Zumindest meldet der Umgebungstest bereits eine Warnung, sollte NetBIOS over TCP/IP auf dem Server deaktiviert sein. Ebenfalls schon im Vorfeld meldet die Prüfung, das die Firewall des Servers doch bitte deaktiviert werden solle. Ist die Vorabprüfung überstanden, beginnt die eigentliche Installation. Setup fragt nach einem Account mit Administrativen Rechten auf dem Lokalem Server, unter dem die BE12 Dienste ausgeführt werden sollen. Eine Option zur Verwendung des Kontos „lokaler Dienst“ oder „Netzwerkdienst“ ist nicht vorgesehen. Erstellt man vorher einen dezidierten Backup-User, so muss dieser ebenfalls über Administratorrechte auf dem Server verfügen. Hat man zähneknirschend einen passenden Benutzer angegeben, fragt Setup im nächstem Schritt nach einem passendem Datenbankserver. Gibt man nun einen bestehenden SQL-Server (Microsoft SQL-Server 2005) im Netzwerk an, erscheint eine Meldung, das die Instanz des SQL-Servers unter dem Backup-Exec Benutzer ausgeführt werden muss um fortzufahren. Bestätigt man diese Meldung mit Ja, ändert Setup die Anmeldeinformationen des SQL-Server Dienstes auf den BE12 Benutzer OHNE vorher zu prüfen, ob nicht noch andere Datenbanken auf dem Server laufen. Dies hat zur folge, wenn der BE Benutzer nicht auch auf dem SQL-Server über Admin-Rechte verfügt, der Dienst aufgrund fehlender Berechtigungen im Datenbankordner nicht mehr startet. Entweder konfiguriert man nach der Installation den SQL-Server wieder „richtig“, oder man muss zähneknirschend eine lokale SQL-Instanz auf dem BackupExec Server installieren. Letzteres ist übrigens auch die Empfehlung des Herstellers. Hat man es bis hier her geschafft, fragt BE12 ob man S*mantec-Treiber für Alle Geräte, Geräte ohne Treiber oder gar keine Geräte verwenden möchte. Gibt man hier an, man möchte die Treiber nur für Geräte, die über noch keine Treiber verfügen, verwenden, kommt es mit Geräten, die die Windows-eigenen Treiber verwenden zu Problemen. So hat BE12 eine HP MSL6000 und das LTO-Laufwerk einzeln erkannt (beim versuch zu Sichern sollte man doch bitte ein Medium in das LTO Laufwerk einlegen, beim versuch auf der Library zu sichern, erscheint die Meldung „Es stehen keine nicht aktiven Geräte zur Verfügung“. Am besten gleich die Symantec-eigenen Treiber verwenden, und die Library sollte korrekt erkannt werden. Nach Abschluss der Installation startet das System neu und LiveUpdate versucht die aktuellen Updates herunterzuladen. Das herunterladen war auch nicht das Problem, die Installation scheiterte allerdings. Nach mehreren Neustarts und diversen Versuchen wurden die Updates manuell auf der Website heruntergeladen und installiert. LiveUpdate funktionierte auch nach einspielen der Updates nicht (scheiterte nach wie vor an der Installation).

Nach der Installation des Servers muss ein Anmeldekonto für Sicherungen an Remotesystemen festgelegt werden. Normaerweise sollten die Rechte eines „Sicherungs-Operators“ ja ausreichen um Daten von Servern sichern zu können. Anschließend sollten die Agents auf dem zu sichernden Systemen installiert werden. Der Assistent lief problemlos durch und installierte den Agent. Anschließend war der Server allerdings mit einem gelben Ausrufezeichen in der Auswahl zu sehen, und es konnten nur Freigaben gesichert werden. Nach einigen Recherchen in der Support-Datenbank, musste auf dem zu sicherndem Server in den Eigenschaften des Agents der Medienserver eingetragen werden. Eigentlich sollte das die Push-Installation ja erledigen, was aber auf unbekannten Gründen fehlschlug. Nun sollte eine Testsicherung des Servers durchgeführt werden. Bei dem Server handelte es sich um einen virtualisierten (ESX-Server) ActiveDirectory Domänencontroller (Windows Server 2003 R2 SP2) mit aktuellen Hotfixes (stand 04/2008). Die Auswahl ist sehr übersichtlich und einfach gehalten. Die Testsicherung sollte den SystemState und die lokalen Festplatten sowie einen DFS Replizierten Ordner sichern. Also, den vollständigen Server (der Server selbst war teil des Test-Netzes). Also, das Häkchen auf den vollständigen Server in der Quellauswahl gesetzt, unter Optionen noch den Typ kopieren ausgewählt und als Ziel die Library angegeben. Ausführung Sofort und los geht’s. Die Sicherung startete, die Library wurde korrekt angesprochen und ein neues Medium in den Default-Pool „unbegrenzt aufbewahren“ aufgenommen, formatiert und in das Laufwerk eingelegt. Anschließend startete der kopiervorgang der lokalen Festplatten. Als der kopiervorgang fertig war, und BE12 unter verwendung von Schattenkopien den Systemstatus sichern sollte, brach die Sicherung allerdings mit dem Fehler „Verbindung zu Quellhost verloren“ ab. Sicherung fehlgeschlagen. Der quellhost war nun auch nicht mehr in der Sicherungsauswahl zu sehen. Ein blick auf das Eventlog des Quellservers zeigte eine unerfreuliche Meldung von DrWatson, das der Agent mit einem internem Fehler abgestürzt sei.

Es wurden mehrere Versuche gestartet (auch auf anderen Servern), das Problem in den griff zu bekommen, doch leider half nichts. Auch nicht die erneute Installation des BE12 Servers oder des darunterliegenden Betriebssystems. Immer der gleiche Fehler. Im Moment sind wir im engen Kontakt mit dem Symantec Email-Support, bisher sollten wir aber nur protokolle sinnloser Sicherungen, Windows-Eventlogs und andere Daten übermitteln. Eine Problemlösung ist im Moment nicht in Sicht.

Was ich während der Problemlösung auch noch feststellen musste, hat man Backup2Disk Ordner angelegt, und der Speicherplatz auf der Festplatte ist erschöpft, bricht der Sicherungsjob nicht etwa ab, sondern verlangt das einlegen eines neuen Mediums. Bei einer B2D Sicherung könnte man doch mindestens verlangen, das man Limits für die maximale Größe des Ordners angeben kann, das ist aber leider nicht der Fall. BE sichert bis die Platte voll ist und wartet anschließend unendlich lang auf das einlegen eines neuen Datenträgers. Nicht ganz das was ich mir vorgestellt habe.

Mal sehen wie lange es Dauert bis die Sicherung funktioniert. Bis heute sind 8 knapp Wochen vergangen.

Fazit: Im Vergleich zu anderen Sicherungslösungen wie zb. Yosemite Backup oder des Windows-Internen NTBackup kommt mir die Lösung extrem instabil und unausgereift vor. Zusätzlich ist die Software sehr Aggressiv gegenüber anderen Programmen/Datenbanken und sollte immer auf einem Isoliertem Server ausgeführt werden. Was die Systemsicherheit angeht, werden durch das Vorraussetzen von NetBIOS und dem deaktivieren der Firewall massive Sicherheits und Datenschutz-Probleme geschaffen, die eine Software mir einer so langen Entwicklungsgeschichte eigentlich nicht mitbringen sollte. Die nicht funktionierenden LiveUpdates, eigene Treiber und die zusätzliche, lokale Datenbank erhöhen den Wartungsaufwand und das Ausfallrisiko des Medienservers und treiben die Anforderungen an Speicher und CPU unnötig in die höhe. Der etwas unfähige Support und die langen Wartezeiten bei Email-Anfragen ziehen die Problemlösung extrem in die länge.

Hotplug ist nicht immer Hotplug – Entferne niemals ein Netzteil einer MSA30 länger als ein paar Minuten


Was würde man wohl machen, wenn an einem Server ein Hotplug-Netztzeil eines redundanten Paares ausfällt? Ausbauen und auswechseln. Nun, man bei Netzteil defekten nie ganz sicher sein kann, das diese nicht doch noch andere Fehlfunktionen verursachen, am besten gleich ausbauen. Ist ja redundant. Was macht man bei einer MSA30 von HP? Am besten das defekte NT im Slot lassen bis Ersatz eingetroffen ist. Ja warum das denn? Folgendes ist passiert. Das Gerät hängt an einer MSA1500CS und beherbergt 14 SCSI-Festplatten eines R10 Volumes. Es verfügt über 2 Netzteile, die laut Dokumentation für Redundanz sorgen sollen. Nun viel eines der beiden Netzteile aus, wir haben es entfernt und nach exakt 5 Minuten schaltete sich die MSA30 ab die (ebenfalls Redundanten) Controller der MSA1000 in der 1500CS verworfen das logische Volume. Das war natürlich mit einem wunderschönem Crash der Server, die dieses Volume als zuhause für ihre Daten verwendeten. Wiederbeleben konnte man das Array erst, indem man die MSA30 UND die MSA1500 vollständig abschaltete, das defekte Netzteil wieder steckte, einmal an allen kabeln wackelte und zuerst die MSA30 und anschließend die 1500 wieder einschaltete. Alles andere als Hotplug. Darauf hin riefen wir bei HP an und meldeten einen Service-Fall. Es wurde ein Techniker vorbeigeschickt der sagte „Was? Wussten Sie nicht das die Geräte nur 5 Minuten mit einem Netzteil überstehen?“. Auf meine Frage wo man das nachlesen könne, sagte er „Das steht nicht in der Dokumentation, sollte aber eigentlich bekannt sein.“. Ganz toll. Muss man nun noch hellsehen können oder alle bekannten Fehler dieser Geräte auswendig lernen? Sehr seltsam. Das Problem, das die MSA nicht mehr neustartete wurde von ihm mit einem defektem Controller (MSA1000) begründet und dieser auch getauscht.

Experimentierfreudige Admins und andere Probleme

Was gibt es schöneres als am Wochenende die letzten Tips und Tricks in den gängigen Foren, Newsgroups oder sonstwo zu lesen und diese am Montag Morgen in der Firma auszuprobieren? Naklar, diese Tips an Produktivsystemen auszuprobieren.  Oder vieleicht der darauf folgende Totalausfall des Netzwerkes? Nagut, was auch immer. Ließt man manche Beiträge in Foren oder Newsgroups könnte man manchmal denken das es mehr dieser “experimentierfreudigen” Menschen gibt als man denkt. So ließt man zb. sehr oft Beiträge wie “Hilfe – Anmeldung am Netzwerk dauert sehr lange” … nach einigen Rückfragen kommt dann heraus das der “Admin” auf empfehlung eines HowTo von Seite xy die DNS-Server Adressen vom DC auf den DSL-Router des ISP umgeschaltet hat um die letzten 2% aus der Leitung herauszuholen …. naja … ich meine natürlich die Variante ohne DNS-Weiterleitung für die interne Zone ;-) . Ich habe nichts dagegen, wenn jemand die entsprechende Technik noch nicht ganz verstanden hat und es schnell einrichten musste, aber wer blind irgendwas von einer Website abtippt und ein funktionierendes Netzwerk lahmlegt … ohne Worte. Ich meine, Fehler können jedem jederzeit passieren, aber abtippen, ich verstehe einfach nicht wie diese Menschen manchmal Jahre oder Jahrzehnte in der Branche überleben. HowTo’s sind Ansätze, “Wie wird’s gemacht?” um das Thema besser verstehen zu können und KEIN Freischein das es genau so und nicht anders funktioniert. Richtig angewendet, bringen sie jeden schneller an die Lösung eines Problems. Falsch angewendet passieren obengenannte Dinge.

Die andere Seite ist aber, das lesen von Foren oder Newsgroups würde ohne solche Menschen nicht wirklich Spaß machen.