Gegenüber den Möglichkeiten, die unter Unix-Systemen in z.B. der BASH zur Verfügung stehen, hat die mit Windows mitgelieferte CMD.exe einen eher schlechten Ruf. Microsoft hat zwar mit der Powershell im Laufe der Jahre eine leitsungsfähige Alternative geschaffen, die allerdings ohne entsprechenden Einarbeitungsaufwand alles andere als intuitiv funktioniert.

Will man sich einfach nur durch mehrere Unterverzeichnisse wühlen, reicht innerhalb einer Batch-Datei folgender Aufruf:

Der Platzhalter “[Wurzelverzeichnis]” muß durch den entsprechenden Pfad ersetzt werden, wobei die umgebenden Anführungszeichen bei einem vorhandenen Leerzeichen innerhalb des Pfades beibehalten werden müssen.

Zwischen den Klammern können beliebige Befehle eingesetzt werden.

Versucht man auf einem 64bit System mit 32bit Software auf eine ODBC-Quelle zuzugreifen, so erhält man statt der erhofften Daten lediglich eine Fehlermeldung:

connection failed: [Microsoft][ODBC Driver Manager] Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf. (SQL-IM014)

Auf den ersten, zweiten und dritten Blick bietet Windows auch keine Möglichkeit, die gewünschte Architektur der Datenquelle anzugeben. Der Trick liegt im expliziten Aufruf des ODBC-Datenquellen-Administrators “odbcad32.exe” im Pfad “C:\Windows\SysWOW64”, auf den standardmäßig kein Link im Startmenü gesetzt wird.

Da die Verwaltungsoberflächen für 32bit und 64bit nicht gekennzeichnet sind, hilft im Zweifelsfall ein Blick in die Prozessliste des Taskmanagers: hat die dort aufgefühte “odbcad32.exe” den Zusatz “*32”, so ist aktuell die Verwaltung für 32bit-Datenquellen gestartet. Fehlt dieser Zusatz, ist die Verwaltung für 64bit Datenquellen aus dem Verzeichnis “C:\Windows\System32” aktiv.

Verbindet sich ein Windows-Client mit einem Microsoft 2003/2008/2008 R2 DHCP-Server, so wird im Normalfall auch im DNS für diesen Client ein entsprechender Eintrag erstellt. Bei Linux-Clients erfolgt zwar die Zuteilung einer IP-Adresse mitsamt Eintrag im DHCP, der Eintrag im DNS fehlt hingegen.

Den entscheidenden Hinweis liefert das Dokument #816592 “How to configure DNS dynamic updates in Windows Server 2003” der der Microsoft Knowledge Base im Abschnitt “How DHCP/DNS update interaction works”:

You can use the DHCP server to register and update the PTR and A resource records on behalf of the server’s DHCP-enabled clients. When you do this, you must use an additional DHCP option, the Client FQDN option (option 81). This option lets the client send its FQDN to the DHCP server in the DHCPREQUEST packet. This enables the client to notify the DHCP server as to the service level it requires.

Um die zusätzliche Option unter Debian zu setzen genügt es, in der Datei “/etc/dhcp/dhclient.conf” die Zeile

einzufügen. Bei der nächsten Anmeldung am DHCP-Server wird auch ein DNS-Eintrag erzeugt.

Sollte sich ein Windows Server 2008 weigern, sowohl Aufgabenplanung als auch Ereignisanzeige und Servermanager zu öffnen, ist eine der möglichen Ursachen eine vergurkte .NET Installation.

Sofern bei installiertem .NET Framework 3.5 SP1 das Update des zugehörigen Languagepacks fehlschlägt, liegt dies u.U. an einem nicht installierten .NET 3.0 Framework, wie das Log eines manuellen Installationsversuchs zeigt:

Leider führt dies zu einem Henne-Ei-Problem, denn ohne das Language-Pack lässt sich der Server Manager nicht mehr starten, das .NET Framework 3.0 kann aber ausschließlich als Feature über den Servermanager installiert werden.

Als Lösung bleibt die vorübergehende Deinstallation des .NET Frameworks 3.5, welche die Funktionsfähigkeit des Servermanagers wieder herstellt. Über diesen dann das entsprechende .NET Framework 3.0 Feature installieren und anschließend wieder .NET 3.5 inklusive Languagepack nachziehen.