Seit Version 2.0 erlaubt die Packaging PowerBench, Pakete direkt aus dem PPB-GUI heraus in SCCM zu registrieren. Damit entfällt die Notwendigkeit, nach der Erstellung eines Pakets, dies manuell in SCCM als Application anzulegen und sämtliche Eigenschaften manuell zu konfigurieren. Wenn Sie Ihre SCCM-Installation aber auf Version 2103 aktualisieren, erhalten Sie beim Verbindungstest auf die SCCM-Infrastruktur einen Fehler. 

Dieser Blog-Artikel beschreibt die Ursache und den verfügbaren Workaround.

Die Registrierung von Paketen in SCCM oder Intune aus der Packaging PowerBench heraus, erfolgt über integrierte PowerShell-Scripts. Da das SCCM PowerShell-Modul zusammen mit der SCCM Admin-Konsole installiert wird, muss auf dem Rechner, von dem aus das Paket registriert werden soll, auch die aktuelle SCCM-Konsole installiert sein, wie dies in der PPB Online-Hilfe dokumentiert ist.

Nach dem Update auf SCCM 2103 und Aktualisierung der Konsolen-Installation erscheint beim Verbindungstest auf die SCCM-Umgebung jedoch ein Warnhinweis, dass eine neuere Konsolenversion verfügbar wäre und PowerShell Cmdlets eventuell nicht so funktionieren würden, wie man das erwarten würde oder womöglich sogar die Site-Konfiguration korrupt machen würden. Nachdem aber die Konsole definitiv auf dem aktuellen Stand ist, mussten wir die Ursache dieser – falschen – Meldung untersuchen.

Was uns zunächst verwundert hat, ist dass bei einem manuellen "Import-Module" des Configuration Manager PowerShell Moduls in einem PowerShell-Fenster keine Warnung über die angeblich verfügbare neuere Konsolenversion ausgegeben wurde. Da aber auch die Packaging PowerBench an dieser Stelle "nur" das Modul importiert musste es sich im Kontext der PPB anders verhalten als im Kontext von powershell.exe... sehr seltsam!

Beim Einbinden des Configuration Manager PowerShell-Moduls über Import-Module, wird ein PowerShell-Laufwerk für den vorhandenen Standort angelegt. Dabei wird geprüft, ob ein Update der Admin-Konsole (Admin-PowerShell-Modul) erforderlich ist. Dazu wird die Version der vorhandenen (installierten) Admin-Konsole mit der Version einer verfügbaren (eventuell noch nicht installierten) Admin-Konsole verglichen.

Bei der Ausführung von "Import-Module" oder "New-PSDrive" mit dem "-Verbose" Parameter, werden auch die zu vergleichenden Versionsnummern ausgegeben:

Current version: ... Available version: ...

Die verfügbare Version wird dabei über WMI ermittelt, was man manuell in einem PowerShell-Fenster z.B. so nachvollziehen kann:

$site="CHI"
$server="chisv01.solys.local"
(Get-WmiObject -Class SMS_Identification -Namespace root\sms\site_$site -ComputerName $server).SMSAvailableConsoleVersion

Die vorhandene Version wird vorzugsweise(!) aus der Registry ausgelesen und zwar aus dem Schlüssel "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ConfigMgr10\Setup" und dem dort vorhandenen Value "AdminConsoleVersion" – und hier ist der Knackpunkt!

Dieser Registry-Schlüssel existiert auf einer 64-Bit Plattform nicht. Stattdessen existiert nur – vermutlich weil es sich bei der Admin-Konsole um eine 32-Bit Anwendung handelt – der Key "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\ConfigMgr10\Setup". Dort findet sich auch der gesuchte Wert "AdminConsoleVersion". 

Dieser Schlüssel wird jedoch nicht abgefragt und damit kann die Versionsnummer der Admin-Konsole nicht aus der Registry ermittelt werden. Da, wie oben geschrieben, die vorhandene Version offensichtlich nur "vorzugsweise" aus der Registry gelesen wird, kommt nun – vermutlich als "Fallback" – eine zweite (durchaus fragwürdige) Methode der Ermittlung der aktuellen Konsolenversion zum Einsatz: es wird die Versionsnummer der (Windows-Forms-) Anwendung herangezogen, die das PowerShell-Modul lädt.

Auf diese Weise werden allerdings sozusagen "Äpfel mit Birnen" verglichen, da die ermittelte Version der vorhandenen "Admin-Konsole" damit der Versionsnummer der jeweiligen Anwendung entspricht – das Ergebnis ist damit dementsprechend:

Versionsnummer der verfügbaren Admin-Konsole: 5.2103.1059.1800
Versionsnummer der vorhanden Admin-Konsole …
… bei PackagingPowerBench.exe: 2.1.0.0
… bei powershell.exe (z.B.): 10.0.14393.0

Damit erklärt sich auch das unterschiedliche Verhalten bei der Ausführung der Paket-Registrierung über PPB gegenüber einem interaktiven "Import-Module" in einem PowerShell-Konsolenfenster:

  • Paket-Registrierung über PPB: Version 2.1.0.0 (vorhanden) ist kleiner als 5.2103.1059.1800 (verfügbar). Es wird daraus geschlossen, dass die vorhandene Admin-Konsole scheinbar veraltet ist und der Fehler / die Warnung wird ausgeben.​
  • "Import-Module" über die PowerShell-Konsole: 10.0.14393.0 (vorhanden) ist größer als 5.2103.1059.1800 (verfügbar). Schlussfolgerung also, die vorhandene Admin-Konsole ist aktuell und es muss kein Fehler / keine Warnung ausgegeben werden...​

 Damit ergibt sich folgende Abhilfe: Anlegen des Registrierungsschlüssels "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ConfigMgr10\Setup" und in diesem Key des RegSZ-Werts "AdminConsoleVersion". Als Inhalt sollte der Wert des gleichnamigen Values aus "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\ConfigMgr10\Setup" übernommen werden. Nachdem dieser Wert angelegt ist, können PPB-Pakete wieder ohne Fehlermeldung in Ihrer SCCM-Umgebung als Application registriert werden.

Nachtrag: der am 07.05.2021 veröffentlichte Configuration Manager Hotfix KB9833643 (siehe https://docs.microsoft.com/en-us/mem/configmgr/hotfix/2103/9833643) behebt das Problem ebenfalls.