Heute morgen hatte ich das Vergnügen eines Zahnarztbesuches. Im Rahmen der Untersuchung wurden Kiefer und Zähne geröngt; dazu bewegt sich der Apparat einmal um den Kopf herum.
Nun wäre das ja kaum eine Erwähnung wert; aber der Apparat spielte dazu Musik.
Für Elise…
Manche Dinge kann man sich nicht ausdenken.
]]>Gerade (20:30 Uhr) bekam ich einen Anruf von einem Kollegen. Ein Kunde hatte sich angeblich seinen Exchange-Server zerlegt. Ich habe den Kunden dann angerufen und er erzählte mir, dass er aus Platzmangel den Mailbox-Store seines Exchange 2003 Servers verschieben wollte. Das hätte auch soweit für die EDB-Datei geklappt; bei der STM-Datei wäre er aber bei 100% stehen geblieben. Es gäbe weder eine Fehlermeldung noch einen nennenswerten Eintrag im Ereignisprotokoll.
Während ich dann noch einige Parameter abfragte, teilte er mir mit dass im Zielverzeichnis jetzt auch die STM-Datei aufgetaucht wäre. Offensichtlich alles eine Frage der Geduld…
Dummerweise konnte er nun im Quell- und im Zielverzeichnis die Dateien sehen (zumindest meldete sein Outlook wieder eine funktionierende Verbindung).
Einer meiner nächsten Fragen war dann die nach dem Virenscanner. Ja. sie hätten einen Exchange-Virenscanner (ScanMail von TrendMicro). Ich hakte dann direkt nach und fragte ihn, ob auf dem Server auch ein Dateiscanner laufen würde? Und richtig, es lief auch ein TrendMicro OfficeScan. Ich habe ihn dann aufgefordert, diesen doch mal bitte zu beenden und kaum hatte er es getan, wurde der Verschiebevorgang sauber abgeschlossen.
Wie sich herausstellte, hatte er zwar im OfficeScan das Quellverzeichnis ausgeschlossen, aber nicht das Zielverzeichnis…
]]>Ich habe vor Kurzem bei einem Kunden eine Migration von Exchange 2003 auf Exchange 2010 durchgeführt. Die Migration lief relativ problemlos durch, so daß ich das Projekt als abgeschlossen betrachtet habe. Vor einigen Tagen aber bekam ich den Anruf, dass nach der Umstellung der Terminalserver von Windows 2003 als Plattform auf Windows 2008 R2 es zu häufigen Abstürzen beim Start von Outlook 2003 kommt.
Leider war die Fehlermeldung nicht sehr aussagekräftig (der Fehlermodulname variierte), so daß mit ProcMon versucht habe, dem Fehler auf die Spur zu kommen. Zuerst hatten wir den verdacht, daß Überreste einer Scan2EMail-Software die Ursache waren; dieser verdacht bestätigte sich aber nicht. Nach längerer erfolgloser Suche blieb mir als letzte Waffe dann eigentlich nur noch der Einsatz eines Debuggers;w as mir aber auf einem terminalserver irgendwie widerstrebte;-)
Ich habe mir stattdessen noch mal die Fehlermeldun und die Einträge im ereignisprotokoll angeschaut. Eine Eingabe des Fehlercodes c0000005 und des Problemereignisnamens BEX in Google brachte dann die Lösung.
Seit Windows XP SP2 gibt es das Feature DEP (Data Execution Prevention); mit dem bestimmte Speicherbereiche als nicht ausführbar markiert werden. In 64-Bit Betriebssystemen ist das Feature aktiviert und hier wird auch Hardware-seitiges DEP genutzt (NX-Flag gesetzt). Leider scheint Outlook 2003 damit nicht zurecht zu kommen.
Wie sieht nun die Lösung aus?
Outlook 2003 muss auf den Citrix-Servern in die DEP-Ausnahmeliste aufgenommen werden. Dazu wird zuerst über einen Kommandozeilenbefehl der aktuelle Richtlinien-Level geprüft:
wmic OS Get DataExecutionPrevention_SupportPolicy
Es gibt vier Stufen:
Die gewünschte Stufe ist „3 – Optout“.
Falls die aktuelle Stufe einen anderen Wert aufweist, muss der Wert angepasst werden. Dazu nutzt man den folgenden Befehl:
bcdedit.exe /set {current} nx OptOut
Wichtig: der Server muss danach neu gestartet werden.
Danach ruft man den Server-Manager auf. Unter
„Systemeigenschaften ändern“ -> „Erweitert“ -> „Leistung“ -> „Datenausführungsverhinderung“
kann nun Outlook eingetragen werden.
Weitere Informationen:
In dem Artikel wird Outlook über die Registry der Ausnahmeliste hinzugefügt
]]>Der im letzten Artikel erwähnte Kunde hatte nach der Umstellung noch ein weiteres Problem: innerhalb einer Citrix-Sitzung liessen sich bestimmte Dateianhänge nicht öffnen. Der Benutzer bekam die Fehlermeldung „Zugriff verweigert“. Speicherte er den Anhang ab und versucht ihn dann zu öffnen, erhielt er die Fehlermeldung: Auf das angegebene Gerät, bzw. den Pfad oder die Datei kann nicht zugegriffen werden. Sie verfügen eventuell nicht über ausreichende Berechtigungen, um auf das Element zugreifen zu können.
Die Fehlermeldungen traten nur auf, wenn versucht wurde, den Anhang mit der Windows Bild- und Faxanzeige zu öffnen. Wurde der Anhang mit einem anderen Programm geöffnet (z.B. Paint), funktionierte es einwandfrei.
Zugriffsfehler sind ja ein Problemfeld, bei dem das schon erwähnte ProcMon eigentlich gute Dienste leistet. Interessanterweise tauchte aber gar keine ausführbare Datei auf. Ich konnte allerdings ziemlich viele Registryzugriffe sehen, bei denen das mit TIFF verknüpfte Programm gesucht (und eigentlich auch gefunden) wurde. Etwas knifflig wurde es dadurch, dass man im Startmenü gar kein Programm namens „Windows Bild- und Faxanzeige“ findet. Das macht das Filtern nach bestimmten Eigenschaften etwas schwierig;-)
Aber schliesslich fand ich die Lösung. Ich zitiere hier mal den zugehörigen MS-Artikel:
Die Windows Bild- und Faxanzeige ist kein eigenständiges Programm, sondern eine DLL. Diese DLL wird über den COM+-Hostprozess gestartet (DLLHOST.EXE).
Die „Windows Bild- und Faxanzeige“ wird aber auch innerhalb des Explorers genutzt, falls Vorschaubilder zum Einsatz kommen. Auf einem Citrix-Server ist es also nicht ungewöhnlich, dass es schon geöffnet ist.
Gemäß MS-KB 980393 ist dieser Prozess aber so konfiguriert, dass er auf jedem Computer nur einmal gestartet werden kann!
Der Fehler ist unabhängig von Citrix; er tritt auch bei der Verwendung von Remote Desktop sowie bei der Nutzung der schnellen Benutzerumschaltung auf.
Die Lösung:
Microsoft stellt hierfür einen Hotfix zur Verfügung. Dieser Hotfix ist im SP1 für Windows 2008R2 und Windows 7 enthalten. Als Workaround kann auch ein anderes Programm zum Öffnen der Dateien genutzt werden.
]]>Da war ich wohl etwas voreilig: am fehlenden Platz hat es nicht gelegen. Sichere ich nur die Exchange-Datenbank und die Transaktionsprotokolle, dann funktioniert die Sicherung. Nehme ich aber den Systemstate dazu, schlägt die Sicherung fehl obwohl am Ende noch fast 19GB frei sind. Sichere ich nur den Systemstate, läuft die Sicherung ohne Fehler durch. Es scheint also so, dass bei einer Sicherung auf eine lokale Platte (die nicht in die Sicherung eingeschlossen ist) man nicht gleichzeitig Exchange und den Systemstate sichern kann. Leider scheint man über die GUI auch keine zwei getrennten Sicherungsjobs einrichten zu können.
NTBACKUP konnte das; Windows Backup ist also ein klarer Rückschritt.
]]>Windows identifiziert Benutzer, Gruppen und Computer nicht über den Namen, sondern über einen eindeutigen Wert. Dieser Wert ist der sogenannte Security Identifier oder kurz die SID. Da dieser Wert weltweit nicht eindeutig ist sondern von der Windows-Domäne abhängt, in der sich z.B. der Benutzer befindet, stellen Migrationen zwischen Domänen den Berater vor eine interessante Herausforderung. Ich möchte natürlich dass die Anwender von einer Migration möglichst wenig mitbekommen und dass sich der manuell zu erledigende Aufwand in Grenzen hält. Aus diesem Grund ist es ganz praktisch, wenn der Benutzer nach der Migration nicht nur eine neue SID hat, sondern auch noch die alte SID behalten hat. Microsoft unterstützt das mit dem Attribut SID-History.
In neuen Windows-Versionen gibt es aber nun die sogenannte SID-Filterung; hierbei werden (grob gesprochen) die „alten“ SIDs nicht berücksichtigt, wenn der Benutzer auf Ressourcen zugreift (Details erspare ich mir hier).
Stell man aber nun nicht in einem Schritt um, sondern sind User und Ressourcen (wie Fileserver) über einen gewissen Zeitraum über zwei Active Directory Gesamtstrukturen (Forests) verteilt, dann muss man die SID-Filterung abschalten.
Eigentlich ist das ein ganz einfacher Vorgang, den man mit dem Tool netdom erledigen kann.
Bei der Vorbereitung einer Migration bei einem Kunden habe ich also frohgemut den folgenden Befehl eingetippt (Domänennamen angepasst):netdom trust quelle /domain:ziel /quarantine:no
Die Eingabe wurde auch mit „Befehl erfolgreich ausgeführt“ quittiert; nur zeigte die Kontrolle (in der GUI), dass die SID-Filterung immer noch aktiv war.
Eine längere Suche im Internet (was machen wir eigentlich ohne Google?) brachte dann den folgenden Hinweis: wenn man den Befehl auf einem deutschen Windows 2008 Server ausführt, dann muss er wie folgt lauten:
netdom trust quelle /domain:ziel /quarantine:nein
Falls sich jemand der Unterschied nicht sofort erschliesst: die Parameter werden zwar weiterhin in Englisch geschrieben, aber bei „quarantine“ muss es dann „ja“ oder „nein“ heissen.
Mir stellt sich dann nur die Frage: was muss man rauchen, um auf so etwas zu kommen?
]]>Da werden bei uns Leute in Länder abgeschoben, in denen ihnen Tod und Folter droht und es wird lang und breit darüber diskutiert, ob man Leute aufnehmen soll, denen die Amerikaner fünf Jahre lang nichts nachweisen konnten (Guantanamo)
Plötzlich aber überschlagen sich unsere Politiker und dienen sich einem Diktator (sorry, muss heissen: ein autokratisch herrschender Freund des Westens) an, ob er nicht bei uns Unterschlupf finden soll. Einfach nur widerlich
Mir ist auch nicht ganz klar, wie das dem Übergang helfen soll. Entweder tritt er sofort ab oder nach den Wahlen im Herbst. Das erste Szenario wird ja gerne abgelehnt, da dann angeblichd as Chaos (sprich: die Muslimbruderschaft) regiert. Nur was soll dann das Gerede vom „Abgang in Würde“? Soll er dann erst im Herbst (nach den Wahlen) gehen? Dann kann er auch direkt in Ägypten bleiben und sich dann vor Gericht verantworten.
Meine Vermutung: unsere Politiker haben ein paar Leichen im Keller und er hat den Schlüssel;-)
]]>Exchange 2010 setzt, wie auch frühere Versionen, einige installierte Windows-Komponenten voraus. In Exchange 2010 gibt es bei der Installation sogar einen extra Menüpunkt dazu; wählt man diesen an, werden die benötigten Windows-Komponenten mitinstalliert.
Neulich habe ich bei einem Kunden einen Exchange 2010 Server aufgesetzt. Nach der Installation haben wir festgestellt das Outlook Web Access nicht lief. Leider waren die Fehlermeldungen ziemlich nichtssagend. Nachdem ich so ziemlich alles überprüft habe, kontrollierte ich zum Schluss (auch angeregt durch eine Webseite im Internet) die installierten Windows-Komponenten. Und siehe da: RPC-over-HTTP-Proxy war nicht installiert. Ich habe da keinen direkten Zusammenhang egsehen, da wir ja kein Outlook Anywhere gemacht haben. Aber ich habe es dann mal nachinstalliert und danach ging auch OWA. Entweder gibt es also einen Zusammenhang, den ich noch nicht kenne oder die Nachinstallation hat einen Fehler in der IIS-Konfiguration korrigiert.
Die Lehre daraus: alles selber kontrollieren und Automatismen nicht trauen.
PS: Jaja, ich weiss: eigentlich hätte ich wissen müssen dass Automatismen nie richtig funktionieren;-)
]]>In einem aktuellen Projekt haben wir vor dem Problem gestanden dass die vorhandene Sicherungssoftware Exchange 2010 unterstützt. Unglücklicherweise muss der Kunde seine Sicherungssoftware wechseln (mangels Informix 64-Bit Unterstützung) und die neue Software unterstützte auch noch kein Exchange 2010 (mittlerweile schon). Für die Übergangszeit haben wir nun eine Sicherung des Systemstate, des Laufwerks mit den Datenbanken und dem Laufwerk mit den Transaktionsprotokollen über Windows Backup auf ein lokales Laufwerk gemacht. Eine Testsicherung schien auch (laut GUI) funktioniert zu haben.
Vor ein paar Tagen wurde ich nun angerufen: der Exchange-Server steht. Es stellte sich ziemlich schnell heraus, dass die Platte mit den Log-Dateien voll war[1]. Ich erfuhr dann auch, dass das in der Zwischenzeit schon zwei Mal passiert war[2]; ich wurde nur aufgrund eines krankheitsbedingten Ausfalls nicht informiert.
Ein erster Blick auf die Sicherungen (in der GUI) schien zu bestätigen dass alles ok ist. Aber schaute man dann in die Details, schienen nur Dateien aus dem Systemstate gesichert worden zu sein (und auch das nur teilweise). Ein Blick ins Event Log (Event-Id 9782, Quelle MSExchangeIS, Aufgabenkategorie Exchange VSS Writer) zeigte dann, dass die Sicherung nicht sauber abgeschlossen wurde und deshalb die Logdateien nicht aufgeräumt wurden. Da auf dem Sicherungslaufwerk noch über 3GB frei waren (von 30GB), schloss ich fehlenden Platz einfach mal aus. Eine Einzelsicherung mit denselben Parametern wie die tägliche Sicherung zeigte dasselbe Bild: laut GUI alles ok, Event Log zeigt aber Fehler. Ich vermutete dann Probleme mit dem Virenscanner, fand aber keine belastenden Hinweise. Ich habe dann mal den Diagnoseprotokolllevel für das Backup (innerhalb von Exchange) erhöht. Auch auf Level „Hoch“ gab es keine richtig weiterführenden Informationen. Allerdings fand ich unter den Event_Einträgen im Protokoll „Backup“ (Anwendungs- und Dienstprotokolle) die Warnung mit der Event-ID 51 (Quelle Backup). Sie verwies darauf dass am Zielort wenig freier Speicher wäre und weitere Sicherungen eventuell fehlschlagen würden.
Ich habe dann den Systemstate mal aus der Sicherung herausgenommen und erneut eine Einzelsicherung angestossen. Nun sind am Ziel 11GB frei und die Sicherung lief ohne Probleme durch (alle Transaktionsprotokolle wurden bereinigt).
Was lernen wir daraus: vertraue dem System und einer einfachen Addition nicht und lege bei Laufwerken lieber ein paar GB drauf,d a 11% freier Speicherplatz manchmal eben doch zu wenig ist.
[1] Im Gegensatz zu früher (Exchange 5.5) zählt wohl schon „1.5GB freier Speicherplatz“ als „Platte voll“, wie ich schon häufiger beobachten durfte. Und dabei lege ich diese Partition immer schon mit mindestens 8GB aus; auch bei relativ kleinen Kunden
[2] Ein Mal behalf man sich damit, dass man Protokolldateien verschob; die absolue Exchange Totsünde. Ohne Prüfung der Datenbank mit eseutil /mh (welche Protokolldateien werden noch benötigt?) ist das ein klares No-Go.
]]>Der längste Running Gag der Computerspielgeschichte scheint jetzt doch ein Ende zu finden. Wo es bisher auf die Frage „Wann ist es fertig?“ immer ein „Its done when its done“ (ein genialer One-liner) zurück gab, steht nun wirklich ein Releasedatum im Raum: 03.05.2011 für die USA, 06.05.2011 für den Rest der Welt.
Wer nun denkt „Worüber redet der Kerl nur wieder?“, dem sei gesagt dass das nicht mehr für möglich gehaltene nun doch geschieht: DUKE NUKEM FOREVER hat ein Releasedatum. Nach ca. 14 Jahren Entwicklungszeit, geschätzter Kosten in Millionenhöhe und der Pleite des ursprünglichen Entwicklers wird der gewinner des „Vaporware Lifetime Award“ nun doch gekauft werden können.
Wir brauchen uns heir keiner Illusion hingeben: das Spiel kann die hohen Erwartungen nach dieser Vorgeschichte gar nicht mehr erfüllen. Es wird ein bestenfalls mittelmäßiges Spiel werden und es wird wohl hauptsächlich von Veteranen wie mir erworben werden (das „alte Säcke“ habe ich mir mal verkniffen).
Warum kaufe ich es mir dann? Simple Antwort: Nostalgie.
DUKE NUKEM 3D ist nach heutigen Massstäben Computerspielesteinzeit, war aber zum Zeitpunkt der Erscheinung schon etwas Besonderes durch die Quasi-3D-Darstellung. Zudem verfügte es über etwas, dass oft in Spielen fehlt: einer Hauptfigur mit Namen. Da war ein Held, der Dinge durfte, die man als 18-Jähriger nicht machen durfte oder konnte. Er trieb sich in Stripteaselokalen rum, rauchte Zigarre, fluchte, hatte jede Menge cooler Sprüche auf Lager und er durfte die Welt von Aliens befreien. Dazu durfte er Waffen benutzen, die entweder total abgedreht waren (Schrumpfstrahler) oder die wir als Normalsterbliche hätten gar nicht tragen können (Riesen-MG). Aber der Duke hatte ja Oberarme, gegen die selbst Arnie magersüchtig aussah.
Genau das fehlt vielen Spielen heutzutage (zumindest Shootern): eine Spielfigur, zu der ich eine Verbindung aufbauen kann. Es ist wie im Kino: ist mir die handelnde Person egal, dann gefällt mir auch der Film nicht. Bei DUKE NUKEM ist es wie mit John McLane aus Die Hard: es ist ein Wiedersehen mit einem alten Bekannten. Max Payne ist ein weiteres Beispiel aus einem Computerspiel: hier hat mich der Fortgang der Geschichte genausso gefesselt wie das Spiel selbst (Max Payne hole ich heute noch gerne raus und spiele es durch). Die emotionale Verbindung zur Hauptfigur zeigt sichd aran, dass viele Spieler protestierten, als bekannt wurde dass Max Payne nun vom New Yorker Cop zu einer Art McLane-Verschnitt werden sollte (der zudem in den Dschungel reist). Aber ich schweife ab…
Der zweite Grund für meine Verbundenheit ist ein Erlebnis, dass ich für immer mit diesem Spiel verbinde. 1995 oder 1996 war ich mit zwei Kollegen in Deutschland unterwegs und habe Niederlassungen eines Kunden auf Windows NT 4.0 umgestellt. Wir hatten Laptops dabei und ein Netzwerkkabel (Koax!). Ich erinnere mich noch lebhaft an eine Szene irgendwo auf der Autobahn in der Nähe von Weimar: einer fuhr und die beiden Anderen zockten DUKE NUKEM 3D im Netz (vermutlich als Deathmatch). Also allein schon aus Nostalgiegründen muss ich das neue Spiel kaufen. Von hämischen Kommentaren (Midlife-Crisis, erinnert sich gerne an die Zeit vor dem Krieg etc.) bitte ich Abstand zu nehmen;-)
In diesem Sinne überlasse ich das Schlusswort dem Duke:
Its time to kick ass and chew bubble gum… and Im all outta gum.
]]>