Ihr kennt das Fenster bestimmt, wenn ein USB-Gerät angeschlossen oder ein „Scheibenmedium“ eingelegt wird. Ich glaube 90% aller Computeruser klicken dieses Fenster entweder weg oder klicken auf „Ordner öffnen, um Dateien anzuzeigen“. Ich hab schon Leute gesehen, die Musik CDs eingelegt haben, auf „Ordner öffnen“ geklickt haben, nur um dann Rechtsklick auf das CD-Laufwerk zu machen und „Mit Windows Media Player abspielen“ zu klicken. Anstatt sie gleich die Media Player Option wählen.

Wie dem auch sei, die Funktion ist bei einer Standard Windowsinstallation suboptimal konfiguriert.
Unten, in diesem Fenster steht ein Link zu den „weiteren Optionen für die automatische Wiedergabe“, klickt darauf. Ist gerade ein solches Fenster nicht offen, könnt ihr im Startmenü nach „automatische Wiedergabe“ suchen und dadurch in die Systemsteuerung gelangen.
Unter Windows XP müsst ihr Rechtsklick auf euer Gerät machen (CD/DVD-Laufwerk, Wechseldatenträger etc) und dann in der Kartei „AutoPlay“ nachsehen.

Von hier aus könnt ihr steuern, bei welchem Inhalt welche Aktion ausgeführt werden soll. Ich habe hier mal eine – für mich einleuchtende – Konfiguration vorbereitet.

Ihr könnt die Funktion auch deaktivieren wenn Wechselmedien bei euch z.B. durch Autorun Scripte geöffnet oder verwaltet werden. Ganz oben in diesem Fenster müsst ihr dafür nur das Häkchen von „automatische Wiedergabe [..] verwenden“ entfernen.

cpau habe ich ja bereits vorgestellt. Sinn und Funktionsweise setze ich hier voraus 🙂

Das Ausführen von CPAU Jobs vom Netzlaufwerk funktioniert aufgrund von simplen Windows Sicherheitsprinzipien nicht. Schließlich hat ein lokales Administratorkonto kein Zugriff auf Netzlaufwerke, die ja einen Domänenaccount benötigen. Also brauche ich ein Workaround, wenn ich automatisierte Softwareinstallationen auf einem UNC Share im Unternehmen bereitstellen will.

Ziel soll es sein, jedem eingeschränkten Nutzer Admin-Softwareinstallationen dank CPAU vom Netzlaufwerk aus bereitzustellen:

So wird es dann aussehen. Der Nutzer bewegt sich auf dem Netzlaufwerk, starte eine Batch und die Installation mit Adminrechten wird gestartet.

Kurz zum Verständnis:
Der Aufbau eines cpau Systems (mit Jobs) ist grundsätzlich recht einfach:
1 Batch Script ist für den Benutzer („Userscript“). Bei Doppelklick führt es die gespeicherte Job Datei aus. Die Job Datei führt wiederum ein Login auf das Administratorkonto durch und startet eine Datei oder ein Script („Ziel-Datei/Installer“) mit den entsprechenden Rechten. Für den Benutzer müssen weder Job Datei noch die Ziel-Datei sichtbar sein.

Das Verzeichnis mit den Benutzerscripten und das Verzeichnis mit den Job- und Ziel-Dateien.

Wären Netzlaufwerke erlaubt müsste das Benutzerscript nur 1 Zeile haben:
bash“>“\\Server\Pfad\zu\cpau.exe“ -dec -file „\\Server\Pfad\zu\jobfile.job“ -nowarn -lwp

Das geht natürlich nicht. In der Job sind die Administratorcredentials gespeichert, beim Start von cpau wird das working dir auf einen lokalen Pfad gelegt und der Administrator kommt auch nicht mehr an den Server. Es bleibt nur eine Lösung: alles, was benötigt wird, lokal zu kopieren und damit lokal zu arbeiten.

Hier das Userscript:
winbatch“ line=“1″>
@echo off
echo Verzeichnis erstellen und reinigen
if not exist c:\temp md c:\temp >> nul
del c:\temp /f /s /q >> nul
echo Job Files und Ziel-Dateien lokal kopieren
copy \\Server\Pfad\zu\den\Installer\und\Jobfiles c:\temp /y >> nul
echo Lokale Jobfile ausführen
c:\temp\cpau.exe -dec -file „c:\temp\notepad.job“ -nowarn -lwp
echo Verzeichnis löschen, 1 Ziel-Datei ist in Benutzung und bleibt übrig
del %wdir% /f /s /q >> nul

Das mag jetzt etwas unübersichtlich aussehen, ist aber ein einfaches Prinzip.
Es wird ein lokaler Ordner erstellt, falls noch nicht vorhanden. Der Inhalt des Ordners wird gelöscht, falls der Ordner existieren sollte und sich noch Dateien darin befinden. Dann wird der Ordner vom Netzlaufwerk, in dem Installer und Jobfiles liegen in diesen lokalen Ordner kopiert. Die nun lokal liegende Jobfile kann jetzt ausgeführt werden. Danach wird der Ordnerinhalt gelöscht. Fertig.
Der Benutzer startet dieses Userscript vom Netzlaufwerk aus und bekommt von der ganzen lokalen Geschichte nichts mit, einige Sekunden später startet einfach die administrative Installation, die das Userscript schließlich ja hervorbringen sollte.

Nun müsst ihr das Jobfile speziell für diesen Fall generieren. Erstellt euch den temporären Ordner, falls noch nicht vorhanden. Pfad und Name genauso wie in dem Userscript benutzt. Kopiert dort den gewünschten Installer oder Ziel-Datei hinein und erstellt die Job File mit folgender Codezeile:
cpau.exe -u Administrator -p PaSsWoRt -ex „c:\temp\installer.exe“ -crc „c:\temp\installer.exe“ -enc -file „\\beliebiger\lokaler\oder\serverpfad\installer.job“

Wichtig ist, dass ihr die Jobfile mit den lokalen Pfaden der Ziel-Datei erstellt. Der Installer muss in dem selben lokalen Verzeichnis liegen, wie die Dateien durch das Userscript kopiert werden.

Ich nutze das System, wie man auf den Screenshots oben sieht, bereits produktiv im Unternehmen und es kommt sehr gut bei den Mitarbeitern an. Sollte es über einfache Aufgaben hinausreichen, bietet es sich an, das Script zu verbessern. Hier ist meine Version des Userscripts:
winbatch“ line=“1″>
@echo off
echo Variablen erstellen…
set log=\\server\laufwerk\Computer\Software\GPOs_Install\PC-Data\Updatelogs\Programmupdates.txt
set wdir=c:\updatetemp
set updatedir=\\server\laufwerk\Computer\Software\GPOs_Install\Updates\
set /a loop=0
echo Verzeichnis erstellen, reinigen und kopieren…
echo %computername% – %username% – %date% %time% startet Notepad++ Installer >> %log%
if not exist %wdir% md %wdir% >> nul
del %wdir% /f /s /q >> nul
:kopieren
set /a loop=%loop%+1
if %loop%==4 goto :Fehler
copy „\\server\laufwerk\Computer\Software\cpau.exe“ %wdir% >> nul
if errorlevel 1 goto :kopieren
copy %updatedir% %wdir% /y >> nul
if errorlevel 1 goto :kopieren
echo Installation starten…
%wdir%\cpau.exe -dec -file „%wdir%\notepad.job“ -nowarn -lwp
echo Verzeichnis löschen…
del %wdir% /f /s /q >> nul
echo %computername% – %username% – %date% %time% beendet Notepad++ Installer >> %log%
echo ################ >> %log%
goto :eof

:Fehler
echo.
echo ### Fehler beim Kopieren ###
echo Bitte informieren Sie die EDV Abteilung.
pause
goto :eof

Alle Pfade werden in Variablen gespeichert und erleichtern die Übersicht im Script. Ein Logfile wird beim Start und beim Beenden einer Softwareinstallation (hier im Beispiel Notepad++) beschrieben und ermöglicht mir das (noch relativ grundlegende ^^) Troubleshooting, falls es zu Problemen kommen sollte. Der Kopiervorgang des Installer- und Jobordners wird mit errorlevel überwacht und in einer Schleife wiederholt, sollte er fehlschlagen. Schlägt er zu oft fehl, wird eine Fehlermeldung ausgegeben. Läuft alles gut (das war bis jetzt immer der Fall), so wird die Job gestartet und der lokal liegende Installer mit dem lokalen Administrator ausgeführt.

Was der Benutzer sieht, zeige ich in dem Video ganz oben. Das passiert im Hintergrund:

Der Nachteil wird schnell klar: je mehr Softwareinstallationen ich bereitstelle und je größer die Produkte sind desto länger dauert der Kopiervorgang für jeden Benutzer bei jeder Installation, da immer der ganze Ordner kopiert wird. Das könnte man ganz leicht umgehen, in dem man in jedem Script nur die Dateien kopieren lässt, die auch wirklich benötigt werden, z.B. %programm%.job und %programm%.exe. Sollte ich das demnächst noch so programmieren werdet ihr es erfahren.

Bei Fragen und Anregungen mail me 🙂

Wenn man unter Windows XP Drucker, Druckertreiber und Anschlüsse zentral verwalten wollte hat man die „Servereigenschaften“ des lokalen Druckservers genutzt. Diese waren im Fenster „Drucker und Faxgeräte“ per Rechtsklick auf „Servereigenschaften“ zu erreichen. Diese Druckserververwaltung war besser geeignet als die normale Übersicht des Druckerfensters.

In Windows 7 heißt die Funktion jetzt „Druckverwaltung“ und kann über die Startmenüsuche gefunden werden. Von hier erfolgt die Verwaltung über den lokalen Druckserver.

Eine ähnliche Ansicht kann man öffnen, indem man bei den Druckern einen Drucker anklickt und dann in der Funktionsleiste „Druckerservereigenschaften“ anklickt.

Es kann vorkommen, dass eine Softwareinstallation via GPO nicht so rund läuft und die Software fehlerhaft installiert wird. Die Gruppenrichtlinie sieht die (fehlerhaft) installierte Software und hakt diesen Punkt also ab, die Softwareinstallation bleibt fehlerhaft. Wenn nun auch die manuelle Deinstalltion der Software nichts daran ändert und die Gruppenrichtlinie immernoch nicht die Software neu zuweisen will, muss ein Trick her.
Grundsätzlich kann natürlich mein Guide zum Troubleshooten von GPO-/Softwareinstallationsfehlern helfen.

Ich möchte jetzt aber noch einen Trick ergänzen, den ich gestern entdeckt habe.

Grundsätzlich hilft bei diesem Problem (Installation fehlerhaft, Deinstallation wird nicht erkannt) wie erwähnt das Löschen des Registry Keys

HKLM/Software/Microsoft/Windows/CurrentVersion/Group Policy

und die komplette Gruppenrichtlinie wird erneut angewandt.

Wenn in der Softwareinstallation nun aber 5-10 Programme stehen und dann alle neu installiert werden ist das eine wirklich zeitraubende Lösung. Möglicherweise verlorene Programmfeatures, Updates, Pakete, Einstellungen durch die Neuinstallation sind auch oft ärgerlich.
Also wäre es besser nur die Installation zurückzusetzen, die tatsächlich fehlerhaft ist.


Geht in den Group Policy Key (siehe oben), dort in „AppMgmt“ und ihr werdet einige GUID Schlüssel sehen. Jeder Schlüssel representiert eine Softwareinstallation. Klickt eine GUID an und schaut euch den Wert „Deployment Name“ an, dort steht der Softwarename, den ihr in der GPO vergeben habt.
Löscht den Schlüssel der fehlerhaften Software und startet den Computer neu.

Die GPO wird jetzt diese Software neu installieren.
Gibt es immernoch Probleme dann deinstalliert die Software erneut, löscht alle Spuren (Regcleaner wie CCleaner), löscht den eventuell verbliebenen Installerverweis mit Microsoft Installation CleanUp Utility, löscht nochmal den Registry Key und rebootet nochmal den PC. Spätestens jetzt sollte die Software so korrekt installiert werden. Wenn nicht liegt der Fehler eher woanders 😉

Die IP-Einstellungen einer Netzwerkverbindung nicht von Hand sondern mit einem Batch Script machen zu lassen kann mehrere Vorteile haben. Natürlich schließt man dadurch Tippfehler aus und spart auch ein wenig Zeit aber sinnvoller ist der Einsatz bei mehreren Standorten mit unterschiedlichen IP-Einstellungen, zwischen denen man selber oder ein Kollege pendelt. Die IP Settings eines jeden Standorts lassen sich dann einfach per Doppelklick übernehmen.

Hier ein Beispiel Batch Script:

netsh interface ip set address "LAN-Verbindung" static 192.168.178.44 255.255.255.0 192.168.178.1 256
netsh interface ip set dns "LAN-Verbindung" static 192.168.178.10 PRIMARY
netsh interface ip set dns "LAN-Verbindung" static 192.168.178.11 index=2

Achtung: Hier müssen also Name der Netzwerkverbindung und natürlich die Adressen angepasst werden.

Mit diesem Script werden an der Netzwerkverbindung „LAN-Verbindung“ folgende Einstellungen übernommen:
IP-Adresse: 192.168.178.44
Subnetzmaske: 255.255.255.0
Gateway: 192.168.178.1
Gateway-Metrik: 256
DNS 1: 192.168.178.10
DNS 2: 192.168.178.11

Für DHCP bei den IP- als auch den DNS-Einstellungen einfach folgende Zeilen verwenden:

netsh interface ip set address "LAN-Verbindung" dhcp
netsh interface ip set dns "LAN-Verbindung" dhcp

Für Informationen zu den aktuellen Einstellungen reicht der Befehl

netsh interface ip show config

oder ganz klassisch

ipconfig /all

.

aida32 ist zugegebenermaßen kein sehr aktuelles Programm, die letzte Version kam 2004 raus und fällt bei den meisten Administratoren deswegen schon direkt durch. Was ich aber sehr schätze ist, dass das Programm klein ist, keine Installation benötigt, keine Lizenzeinschränkungen im Business Bereich hat und seine Aufgaben möglichst performant, schnell erledigt. Für eine netzwerkweite Inventarisierung wollte ich zuerst msinfo32 nutzen, dass bei jedem Windows System von Hause aus mitgeliefert wird (

%commonprogramfiles%/microsoft shared/msinfo/msinfo32.exe

) und auch alles nötige über das System herausfinden und als Report auch abspeichern kann.
Leider funktioniert das Programm ab Windows Vista nicht mehr korrekt, um genau zu sein werden wichtige Paramter einfach ignoriert. Die Parameter /category oder /categories, die für eine performante Inventarisierung unverzichtbar sind, werden gekonnt missachtet. Das fällt also leider raus.
Programme wie SIW 2010, Everest o.Ä. sind in kommerziellen oder Businessbereichen zu lizenzieren und eventuell auch einfach zu umfangreich.

Also, ich hab mir erstmal aida32 3.93 auf unser Netzlaufwerk geschoben.
Als nächstes ist es wichtig eine klare Vorstellung davon zu haben, was inventarisiert werden soll. Alles zu inventarisieren ist absolut kontraproduktiv. Der Vorgang an sich würde bestimmt eine Minute dauern und der Informationsgehalt wäre für die Administratoren auch einfach zu extrem.
Folgende Daten waren mir in unserem Netzwerk wichtig:

  1. Betriebssystem mit z.B. so Informationen wie Computerbeschreibung, Computername und Domäne.
  2. Systemdaten zur Hardware wie Prozessortyp, Mainboard, Speicher, Festplatten etc
  3. letzter angemeldeter Benutzer
  4. Netzwerkinformationen wie IP, MAC, Anzahl der Netzwerkkarten, vorhandenes WLAN etc
  5. Monitormodell
  6. (Autostart)
  7. installierte Programme mit Version und ggf. Installationsdatum

Um von Aida32 wirklich nur diese Informationen zu bekommen muss man sich eine Berichtvorlage erstellen. Das ist schnell gemacht, einfach Aida32 starten und dann beim Berichtsprofil unter

Bericht -> Bericht-Assistent Pro/Lite...

„angepasste Auswahl“ einstellen. So habe ich nur die Bereich aktiviert, die ich brauche. Generiert wird eine .rpf Datei im Verzeichnis von aida32, die nachher noch wichtig ist.
Es ist zu empfehlen möglichst wenig Daten zu sammeln um den Vorgang der Analyse, die ja bei jedem Systemstart dann durchgeführt wird, möglich gering zu halten. Die Analyse sollte nicht länger als 10 Sekunden dauern, der Userstimmung wegen. Wird mehr Zeit benötigt würde ich unnötige Informationen aussortieren. Meine paar Dinge reichen vollkommen aus und sind in 3-6 Sekunden erfasst, je nach Rechnertyp. Je nach Anzahl der Mitarbeiter/Computer und der Arbeitsstimmung her muss jeder Administrator das aber selber einschätzen.

Nun brauchen wir den Bericht durch einen Batchbefehl, den wir dann später zum Automatisieren des Vorgangs nutzen. Also die CMD öffnen und zuerst schauen wir in die Hilfe von aida32:

aida32.exe /?

(aus dem Verzeichnis von aida32 raus oder mit dem entsprechenden Pfad davor) bringt nämlich erstaunlich viele Parameter zum Vorschein, mit der sich die Inventarisierung super steuern lässt.

Folgenden Befehl nutze ich für die Aufgabe:
dos“>\\serverpfad\zu\aida32\aida32.exe /r „\\serverpfad\zu\den\logs\$hostname“ /text /silent /safe /custom „iqb.rpf“
Also, mit

/r

erstelle ich allgemein einen Report im Verzeichnis bla\logs\. Der Dateiname wird mit $hostname auf den Namen des Computers gesetzt. Bei diesem Pfad keine Dateiendung angeben, diese wird nämlich mit dem Parameter für das gewünschte Format, bei mir

/text

, von alleine ergänzt.

/silent

führt den Vorgang ohne GUI durch, mit

/safe

umgeht aida32 das Laden der Gerätetreiber, was anscheinend eine häufige Fehler/Konfliktquelle sein soll. Die letzte Option

/custom

übergibt aida32 meine benutzerdefinierte Berichtvorlage, sodass nur die Informationen ermittelt werden, die ich brauche.

Wenn der Test in der CMD klappt wars das eigentlich schon. Diesen Befehl jetzt am besten als Startscript in ein GPO einbauen und an alle Computerobjekte knüpfen, die inventarisiert werden sollen. Done! Ich hoffe, ich konnte helfen. Fragen, Verbesserungen, etc, wie immer in den Comments!

Bei der Erstellung von VMs in VMware Server 2 stehen für die virtuelle Festplatte 2 verschiedene Adaptertypen zur Auswahl: IDE oder SCSI.
Nach der Erstellung lässt sich der Adaptertyp nicht aus dem grafischen Webinterface von VMware heraus ändern. Nicht nur das: virtuelle HDDs vom Typ IDE lassen sich nicht mal vergrößern, SCSI Platten dagegen schon.

Wenn also eine IDE Festplatte voll ist kann man aus dem Webinterface von VMware Server weder den Typ noch die Größe ändern.

Es geht doch, und zwar mit dem Konsolentool „vmware-vdiskmanager.exe“.
Sucht das VMware Programm „vmware-vdiskmanager.exe“ im Installationsverzeichnis vom Server.
Der Standard wäre: C:\Programme\VMware\VMware Server\
Nun noch den Pfad der zu ändernden .vmdk (HDD der VM) kopiert und bastelt dann folgenden Befehl:

html“>“c:\Program Files (x86)\VMware\VMware Server\vmware-vdiskmanager.exe“ /x 20GB „D:\VMs\Test1\Test1.vmdk“

/x steht hierbei für „eXpand“ also erweitern und die Größe wird danach mit Wert und einer der 2 Einheiten MB oder GB angegeben.

Nun ist die Festplatte der VM größer aber die Partition immernoch unverändert. Also müsst ihr auf die VM jetzt ein Partitions Manager wie EASEUS Partition Master oder Paragon Partition Manager installieren und die gewünschte Partition vergrößern.

In der Toolreferenz stehen die restlichen Parameter und bei Google gibts es zum vdiskmanager noch viele andere Infos zu entdecken. Have fun.