Monthly archives "Februar 2011"

Update zu Windows Backup und Exchange

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.

]]>

Parameter in Windows Kommandozeilentools

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?

]]>

Asyl (sorry: Exil) für Diktatoren

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;-)

]]>

Spass mit Exchange 2010 Installation

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;-)

]]>

Exchange 2010 und Windows Backup

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.

]]>