Mai 6 2015

Bestimmte Updates nicht verteilen – ConfigMgr 2012

Wenn man die Windows/Office Updates per ConfigMgr 2012 und Automatic Deployment Rules (ADR) verteilt kommt man ggf. in die Situation, dass man spezifische Updates nicht verteilen bzw. zurückhalten möchte. Leider gibt es dafür eine direkte Lösung, gängig ist aber folgender Ansatz:

Unter Software Updates das entsprechende Update suchen, Rechtsklick -> Properties. Dort die Custom Servenity auf "Low" stellen.

Danach müssen alle ADR angepasst werden. DIese werden um das Suchkriterium "Custom Servenity = None" erweitert.

 

Dadurch fallen diie Updates, die eine eigene Servenity (in diesem Fall 'Low') haben beim nächsten ADR Durchlauf raus.

Siehe: http://blog.danovich.com.au/2012/12/18/decline-exclude-an-update-in-sccm-2012/

April 24 2015

Image Capture Wizard has failed with error code (0x800704CF)

Gerade wollte ich ein neues Referenz Image mit dem Configuration Manager 2012 erstellen wes jedoch mit dem Error Code 0x8070cf abgebrochen ist. Ein neues Image des bisherigen Referenz Computers lief erfolgreich durch.

Die Lösung war mal wieder einfacher als gedacht… Beim neuen Image habe ich Office 2013 inkl. allen Updates mit in das Image gepackt wodurch die Dateigröße des WIM von ca. 4,5GB auf über 10GB angewachsen ist. Dumm nur, dass mein Netzwerkshare für das Image nur noch 9GB freien Speicherplatz hatte… ;-)

Festplatte vergrößert und schon lief das Image durch. Merke: Statt Log Files lesen erstmal die einfachsten Grundlagen prüfen.

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.

 

Januar 28 2015

WMI Cleanup SMS_PackagesInContLib

Im Distribution Point Configuration Status habe ich seit dem löschen vieler Pakete folgenden Fehler drin: Failed to retrieve the package list on the distribution point….

28-01-_2015_15-04-31

Die betroffenen Packages kann man in dem smsdpmon.log auf dem betroffenen DP-Server finden:

28-01-_2015_15-18-56

Die Package ID kann dann am einfachsten über den Content Status gesucht werden. Findet man das Paket so, dann am besten neu auf den DP verteilen und schauen ob es durchläuft. In meinem Fall wurde das Paket jedoch schon in der Software Library gelöscht.

28-01-_2015_15-19-22

 

In diesem Fall muss auf dem betroffenen Distribution Point im WMI das Paket aus der Content Library entfernt werden.

Dies kann u.a. über die PowerShell schnell und einfach erleidigt werden. Ich übernehme jedoch keine Verantwortung, aufpassen was ihr löscht! :-)

28-01-_2015_15-35-44

Anzeigen: gwmi -Namespace root\sccmdp -Query "select * from SMS_PackagesInContLib where PackageID = '……….'"
Entfernen: gwmi -Namespace root\sccmdp -Query "select * from SMS_PackagesInContLib where PackageID = '……….'" | Remove-WmiObject

 

Pakete, die noch in der Software Library vorhanden sind, können einfach mittels "Update Content" neu verteilt werden.

 

Eine vollständige Content Validation kann mit smsdpmon.exe durchgeführt werden. Wer nicht so lange warten möchte, kann auch gezielt einzelne Pakete validieren: smsdpmon.exe PACKAGE-ID.

28-01-_2015_15-57-37

Damit sollten die Fehler im DP Configuration Status dann verschwinden…. (Wie immer, SMS = Small Moving Server ;))

 

Links zum Thema:

 

Oktober 22 2014

SCCM2012 – Software Deployment Return Error Code 0x87D00324(-2016410844)

Ich hatte gerade etwas mit dem SAP GUI Deployment  zu kämpfen. Die Installation lief immer durch (SAP Front-End korrekt installiert), jedoch zeigte das Softwarecenter immer einen Fehler 0x87D00324 an.

22-10-2014 16-59-18

Nach einiger Suche wurde ich im AppEnforce.log fündig:

22-10-2014 17-01-12

Die Lösung: Ich hatte einen kleinen Fehler in der Detection drin. Hier frage ich die Existenz eineses RegKeys ab…. Nach dem entfernen des Tippfehlers wechselte der Status recht schnell von "Fehler" auf "Installiert". Merke: Immer alles genau kontrollieren. :-)

Juli 14 2014

ConfigMgr 2012 SQL Server Firewall Port Monitor

OpsMgr Alert:
Operations Manager 2012 Hierarchy Monitor Alert: SQL Server Firewall Port Monitor Critical

HierarchyMonitoring

Obwohl auf dem betreffenden Zielsystem die Windows Firewall deaktiviert ist (und demnach auch der SQL Zugriff funktioniert) meldet der Firewall Port Monitor diesen Fehler als kritisch.

Die Lösung ist relativ einfach, der Firewall Service muss zumindest kurzzeitig gestartet werden. Sobald die Firewall aktiv ist müssen für die Ports TCP_1433 und TCP_4022 Ausnahmen definiert werden. Anschliessend kann das Firewall Profil deaktiviert werden: netsh advf set allp state off

April 15 2014

Lync 2013 Deployment

Es könnte alles soooo einfach sein… Leider hat mich das Deployment Package vom Microsoft Lync 2013 Client doch ein paar Nerven gekostet. Hier eine kleine Zusammenfassung, möge es anderen hilfreich sein…

Ausgangsituation: Windows 7 x64 Clients mit installiertem MS Office 2010 + Lync 2010
Beim Lync 2013 Rollout soll das Office 2010 nicht zeitgleich mit aktualisiert werden. Das Lync Paket soll mehrsprachig sein (5 Sprachen).

 

Das erste Drama war die Versionierung von Lync. Ordentliche Versionsnummern scheint etwas zu sein, was Microsoft selbst 2014 noch nicht im Griff hat. Mit dem aktuellen Cumulative Update April 2014 sollte die Lync Version eigentlich die 15.0.4605.1003 sein. In der GUI wird jedoch 15.0.4605.1000 oder älter angezeigt… (siehe Release Notes KB2880474). IstHaltSo…

 

Zuerst habe ich mir ein Source Directory angelegt und das Lync ISO darin entpackt, inklusive allen gewünschte Sprachen:

Danach habe ich das Microsoft Office-Anpassungstool mit setup.exe /admin angeworfen und mir ein schönes MSP Adminfile geklickt. Ich denke dazu muss ich nichts weiter schreiben…

Leider geht es dann aber doch nicht ohne config.xml, siehe Technet Referenz.
In meiner Umgebung schaut das wie folgt aus:

<Configuration Product="Lync">
  <Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
  <Setting Id="SETUP_REBOOT" Value="Never" />
  <Logging Type="standard" Path="%windir%\CCMlogs" Template="Lync2013.log" />
  <AddLanguage Id="match" ShellTransform="yes"/> 
  <AddLanguage Id="en-us" />
  <AddLanguage Id="de-de" />   
  <AddLanguage Id="fr-fr" />   
  <AddLanguage Id="it-it" />   
  <AddLanguage Id="pt-br" />   
</Configuration>

Hiermit unterbinde ich die EULA und einen eventuellen Reboot Request und benenne einen Logfile Speicherort.

Mit AddLanguage Id="match" wird definiert, dass sich Lync in der gleichen Sprache wie das OS installiert, zusätzlich werden aber auch die anderen 5 Sprachen lokal mit installiert…

 

Was dann noch fehlt ist ein schönes install.cmd:

Hier schiesse ich zuerst mehrere msiexec.exe /X auf die ganzen Lync 2010 UUID's ab. Diese hatte ich mir zuvor mit dem ConfigMgr zusammengesammelt. Damit werfe ich die halten Lync Clients, sofern vorhanden, vom Zielsystem.

Danach rufe ich das Lync 2013 Setup auf, warte etwas und schiebe das Cumulative Update April 2014 inkl. der PreRequirements gleich hinterher:

:: Install Lync 2013...
"%~dp0SETUP.EXE" /adminfile "%~dp0ADMIN.MSP" /config "%~dp0CONFIG.XML"
ping 127.0.0.1 -n 30 >nul
:: Install PreReqs for KB2880474
"%~dp0_kb2880474\mso2013-kb2727096-fullfile-x86-glb.exe" /log:"%windir%\CCMlogs\Lync2013_KB2880474.log" /quiet /passive /norestart
"%~dp0_kb2880474\msores2013-kb2817624-fullfile-x86-glb.exe" /log:"%windir%\CCMlogs\Lync2013_KB2880474.log" /quiet /passive /norestart
"%~dp0_kb2880474\orgidcrl2013-kb2817626-fullfile-x86-glb.exe" /log:"%windir%\CCMlogs\Lync2013_KB2880474.log" /quiet /passive /norestart
"%~dp0_kb2880474\lynchelploc2013-kb2817678-fullfile-x86-glb.exe" /log:"%windir%\CCMlogs\Lync2013_KB2880474.log" /quiet /passive /norestart
:: Install CU April 2014 - KB2880474
"%~dp0_kb2880474\lync2013-kb2880474-fullfile-x86-glb.exe" /log:"%windir%\CCMlogs\Lync2013_KB2880474.log" /quiet /passive /norestart

 

That's it…
Das ganze ist in meinem Script noch etwas schöner ausformuliert, hat ein Error Handling und macht dann auch entsprechend noch ein Registry Branding.

Userseitig schaut die Migration so aus, dass Lync 2010 direkt geschlossen wird. Vermutlich würde es auch gehen, dass man zuerst Lync 2013 installiert und anschliessend die 2010er Version runter wirft…

Damit die User wieder schnell an Lync ran kommen erstelle ich noch im Startup sowie im Desktop Ordner eine Verknüpfung, das direkt aus dem MSP heraus:

 

Läuft…. :-)

 

Nachtrag:

Leider fällt er bei einer anderen OS Sprache doch auf die Nase… Ich fange das nun über den Errorcode ab und installiere dann mit <AddLanguage Id="en-us" ShellTransform="yes"/> Englisch als Sprache… Ich schreib dazu die Tage noch was (vermutlich). Aber nun erstmal: Frohe Ostern.

Juni 24 2013

Cumulative Update 2 für ConfigMgr 2012 SP1 veröffentlicht

Letzte Woche hat Microsoft das Cumulative Update 2 für den ConfigMgr 2012 (SCCM) veröffentlicht. Microsoft empfiehlt die Installation nur wenn man mit einem der behobenen Probleme konfrontiert ist. Ansonsten soll man auf das Service Pack 2 warten welches alle Fixes enthalten wird. Das CU2 ersetzt das CU1.

Fixes:

  • Admin Console (2)
  • App-V (2)
  • OS Deployment (4)
  • Asset Intelligence (1)
  • Mobile Device Management (1)
  • Site Systems (3)
  • ConfigMgr SDK (1)
  • Client (1)
  • CU Setup Wrapper

Besonders interessant könnte sein, dass Microsoft wieder einen limitierten Support für WinPE3 eingebaut hat. Damit tritt dann kein BSOD mehr auf, wenn man ein VMware ESX4 Client im OSD betanken will.

Detailierte Informationen gibt es bei Microsoft Support.