<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=

Im Teil 2 wurde die Batch und vbs Datei vorgestellt, um auf eine Reihe von Clients die Hardwareinventur anzustossen.

Dies geht genauso mit dem Computer Policy Update:

startmachineupdate.cmd

@echo off
set PC=%1
if .%PC%==. set /p PC=Enter Computer Name to start HINV:
call %~dp0findip.bat %PC%
if %ip%.==. goto fehler
echo Start Machine Policy Update %PC%
cscript.exe //Nologo %~dp0sendsched.vbs {00000000-0000-0000-0000-000000000021}  %PC%
goto ende
:fehler
echo Abbruch, da Rechner %PC% auf ping nicht antwortet.
:ende
set ip=

und die dazugehörige startmachineupdateall.cmd:

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

Benötigt dazu wird findip.bat und getcomputer.vbs aus Teil 1 bzw. Teil 2.

Es korrigiert einen recht störenden Agent Update Bug im CU4 (beim Update des Agents, der normalerweise kein Neustart des Servers benötigt wurden automatisch andere Dienste neugestartet und hat somit zu Serviceunterbrechungen geführt) und ein paar andere Fehler. Zusätzlich beinhaltet es den Agent für Red Hat 6.

Zu finden ist es unter http://support.microsoft.com/kb/2495674.

Bei Antivirendefinitionen macht ein solches Vorgehen keinen Sinn. Tests gegen alte und neue Viren oder gegen bestimmte Clients, um False-Positives zu erkennen kann man ein paar Mal machen, sobald Updates mehrfach am Tag kommen ist dies nicht mehr sinnvoll.

Forefront Client Security 2010 integriert sich so tief in den SCCM, dass auch für die Definitionsverteilung der SCCM genutzt werden kann. Hat dieser keine aktuellen Definitionen, so kann der Client auf eine Freigabe (UNC-Pfad), einen WSUS oder Microsoft Updates ausweichen. Als WSUS wird natürlich der auf dem Client hinterlegte verwendet, der bei einem SCCM Client immer der vom Server gemanagte WSUS sein muss.

Daher wäre es wünschenswert, wenn dieser die Definitionsupdates automatisch freigibt. Generell ist es nicht empfehlenswert in einen vom SCCM verwalteten WSUS einzugreifen. In diesem Szenario ist es die einzige sinnvolle Lösung.

Um das (von mir ebenfalls schon umgesetzte) Verfahren nicht erneut beschreiben zu müssen, verlinke ich einfach auf den nachfolgenden Blog Post:

Approve updates for Forefront Endpoint Protection 2010

Der Abbruch ist deswegen relevant, da u.U. das WoL nicht funktioniert. Startet der Benutzer am nächsten Morgen den PC wieder ganz normal an, so würde die Installation direkt startet und er könnte ein paar Stunden nicht arbeiten. Daher stoppt das Script die Installation automatisch, falls sie nicht innerhalb eines bestimmten Zeitfenster gestartet werden konnte.

Abgebrochen wird die Installation “zur Sicherheit” auf zwei Wegen: Zuerst wird das Computerkonto im Enteo deaktiviert. Danach wird über die Policy-ID die entsprechende OS Installation gestoppt. Diese Policy_ID kann man über Powershell ermitteln, indem man z.B. alle an einem zur Reinstallation vorgesehenen PC angehängten Policies ausgeben lässt und die gewünschte Policy anhand des Namens identifiziert. Natürlich muss die Funktion zum Anstossen der Installation diese Policy auch wieder aktivieren.

Nachfolgend die Funktion zum Starten des OS-Rollouts: Beide Funktionen benötigen als Übergabeparameter des EmDB-Computer Objekt der NWC Powershell Bibliothek:

function doReinstall
{param($PC,[string]$WOL)
      Reinstall-EmdbComputer $PC.path -StartImmediately -RecalculateInstallationOrder | out-null
      $policy=(Get-EmdbPolicyInstance $pc | where {$_.AssignedObjectID -eq $PolicyToDeactivate})
      $policy.isActive=$true
      $policy.update()
}

In Zeile 3 wird die eigentliche Neuinstallation des PCs angestossen. Die Umleitung nach out-null unterdrückt die Ausgabe der Funktion und ermöglicht so eine sauberere Protokollierung. Interessanter wird es in Zeile 4.
EmdbPolicyInstance ist die Verbindung zwischen einem Objekt (PC) und der zugeordneten Policy. Anhand der Policy ID (AssignedObjectID) kann die beim Stoppen deaktivierte Policy ermitteln und sicherheitshalber wieder aktiviert werden. Ändert man direkt Eigenschaften eines Objekts so müssen diese Änderungen per update() wieder zurückgeschrieben werden. Führt man eine Methode wie Reinstall-EmdbComputer aus, so ist dies nicht notwendig.

Und nun die Funktion zum Stoppen einer Installation:

function doStopInstall
{param($pc)
 $pc.deactivate()
 $policy=(Get-EmdbPolicyInstance $pc | where {$_.AssignedObjectID -eq $PolicyToDeactivate})
 $policy.isActive=$false
 $policy.update()
}

Diese Funktion ist analog zur obigen aufgebaut. Zuerst wird der PC deaktiviert. Danach wird erneut die PolicyInstance gesucht und ebenfalls deaktiviert.

client,OU,User,Mac,OS,Softwareliste

• Client: Name des neuen Computers
• OU: Abteilungsname (wird als OrganisationalUnit abgebildet)
• User: Benutzername (wird in Description hinterlegt)
• Mac: MAC-Adresse des Computers (wird in InitialMacAddress hinterlegt)
• OS: Gruppe, in der der Computer für die OS-Installation eingeordnet werden muss
• Softwareliste: CSV Liste der zuzuordnenden Software (muss in ” stehen)

Somit sieht das Powershell Script so aus:

Add-PSSnapin NwcServices.BlsAdministration

$server="\\enteowsserver"
$csvfile="C:\computerliste.csv"

function createOU
{param([string]$name,$ou)
  cd $ou.path
  $ouRT=Get-EmdbOrganizationalUnit -recurse $name
  if (-not $ouRT) {
    $name.toCharArray() | foreach
    {
      $ouname=$ouname + $_
      $oupath=$ou.path + "\" + $ouname
      $ou=Get-EmdbOrganizationalUnit -recurse $ouname
      if (-not $ou)
      {
        $ou=new-EmdbOrganizationalUnit -Path $oupath
      }
    }
    $ou
  }
  else
  {
    $ouRT
  }
}

New-PSDrive -Name emdb -psProvider BlsEmdb -Root $server
cd "emdb:\rootdse"

$csv=import-csv $csvfile

$csv | forEach-Object
{
  if (-not $_.client -eq "")
  {
    $ou=Get-EmdbOrganizationalUnit -recurse "Powershell"
    $ou=createOU $_.OU $ou
    cd "emdb:\rootdse"
    $filter="Computer.InitialMACAddress="+$_.Mac
    $pc=Get-EmdbComputer -recurse -filter $filter
    if (-not $pc)
    {
      $pc=New-EmdbComputer -Path $ou.path -Name $_.client -description $_.user -InitialMACAddress $_.mac
    }
    else
    {
      if (-not ($pc.Name -eq $_.client))
      {
        $pc.name=$_.client
        $pc.update()
      }
      if (-not ($pc.description -eq $_.user))
      {
        $pc.description=$_.user
        $pc.update()
      }
    }
    if (-not ($ou.path -eq $pc.getParentContainer().path))
    {
      $pc.moveTo($ou)
    }
    $grp=get-emdbgroup -recurse $_.OS
    $grp.addMember($pc)
    $sw=$_.Softwareliste.split(",")
    $sw |foreach
    {
      if (-not $_ -eq "")
      {
        $grp=get-emdbgroup -recurse $_
        if ($grp)
        {
          $grp.addMember($pc)
        }
      }
    }
  }
}

• Automatic Updates mit SCCM: zuerst wird ein Update nur als metadata veröffentlicht ohne das eigentliche Update herunterzuladen. Bei einer späteren Synchronisation ließt der SCUP aus dem SCCM (System Center Configuration Manager 2007 oder höher) aus, ob Clients dieses update benötigen. Ist dies der Fall, dann lädt er das komplette Update herunter und stellt es in den WSUS zur Verteilung bereit
• Software update Cleanup Wizard: Ermöglicht es nicht mehr benötigte Updates zu bereinigen, indem sie auf expired gesetzt werden
• …

Herunterzuladen ist das Tool unter http://www.microsoft.com/downloads/en/details.aspx?FamilyID=083f45ca-1ede-4f7a-be74-77854c3a9b01.

Eine gute Installationsanleitung ist hier zu finden: http://blogs.technet.com/b/jasonlewis/archive/2011/05/24/getting-started-with-updates-publisher-2011.aspx (Keine Bilder, aber dafür alle wesentlichen Punkte enthalten, ich konnte problemlos nach ein “Upgrade” machen, daher werde ich es nicht nochmal hier beschreiben)

Meine Vorgehensweise zum Publizieren von Updates (nachdem die Konfiguration inkl. WSUS und SCCM abgeschlossen ist):

• Importieren der ausgewählten Kataloge
• Auswahl aller Updates auf oberster Ebene
• Publish drücken und dabei Automatic auswählen
• WSUS Sync in der SCCM Konsole anstoßen
• etwas warten, damit Clients einen Scan mit dem neuen Katalog ausgeführt haben (oder einen Scan auf einem oder mehreren Clients manuell starten)
• Erneuten Sync im SCUP mit Automatic: jetzt lädt er die benötigten Updates herunter
• Verteilung der benötigten Updates im SCCM wie normale Windows Updates

Insgesamt eine wirklich gelungene Aktualisierung mit der der SCUP endlich erwachsen wird.

Es verwendet ebenfalls auf dem zu überwachenden Server den SCOM 2007 R2 Agent und unterstütz dabei Multihome, d.h. man kann auch parallel seinen eigenen SCOM Server weiterbetreiben. SCA liefert eigene Management Packs mit, die speziell für SQL Server optimiert wurden. So werden fehlende Microsoft Updates (die nicht im Windows Update Katalog sind) angezeigt, nicht optimale TempDB Einstellungen, … aufgelistet.

Der SCOM Agent sendet nicht direkt zu Microsoft, sondern packt die SCOM Informationen (Alerts, Konfigurationsinformationen), die als einzelne XML-Dateien vorliegen zu CAB-Dateien zusammen in legt sie unter

%programFiles%\System Center Advisor\Mailbox\outbox

ab. Diese werden zu bestimmten Zeitpunkten am Tag (minimal per Registry auf alle 12h einstellbar) genommen (Tipp: startet man den SCOM Agent (der SCA Agent hat keinen eigenen Dienst, sondern wird über den SCOM Agent gesteuert) neu, dann werden die CAB Dateien sofort verschickt) und per http an den im Unternehmen zu installierenden SCA Gateway Server geschickt (Achtung: der hört auf Port 80 und ist nicht im IIS integriert – kann somit nicht auf einem System mit IIS oder einen anderen Webserver auf Port 80 installiert werden).

Die verschickte CAB Datei landet dann auf dem Agent unter

%programFiles%\System Center Advisor\Mailbox\send Items

Auf dem Gateway  landen die empfangenen CAB Dateien unter fromAgent Verzeichnis unter

%programFiles%\System Center Advisor\GatewayData\Mailboxes\<guid>

In diesem Verzeichnis liegt eine machine.xml Datei, in der unter anderem der Agent-Servername zu finden ist. Nach einem Upload zu Microsoft (auch über einen Webservice) landen die Dateien unter

%programFiles%\System Center Advisor\GatewayData\Mailboxes\<guid>\Uploaded\*.cab

Auch hier beschleunigt ein Neustart des Dienstes den Upload zu Microsoft. Durch zwei Dienstneustarts (erst Agent dann Gateway) kann man im Gegensatz zur Dokumentation sofort Daten zu Microsoft schicken, die dort wohl auch sofort verarbeitet und auf der Webseite angezeigt werden.

(Das Update ist nicht für Ihren Computer geeignet), der kann mit folgendem Skript aus dem Technet (s.u. Kommentare, http://technet.microsoft.com/en-us/library/ee449475%28v=ws.10%29.aspx) die Installation trotzdem durchführen:

Für das x86 RSAT:

(x86.cmd)

MD C:\RSAT
expand -f:* "%~dp0x86fre_GRMRSAT_MSU.msu" C:\RSAT
CD\RSAT
pkgmgr.exe /n:C:\RSAT\Windows6.1-KB958830-x86.xml
pause

Für das 64-bit RSAT:
(x64.cmd)

MD C:\RSAT
expand -f:* "%~dp0amd64fre_GRMRSATX_MSU.msu" C:\RSAT
CD\RSAT
pkgmgr.exe /n:C:\RSAT\Windows6.1-KB958830-x64.xml
pause

Daher habe ich mir ein kleines Script geschrieben, dass die MP-Änderungen innerhalb eines Zeitraumes ausließt und ausgibt. Ich werde demnächst einmal die Woche diese Liste hier posten. (Momentan noch halbautomatisch und demnächst hoffentlich automatisiert.)

Damit man sich selber dauerhaft einen Überblick über die Aktualisierungen machen kann, sind alle Post dazu mit dem Tag SC Software Updates markiert und lassen sich über den RSS Feed abonnieren (http://www.mbaeker.de/tag/sc-software-updates/feed/).

Neue Management Packs im Zeitraum zwischen 04.02.2011 und 06.03.2011

• Microsoft.Fep2010.Monitoring.DEU 2.0.697.0
• Microsoft.Fep2010.Monitoring.FRA 2.0.697.0
• Microsoft.Fep2010.Monitoring.JPN 2.0.697.0
• Microsoft.Fep2010.Monitoring.RUS 2.0.697.0
• Microsoft.Fep2010.Monitoring.CHS 2.0.697.0
• BizTalk Server Discovery 7.0.389.0
• BizTalk Server Library 7.0.389.0
• BizTalk Server Monitoring 7.0.389.0
• Microsoft HPC Library 3.1.3266.0
• Microsoft HPC Server 2008 R2 3.1.3266.0
• Microsoft Windows DNS 2003 Server 6.0.7000.0
• Microsoft Windows DNS 2008/R2 Server 6.0.7000.0
• Microsoft Windows DNS Server Library 6.0.7000.0
• MP Guide BizTalk 2010
• MP Guide Chinese Simplified
• MP Guide Domain Naming Service 2003
• MP Guide Domain Naming Service 2008
• MP Guide Forefront Endpoint Protection Server Health
• MP Guide French
• MP Guide German
• MP Guide HPC Server 2008 R2
• MP Guide Japanese
• MP Guide Russian