Getagged : Windows

Hinter dir, ein dreiköpfiger Affe

Good news everyone! Ich war bisher immer der Meinung, dass man erst die Klassiker der Computerspiele-Geschichte spielen sollte, um eine Aussage über die Qualität heutiger Spiele treffen zu könne. Ausreden gab es viele, warum man die Klassiker nicht spielen “konnte”: laufen kaum auf heutigen PCs oder sind graphisch “grottenschlecht” (neee, das denke ich persönlich nicht). Jetzt ziehen diese Ausreden aber nicht mehr, denn TADAAA:

Monkey Island wird es im Sommer als Special Edition geben. Das Spiel wurde Windows-tauglich gemacht und zudem massiv aufpoliert, nebst Sprachausgabe und zeitgemäßen gezeichneten neuen Grafiken. Und da die Engine die gleiche ist, ist auch das Spiel im Kern zum Original aus dem Jahre 1990 identisch. Und mit das Beste an der Neuauflage ist die Möglichkeit zur Laufzeit zwischen Retro- und Neuansicht umzuschalten. Genial! Ich freu mich – wieder etwas für die Sammlung

RTFM

sbs-2k8-ram.jpg Derzeit testen wir in der Firma unterschiedliche Serverbetriebssysteme und Serveranwendungen aus, da die Infrastruktur bei uns erneuert werden soll. Zusätzlich muss man in diesem Gewerbe auf der Höhe der Zeit bleiben und seine Hände an neuen Hard- wie auch Softwaretechnologien legen – man möchte ja auch den bestmöglichen Support seinen Kunden zu Gute kommen lassen.

Dass bei jeder Aktion auch immer RTFM (Read The Fucking Manual) gilt, sollte bekannt sein. Dass man selbst das mitunter nicht beachtet ebenso – zum Leidwesen der eigenen Zeit. Heute zum Beispiel lief eine knappe Stunde lang die Installation eines SBS 2008 Standard (Small Business Server 2008) auf einer Testmaschine, nur um im Moment der Euphorie über das baldige Ende der Installation der angegebene Screenshot gezeigt wird.

Installation ergo nicht möglich, da die Testmaschine “nur” 2GB RAM zur Verfügung hat und kein passender RAM mit ECC zur Verfügung steht und ebenso nur für diesen Fall speziell für die Testmaschine nicht extra angeschafft wird. Ich sagte ja schon immer, dass mehr RAM stets zu bevorzugen ist, aber dass für solch ein Produkt gleich 4GB Pflicht sind, ist schon etwas … nja, bescheiden!

Dennoch hätte man die Stunde einsparen können, wenn schon während oder vor der Installation darauf hingewiesen worden wäre, dass zu wenig RAM in der Kiste steckt. Microsoft signalisiert ja sonst auch jeden Pups unter Windows.

Naja, was solls .. die Moral von der Geschicht – vergiß niemals nie das RTFM nicht!

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 …

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.

 

Auflösung: Langsamer Datei-Transfer

Was hab ich mich gestern nicht geärgert, als mehrfach, auf Grund des Reparaturvorganges, welcher im Übrigen erfolgreich verlaufen ist, der Exchange Store hin- und herkopiert wurde und dieser Kopiervorgang jeglichen Wert von Zeit und Raum sprengte. Mich ließ dieses “Problem” nicht sonderlich gut schlafen, vor allem weil mich das doch innerlich ziemlich gewurmt hatte und ich versuchte heute herauszufinden, ob der Server anfängt in die digitalen Abgründe zu wandern, oder aber noch viel schlimmer – ob das Ganze normal ist.

Im Zuge dessen habe ich als Erstes das Ganze Verhalten an unseren eigenen Servern nachgespielt. Dazu nahm ich eine Systemsicherung in Größe von 19GB und kopierte diese auf unterschiedliche Ziele – auf ein UNC-Pfad, USB-Platte und ein physikalisch getrenntes Plattensystem. Bei all diesen Vorgängen konnte ich eines beobachten: nach 2GB übertragenen Daten sauste die Transferrate massiv in den Keller, um wenige Sekunden später wieder auf fast volle Leistung zu steigen. Das Erscheinungsbild war also ähnlich, nur nicht mit derart langen “Blockaden”, wie beim Servereinsatz gestern.

Selbst auf dem Kundenserver habe ich das Ganze heute noch einmal laufen lassen. Nein, nicht den Reparaturprozess – ich bin doch nicht verrückt. Zur Verwunderung verliefen diese “Blockaden” relativ kurz. Es schien nahezu ähnlich schnell (schnell ist hier dehnbar), wie bei unserem Firmenserver. Was passiert hier also? Weiter lesen …