Gestern war es soweit und ich habe mutig in meiner Produktionsumgebung das Inplace Upgrade 1610 (von 1606) angestartet. Das lief überraschend unauffällig durch und dauerte ca. eine Stunde und es wurden die CCMclient Packages sowie die Standard Boot Images aktualisiert und neu verteilt.

Clientseitig habe ich bislang nur eine Testgruppe aktualisiert was auch lautlos passierte – den großen Rollout gibt es in ein paar Tagen.

Der Update Prozess ist bei den Systemcenterdudes wunderbar beschrieben, das könnte ich nicht besser:

Step-by-Step SCCM 1610 Upgrade Guide

SCCM Pre-Production Client Deployment

Wie schon beim 1606 werden die Konsolen automatisch aktualisiert. Aktuell teste ich noch alles durch es sind mir aber bislang keine Fehler aufgefallen. Well done, Microsoft.

Vor einigen Tagen habe ich in meiner ConfigMgr Landschaft das Client Healh Summary Report Script von Trevor Jones implementiert. Meiner Meinung nach eine absolut feine Sache, so bekommt man einen schicken Status Report per Email zugestellt:

Das Powershell Script selbst wird einfach als geplante Aufgabe ausgeführt:

Powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File „<path>\New-CMClientHealthSummaryReport.ps1“

Microsoft hat gestern das 1610 Update für den ConfigMgr Current Branch im Fast Ring veröffentlicht. Es sollte bei allen Installationen in den nächsten Tagen/Wochen im „Update and Servicing“ Node auftauchen. Wer das Update schneller haben möchte, kann sein System mit einem Powershell Script in den Fast Ring aufnehmen.

Microsoft spricht von derzeit über 25000 Unternehmen weltweit welche insgesamt über 50 Millionen Geräte mit dem Configuration Manager 1511 oder später verwalten.

Neuigkeiten/Veränderungen bei 1610 (Auszug):

• Windows 10 Upgrade Analytics Integration
• Neues Office 365 Client Management Dashboard
  (Software Library > Overview > Office 365 Client Management)
  -> Manage Office 365 ProPlus updates
• Neues Software Update Compliance Dashboard
  (Monitoring > Overview > Security > Software Updates Dashboard)
  -> Monitor software updates
• Cloud Management Gateway (Management von Clients im Internet durch Azure)
  -> Manage clients on the Internet
• Client Peer Cache (Neues Content Caching auf Clientseite inkl. Monitoring, muss als Pre-Replease Feature in 1610 aktiviert werden)
  -> Peer Cache und Client Data Sources dashboard
• Software Center (mehr Anpassungsmöglichkeiten für Dialogfenster, Benachrichtigung bei neuer Software)
• Erweiterte Funktionen bei Required Software Dialogen (Mitarbeiter können verpflichtende Updates besser zurückstellen, siehe Client Settings -> Computer Agent)
• Remote Control (Performanceverbesserungen)
• Bessere Überwachung von In-Console Updates (steht erst nach der Installation von 1610 zur Verfügung)
  -> Install in-console updates
• Microsoft Intune: Neue Einstellungen für Android, iOS, Mac, Windows Phone, Windows 8.1 und 10.
• Microsoft Intune: Unterstützung für kostenpflichtige Apps im Windows Store for Business
  -> Managge apps from the Windows Store for Business with SCCM
• Lookout Integration für iOS und Android
  -> Configure and deploy Lookout for Work apps
• Client Collections können vom automatischen Client Update ausgeschlossen werden
  -> Exclude Windows clients from upgrades
• Das Konzept der Boundary Groups wurde überarbeitet, bitte dazu den Microsoft Artikel beachten. Bestehende Boundary Groups werden automatisch migriert
  -> Boundary Groups
• Hardware Indentifiers: Bislang floss die MAC Adresse in den Hardware Indentifier mit ein was insbesondere bei Geräten ohne Ethernet zu Problemen führen kann wenn man USB-Ethernet Karten für das Deployment verwendet. In 1610 kann nun die MAC Adresse herausgefiltert werden.
  -> Manage duplicate hardware identifiers
• Der Windows Defender kann nun mit Compliance Settings bei Intune-enrolled Windows 10 Cleints konfiguriert werden
• In Automatic Deployment Rules kann nun nach der Content Size gefiltert werden, damit kann das automatische Verteilen von großen Updates besser gesteuert werden
  -> Automatically deploy software updates
• BIOS -> UEFI Konvertierung per neuer Task Sequence Variable
  -> Task sequence steps to manage BIOS to UEFI conversion

Details zu den Änderungen gibt es hier bei Microsoft.

Fehler: Beim Aufruf eines Queries im SQL Management Studios gegen die Configuration Manager Database kommt sofort die Fehlermeldung
Msg 208, Level 16, State 1, Line 1
Invalid object name ‚dbo.v_R_System‘.

Ursache: Im SQL Management Studio ist im Standard die Datenbank ‚master‘ hinterlegt und nicht die ConfigMgr Datenbank. Stellt man hier im Dropdown auf die CM DB um funktioniert das Query.

Lösung: Unter Security \ Logins den Datenbank User auswählen, die Eigenschaften öffnen und dort die CM Datenbank als Standard hinterlegen.

Ich habe endlich mal einen Testlauf für ein Windows 10 Upgrade mit dem ConfigMgr gemacht. Auf das neue Windows Servicing werde ich ein anderes mal eingehen, erst einmal möchte ich die Vorgehensweise mit einer Task Sequence beschreiben. Als Voraussetzung braucht ihr dazu einen ConfigMgr Current Branch.

Im ersten Schritt muß dazu ein Operating System Upgrade Package erstellt werden:

Als Quelle muss hier ein entpacktes Windows 10 Image (WIM) verwendet werden.

Im Anschluß kann nun das OS Upgrade Package auf die benötigten Distribution Points verteilt werden.

Der In-Place Upgrade Vorgang wird mit einer Task Sequence gestartet, welche nun als nächstes gebaut werden muss:

Create new task sequence –> Upgrade an operating system from an upgrade package

Hier das zuvor erstellte Upgrade Package auswählen, einen Produkt Key ist bei der Verwendung eines MKS Servers nicht nötig.

Als nächstes kann man das Update Verhalten definieren, d.h. ob gleich nach dem In-Place Upgrade die Windows Updates (vom ConfigMgr) installiert werden sollen.

Ebenso können direkt im Anschluß des Upgrades Anwendungen installiert werden, dieser Schritt bietet sich an um z.B. direkt eigene Anpassungen (Startmenü, usw.) nach zu schieben.

Die Task Sequence muss dann nur noch auf die Device Collection verteilt werden, welche die gewünschten Clients beinhalten. Theoretisch sollte so auch problemlos ein Upgrade von Windows 7/8/8.1 auf Windows 10 möglich sein, bislang habe ich nur die In-Place Upgrade von Windows 10 1511 auf 1607 getestet.

In der Task Sequence selbst habe ich dann noch als Requirement „15GB free Disk Space“ eingetragen, diesen Wert werde ich aber wohl eher noch auf 20 oder 25GB erweitern da nach dem Upgrade ein Windows.Old Ordner zurück bleibt. Dieser hatte bei meinen Tests immer um die 15GB und wird für einen eventuellen Rollback benötigt. Wie man diesen wieder los werden kann ist ein Thema für einen späteren Artikel..

Ein In-Place Upgrade von Version 1511 auf 1607 dauerte bei mir ca. 25 Minuten. Alle Daten und auch die Startmenü Anpassungen des Users wurden übernommen.

Quick & Dirty: Aufgefallen ist der Client durch seine veraltete Endpoint Protection Definitionsdatei. Nach einer erfolgloser Suche wollte ich den Agent neu installieren, allerdings bricht das ccmsetup mit denm Fehlercode 0x80004005 ab.

Hier liegt die Ursache meist beim WMI Namespace, den Fehler konnte ich mit dem guten, alten SCCM Client Center von Roger Zander (http://smsclictr.sourceforge.net/) beheben:

Unter dem Reiter Install/Repair findet man u.a. WMI Repair Optionen. Das löschen des root\ccm Namespace brauchte die Lösung – der SCCM Agent war weg und konnte neu installiert werden.

Mit dem ConfigMgr Current Branch (Version 1606) kam auch das neue Softwarecenter ("ClientUX") auf die Clients welches in der Standard Ansicht die Anwendungen mit großen Symbolen, ähnlich zur Windows 10 Kacheloptik, darstellt. Wenn man in der Vergangenheit hier keine sauberen Icons bei den Anwendungen gepflegt hat, schaut das nach der Migration eher unschön aus:

Der ConfigMgt unterstützt neben Icons (.ICO oder eingebundene Symbole aus .DLL oder .EXE) auch Bilddateien in den Formaten .JPG, .JPEG und .PNG bis zu einer Größe von 250×250 Pixeln:

Ergebniss:

Beim gestrigen System Center User Group (#SCUG) Treffen im München hielt André Picker einen Vortrag über OS-Deployment mit dem ConfigMgr. Ein Teil davon ging um das Thema PXE Boot und wie man hier optimieren kann.

Technisch bedeutet PXE Boot beim ConfigMgr, dass der Client ein Windows Preboot Environment (WinPE) Image per TFTP herunterläd und dann davon startet um die eigentliche Betriebssysteminstallation durchzuführen. Hier gibt es einige Stellschrauben, konkret die TFTP Block Size und die TFTP Windows Size.

Die ConfigMgr Standartwerte sind eine WindowsSize von 4 und eine BlockSize von 1024 Bytes. Damit dauert der Startvorgang mit einem HP Testnotebook bis zur Abfrage des Task Sequence Passwortes knapp 80 Sekunden.

Davon ausgehend habe ich einige Werte getestet und konnte das beste Ergebniss mit 8192 Byte Blöcken und 8 Chunks erhalten, die Bootzeit ging auf ca. 35 Sekunden zurück. Leider stellte sich dann aber heraus, dass VMware ESX mit einer Blockgröße >1432 Bytes Probleme bekommt. Bei Verwendung eines E1000 Adapters bricht das PXE mit einer „A required device isn’t connected or can’t be accessed“ ab, mit einem VMXNET3 Adapter um kommt stattdessen „The application or operating system couldn’t be loaded because a required file is missing or contains error“.

Als ein funktionierender Kompromiss für meine Umgebung hat sich eine Windows Size von 6 und eine Blocksize von 1024 herausgestellt womit Virtuelle Maschinen noch sauber vom Netzwerk starten und das Testnotebook bereits nach 44 Sekunden bei der TS-Passwort Abfrage steht. Manches mal muss man auch mal mit etwas zufrieden sein… ;-)

Gesetzt werden die Werte direkt auf dem entsprechenden Distribution Point in der Registry wo zwei neue DWORD (32bit) Schlüssel gesetzt werden müssen:

Name: RamDiskTFTPWindowsSize
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
Values: 4 (Default), 8

Name: RamDiskTFTPBlockSize
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
Values: 1024 (Default), 2048, 4096, 8192, 16384

Wenn die Änderungen nicht gleich übernommen werden dann muss ggf. der WDS Dienst (Windows Deployment Services Service) neu gestartet werden.

Weiterführende Informationen:

• Technet – Planning for PXE-Initiated OSD in ConfigMgr
• bcTechNet – VMware PXE Limitations

Microsoft hat das Update Rollup 1 für den ConfigMgr 1606 veröffentlicht welches über den "Updates and Servicing" Note in der Konsole bereitgestellt wird.

Unter anderem wird ein Bug behoben, der dafür sorgt dass bereits bearbeitete EPP Dateien (\EpMgr.box\process) nicht automatisch gelöscht werden. Außerdem können nun Task Sequenzen importiert werden, welche einen "Install Software Updates" Step beinhalten.