aeroCMD enables transparency for your Windows command prompt:
Inspired by the AutoIt-application „Glass CMD„, the basic idea behind aeroCMD was to do the same thing without the overhead of a scripting system running in the background. There’s already a pure C++ application called „Glassy“ out there, but according to it’s description it works on 32bit „cmd.exe“ only.
aeroCMD is a lightweight (48kb) application that works with 32bit and 64bit „cmd.exe“ and „powershell.exe“.
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:
for /f "tokens=*" %%D in ('dir /b /s /a:d "[Wurzelverzeichnis]"') do (
echo found %%D
)
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.
In einer Domäne ist es recht einfach, einen Rechner remote heruterzufahren. Einfach an der Kommandozeile
shutdown -s -t 0 -m \\HerunterzufahrenderRechner
eingeben und sofern der ausführende Benutzer innerhalb der Domäne die benötigten Rechte hat, führt der angegebene Rechner den Befehl klaglos aus.
Nicht so trivial ist das Szenario bei Rechnern im z.B. heimischen Umfeld, wo nur selten eine zentrale Benutzerverwaltung aktiv sein dürfte:
shutdown -s -t 0 -m \\HerunterzufahrenderRechner HerunterzufahrenderRechner: Zugriff verweigert(5)
Als ersten Lösungsansatz stößt man meistens auf den Hinweis, sich zuerst mittels einer administrativen Netzerkverbindung gegenüber dem herunterfahrenden Rechner zu authentifizieren, wofür sich z.B. die Freigabe IPC$ anbietet:
net use \\HerunterzufahrenderRechner\ipc$ Das Kennwort oder der Benutzername ist ungültig für \\HerunterzufahrenderRechner\ipc$ Geben Sie den Benutzernamen für "HerunterzufahrenderRechner" ein: Benutzer Geben Sie das Kennwort für "HerunterzufahrenderRechner" ein: Der Befehl wurde erfolgreich ausgeführt.
Unter Windows XP war dies schon vollkommen ausreichend, unter Windows Vista und Windows 7 wird allerdings weiterhin der Zugriff verweigert. Wie der KnowledgeBase-Artikel „Description of User Account Control and remote restrictions in Windows Vista“ erklärt, handelt es sich hierbei um ein Feature und keinen Bug:
When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection by using the net use * \\remotecomputer\Share$ command, for example, they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks.
Um auch über das Netzwerk verbundenen, lokalen Benutzern entsprechende Berechtigungen zu erteilen, ist das setzen des Registry-Schlüssels „LocalAccountTokenFilterPolicy“ innerhalb des Pfades
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
notwendig, dieser muß als DWORD mit dem Wert 1 angelegt werden.
Nicht nur die Festplattenverwaltung von Vista führt zum Nachdenken, auch die Tatsache, daß das Diskettenlaufwerk, das schon seit Urzeiten (zur Erinnerung: Mensch und Gewohnheitstier) als Laufwerk „A:“ im System vorhanden war, unter Vista plötzlich „B:“ heißt.
Ein ernster Blick über die Computerverwaltung bringt leider keine sinnvollen Erkenntnisse – und somit bleibt nur die Suche nach alternativen Heilmethoden:
In der Registry gibt es den Schlüssel „HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices“ – ein Hinweis darauf, daß unter Unix mittels „mount“ eine Lösungsversuch möglich wäre – und siehe da, auch unter Windows gibt es was ähnliches, nur heißt es hier „mountvol.exe“.
C:\Windows\system32>mountvol b: /l
\\?\Volume{ca86470a-be5e-11db-844e-806e6f6e6963}\
C:\Windows\system32>mountvol b: /d
C:\Windows\system32>mountvol a: \\?\Volume{ca86470a-be5e-11db-844e-806e6f6e6963}\
Anschließend ist das Diskettenlaufwerk wieder als „A:“ zu finden, ein Zustand, der erfreulicherweise auch die bisherigen Reboots überlebt hat.