Das Systemsteuerungselement „Mail (32bit)“ dient der einfachen Konfiguration der E-Mail Konten und Eigeschaften von Outlook. Diese Einstellungoberfläche ist teilweise sogar zwingend erforderlich, da z.B. systemsteuerung-mail-32bit-funktioniert-nicht-großneue E-Mail (Exchange) Konten nicht während des Betriebes von Outlook eingerichtet werden können. Umso ärgerlicher, wenn beim Klick auf das Element nichts passiert oder es in der Übersicht der Systemsteuerung nicht vorhanden ist.

Es gibt ein paar Tipps, die helfen können, das wieder in den Griff zu bekommen:

Den Mail Dialog manuell öffnen:

Sucht im Installationordner von Office, beispielsweise

c:\Program Files (x86)\Microsoft Office\Office12\

, nach der Datei MLCFG32.CPL. Diese müsste existieren und beim Doppelklick das gewünschte Mailkonfigurationsfenster öffnen. Ihr könnt diesen Dialog jederzeit auf diesem Weg öffnen.

Eine neue Verknüpfung erstellen:

Egal, ob das Element „Mail (32bit)“ nicht funktioniert oder gar nicht vorhanden ist, ihr könnt euch einfach selber eine Verknüpfung erstellen, diese macht dann genau das gleiche wie die Verknüpfung in der Systemsteuerung.
Erstellt eine neue Verknüpfung, beispielsweise auf dem Desktop oder in einem Ordner eurer Wahl, und tragt als Ziel die MLCFG32.CPL Datei aus eurem Office Installationsordner ein.
Dann könnt ihr noch in den Eigenschaften der Verknüpfung mit „Anderes Symbol…“ eine passenderes Icon wählen.

systemsteuerung-mail-32bit-funktioniert-nicht-shotcut

Systemsteuerungselement reparieren:

Am wahrscheinlichsten wird eine Office Reparatur das Problem beheben. Geht dazu in die Systemsteuerung zu euren installierten Programmen, Rechtsklick auf euer Office, „Ändern“ und wählt Reparieren.
systemsteuerung-mail-32bit-funktioniert-nicht-outlook-repair
Startet nach der Installation euren Rechner neu.

Sollte das Element immernoch nicht funktionieren, überprüft bitte folgenden Registry Key:

HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Microsoft Outlook\shell\Properties\command

Dieser sollte auf die CPL Datei in eurem Office Verzeichnis hinweisen, mit ein paar Wörtern davor.
Der Inhalt sollte also in etwa so aussehen:

rundll32.exe shell32.dll,Control_RunDLL "C:\PROGRA~2\MICROS~1\Office12\MLCFG32.CPL"

Ihr könnt die Richtigkeit des Pfades überprüfen, in dem ihr diesen einfach kopiert und in Start -> Ausführen eintragt.
systemsteuerung-mail-32bit-funktioniert-nicht-test-office-path
Dies sollte den gewünschten Dialog öffnen.

Java, ein Grundpfeiler von Windows PCs, der schnell bröckelt und regelmäßig aktualisiert werden muss. Fast immer installiert und leider oftmals nicht auf dem neuesten Stand, wodurch sehr schnell sehr große Sicherheitslücken entstehen können; denn Java wird gerne von Exploits ausgenutzt.

Ein flexible, schnell konfigurierte und scriptbasierte Java Verteilung soll dieses Problem und den damit verbundenen Aufwand auf ein Minimum reduzieren.
Bei dieser wird ein Startscript im AD auf den Zielcomputern, die vom Clientfilter akzeptiert werden, Java sowohl in der 32bit als auch in der 64bit Version installieren.
Die Installation beider Bit-Varianten ist notwendig, da die meisten Browser immernoch ausschließlich als 32bit Fassung existieren. Ein 32bit Browser würde selbst auf einem 64bit System mit installiertem 64bit Java keine existierende Java Installation finden.

Der Aufbau

java-deployment-working-dir-neu
Bei einem neuen Java Update werden die beiden .exe Installer benötigt, diese müssen entsprechend dem Muster im Bild umbenannt werden. Abschließend müssen noch 2 Zeilen im Script angepasst werden. Das ist der komplette „Aufwand“, wenn ein neues Java Update veröffentlicht wird.

Das Script

Stand: 13.3.2015 (Java 8u31), working

@echo on & Color 9f & setlocal
 
set wd=\\lea\Deployment\Software\Flash
set log=%wd%\flash-log.txt
REM --- Version hier ändern ---
set version=16.0.0.305
REM ---------------------------
set tools=\\lea\Deployment\Sonstiges\tools
set flashieEL=999
set flashplEL=999
set combinedEL=999
set versionEL=999
set instversion=000
set retry=0
 
REM Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
::for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto check
::goto end
 
REM Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end
 
:check
REM check installed version
for /f "tokens=1,2,3 delims= " %%a in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\FlashPlayerPlugin" /v "Version"^|findstr "Version"') do set instversion=%%c
if "%instversion%"=="000" goto install
%tools%\VersionCompare.exe %instversion% %version%
set versionEL=%errorlevel%
if "%versionEL%"=="-1" goto install
if "%versionEL%"=="0" echo %date% %time:~0,8% - %computername% hat bereits %instversion% installiert >> %log% & goto end
if "%versionEL%"=="1" echo %date% %time:~0,8% - %computername% hat bereits %instversion% (neu) installiert >> %log% & goto end
 
:install
echo %date% %time:~0,8% - %computername% (%instversion%) startet die Installation... >> %log%
start /w %wd%\flash-%version%_IE.exe -install
set flashieEL=%errorlevel%
start /w %wd%\flash-%version%_OTHER.exe -install
set flashplEL=%errorlevel%
 
if %flashieEL%==1618 goto retry REM msiexec process in use, installation already in progress
if %flashieEL%==1602 goto retry REM user canceled installation
if %flashieEL%==1603 goto retry REM fatal error, some use it for "already installed" (eg. java)
if %flashplEL%==1618 goto retry REM msiexec process in use, installation already in progress
if %flashplEL%==1602 goto retry REM user canceled installation
if %flashplEL%==1603 goto retry REM fatal error, some use it for "already installed" (eg. java)
if %flashieEL%==1041 echo %date% %time:~0,8% - %computername% strange 1041 open browser fail, end >> %log% & goto end
if %flashplEL%==1041 echo %date% %time:~0,8% - %computername% strange 1041 open browser fail, end >> %log% & goto end
 
set combinedEL=%flashieEL%%flashplEL%
echo %date% %time:~0,8% - %computername% hat die Installation von %version% abgeschlossen, errorlevel: %combinedEL% >> %log%
goto finish
 
:retry
if %retry%==1 goto retryfailed
echo %date% %time:~0,8% - %computername% hat nicht Errorlevel 00 erreicht, retry in 200Sek... >> %log%
set retry=1
ping localhost -n 200 > nul
goto install
 
:retryfailed
echo _!_ %date% %time:~0,8% - %computername% hat die Installation abgebrochen, RETRY FAILED! EL: %flashieEL% %flashplEL% >> %log%
goto end
 
:finish
REM copy flash config file for silent background updates
if "%processor_architecture%"=="x86" xcopy "%wd%\mms.cfg" "%systemroot%\System32\Macromed\Flash" /y & goto end
xcopy "%wd%\mms.cfg" "%systemroot%\SysWOW64\Macromed\Flash" /y
xcopy "%wd%\mms.cfg" "%systemroot%\System32\Macromed\Flash" /y
goto end
 
:end
endlocal
exit

Um einzelne Computer für die Ausführung eines bestimmten Scripts ein- bzw. auszuschließen, verwende ich seit Langem in fast allen produktiven Scripts einen – von mir so benannten – „Clientfilter„. In einem alten Beitrag hatte ich die zugrunde liegende Technik bereits erklärt, möchte das jetzt nochmal ein wenig ausführlicher, in 2 verschiedenen Ausführungen, zeigen.

Das Prinzip müsste klar sein: eine Textdatei enthält einen oder mehrere Computernamen, 1 pro Zeile. Der Clientfilter vergleicht den Computernamen des ausführenden Computers mit jeder Zeile der Textdatei und reagiert entsprechend.

Zwei typische Anwendungen baue ich immer in die Scripte mit ein:

Fall 1: nur bestimmte Computer dürfen ausführen

In einem Unternehmen mit XXX Computern möchte ich ein neues Script vorerst testen. Dazu soll dieses Script erst einmal nur von 1 oder 2 Computern gestartet werden können. Ich konfiguriere also folgenden Clientfilter:

set wd=\\server\working\dir
REM Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto nextstep
goto end

:nextstep
...
:end
...

Das Script prüft also an dieser Stelle, ob der ausführende Computer(name) in der allowedPCs.txt Datei im %wd% Verzeichnis vorhanden ist. Wenn ja, geht es zur Sprungmarke

nextstep

, wenn nicht, zu

end

. Somit erlaube ich das Script nur für einzelne aus einer Gruppe von vielen Rechnern.

Fall 2: nur bestimmte Computer dürfen nicht ausführen

Nun habe ich das Script also getestet und möchte es auf XXX Computer installieren. Dabei möchte ich aber einzelne Rechner ausschließen. Hierfür ist folgender Clientfilter gedacht:

set wd=\\server\working\dir
REM Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end
goto nextstep

:nextstep
...
:end
...

Das Script wird also von allen Computern ausgeführt, deren Name nicht in der deniedPCs.txt steht. Ist die deniedPCs.txt leer, so wird das Script von allen Computern ausgeführt.

Beides baue ich in meine Scripte ein und kommentiere den gerade nicht benötigten Bereich aus.
clientfilter-script-execution-check-standard

clientfilter-script-execution-check-standard-filesSomit ist es für meine Verteilungen also normal, wenn neben dem Script auch immer diese beiden Textdateien allowedPCs.txt und deniedPCs.txt im Verzeichnis enthalten sind. In der allowedPCs.txt stehen meisten die Testrechner, die deniedPCs.txt ist meistens leer.

Ziel ist es, die aktuellste Version Adobe Reader auf allen Computern eines AD Netzwerks zu verteilen. Es handelt sich um die Version 11.0.10 (Update 13.3.2015), die speziell angepasst (deutsche Sprache, keine EULA, paar Features deaktiviert) installiert werden soll. Da ich bei diesem Prozess auf verschiedenste Fehler und Probleme stieß, werde ich die Verteilung hier detailliert erläutern.

Seit 2010/2011 gibt es ja den Hintergrundupdater in Adobe Produkten. Eigentlich gehören Verteilungen dieser Art also der Geschichte an. Jedoch kann es trotzdem notwendig werden, wenn erstmal eine Basis geschaffen werden muss, weil beispielsweise kein einheitlicher Standard des Produkts installiert ist. Einige haben Version X, andere Version Y, einige PCs haben die Software nicht einmal installiert. In diesem Fall ist ein komplettes Rollup inklusive Cleaning, also Deinstallation aller Versionen vor der Verteilung, sinnvoll und empfehlenswert.

Wie üblich gibt es mehrere Herangehensweisen, bei Adobe habe ich im Laufe der Jahre folgende Methode als sicherste empfunden:
Installer laden -> AIP lokal erstellen -> Patches slipstreamen -> mit Customization Wizard anpassen -> mit Orca optimieren -> Verteilen,
wobei der Verteilen-Punkt je nach Produkt und Situation natürlich zwischen Script oder GPO Installation unterschieden wird.
Das hier sagt Adobe zu den „Best Practices“.

Schritt 1: Installer laden

Adobe bietet für ihre Produkte teilsweise 2 verschiedene Downloadseiten an. Die typisch einfache Seite und die Seite für Administratoren, hier am Beispiel vom Reader (bei Acrobat ist das ebenfalls so).
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-installerIhr braucht natürlich das komplette Paket: 11.0.0 Basis plus aktuellstes Update, am besten in der MUI Variante.
Für die Pro’s auch ohne viel Schickschnack via FTP.

Schritt 2: AIP erstellen

Falls die Grundversion (z.B. 11.0.0) eine .zip Datei war, entpackt diese. Geht per CMD in diesen Ordner und führt den Befehl

msiexec /a "AcroRead.msi"

Der Installer startet, installiert am besten lokal, C:/Reader11/ oder so. AIP fertig!

Schritt 3: Patches integrieren

Geht per CMD in den Ordner des Updates und führt den Befehl aus:

msiexec /a "C:\Reader11\AcroRead.msi" /p "AdbeRdrUpd11004_MUI.msp"

(ihr müsst natürlich Pfade und Dateinamen entsprechend anpassen…)
Der grafische Installer für den Patch erscheint, durchklicken, fertig. Verfahrt so mit allen Patches, wenn ihr mehrere habt. Für gewöhnlich lässt sich aber das aktuellste Update auf die Basisversion anwenden, mehr dazu steht auf der Detailseite des Updates bei den „Installation Instructions“ („This update requires that Adobe Reader 11.0 MUI or later is installed on your system.“).
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-update-slipstream

Schritt 4: mit dem Customization Wizard anpassen

Wie bei Acrobat kann man auch den Reader mit dem Adobe Customization Wizard anpassen:
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-customization-wizard
EULA deaktivieren, Sprache wählen, Deinstallation alter Versionen aktivieren, paar Online Features deaktivieren, Shortcuts anpassen, tobt euch aus und speichert das Ergebnis als MST Anpassungsdatei ab.

Fertig, ihr habt jetzt eine geupdatete AIP Installation, C:/Reader11. Die könnt ihr auf das Netzlaufwerk schieben. Dazu die gerade erstellte MST. Beides zusammen könnt ihr nun Verteilen. Entweder via GPO Softwareinstallation oder per Script. Letzteres bevorzuge ich aus Gründen der Funktionalität.
Kommen wir also zum letzten Schritt.

Schritt 5: Verteilung via Script

Hier wird es nochmal spannend.
Das Installer-Script
– hat einen Clientfilter, kann also einzelne Rechner zulassen oder ignorieren
– räumt alte Reader Installationen auf (Version 9 und 10) – siehe Acrobat & Reader Cleaner Tools
– besitzt umfangreiche Logging-Möglichkeiten
reagiert auf die Fehlercodes 1618 (Installer Prozess wird gerade verwendet), 1602 (Installation vom Nutzer abgebrochen) und 1603 (Installationsfehler) mit einem Retry nach 5 Minuten

Update: 28.07.2015 Version 11.0.12, getestet und läuft.

@echo on & Color 9f & setlocal
set wd=\\server\Deployment\Software\Reader
set log=%wd%\reader-log.txt
set readerEL=999
set retry=0
set forcecleanup=yes
REM:: ******************
set version=11.0.12
REM:: ******************

REM:: Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
::for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto start
::goto end

REM:: Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end

:start
if not exist %wd%\deploy\%version%\complete md %wd%\deploy\%version%\complete
if exist %wd%\deploy\%version%\complete\%computername% goto end

if "%forcecleanup%"=="yes" goto cleanup
goto install

:cleanup
echo %date% %time:~0,8% - %computername% deinstalliert alle Reader Versionen... >> %log%
REM:: uninstall all reader versions
start /w %wd%\cleaner\reader-cleaner-9.exe /silent /product=1
start /w %wd%\cleaner\reader-cleaner-10-above.exe /silent /product=1
echo %date% %time:~0,8% - %computername% hat alle Reader Versionen deinstalliert... >> %log%
goto install

:install
echo %date% %time:~0,8% - %computername% startet die Installation... >> %log%
start /w msiexec /i "%wd%\deploy\%version%\AcroRead.msi" /qn TRANSFORMS="%wd%\deploy\%version%\AcroRead.mst"
set readerEL=%errorlevel%

if %readerEL%==1618 goto retry REM:: msiexec process in use, installation already in progress
if %readerEL%==1602 goto retry REM:: user canceled installation
if %readerEL%==1603 goto retry REM:: fatal error, some use it for "already installed" (eg. java)
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%... >> %log%
if %readerEL%==0 md %wd%\deploy\%version%\complete\%computername%
goto end

:retry
if %retry%==1 goto retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry in 5min... >> %log%
set retry=1
ping localhost -n 300 > nul
goto install

:retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry failed, end >> %log%
goto end

:end
endlocal
exit

Damit das Script funktioniert, braucht ihr allerdings eine spezielle Ordnerstruktur. Ich skizziere sie mal eben schriftlich, ggf. mit Dateien:
Reader\cleaner\reader-cleaner-10-above.exe (Cleanup Tools, umbenannt)
Reader\cleaner\reader-cleaner-9.exe (Cleanup Tools, umbenannt)
Reader\deploy\[version](die in der Batch als Variable gesetzt wird)\[Dateien: AIP,.mst,usw]
Reader\deploy\[version]\complete\

Wenn ihr also in der Batch beispielsweise die Version 11.0.04.63 verteilen wollt, tragt die Version in Zeile 11 so ein und der Ordner lautet:
Reader\deploy\11.0.04.63\
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-deploy-dir

Hier ein Beispielausschnitt der Logdatei:
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-logfile

Probleme mit der Sprache?

acrobat-multilanguage-testsIst das Produkt trotz Anpassung nicht auf Deutsch? Das Problem hatte ich auch und habe einige Stunden mit verschiedensten Tests an der MST, der setup.ini und den MSI Parametern verbracht. So richtig klar wurde mir das alles nicht, ich habe nun aber einige Anpassungstipps, die das Sprachproblem beheben sollten. Lest vorher nochmal die paar Infos des Admin Guides zu den Sprachen, das erleichtert das Verständnis der folgenden Punkte.

Also, MSI in Orca laden, über Transform -> „Apply Transform“ die angepasste MST des Customization Wizards laden und ab in die Property Tabelle.
(Das ginge übrigens auch über den Customization Wizard -> Direct Editor)
Schaut hier nach folgenden Schlüsseln und passt diese ggf. an, um die deutsche Sprache einzustellen:

Propertyalter Wertneuer Wert
ProductLanguage10331031
ISLANGFLAGen_USde_DE
ProductCode{AC76BA86-7AD7-FFFF-7B44-AB0000000001}{AC76BA86-7AD7-1031-7B44-AB0000000001}

(zum Product Code lest bitte den Admin Guide)
Speichert diese Anpassungen über Transform -> Generate Transform am besten in einer seperaten MST.

Editiert dann die setup.ini vorsichthalber, sodass sie nur noch die deutsche Sprache und die neue Transorm enthält:
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-setup-ini

[Product]
msi=AcroRead.msi
Languages=1031
1031=German (Germany)	
CmdLine=TRANSFORMS="AcroRead-deu.mst"

Installiert dann den Reader entsprechend dem oben gezeigten Script, dann sollte die Installation die Anpassungen der MST beinhalten und auf deutsch sein.

Kürzer, schneller, härter

Die richtigen Pro’s werden bei den ersten Schritten den Kopf schütteln, „das geht ja alles viel einfacher, schneller, in weniger Schritten“ usw.
Ja, man kann die Anpassungen, AIP und Patches mit viel weniger Schritten abarbeiten. Der Admin Guide hat an vielen Stellen diese komplizierteren Schritte beschrieben.
2 Beispiele:
Gleich am Anfang nach dem Download per Customization Wizard die Version angepasst und dann direkt diesen Befehl genutzt:

msiexec /i AcroRead.msi PATCH="AdbeRdrUpd11001.msp; AdbeRdrSecUpd11002.msp" TRANSFORMS="AcroRead.mst"

Damit wird der angepasste Reader installiert und daraufhin mit den Patches versehen. Mehrere Patches lassen sich wie gezeigt aneinanderreihen, die Pfade sollte man lieber noch ergänzen; habe ich der Übersicht wegen weggelassen.
Oder: alternativ kann man ohne Anpassung auch die wichtigsten Eigenschaften direkt bei der Installation mit den Property-Parametern setzen:

msiexec /i AcroRead.msi PATCH="AdbeRdrUpd11004_MUI.msp" LANG_LIST=de_DE SUPPRESSLANGSELECTION=1 REMOVE_PREVIOUS=YES EULA_ACCEPT=YES SYNCHRONIZER=NO

Die CMD Möglichkeiten beim Erstellen des AIP und der Installation sind vielfältig, aber benötigen auch weit mehr Expertise.
Außerdem machen sie die Fehlersuche viel komplizierter, sollte es während eines 1-Liner zu einem Fehler kommen.
Ich war deswegen immer der Freund von ausführlichen Schritt-für-Schritt Herangehensweisen. Entscheidet selbst.

Viele komplexere Windows Installationen werden von .msi Installern durchgeführt. Diese MSI Datenpakete sind oftmals datenbankähnliche Datenstrukturen, die Informationen und Dateien für eine Installation bereithalten. Der Vorteil dieser Installer ist, dass sie sich, im Gegensatz zu .exe Dateien, einsehen und anpassen lassen. Änderungen an MSI Daten können direkt in der MSI, oder als extra Datei in Form einer .mst Datei, abgespeichert werden. So kann eine Grundinstallation in verschiedenen Formen, also eine .msi mit verschiedenen .mst Anpassungen, ausgeliefert werden.

Mit dem kleinen (retired) Microsoft Tool Orca (Parameter) lassen sich nicht nur .msi Dateien anpassen, sondern auch bestehende .mst Dateien anwenden und analysieren.

orca-msi-editor-standard

Über den Menüpunkt Transform kann man nun neue Änderungsdateien erstellen und speichern oder bestehende laden. Das ist besonders praktisch wenn man eine .mst nicht selber erstellt hat und nachsehen möchte, was konkret verändert wurde.
Beispiel: Adobe Produkte, wie z.B. der Reader oder Acrobat Professional, werden für gewöhnlich vor der Verteilung im Unternehmen mit dem Tool „Adobe Customization Wizard“ angepasst. Dieses Tool erstellt mit den gewünschten Anpassungen (Sprache, Pfad, Serial usw.) eine fertige .mst Datei, mit der man die Verteilung starten kann. Mit Orca kann man nun vorher diese .mst Datei laden und nachsehen, ob soweit alles stimmt.

orca-msi-editor-mst-transform-file-view

Im Fenstertitel sind die verknüpften .msi und .mst Dateien vermerkt, in der Oberfläche sind angepasste, hinzugefügte und entfernte Daten grün markiert. Nützlich, was?

Ich komme später nochmal darauf zurück, in welchen Fällen das besonders sinnvoll sein kann 😉

Die Windows Indizierung verbessert die Windows Suche und ergänzt sie um Dateien, Dateiinhalte und sogar E-Mails, Kalendereinträge und andere Daten, falls Microsoft Produkte wie Outlook genutzt werden.
Sollte es bei der Suche (sowohl in Windows als auch in Outlook) zu Problemen kommen, hilft das Zurücksetzen der Windows Suche bzw. das Neuerstellen des Suchkatalogs.

Händisch:
Dies geht relativ einfach über Start -> Indizierungsoptionen -> Erweitert -> Neu erstellen.
Dadurch wird der Suchkatalog gelöscht und alle gespeicherten Orte neu indiziert.

Für Administratoren ist es aber viel wichtiger, diese Aktion verteilen zu können. Dafür gibt es eine Registry Lösung, die bewirkt, dass die komplette Windows Suche zurückgesetzt wird. Hierbei werden alle Orte gelöscht, Einstellungen zurückgesetzt und der Katalog neu erstellt.

Registry:
Der Schlüssel

HKLM\SOFTWARE\Microsoft\Windows Search

enthält das Wertepaar „SetupCompletedSuccessfully“, welches für gewöhnlich auf „1“ gestellt ist. Den Wert auf 0 zu setzen kommt einem Reset des Dienstes gleich.

Am besten eignet sich hierfür ein Script:

@echo on & Color 9f & setlocal
set regEL=9

REM stop windows search service
net stop wsearch

REM reset search settings/catalog by resetting reg key
reg add "HKLM\SOFTWARE\Microsoft\Windows Search" /f /v "SetupCompletedSuccessfully" /t REG_DWORD /d "0"
set regEL=%errorlevel%
move "%programdata%\microsoft\search\data\applications\windows\Windows.edb" "%programdata%\microsoft\search\data\applications\windows\Windows.edb.bak"
REM to be sure:
del "%programdata%\microsoft\search\data\applications\windows\Windows.edb"

REM start windows search service
net start wsearch

endlocal

Ich habe heute ein Script zusammengebastelt, welches den Windows 7 und den Office 2007 Lizenz-Key des Computers ausliest und ihn in eine Textdatei speichert. Die Textdatei entspricht dem Computernamen zur einfachen Zuordnung von PC und Key. Das Script läuft komplett selbstständig, kann also z.B per Gruppenrichtlinie automatisch ausgeführt werden.
Code-Grundlage ist dieser Forum Post.

Ich habe den Code bereinigt, gekürzt und um die Erkennung von Office 2007 erweitert. Das Script erkennt außerdem, ob das System mit 32bit oder 64bit läuft und passt die Erkennung dementsprechend an.

Hier der verbesserte Code:

On Error Resume Next
Dim WshNetwork
Set WshNetwork = CreateObject("WScript.Network")
cName = WshNetwork.ComputerName
Set WshShell = CreateObject("WScript.Shell")
' detect processor architecture, returns 32 or 64
pa = GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth
' get current path
set fso = CreateObject("Scripting.FileSystemObject")
logpath = fso.BuildPath(fso.GetAbsolutePathName("."), "Keys.txt")
'logpath = "\\server\path\to\log.txt" 'for servers

' ----------- Windows 7 Key -----------
wkey = "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\"
wdigitalId = WshShell.RegRead(wkey & "DigitalProductId")
wProductName = "Product Name : " & WshShell.RegRead(wkey & "ProductName") & vbNewLine 
wProductId   = "Product Id   : " & WshShell.RegRead(wkey & "ProductId") & vbNewLine 
wProductKey  = "Install Key  : " & Converted(wdigitalId)

windowsData = wProductName & wProductId & wProductKey
' ----------- Windows 7 END -----------

' ----------- Office 2007 Key -----------
'32bit or 64bit?
If pa = "32" Then
	okey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\ Registration\{90120000-0011-0000-0000-0000000FF1CE}\DigitalProductID\"
Else
	okey = "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\Registration\{91120000-00CA-0000-0000-0000000FF1CE}\"
End if

odigitalId = WshShell.RegRead(okey & "DigitalProductID")    
If (IsEmpty(odigitalId)) Then 
    officeData = "Office 2007 not found"
Else
    oProductKey  = "Install Key  : " & Converted(odigitalId)
    oProductName = "Product Name : " & WshShell.RegRead(okey & "ProductName") & vbNewLine 
    oProductId   = "Product Id   : " & WshShell.RegRead(okey & "ProductId") & vbNewLine 
    officeData = oProductName & oProductId & oProductKey
End If

' ----------- Office 2007 END -----------

Save()

Function Converted(id)
    Const OFFSET = 52
    i = 28
    Chars = "BCDFGHJKMPQRTVWXY2346789"
    Do
        Cur = 0
        x = 14
        Do
            Cur = Cur * 256
            Cur = id(x + OFFSET) + Cur
            id(x + OFFSET) = (Cur \ 24) And 255
            Cur = Cur Mod 24
            x = x -1
        Loop While x >= 0
        i = i - 1
        Converted = Mid(Chars, Cur + 1, 1) & Converted
        If (((29 - i) Mod 6) = 0) And (i <> -1) Then
            i = i -1
            Converted = "-" & Converted
        End If
    Loop While i >= 0
End Function

Function Save()
  WScript.Echo "Save to: " & logpath
  Set file = CreateObject("Scripting.FileSystemObject").CreateTextFile(logpath,2,0)
  file.Writeline(FormatDateTime(Date, vbLongDate) & vbNewLine)
  file.Writeline(windowsData & vbNewLine) 'Windows 7
  file.Writeline(officeData & vbNewLine) 'Office 2007
  file.close
End Function

Ergebnis:
windows-7-office-2007-key-reading-decrypting-script

Den Logpath in Zeile 7 müsst ihr anpassen. Ihr könnt diese Zeile auch komplett entfernen und die Zeile 61 anpassen („logpath &“ entfernen), dann wird die Logdatei immer im selben Ordner mit der .vbs erstellt. Dann ist das Script allerdings nicht mehr GPO tauglich. Für GPO Verteilung via Computer-Startscript müsst ihr den Pfad im Script explizit angeben.

Hinweis: Die Erkennung des Windows Keys funktioniert bei der Enterprise Version voraussichtlich nicht. Bei Windows Server 2008 R2 (Standard) funktioniert es.
Es ist etwas erschreckend wie schlecht die Keys geschützt waren. Ich weiß nicht, ob sich diese Methode auch für andere Versionen von Windows oder Office verwenden ließe. Vielleicht ist hier ein ITler mit WinXP, Office 2k3 o.Ä. und schaut mal in der Registry nach.