In dem unwahrscheinlichen Fall, dass dies bei einer produktiven Installation passiert, würde ich den sauber Weg empfehlen und den SQL Server wieder deinstallieren und mit der richtigen Collation (=Sortierreihenfolge) neuinstallieren. Die Richtige ist übrigens SQL_Latin1_General_CP1_CI_AS:

Sind noch keine Benutzerdatenbanken auf dem SQL Server installiert, dann kann man auch die Collation direkt mit dem SQL Setup ändern lassen:

Dazu startet man das SQL Setup (z.B. von der DVD) mit folgendem Aufruf (in einer Zeile!):

setup.exe /quiet /action=rebuilddatabase /sqlcollation=SQL_Latin1_General_CP1_CI_AS
     /instancename=MSSQLSERVER /SQLSYSADMINACCOUNTS=BUILTIN\Administrators

Dies ist die minimale Anzahl an Parametern, die man übergeben muss. In diesem Beispiel soll die Stanardinstanz (interner Name MSSQLSERVER) aktualisiert werden. Berechtigung erhält die lokale Administratorgruppe des Servers. Bei einem deutschen Server heißt diese natürlich Administratoren.

Da das Setup silent ausgeführt wird, sieht man auch keine Fehlermeldungen. Wie bei einem SQL Setup üblich, landen die Installationslogs unter c:\programme\Microsoft SQL Server\100\Setup Bootstrap\Log\<datum+uhrzeit>\Detail.log

Hier nochmal die Kommadozeile als Screenshoot:

Manchmal ist es schwierig den passenden Treiber zu finden. Hilfreich dabei ist die PCI Device ID. Mit dieser eindeutigen ID kann man den Hersteller (VEN_XYZ) und das entsprechende Gerät (DEV_…) über eine Google Suche ermitteln.

Um diese ID zu ermitteln muss man zuerst die Kommandozeilen Option im WinPE Boot Image aktivieren (Eigenschaften des Images).

Danach kann man per F8 eine Kommandozeile auf dem System mit den fehlenden Treibern starten und per

wmic nic get PNPDeviceID

bzw.

wmic idecontroller get deviceid

die IDs ermitteln. Ein Beispiel der Ausgabe ist im folgenden Bild dargestellt:

Relevant sind hier nur die PCI\VEN… Einträge.

Also, da man nicht nur schimpfen soll, sondern auch loben: Gut so (und ich hoffe es bleibt auch im RTM so )

Folgende Änderungen wurden dabei gemacht:

The September 2011 release (version 6.0.6957.0) of the System Center Monitoring Pack for the Windows Server Operating System includes the following changes:

• Optimized operating system performance collection rules.
• Added two new operating system-specific reports:
  • Performance by System
  • Performance by Utilization

• Added support for the Server Manager Best Practices Analyzer (BPA). The monitoring pack now collects BPA results from monitored servers and returns the BPA state to Operations Manager.
• Added support to discover and monitor Cluster Shared Volumes (CSV).
• Modified collection rules to include the latest service packs and hotfixes.
• Changed the threshold for the “Average Disk Seconds Per Read”, “Average Disk Seconds Per Transfer”, and “Average Disk Seconds Per Write” monitors to 0.04.
• Added new monitors for “Disk $ Idle Time” and “Current Disk Queue Length”.
• Changed the monitor types for disk performance from Average Samples to Consecutive Samples to reduce noise and improve collected data.
• “Logical Disk Availability Monitor” has been renamed to “File System Error or Corruption”.

Auch das SCCM 2007 Management Pack wurde aktualisiert. Wichtige Neuerungen sind:

• Added Support for 64-bit Operations Manager 2007 R2 Agent
• Added Support for Configuration Manager 2007 Features
• Und viele weitere Monitore zur Überwachung von Teilbereichen von SCCM.

Hier die direkten Links:

Neue Management Packs im Zeitraum zwischen 17.09.2011 und 01.10.2011 :

• Microsoft System Center Configuration Manager 2007 6.0.6000.3
• Windows Server 2000 Operating System 6.0.6957.0
• Windows Server 2003 Operating System 6.0.6957.0
• Windows Server 2008 Operating System (Discovery) 6.0.6957.0
• Windows Server 2008 Operating System (Monitoring) 6.0.6957.0
• Windows Server 2008 R2 Best Practice Analyzer Monitoring 6.0.6957.0
• Windows Server Cluster Shared Volume Monitoring 6.0.6957.0
• Windows Server Operating System Library 6.0.6957.0
• MP Guide Configuration Manager 2007 SP2
• MP Guide Core OS

Eine Beispiel-Config kann so aus sehen: (innerhalb des umgebenen <Configuration> Bereichs)

<Display Level="none" CompletionNotice="no" SuppressModal="no" AcceptEula="yes" />
<Logging Type="Verbose" Path="%temp%" Template="VisioProject_Setup(*).txt" />
<USERNAME Value="Benutzername" />
<COMPANYNAME Value="Firma" />
<PIDKEY Value="abcdefg" />
<INSTALLLOCATION Value="%programfiles%\Microsoft Office" />

Interessant wird es beim PIDKEY. Office 2010 kann wie Windows Vista oder Win7 mithilfe eines KMS aktiviert werden. Diese Möglichkeit sollte man auch wenn irgend möglich verwenden. Microsoft installiert grundsätzlich bei Visio und Project die Premium Version. Als diese Version versucht sich das Produkt danach auch am KMS zu aktivieren. Möchte man eine andere Version verteilen, so muss man bei PIDKEY den jeweiligen KMS Standardkey hinterlegen (Achtung! Dies ist nicht der KMS Key zur Aktivierung des KMS Servers!!!). Den Key finden man auf den Microsoft Webseiten:

Für Visio:

http://technet.microsoft.com/de-de/library/ee624357.aspx

Für Project:

http://technet.microsoft.com/en-us/library/ee624355.aspx

Zum Schluss sollte man noch das aktuelle Service Pack (aktuell: 1) herunterladen und die EXE mittels 7Zip öffnen. Die Darin enthaltenen MSP Dateien landen dann im jeweiligen Updates Verzeichnis. Das hat zur Folge, dass direkt beim Setup das entsprechende Service Pack mitinstalliert wird. Wenn man sich die Mühe machen möchte, dann kann man natürlich auch die jeweiligen Hotfixe dort ablegen.

Eine liste mit Downloadlinks zu allen Office 2010 SP1 Installationspaketen finden man hier:

http://support.microsoft.com/kb/2510690/de

Die SCCM Produkt Gruppe hat zu diesem Problem bereits einen Workaround beschrieben, der anhand der Anleitung auch sehr gut umzusetzen war:

http://blogs.technet.com/b/configmgrteam/archive/2011/08/17/known-issue-and-workaround-duplicate-records-when-you-use-unknown-computer-support-with-active-directory-delta-discovery.aspx

So kann man einen Aufruf von %windir%\system32\regedit.exe ersetzen durch %windir%\sysnative\regedit.exe. Im WOW64 Kontext wird dieser Alias erkannt und durch den Verweis auf die 64bit Variante ersetzt.

Details dazu sind auch in der MSDN von Microsoft zu finden: http://msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29.aspx

Mir ist keine SCCM interne Möglichkeit bekannt dies umzusetzen. Auch eine versuchsweise erstellte Tasksequenz, die nur die Treiberauswahl beinhaltet bricht auf einem Zielsystem ab, da es nicht im richtigen Kontext (WinPE) ausgeführt wird.

Daher habe ich durch die Ergänzung des Treiberpaketes durch drei Dateien diese Möglichkeit geschaffen. Dazu verwende ich dpinst.exe. Das ist ein Tool von Microsoft, um Treiberpakete (DP) zu verwalten und zu installieren. Treiberpakete sind im Grunde nichts weiteres als ein Verzeichnis, in dem in Unterordner verschiedene Treiber und deren INF Dateien liegen – also exakt das, was ein Driver Package bei SCCM auch ist .

Das Programm findet man im Windows Driver Kit (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11800). Dazu lädt man sich das ISO File herunter und öffnet es mit 7Zip (oder mountet es in einem virtuellen CD Laufwerk).

Im Unterordner WDK ist die Datei je nachdem ob man x64 oder x86 Betriebsysteme hat im File dfx_x64fre_cab001.cab bzw. dfx_x86fre_cab001.cab zu finden und kann erneut direkt in 7Zip geöffnet werden. Daraus einfach die _dpinst.exe_00005 extrahieren und in dpinst.exe umbenennen.

Die dpinst.exe legt man dann in das Root-Verzeichnis des Treiberpakets und ergänzt diese um zwei weitere Dateien:

dpinst.xml:

    *

und zum Starten der Installation:

Rundpinst.cmd:

"%~dp0dpinst.exe" /SA /Q /SH /SE /C /SW

dabei werden die passenden und neueren PNP Treiber ermittelt und ohne nachfrage installiert. Ein automatischer Neustart erfolgt nicht.

<pre>
NET STOP WUAUSERV
NET STOP BITS

rem sicherstellen das vbs funktioniert:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /t REG_DWORD /d 1 /f

rem gegen Fehler 1026?
rd /s /q "%systemroot%\SoftwareDistribution"
regsvr32 /s cdm.dll
regsvr32 /s bitsprx2.dll
regsvr32 /s bitsprx3.dll
regsvr32 /s iuengine.dll
regsvr32 /s qmgr.dll
regsvr32 /s qmgrprxy.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml2.dll
regsvr32 /s msxml3.dll
regsvr32 /s urlmon.dll
regsvr32 /s wuapi.dll
regsvr32 /s wuaueng.dll
regsvr32 /s wuaueng1.dll
regsvr32 /s wuauserv.dll
regsvr32 /s wucltui.dll
regsvr32 /s wups.dll
regsvr32 /s wuweb.dll

sc sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

NET START BITS
NET START WUAUSERV
regsvr32 /s softpub.dll
regsvr32 /s initpki.dll
regsvr32 /s mssip32.dll
regsvr32 /s wintrust.dll
regsvr32 /s dssenh.dll
regsvr32 /s rsaenh.dll
regsvr32 /s gpkcsp.dll
regsvr32 /s sccbase.dll
regsvr32 /s slbcsp.dll
regsvr32 /s cryptdlg.dll
regsvr32 /s jscript.dll

Es stoppt zuerst die Dienste, stellt sicher, dass VBS Script funktionieren, registriert notwendige XML, Windows Update und Bits Bibliotheken, korrigiert die Sicherheitseinstellungen des Windows Update Dienstes, löscht den lokalen Cache und registriert am Ende nochmal die PKI Bibliotheken.

Das Ganze kann man dann natürlich auch remote anstoßen:

@echo off
set PC=%1
if .%PC%==. set /p PC=Enter Computer Name to start repair:
call %~dp0findip.bat %PC%
if %ip%.==. goto fehler
echo Start Windows Update Agent Installation %PC%
call updatewua.cmd %pc%
echo Versuche Reparatur des Windows Update Agents
psexec \\%PC% /c /f %~dp0repair.cmd
goto ende
:fehler
echo Abbruch, da Rechner %PC% auf ping nicht antwortet.
:ende
set ip=

makeccrall.cmd:

for /F %%i in ('cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 smsserver sitecode') do call %~dp0makeccr.bat %%i

(auch hier wieder smsserver und sitecode durch die korrekten Daten ersetzen)

Alterntiv möchte man eventuell die Installation erzwingen, d.h. egal ob ein Client vorhanden ist oder nicht soll dieser auf jeden Fall installiert und gegebenenfalls repariert werden. Dazu muss in der CCR Datei ein zusätzlicher Parameter angegeben werden. Hierfür ist die Batchdatei forcemakeccr.cmd zuständig:

@echo off
set PC=%1
set sitecode=SMS
set siteserver=SMSSERVER
if .%PC%==. set /p PC=Enter Computer Name to install SMS Client:

call %~dp0findip.bat %PC%
if %ip%.==. goto ende

:testdomain
echo Computer:%PC%

:weiter
set output="%temp%\%PC%.ccr"
echo [NT Client Configuration Request]>%output%
echo   Client Type=1>>%output%
echo   Machine Name=%PC%>>%output%
echo   Forced CCR=TRUE>>%output%
copy %output% \\%siteserver%\sms_%sitecode%\inboxes\ccr.box\
dir  \\%siteserver%\sms_%sitecode%\inboxes\ccr.box
del %output%

:ende
set output=
set ip=
set d=

Der einzige Unterschied ist in Zeile 18 mit Force CCR=TRUE zu finden.

Daher sieht auch die forcemakeccrall.cmd, um eine komplette Collection neu installieren zu lassen identisch aus:

for /F %%i in ('cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 smsserver sitecode’) do call %~dp0forcemakeccr.cmd %%i