Getagged : Arbeit

in Arbeit, Kurioses

Unmöglich? Doch möglich …

KabelSo etwas habe ich in meiner langjährigen Berufszeit noch nicht erlebt. Ein Kollege hatte bei einem Kunden heute Netzwerkkabel, welche von einer Kabeltrommel des Elektrikers bereits vorverlegt war, fertig gemacht und aufgelegt. Beim letzten Kabel bekam er aber keine Verbindung mittels seiner Testgeräte. Erst das “Gute” zeigte auf, dass es bei dem 18m langen Kabel ein Problem nach 16m,  bzw. 2m, wenn man von der anderen Seite heran geht, auftauchte.

Er stellte einen massiven Knick in der Isolierung fest und öffnete diese. Gummi-Isolierung und äußerer Flechtschirm waren intakt, aber die einzelnen Adern darunter waren der Hammer, denn diese waren anscheinen während der Produktion mal gerissen und mittels kleinen roten Isoierbändern miteinander verknüppert worden. Danach kam der Flechtschirm und die Isolierung drüber, welche sich durchgehend bei der besagten Kabeltrommel auf 1km Länge erstreckte. Ergo existierte dieser Fehler bereits während der Produktion des Kabels.

Das so etwas überhaupt verkauft wird? Zum Glück gibt es Firmen und Leute, die ihre Arbeit noch testen …

 

in Arbeit, Hard & Software, Netz

Dozententätigkeit

Meine “damalige” Dozententätigkeit war bei den Verantwortlichen und den Teilnehmern gut angekommen. Auf Grund dessen ist der Auftraggeber auf mich zu gekommen, um mich zu bitten, den gleichen Kurs erneut zu halten. Das Thema, wie beim letzten Mal – Netzwerke.

So etwas lasse ich mir nicht zweimal sagen – ab morgen geht’s erneut los. Da kann ich mich wieder thematisch 5 Tage lang frei entfalten. Eine neue Truppe und somit eine neue Erfahrung! Ich bin gespannt, was die Tage mit sich bringen … 

in Hard & Software, Hilfe, PC

Tipp und Lösung: XP Feature? Dateinamen werden nicht angezeigt …

xp-feature-03.jpg Das folgende “Problem” hatte ich noch nie, aber ich konnte es dennoch aufspüren und lösen. Ein Kunde rief an und monierte den Windows Explorer unter XP, der ihm keinerlei Dateinamen in der Miniatur- bzw. Filmstreifenansicht in einigen Ordnern mit Bildern darstellte. Das sich dieses Verhalten ebenso in anderweitigen Auswahldialogen von Programmen durchzieht, ist ihm die Arbeit damit unmöglich geworden. Ich dachte erst, dass er irgendwie seine Ansichtsoptionen im Explorer verstellt hätte – dies war aber nicht der Grund, da ein Ausblenden des Dateinamens nicht möglich ist.

xp-feature-02.jpg Die Lösung ist denkbar einfach: man lasse sich den Explorer-Baum anzeigen und klicke auf einen völlig anderen Ordner, als den, der das “Problem” mit der Anzeige hat (hier Beispielbilder). Im Beispiel bin ich einfach auf den Ordner Beispielmusik gewechselt.

xp-feature-01.jpg Nun halte man die SHIFT-Taste gedrückt und klickt im Explorer-Baum auf den Ordner, der das “Problem” hat (Beispielbilder), mit Linksklick. Danach ist die Anzeige der Dateinamen wieder gewährleistet. Will man dieses wieder rückgängig machen (wieso auch immer), wechselt man wieder zu einem anderen Ordner und klickt dann erneut SHIFT-Linksklick auf den Bilderordner. Danach ist die Anzeige der Dateinamen wieder verschwunden.

Wenn das ein Feature sein soll, dann ist es ein eher problemaufwerfendes Feature. Zugegeben trat es bisher nur einmal auf – aber dennoch war es für den Kunden ein Problem und nicht eine Sonderfunktion. Man sieht ja an Windows 7, wieviele Features eingebaut werden, die keiner braucht, der ein stabiles System haben möchte. und auch keiner kennt. Wie sagt man so schön: It’s not a bug, it’s a feature …

in Arbeit, Hard & Software, Hilfe, Kurioses, PC

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.

 

in Arbeit, Hard & Software, Hilfe, PC

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.

in Arbeit, Hard & Software, Hilfe, Netz, PC

Genaue Fehlerbeschreibung

Zum Glück hatte ich heute nichts Wichtiges vorgenommen, denn ansonsten hätte der Kunde !heute! alt ausgesehen. Um 19.00 Uhr bimmelt mein Telefon, während wir uns gemütlich eine Folge Babylon 5 ansehen. Ein Angestellter des Hotels lässt verlauten, dass ein Rechner, der mitunter wichtig ist (wie alle Rechner), ständig die Netzwerkverbindung trennt und wieder aktiviert und somit ein Arbeiten im Netz, sprich mit über das Netz laufende Betriebsanwendungen, nicht möglich ist. Somit sind die Buchungen, Bestellungen, Reservierungen usw. – sprich der gesamte Hotelablauf nicht möglich.

Auf meine Frage, ob es nur diesen Rechner betrifft, erhalte ich ein definitives “JA”. Das schränkte für mich das Problemfeld auf den Rechner ein – ergo Kabel oder Netzwerkkarte. Ich rückte also von zu Hause in die Firma raus, um Netzwerkkarten und Werkzeug zu holen und hottete dann zum Kunden. Dort angekommen wollte ich gerade mich ans Werk machen, begutachtete schon das Problem (welches sich ohne Vorführeffekt auch mal zeige), als ich noch einmal sicherheitshalber nachfragte, ob das Problem wirklich nur an diesem Rechner auftritt.

Natürlich erhielt ich dann die Aussage, dass sich das Problem auch auf andere Rechner ausgeweitet hätte. Dieses Problembild ist natürlich vollkommen anders und schließt als Erstes ein Problem mit einer Netzwerkkarte eines Rechners aus – Murphy schlägt nicht ohne Weiteres so schlimm zu. Es ging daraufhin in den Keller, denn mir schwante schon Übles. Ich begutachtete die Switche eine Weile und an einem Port fiel mir auf, dass dieser alle paar Minuten komplett dunkel wurde, bis er darauf wieder mit voller Last kommunizierte. Wenige Augenblicke später war die LED des Ports wieder aus und so weiter und so fort.

Ich verfolgte das Kabel, welches auch prompt ins Nirvana verschwand. Die Kabeldokumentation war schlichtweg nicht existent und ich hatte schon den Switch in Verdacht. Ich spielte das Ganze gedanklich, als auch verbal durch und der Angestellte meinte darauf hin, dass oben unter dem Tisch nachträglich auch so ein Switch angeschlossen wurde.

Also wieder hoch und quer durch das Hotel gestiefelt und den “neuen” Switch dort unter die Lupe genommen und siehe da: dieser meinte alle paar Minuten einen Reset durchzuführen, welcher dazu führte, dass die Rechner ihre Verbindung zum Netzwerk verlierten. Klasse Sache! Er war übermäßig heiß und das Problembild und die Begleiterscheinungen passten wie die Faust aufs Auge.

Auf ins Auto, zurück in die Firma und einen passenden Switch gesucht und in Windeseile wieder zurück, angeschlossen und alles funktioniert wieder. Fertig war ich dort kurz vor 22.00 Uhr. Die Hin- und Herfahrten und das “falsche” Suchen des Problems forderten ihre Zeit. Aber wäre die später zugetragene Info, dass alle Rechner in einem Bereich davon betroffen sind, früher gekommen, hätte ich schon vorher einen passenden Switch mitgebracht. Das hätte knappe 50 Minuten Zeit einsparen können. Interessant war dann zu erfahren, dass sie schon knappe 2 Wochen das Problem hatten. Nur kristallisierte sich es in Form von Programmaussetzern, temporären Datenfehlern oder allgemeinen Problemen bei Netzwerkzugriffen.

In diesem Sinne – ein schönes und “arbeitsfreies” Wochenende!