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.
Schon zu seligen DOS-Zeiten war meine Platte gevierteilt: 1x System, 1x Temp, 1x Daten und 1x Games. Das System war hierbei in einer primären Partition untergebracht, die restlichen als logische Laufwerke in einer erweiterten Partition angelegt.
Nachdem die Datenträgerverwaltung von Vista glücklicherweise noch immer mittels Rechtsklick auf ‚Computer‘ und ‚Verwalten‘ zu finden ist, geht’s ans Einrichten: die ersten 3 Partitionen kann man – wie auch immer man klickt – nur als primäre Partitionen anlegen, die 4. wird dafür automatisch als logisches Laufwerk in eine erweiterte Partition gepackt. Vista macht das so und damit basta – auch wenn die Hilfe, die ins Microsoft Technet (zur Server 2003 Doku) linkt, was von Auswahl des anzulegenden Typs schreibt.
Eine kurze Suche im Netz bringt das ernüchternde Ergebnis, das dieses Verhalten wohl gewollt ist – und den ersten Kontakt mit dem Werkzeug diskpart.
Microsoft DiskPart Version, 6.0.6000 Copyright (C) 1999-2007 Microsoft Corporation. Auf Computer: SYDNEY DISKPART> select disk 0 Datenträger 0 ist jetzt der gewählte Datenträger. DISKPART> create partition extended Die angegebene Partition wurde erfolgreich erstellt. DISKPART> exit
Na bitte – nach dem Öffnen der Datenträgerverwaltung strahlt eine erweiterte Partition in leuchtendem Grün, in der nun mittels Rechtsklick logischen Laufwerke erstellt werden können.