An einen Client hatte ich soeben das Problem, dass seit Tagen keine Updates und Anwendungen über den ConfigMgr Client installiert bzw. heruntergeladen werden. Der Download bleibt einfach bei 0% stehen, im %windir%\ccmcache Verzeichniss findet man entsprechend auch nur *.BDRTEMP Ordner.

Ein Blick ins LocationServices.log zeigte regelmässige "Unable to retrieve AD site membership" Fehler, dadurch findet der Client dann seinen zugeordneten Distribution Point nicht und der Download bleibt bei 0% stehen (sofern man seine Landschaft ohne automatischen Failover auf andere Distribution Points konfiguriert hat).

Die AD Site Zuordnung kann man schnell mit dem Befehl nltest /dsgetsite prüfen:

Getting DC name failed: Status = 1919 9x77f ERROR_NO_SITENAME

In diesem Fall sollte man sich mal anschauen: Client IP Addresse & Subnet und der AD Site zugeordnete Subnets. In meinem Fall war das alles in Ordnung, die Lösung war letztlich sogar recht trivial: Ich habe den Client neu in die AD Domain aufgenommen und nach einem Neustart passt die Site Zuordnung wieder, die fehlenden Updates und Anwendungen wurden nach ein paar Minuten geladen und installiert.

Passend zum Thema: Man kann anstehende BITS Jobs mit dem Befehl bitsadmin /list /allusers anzeigen lassen.

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:

Der 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.

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.

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.

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.

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.