Hallo Zusammen!

 

Knapp zwei Monate nach wannacry und wir spüren immer noch die Nachbeben.
Ich erspare uns das nochmalige Nachbeten der Details – die gibt es ohnehin hier

 

Wir wissen ja, dass Maschinen hauptsächlich durch das Fehlen eines vorab veröffentlichten Sicherheitspatches infiziert worden sind. Somit wäre der Großteil des Desasters vermeidbar gewesen.

Warum wird Patching so stiefmütterlich behandelt? Darüber könnten wir einen ganzen Tag diskutieren.
Aber erstellen wir eine Kette um einen der Hauptgründe zu identifizieren:

1. Es muss sichergestellt werden, dass Unternehmenssoftware auch nach dem Einspielen von Patches noch läuft und keine Probleme zu erwarten sid

2. Administratoren brauchen Kontrolle über den Patchprozess, um dies sicherzustellen

3. Administratoren brauchen Zeit, um die obige Kontrolle auszuüben

4. Zeit ist richtig teuer und, ich erinnere mich an BWL, ein „knappes Gut“

 

Also: Keine Zeit = kein Patch

 

Wo kommt jetzt Solarwinds ins Spiel? Das Beste wäre natürlich dieses neue Produkt auf das alle warten, GITDLM – GetIntoTheDeLoreanManager - um in der Zeit zu reisen, aber das steckt aus unbekannten Gründen im QA Prozess fest. Seit Jahren!

Hier ist das einzige existierende Foto der Betaversion:

DeLorean

 

Zukunftsmusik!

 

Also schauen wir uns einmal den Patch Manager an.
Dies ist hier das erste von zwei Blogeinträgen und ich will den Hintergrund sowie den Installationprozess erklären.

Patch Manager, oder auch SPM, setzt auf bestehende Microsoft Infrastruktur auf und nutzt den WindowsUpdateAgent um nicht-MSFT Updates zu verteilen, und benötigt eine WSUS oder SCCM Umgebung.
SPM wird meist auf der gleichen Box installiert auf der der WSUS läuft und benötigt eine SQL DB im Hintergrund.

Da die Menge an Daten üblicherweise ziemlich gering ist, kann die SQL Express Version tatsächlich ausreichend sein.

Bedient wird SPM innerhalb einer MMC und diese kann problemlos auf einer Workstation installiert werden. Ebenso gibt es eine Komponente die SPM in ein bestehendes Orion System integrieren kann.

 

Aber mal von Anfang an!

 

Hier die Auswahl der Optionen, wir folgen dem Standard:

 

Dann klicke ich auf Express

 

 

Express installiert einen WSUS sowie eine SQL Express lokal und stellt keine dummen Fragen
Für einen Produktivbetrieb würde ich natürlich die zweite Variante auswählen und meinen eigenen WSUS einhängen, sowie optional auf eine dedizierte SQL verweisen.

 

Das hier dauert ein Weilchen:

 

 

Dieses Fenster kommt beim Starten:

 

 

 

Dann wird ein Benutzer angelegt, dies sollte ein lokaler Admin sein:

 

 

 

Okay das hier klingt verlockend, aber ich gehe die Schritte manuell mit euch durch damit ihr wisst, was passiert. Also bitte die Box abwählen und das Fenster schliessen:

 

 

 

In der MMC links oben klickt auf Enterprise --> Update Services und überprüft ob der WSUS da ist:

 

 

 

Schaut vielleicht auch einmal unter Patch Manager System Config --> Security and User --> Credential Ring und klickt auf Default, dann „next“.
Es sollte etwa so aussehen:

 

 

Hier kann man später bei einem Produktivsystem verschiedene Benutzerkonten zuweisen.
Wenn alles passt, cancel und tschüss.

 

An dieser Stelle würde man jetzt den WSUS einrichten. Das kann man entweder in der WSUS Konsole selbst erledigen oder aber im Patch Manager beim Klick auf den WSUS ganz rechts die folgenden Optionen:

 

 

 

Das Auswählen der Produkte (Windows/Exchange etc) und setzen weiterer WSUS-spezifischer Optionen erkläre ich an dieser Stelle nicht und verweise faul auf die Suchmaschine eurer Wahl.
Gehen wir davon aus, dass WSUS eingerichtet ist und ein paar Clients dranhängen, und machen weiter.

 

Wechselt zu Patch Manager System Config --> Management Groups --> Managed Enterprise und klickt auf den Server, dann rechts auf „Schedule Inventory“

 

Setzt die Frequenz etc wie es passt, hier ein Beispiel:

 

 

 

Ein paar Auswahlmöglichkeiten – beim Klick auf eine Zeile sieht man eine Erklärung

 

 

 

Wir haben gerade unsere erste Aufgabe angelegt!
Verifiziert schnell unter Administration and Reporting --> Scheduled Tasks:

 

 

Wenn die SPM Maschine in einer Domain sitzt, kann man über den Management Group Wizard den DC hinzufügen.
Es sieht dann so aus (Screenshots kommen von einem anderen System):

 

 

 

Beim Klicken auf den DC habe ich rechts eine weitere Inventarisierungsfunktion:

 

 

Dort wählt ihr aus was interessant ist und setzt direkt eine zweite Aufgabe an.

 

 

Mittels rechter Maustaste kann ich diese Aufgaben adhoc starten, damit ich auch vor dem eigentlichen Startzeitpunkt Resultate bekomme.

SPM ist jetzt einsatzbereit und kann schon benutzt werden, aber wir müssen ja noch mit den Clients kommunizieren.

 

Klicken wir einmal auf Administration and Reporting à Software Publishing, dann ganz rechts auf Server Publishing Wizard und wählen den WSUS aus.

Es sollte wie folgt aussehen:

 

 

Kickt auf next. Und next. Und…wartet. Dann auf Finish!

 

 

 

Wir haben jetzt ein Zertifikat aber das reicht noch nicht. Leider wird es jetzt kompliziert.
Ich erklär es daher g-a-n-z l-a-n-g-s-a-m.

 

Klickt rechts auf Client Publishing Setup Wizard. Wählt den WSUS aus und klickt Distribute:

 

 

 

Hier wählen wir die Zielsysteme aus, z.B. über Browse Computers und Update Services Servers, gefolgt von einer Gruppe, oder einem einzelnen System.

Im nächsten Fenster lasse ich alles bei den Standards und klicke direkt auf Finish.

Das Resultat ist höchstwahrscheinlich eine Warnung:

 

 

 

Ok, dann aber ignorieren wir das Fenster und machen etwas Anderes.

Geht ganz hoch zu Enterprise --> Update Services und klickt einmal auf den WSUS, dann ganz rechts etwas weiter unten auf Software Publishing Certificate.
Dort dann bitte rechts auf die drei Punkte:

 

 

Details, copy to file

 

 

DER passt, klickt next und legt es irgendwo hin. Nur nicht unter den Tannenbaum!

 

Nun brauchen wir den Group Policy Editor, entweder direkt auf dem DC oder aber in einer Remote-Konsole.

Wie man mit dem Ding umgeht ist auch wieder ausserhalb des Umfangs dieses Blogposts, in meinem Beispiel schnappe ich mir einfach die ganz normale Domain-Policy und editiere.

 

Wir gehen zu Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Public Key Policies --> Trusted Root, rechtsklicken dann irgendwo und importieren die DER Datei.

Das gleiche dann noch einmal für die Trusted Publisher. Erledigt? Gut.

 

Jetzt zu Computer Configuration --> Administrative Templates --> Windows Components --> Windows Update und sucht nach “Allow signed updates from an intranet Microsoft update service location” oder dem Deutschen Äquivalent bei Deutschem OS.
Aktiviert die Einstellung. Perfekt.

 

Das System ist jetzt komplett einsatzbereit und ich könnte entweder auf das hervorragende Rezept für Tiramisu hinweisen, das ich am Freitag ausprobiert habe, oder einfach das Posting beenden und mit der Arbeit an den nächsten Schritten – dem Patchen – beginnen.

Nach kurzer Überlegung entscheide ich mich für letzteres da ich gerade von einer Fliege angegriffen werde und fliehen muss: