März 31 2015

ConfigMgr 3rd Party Anwendungen aktualisieren

Microsoft bietet passend zur ConfigMgr / WSUS Landschaft den System Center Updates Publisher 2011 an mit welchem 3rd Party Anwendungen aktualisiert werden können. Nach der Installation von SCUP läd dieser Update Kataloge herunter und übergibt diese dann an den WSUS bzw. Software Update Point. Beim nächsten Update Sync tauchen diese dann im Configuration Manager als "normale" Software Updates auf, später dazu mehr.

1) Installation SCUP

Nach dem Download des System Center Update Publisher 2011 (SCUP Download bei Microsoft) wird die Installation mit administrativen Rechten gestartet. Ich habe den SCUP parallel zur WSUS Konsole auf dem SUP instaliert. Die Installation dokumentiere ich hier nicht weiters, Standard Vorgehensweise. Allerdings mit einem Punkt der zu beachten ist:

31-03-_2015_13-21-31

Sofern der Zielrechner nicht Server 2012 / 2012R2 ist (WSUS 4.0) wird das Update KB972455 benötigt.
(generell sollte der WSUS up to date sein)

 

2) Konfiguration SCUP

Den SCUP immer mit Administrativen Rechten starten sonst kann die Patch-Freigabe schiefgehen.

Nach dem ersten Start muß der SCUP initital konfiguriert werden…

 

Zuerst wird die Verbindung zum WSUS eingerichtet und mit "Test Connection" überprüft. Für die Freigabe von Nicht-Microsoft Updates wird ein Zertifikat benötigt. Hier kann ein bereits vorhandes Zertifikat verwerndet werden, egal ob Self-Signed oder Public. Alternativ kann über "Create" ein WSUS Publishers Self-signed Zertifikat erstellt werden.

 

Anschließend wird die Verbindung zum ConfigMgr Management Point bzw. CAS eingerichtet und getestet.

Die Proxy Settings sollten selbterklärend sein.

 

3) WSUS Publisher Zertifikat verteilen & WSUS GPO anpassen

Das verwendete Zertifikat muss nun verteilt werden. Benötigt wird es auf aus dem WSUS/SCUP Server, dem ConfigMgr Server und allen Rechnern wo später die Updates installiert werden sollen und/oder eine ConfigMgr Console läuft.

Das in Schritt 2 generierte Zertifikat muss zuerst als DER codeded binary X.509 exportiert werden:

 

Das CER muss nun auf den entsprechenden Maschinen als "Trusted Root Certification Authorities" (Vertrauenswürdige Stammzertifizierungsstellen) und als "Trusted Publishers" (Vertrauenswürdige Herausgeber) Zertifikat eingetragen werden. Die kann wahlweise von Hand (mmc -> Zertifikate) oder per Gruppenrichtlinie global umgesetzt werden:

 –>  –> 

(gleiche Vorgehensweise füt den Trusted Root Certification Authorities Strore)

 

Als letzter Schritt muss noch der Windows Updater so umkonfiguriert werden, dass selbstsignierte Updates auch installiert werden. Dies kann auch bequem über eine Gruppenrichtlinie verteilt werden:

GPO \ Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Windows Update

Allow signed updates from an intranet Microsoft update service location –> Enabled

 

 

Weiter geht es im nächsten Beitrag mit dem Veröffentlichen erster Updates… :-)

März 27 2015

System Center 2012 Configuration Manager Survival Guide

Viel zu lesen gibt es hier: http://social.technet.microsoft.com/wiki/contents/articles/7075.system-center-2012-configuration-manager-survival-guide.aspx

What is a survival guide? It’s a page we created as a pointer to information on the web. You can use the information below to learn the fundamentals and share information with other community members. And, if you think we missed some great article out there, please add it below!   

März 19 2015

ConfigMgr 2012: Automatische Update Verteilung

Wenn man alle vier Wochen das selbe tut, dann kann man es auch automatisieren. Dachte ich mir… Daher habe ich seit Anfang des Jahres die Microsoft Patch Thuesdays mit dem Configuration Manager 2012 durch automatisiert. Nach kleinen Anpassungen funktioniert das nun ganz gut weshalb ich hier meinen Ansatz vorstellen möchte. Dies ist natürlich keine Best Practice oder gar "das" White Paper sondern nur einer von vielen Wegen die nach Redmond Rom führen. Kritik ist erwünscht. :-)
In meiner produktiven Umgebung habe ich Windows 7 x64 Clients mit Office 2010 sowie Windows 8.1 x64 Clients mit Office 2013, alles Multilingual.
(Anmerkung: Ich installiere meine Systeme i.d.R. immer auf Englisch die SUP Klassen kommen aber z.B. auf Deutsch. Ich lasse das einfach mal so unkommentiert stehen)

 

Zuerst wird der SUP konfiguriert, damit dieser die Updates bei Microsoft abholt und in der ConfigMgr Konsole zur Verfügung stellt:

Software Update Point (SUP) Configuration (Administration – Site Configuration – Sites – Configure Site Compinents)
Sync Source: Syncronize from Microsoft Update
Classifications: Definitionupdates, Service Packs, Sicherheitsupdates, Update-Rollups, Updates, Wichtige Updates
Products: Office 2010, Office 2013, Windows 7, Windows 8.1
Sync Schedule: Occurs every 1 hours
Supersedence Rules: Immediately expire a superseded software update
Language: 6 Sprachen ausgewählt

 

Nun müssen Rechner in Device Collections (Assets and Compliance) zusammengefasst werden, welche später die Updates bekommen sollen. Ich arbeite mit zwei Stufen, einer Pilot Gruppe sowie dem restlichen, produktiven Rechnern. Daher gibt es zwei Device Collections:

PatchMgmt_ADR_Pilot –> Manuell zugewiesene Rechner, welche die Updates zuerst erhalten sollen
PatchMgmt_ADR_Prod –> Alle Clients exklusive der Testgruppe (per Query)

 

Im nächsten Schritt brauchen wir Deployment Packages (Software Library – Software Updates) wo rein die vom WSUS heruntergeladenen Updates gepackt werden. Diese Packages werden dann auch auf alle Distribution Points verteilt. Damit die Packages nicht zu groß werden (man liest immer wieder, man sollte nicht mehr als 500 Updates pro Package haben) habe ich hier eines pro Produkt angelegt und auf alle Distribution Points verteilt:

ADR_Office_2010_32Bit-2015 & ADR_Office_2013_32Bit_2015
ADR_Windows7_x64-2015 & ADR_Windows81_x64-2015

 

So und nun wird automatisiert…

Pro Produkt gibt es nun zwei Automatic Deployment Rules (Software Library – Software Updates), wieder am Beispiel Office 2010 erklärt:

adr1Der entsprechenden Collection zuweisen und Add to an existing Software Update Group [1]

[1] Beim ersten Lauf hatte ich das noch auf "Create a new Software Update Group" damit die entsprechende Gruppe angelegt wird. Ich möchte aber nicht jeden Monat zig neue Gruppen haben weshalb ich das entsprechend umgestellt habe. Das ist letztlich eine Design Frage und was am besten ist habe ich noch nicht final entschieden… Hängt in erster Linie immer von eurer Umgebung mit ab.

 

adr2

Ich nehme alle Updates, die in den letzten 3 Wochen für das entsprechende Produkt veröffentlicht wurden und die von mehr als 10 Rechnern angefordert wurden.

 

adr3

Bei den PILOT Gruppen führe ich die entsprechenden ADRs immer am zweiten Donnerstag des Monats durch, d.h. 2 Tage nach dem Patch Tuesday von Microsoft. Bei den PROD Gruppen schaut die ADR ähnlich aus jedoch wird diese immer an jedem dritten Donnerstag des Monats ausgeführt. Dies bedeutet dass die Testgruppe alle Updates mit zwei Tage Verzug erhalten (bzw. bedingt durch die Zeitzone sogar weniger). Wenn innerhalb einer Woche keine Probleme auftreten, werden die Updates dann auf alle Rechner weiterverteilt. Achtung, kleiner Designschnitzer: Sollte in dieser Woche ein Update zusätzlich veröffentlicht werden (i.d.R. nicht!) dann fehlt das in der Pilot Gruppe und würde ungetestet auf alle Prod Rechner verteilt werden.

 

adr3

Die ADR muss dann noch dem entsprechenden Deployment Package zugewiesen werden, damit die Downloads im korrekten Package landen. Alle von mir übersprungenen Einstellungen wählt ihr, wie es in eure Landschaft passt.

 

 

Zusätzlich zu den ADR Gruppen habe ich noch eine manuelle Patchgruppe für das Jahr 2015 wo ich alle Updates aufnehme, die durch das Raster gefallen sind bzw. nicht der ADR entsprochen hat. Immer zum Jahresende konsolidiere ich die Update Packages und verwerde die nicht mehr benötigten Updates.