Getagged : Lösung

Tipp: NTFS schreiben unter OS X

Wer wie ich hin und wieder auf NTFS-partitionierte Laufwerke zugreifen muss, hatte unter Mac OS X die Qual der Wahl. Entweder musste ein paralleles Windows-System mittels Bootcamp eingerichtet oder eine Software, welche den Zugriff auf NTFS ermöglicht, käuflich erworben werden oder gar nicht erst mit NTFS anfangen und auf FAT32 umsteigen. Nur hat eben FAT32 einige Probleme bezüglich der maximalen Dateigröße, weswegen es nicht sinnvoll war, an dessen Einsatz überhaupt zu denken. 

Ich bin vor Wochen rein zufällig, da ich Bekannten etwas auf eine NTFS-formatierte Festplatte kopieren sollte, über eine Möglichkeit gestoßen unter Mac OS X auf NTFS-Datenträger zuzugreifen – vorausgesetzt, es handelt sich um USB Datenträger. Die Software der Wahl heißt hier VMWare Fusion. Es ist gut möglich, dass dies auch mit VirtualBox funktioniert – probiert habe ich es aber noch nicht.

Weiter lesen …

Vodafone Dashboard – Wegoptimierer Nr. 1

Ich hatte ja bereits in einem Artikel darüber geschrieben, wie die Vodafone Software in der Lage ist, den Mailabruf bzw. Mailversand zu stören bzw. sogar auszuhebeln. Heute lege ich noch einen drauf – mit meiner Erfahrung vom gestrigen Tage bei einem anderen Kunden.

Das Szenario ist ähnlich, wie im oben verlinkten Artikel – Laptop mit Windows XP und Vodafone Dashboard Software. Dieses Mal ist es aber eine neuere Version gewesen – die 9.3 (wenn ich es recht im Kopf habe) vom Januar 2009. Der Kunde beschwerte sich zurecht, dass er weder mit der Vodafone Software via UMTS-Datenkarte, noch via WLAN, ins Internet käme. Ein angeschlossenes Netzwerkkabel funktionierte aber. Schon seltsam.

Es war zu beobachten, dass nach Aktivieren des WLAN-Moduls dieses keine DHCP Informationen erhielt. Da beim Kunden eine Alternativkonfiguration hinterlegt war, wurde diese stattdessen genutzt. Seltsamerweise aber ohne Bindung des Standard-Gateways. Egal, was ich tat, führte dazu, dass alle Einstellungen bis auf das Standard-Gateway gesetzt wurden. Eine Verbindung via UMTS führte zwar zu einer aufgebauten Verbindung, aber bis auf gesendete Daten passierte nichts. Daten kamen nicht rein – ergo auch kein Surfen möglich.

Das das Phänomen dem mir bekannten ähnelte, startete ich den Installer der Dashsoftware und deinstallierte das Optimierungsmodul. Nachdem dies vollbracht war, wurde automatisch die Verbindung zum WLAN getrennt und kurz darauf wieder aufgebaut: diesmal mit der Konfiguration vom DHCP und auch Internetzugriff war möglich.

Zur Probe installierte ich das Optimierungsmodul wieder und musste den bekannten Dreckeffekt wieder sehen.

Also – Tipp an alle Dashboard-Nutzer: deinstalliert bzw. achtet bei der Installation darauf, dass das Optimierungsmodul nicht mit installiert wird, denn in der neueren Version greift es diesmal sogar auf die WLAN-Konfiguration mit ein. Bestimmt, damit Vodafone, wie die Telekom bisher, den bezahlbaren Zugriff auf bestimmte Hotspots im Auge behalten kann.

Das Optimierungsmodul benutzt irgendwie einen Proxydienst, um Grafiken und anderes Gedöhns in ihrem Größenumfang zu minimieren. Toll, dass es so gut optimiert, dass gar kein mobiles Netzwerk funktioniert – wobei es dennoch in der heutigen Zeit viel sicherer ist, kein Internet zu haben ;-)

Artanis selbst hatte damals genug Probleme mit der tollen Software von Vodafone auf seinem MacBook Pro. Ich denke, selbst sein Abenteuer spricht für sich …

Problem durch die Zukunft

Mich ereilte vor Feierabend heut ein dringender Ruf eines Kunden (ältere Generation). Die Anmeldung an seiner Arbeitsstation, welche sich in einer Domäne befindet, war ihm nicht möglich. Über Fehlermeldungen schwieg der Kunde sich aus, dennoch sollte sich jemand unbedingt jetzt sofort und am besten schon vor 5 Minuten dem Problem annehmen.

Da eh fast Feierabend war (Elternzeit) fuhr ich auf dem Weg nach Hause bei dem Kunden vorbei, startete den Rechner und bekam nach versuchter Anmeldung die Meldung, dass auf Grund unterschiedlicher Zeiten zwischen dem Client und dem Server eine Anmeldung nicht möglich sei.

Ich schaute den Kunden an und fragte, ob er die Systemzeit des Rechners geändert hätte. Wie zu erwarten bekam ich die Antwort: “Selbstverständlich nicht!”. Ich startete den Rechner erneut und begab mich ins BIOS und dort zur Abteilung Datum/Uhrzeit und ich erblickte 18.06.2009!

Ich: “Arbeiten Sie gern in der Zukunft?”
Kunde: “Wieso?”

Ich: “Da die Zeit des Rechners auf in 4 Monaten gesetzt ist …” – speicherte die Konfiguration mit korrektem Datum ab und startete den Rechner neu.

Kunde: “Wie passiert denn das?”
Ich: “Was haben Sie denn beim letzten Mal getan?”

Kunde: “Ich habe Termine koordiniert – dazu klicke ich immer rechts unten auf die Uhrzeit und schaue nach, an welchem Wochentag der Termin stattfindet.”
Ich: “Und dann?”

Kunde: “Wenn der Termin bestätigt wird, trage ich ihn in den Kalender in Outlook und schließe danach das Fenster mit ‘OK’.”
Ich: “….”

Ich: “Und hatten Sie rein zufällig gestern einen Termin vereinbart für den 18.06.2009?” 
Kunde: “Ja, wieso?”

Ich: “Weil Sie damit die Systemzeit des Rechner geändert haben …”
Kunde: “…..”

Ich habe ihm dann noch schnell erklärt, wieso diese Art der Methode nicht sonderlich die Beste ist, um Termine abzustimmen und zeigte ihm, dass er auch ruhig den Kalender in Outlook nutzen könne, um herauszufinden, an welchem Tag welcher Wochentag ist. Zusätzlich bekommt er auch die Information, ob er an diesen Tag bereits Termine hat. Somit würde er auch nicht mehr versehentlich die Uhrzeit und das Datum des Rechners ändern.

Der Kunde war fassungslos – über sein unbedarftes Verhalten. Ich beruhigte ihn, da ja nichts passiert wäre. 

Kunde: “Sie sind aber deswegen extra zu uns gekommen … wegen so einen Fehler meinerseits …”
Ich: “Auch das ist mein Job – und wie Sie sehen, können wir auch einige Probleme durch die Zukunft lösen …” ;-)

Ich: “Übrigens – ich wünsche einen schönen Feierabend und selbstverständlich geht diese Runde aufs Haus – versteht sich von selbst …”

Hintergrund: Ursache des Problems liegt in den unterschiedlichen Datumseinstellungen des Servers und des Client innerhalb einer Domäne. Bei Versuch der Anmeldung des Clients am Server wird ein Kerberos Ticket erzeugt. Dies beinhaltet auch, dass ein Zeitunterschied zwischen beiden Systemen nicht mehr als 5 Minuten (laut Erinnerungsstand) betragen darf. Ist dies dennoch der Fall, dann ist das Ticket ungültig und der Nutzer (auch der Domänenadministrator) kann sich nicht anmelden.

Man kann nun sich als lokaler Admin anmelden und das Datum ändern – man kann aber auch, wenn man Zugriff auf das BIOS hat, das Datum im BIOS ändern. Danach sollte eine Anmeldung an der Domäne funktionieren. Wenn nicht, dann sollte man die Einstellung bezüglich Sommer-/Winterzeit beachten (herausnehmen, bzw. setzen). Mir ist es bisher zweimal untergekommen, dass einer der beiden Parteien (Server bzw. Client) den Haken gesetzt hatte, der andere nicht. Somit bestand trotz augenscheinlich gleicher Zeit und Datum eine einstündige Diskrepanz, welche ergo auch dahingehend führt, dass der Server die Anmeldung des Client verweigert.

 

Der Verdammnis entronnen

Ich gräme mich schon einige Tage damit, dass bestimmte Bouquets des hiesigen Kabel-Betreibers RFT kein Bild mehr lieferten. Laut Anzeige von EyeTV war Signal vorhanden und das auch noch zu 100% Qualität, aber es kam kein Bild, geschweige denn überhaupt Ton. Lediglich die Meldung “Dieser Sender ist zur Zeit nicht verfügbar” wurde mir mittels EyeTV mitgeteilt. Es funktionierten ansonsten alle Frequenzen, außer die, der angeprangerten Sender.

Heute hatte ich den Kanal sprichwörtlich langsam voll, denn die Sender waren immer noch nicht erreichbar, meine Aufnahmeliste schwoll ins Unerdenkliche auf jenen Sendern an und diesen Schwall des Grams, der nicht funktionierenden Aufnahmen und der Gedanken höllischer Natur wollte ich erneut dem Support überhelfen, als ich sicherheitshalber meine beiden DVB-C Empfänger von Digital Everywhere vom Strom nahm. Ebenso trennte ich vom Mac mini die Firewire-Verbindung.

Resultat? Die Sender gehen … mir persönlich nicht begreiflich, wieso 2 Frequenzen nicht gingen, aber die anderen doch .. aber alle Sender funktionieren nun wieder. Irgendeine Logik? Ich denke nicht.

Zumindest ist RFT der Verdammnis entronnen … diesmal!

Ade, AD und DNS! Oder etwa doch nicht?

Wenn es nach der gestrigen intensiven Google-Suche meinerseits geht, ist das gestern aufgetretene (berufliche) Problem bei einem Kunden mehr als selten. Informationen hierzu waren spärlich, wenn nicht sogar armseelig. Anscheinend taucht es niemals auf – obwohl es das tut. Was war passiert? Ich versuch es so ausführlich wie möglich, aber bedenkt – ich mach es aus dem Kopf, da ich die Fehlermeldungen nicht mehr vorliegen habe.

Die genauen Hintergründe sind mir selbst verborgen. Anfangs lag der Verdacht auf ein fehlerhaftes Update eines Antiviren-Programmes, welches ich aber nach erster Recherche beim Kunden vor Ort ausschließen konnte. Nach Start des Servers (hier ein MS 2003 Server Standard), war eine Anmeldung nicht möglich, da ein Fehler im Verzeichnisdienst (Active Directory) aufgetreten ist. Um es mit einfachen Worten zu sagen, die Active Directory Informationen waren im Anus.

Im Verzeichnisdienstwiederherstellungsmodus war es mir nicht möglich die ntds.dit-Datei (welche die AD-Informationen beinhaltet) mit den üblichen Tools, wie ntdsutil oder esentutl zu reparieren. Ich hatte an dieser Stelle fast aufgegeben, da eine aktuelle Sicherung nicht vorhanden war. Der Server pfiff eh schon auf dem letzten Loch und die Datensicherung war genauso zuverlässig und glaubwürdig, wie Backsteine in der Luft schweben können.

Die Betonung lag hier auf “aktuelle” Sicherung. Ich hatte noch Zugriff auf eine Sicherung von 2006. Also relativ zeitnah möchte ich anmerken. Aus dieser holte ich im Modus Verzeichnisdienstwiederherstellung die ntds.dit und überschrieb die Originale (nach händischer Sicherung) im Ordner C:\WINDOWS\NTDS. Die Prüfungsmechanismen mittels ntdsutil verliefen fehlerfrei und ich startete den Server durch. Ich konnte mich daraufhin anmelden aber das nächste Problem folgte – der DNS Server. Es handelte sich um eine AD mit integriertem DNS und die rückgesicherte ntds.dit war einfach viel zu alt, sodass der DNS Server dies nicht akzeptierte. Ich konnte den DNS Server nicht konfigurieren oder eine neue Zone erstellen – beides wurde mit einer Meldung in der Art “konnte nicht in Active Directory (null) schreiben”. Ebenso war es mir nicht möglich, mit den mir verständlichen Mitteln den DNS Server zu deinstallieren und blanko zu installieren. Es schlug jeder Eingriff fehl.

Somit konnten auch die Clients keine Namensauflösung mehr machen, geschweige denn sich an der Domäne anmelden. Intern, wie auch extern war der Zugriff auf DNS-Namen nicht möglich. Ein Glück, dass der Kunde mittels HTTP-Proxy surfte. Zumindest war der Server via \\IP-Adresse erreichbar. Eine Konstellation, die dem Kunden “erst einmal ausreichte”. Ich versprach mich darum zu kümmern, denn völlig mich einer Neuinstallation hingeben lag mir fern. Ich recherchierte gestern über 5 Stunden zu Hause und stieß auf den für mich letzten besaglichen Strohhalm.

Heute beim Kunden angekommen, habe ich das auch gleich umgesetzt, Daumen gedrückt, weggesehen und … es lief! Einzig allein die wenigen Arbeitsstationen musste ich aus der “alten” Domäne austreten und in die “neue” Domäne eintreten lassen und alles funktionierte, wie es sollte. Und für alle die, die ungeduldig warten, was ich getan habe, hier eine “Kurzanleitung” am Hauptserver (DC+DNS).

  1. Deinstallation des DNS-Servers (Systemsteuerung->Software->Windowskomponenten hinzufügen/entfernen)
  2. Löschen (vorher sicherheitshalber sichern) der Dateien netlogon.dns und netlogon.dnb (hier unter C:\WINDOWS\SYSTEM32\CONFIG)
  3. Löschen (vorher sichern) des kompletten Ordners DNS (unter C:\WINDOWS\SYSTEM32)
  4. wenn noch nicht vorhanden, die Support Tools von M$ installieren
  5. CMD starten und folgenden Befehl eingeben (vom Support Tools Installationspfad aus): netdom resetpwd /server:SERVERNAME /userd:SERVERNAME\Administrator /passwordd:*
  6. es wird nun nach dem Kennwort gefragt: hier kann einfach das alte Administratorkennwort eingegeben werden
  7. DNS Server installieren (Systemsteuerung->Software->Windowskomponenten hinzufügen/entfernen)
  8. Sicherstellen, dass die oben entfernten Dateien und Ordner wieder erzeugt wurden
  9. CMD starten und netdiag /fix ausführen
  • Restarbeiten (Aus- & Eintritt der Client-PCs in die Domäne)
  • Feierabend machen

Mindestens durch die alte ntds.dit Datei, wenn nicht durch einen Fehler in der DNS Konfiguration oder anderen Ursachen, wurde das Kerberos-Passwort des Administrators zurückgesetzt. Mittels netdom wird dieses “aufgefrischt” und dann sollten in dieser Hinsicht diese Probleme beseitigt sein.

Hoffe es hilft Einem – dem Kunden für sein Geschäft und mir für das “Wissen” auf jeden Fall.

Lösung: Akku futsch?

Digitalkameras brauchen Strom – ich denke, das steht nicht zur Diskussion. Vermehrt tauchen aber Kameras auf, welche über einen “Spezial-Akku verfügen, und nicht einfach mittels Standard-Akkus beladen werden können.

Um so ärgerlicher ist es, wenn dieser Akku etwas längere Zeit nicht genutzt wurde und dessen Kapazität sich auf ein unteres Minima befindet. Das Spezial-Ladegerät zum Spezial-Akku verweigert auch vorschriftmäßig seinen Dienst: es lädt den Akku nicht, da eine zu geringe Restladung vorhanden ist. Der Akku selbst ist aber nicht kaputt.

Im Speziellen Fall handelt es sich um einen Akku aus dem Hause Casio vom Typ NP-20. Bevor man also in die weite Welt hinausrennt und den Elektronikladen des Vertrauens konsultieren möchte, was meist zur Folge hat, dass man sich für 20 Öcken einen neuen Akku kauft, der möge sich doch einen gut gemeinten Tip zu Gemüte führen und ausprobieren. Vielleicht ist ja damit der Akku – oh Wunder – wiederbelebbar.

Wenn die Kapazität also zu gering ist, dann verhelft doch einfach mittels “Starthilfe” dem Akku zu etwas mehr Ladung. Speziell in diesem Fall habe ich einfach eine 9V Blockbatterie genutzt, die Plus-Pole untereinander und die Minus-Pole untereinander verbunden. Den Kontakt für ca. 30 Sekunden bis 1 Minute so belassen. Danach sollte das Ladegerät auch wieder den Akku zum Aufladen wieder akzeptieren. Sollte das noch nicht reichen, dann ist die 1 Minute weiter zu dehnen. Einfach zwischendurch die Überprüfung im Ladegerät durchführen.

Bei mir hat es funktioniert, das Ladegerät macht seine Arbeit, und ich bin froh doch noch etwas vom Physikunterricht behalten zu haben ;-)