Applikation wird trotz gelöschtem Deployment noch im Softwarecenter angezeigt

Veröffentlicht am 28.07.2017 um 15:14 Uhr von Sven Schmittlein

Vor kurzem bat mich ein befreundeter ConfigMgr-Admin um Rat, da ein von ihm gelöschtes Deployment immer noch auf seinen Clients im Softwarecenter angezeigt wurde. Im Policy Spy, sowie im AppIntentEval.log konnten wir sehen, dass der Client immer noch die Policy mit der ID: „ScopeId_C99A464B-3E07-49AA-AF04-B875D5562376/RequiredApplication_1598d8fd-c03b-4a79-9559-5ce66d417917/VI“ heruntergeladen hat, obwohl die dazugehörige Application aus der ConfigMgr-Console gelöscht war. Auch das erneute Anfordern der Policys sowie ein Policy Reset mittels Client Center for Configuration Manager brachte keine Besserung. Mit den folgenden SQL Statements haben wir herausgefunden, dass die Policys immer noch in der Datenbank der CAS und der Primary Sites vorhanden waren.

Select * from Policy where policyID= 'ScopeId_C99A464B-3E07-49AA-AF04-B875D5562376/RequiredApplication_1598d8fd-c03b-4a79-9559-5ce66d417917/VI'

1	Select * from Policy where policyID= 'ScopeId_C99A464B-3E07-49AA-AF04-B875D5562376/RequiredApplication_1598d8fd-c03b-4a79-9559-5ce66d417917/VI'

Select * from PolicyAssignment where PolicyID='ScopeId_C99A464B-3E07-49AA-AF04-B875D5562376/RequiredApplication_1598d8fd-c03b-4a79-9559-5ce66d417917/VI'

1	Select * from PolicyAssignment where PolicyID='ScopeId_C99A464B-3E07-49AA-AF04-B875D5562376/RequiredApplication_1598d8fd-c03b-4a79-9559-5ce66d417917/VI'

Select * from Policyassignment where policyassignemtid = '{241b2188-ba87-4119-abb8-b6348be0666e}'

1	Select * from Policyassignment where policyassignemtid = '{241b2188-ba87-4119-abb8-b6348be0666e}'

Select * from DepPolicyAssignment where PolicyID='ScopeId_C99A464B-3E07-49AA-AF04-B875D5562376/RequiredApplication_1598d8fd-c03b-4a79-9559-5ce66d417917/VI'

1	Select * from DepPolicyAssignment where PolicyID='ScopeId_C99A464B-3E07-49AA-AF04-B875D5562376/RequiredApplication_1598d8fd-c03b-4a79-9559-5ce66d417917/VI'

Select * from DepPolicyAssignment where policyassignemtid = '{241b2188-ba87-4119-abb8-b6348be0666e}'

1	Select * from DepPolicyAssignment where policyassignemtid = '{241b2188-ba87-4119-abb8-b6348be0666e}'

Nachdem wir diese Einträge gelöscht hatten und die Clients ihre Policys erneuerten, wurde die gelöschte Applikation nicht mehr angezeigt. Solltet ihr mehreren Primary Sites im Einsatz haben müsst ihr die SQL Statments natürlich an allen Primary Sites ausführen.

ConfigMgr + Intune: MDM Authority-Fehler im Azure-Portal

Veröffentlicht am 09.07.2017 um 20:47 Uhr von Sven Schmittlein

Kurz notiert: Solltet Ihr eine hybride ConfigMgr-Umgebung mit Microsoft Intune im Einsatz haben und Euch wundern warum ihr im Intune-Tab des Azure-Portals folgende Fehlermeldung bekommt:

An error occurred whilst fetching MDM Authority.
An error occurred whilst fetching device status overview details.
An error occurred whilst fetching list of applications.
An error occurred whilst fetching historical status overview details.

An error occurred whilst fetching MDM Authority.

An error occurred whilst fetching device status overview details.

An error occurred whilst fetching list of applications.

An error occurred whilst fetching historical status overview details.

Diese Meldungen sind normal, da der ConfigMgr als MDM-Authority gesetzt ist. Damit hat der ConfigMgr die Hoheit über Eure Intune-Umgebung und alle wichtigen Daten befinden sich in der ConfigMgr-Console.

Update 1706 für Configuration Manager Technical Preview verfügbar

Veröffentlicht am 26.06.2017 um 08:16 Uhr von André Picker

Das ConfigMgr-Team war in den letzten Wochen offensichtlich sehr produktiv und hat am Freitag das Update 1706 für Configuration Manager Technical Preview mit einer Fülle an neuen Features veröffentlicht. Das Update 1706 ist über die „Updates and Servicing“-Node in der Configuration Manager-Console der Technical Preview verfügbar.

Die „dickste“ Neuerung ist sicherlich die Möglichkeit einen zweiten Primary-Site-Server im „Passive mode“ zu betreiben. Dadurch will das ConfigMgr-Team eine höhere Verfügbarkeit erreichen. Der Site-Server im „Passive mode“ nutzt die gleiche Datenbank wie der Site-Server im „Active mode“ und schreibt keinerlei Daten in die Datenbank, solange er nicht händisch durch den Administrator zum „Active mode“ promoted wird. Ein automatischer Schwenk findet nicht statt. Spannend wird es zu sehen sein, wie in Zukunft die SQL-Server-Empfehlungen seitens Microsoft aussehen wird. Bislang hatte es in der Regel mehr Vor- als Nachteile den SQL-Server direkt mit auf die ConfigMgr-Maschine zu installieren. Das könnte in Zukunft anders aussehen.

Weitere Informationen zu diesem Feature findet ihr hier:

Link: Capabilities in Technical Preview 1706 for System Center Configuration Manager – Site server role high availability

Eine weitere, für mich wirklich tolle Neuerung stellt die neue „Run Script“-Funktion dar. Diese Funktion erlaubt das Ausführen von Powershell-Scripten auf Device Collections in nahezu Echtzeit über den „Client Notification“-Channel. Die Powershell-Scripte können innerhalb der ConfigMgr-Console editiert und einzeln als „Approved“ oder „Denied“ markiert werden. Entsprechende Berechtigungen werden über die „Compliance Settings Manager“-Securityrole vergeben. Die Überwachung der Exit-Codes erfolgt über den „Script Results“-Reiter innerhalb des Monitoring-Workspaces. Dies wird in Zukunft u.a. eine gute Alternative zu den bekannten „Right Click Tools“ sein. Man darf gespannt sein.

Link (1): Capabilities in Technical Preview 1706 for System Center Configuration Manager – Create and run PowerShell scripts from the Configuration Manager console

Link (2): Scconfigmgr.com – ConfigMgr 1706 Technical Preview feature spotlight – Run a script

Eine weitere Neuerung ist die Tasksequenz-Variable „TSDisableProgressUI“. Die Tasksequenz-Variable erlaubt das Aus- (True) und Einblenden (False) der Task Sequence Progress Dialog Box. Bislang ist dafür der Einsatz eines VBScripts nötig gewesen.

Link: Capabilities in Technical Preview 1706 for System Center Configuration Manager – Hide task sequence progress

Diese und viele weitere Neuerungen in der Übersicht:

Kostenlose ConfigMgr-Reports aus der Community

Veröffentlicht am 21.06.2017 um 22:00 Uhr von Sven Schmittlein

Das Thema ConfigMgr-Reports ist ja immer so eine Sache, jeder kennt sie, die meisten nutzen sie und einige erstellen sich sogar ihre eigenen. Genauso ist es auch bei mir, allerdings sind meine selbst erstellten Reports aus Zeitgründen meist eher als rudimentär zu bezeichnen. Ich bekomme zwar alle notwendigen Informationen, aber besonders chic sehen sie nicht aus. Deshalb möchte ich Euch heute einige Reports vorstellen, die direkt aus der ConfigMgr-Community kommen und ich für besonders empfehlenswert halte.

Distribution Point Dashboard Reports von Thomas Larsen (@kakemonstre)

Beim Distribution Point Dashboard Reports sieht man alle Informationen zu seinen Distribution Points. Des Weiteren helfen sie auch Fehler zu finden, wenn man z.B. erkennt das ein Distribution Point gar keine Client-Verbindungen besitzt, obwohl es Clients an diesem Standort vorhanden sind. Mein absoluter Favorit.

Link: Distribution Point Dashboard Reports

OS Deployment Dashboard von Thomas Larsen (@kakemonstre)

Ein weiterer Report von Thomas Larsen. Mit diesem Report könnt ihr sehen wie viele Rechner an einem Tag / in einer Woche installiert wurden, wie lange es gedauert hat und wie viele Installationen davon erfolgreich waren.

Link: OS Deployment Dashboard

SCCM Office 365 Inventory Report von den Systemcenterdudes (@scdudes)

Wer Office 365 nutzt und per ConfigMgr verteilt, möchte in der Regel auch wissen welche Versionen im Einsatz sind. Darüber hinaus ist oftmals interessant, welche Sprache installiert ist, ob Updates erlaubt sind usw. Mit diesem Report der Systemcenterdudes seht ihr fast alles auf einem Blick. Bitte beachtet, dass ihr bevor ihr diesen Report nutzen könnt, die Hardwareinventur um die Klasse „Office365ProPlusConfiguration“ erweitern müsst.

Link: SCCM Office 365 Inventory Report

Client Health Report von Trevor Jones (@trevor_smsagent)

„Client Health“ zählt in Zeiten von WannaCry und Co. zu einen der wichtigsten Aufgaben eines jeden ConfigMgr-Admins. Denn nur wenn die Clients „healthy“ sind, kann garantiert werden, dass sie alle sicherheitsrelevanten Updates bekommen. Mit diesem Report von Trevor Jones bekommt Ihr einen schnellen Überblick wie „healthy“ Eure ConfigMgr-Clients tatsächlich sind und müsst Euch die Informationen nicht mühsam aus mehreren Standard-Reports heraussuchen.

Link: Client Health Report

SCCM Configmgr Software update Compliance Report for multiple Software Update groups per collection von Eswar Koneti (@eskonr)

Das schon zuvor erwähnte Patchen von Clients und Server spielt natürlich auch beim Reporting eine große Rolle. Der Report von Eswar Koneti erlaubt es Euch die Compliance von mehreren Software Update Groups auf einer Seite darzustellen.

Link: SCCM Configmgr Software update Compliance Report for multiple Software Update groups per collection

Dell Warranty Report von Gary Town (@gwblok)

Meine „Service Desk“-Kollegen lieben diesen Report. Mit dem Dell Warranty Report lassen sich schnell und einfach die Support-Status von Dell-Geräten herausfinden. Damit Ihr den Report nutzen könnt, müsst Ihr bei Dell eine API beantragen und eine eigene Hardwareinventur-Klasse erstellen. Wenn dies erst einmal erledigt ist, dann erleichtern diese drei Reports von Gary Town auch Euren „Service Desk“-Kollegen das Leben ungemein.

Link: Dell Warranty Reporting via ConfigMgr – Dell Warranty API

Ihr kennt noch mehr hilfreiche Reports? Lasst es mich in den Kommentaren wissen.

Umfrage: Weitere Themen auf Clientmgmt.de?

Veröffentlicht am 16.06.2017 um 13:06 Uhr von André Picker

Ich überlege derzeit, ob ich die Themen auf Clientmgmt.de etwas erweitere. Daher würde mich mal interessieren, welche Themen ihr Euch – zusätzlich zum bisherigen Inhalt – wünscht. Spielen beispielsweise kostenpflichtige ConfigMgr-Erweiterungen von Drittherstellern eine Rolle? Stimmt ab, oder nutzt gerne auch die Kommentarfunktion. Eine Mehrfachabstimmung ist möglich.

Loading ...

OSD bleibt bei „Initializing the System Center Configuration Manager client“ hängen

Veröffentlicht am 15.06.2017 um 12:26 Uhr von Sven Schmittlein

Vor kurzem hatte ich das seltsame Phänomen, dass mein neuerstelltes Windows 7 Image beim Initialisierung-Step des ConfigMgr-Clients stehen geblieben ist. Abhilfe schaffte nur ein harter Reset des PCs, danach lief die Tasksequenz weiter und konnte erfolgreich abgeschlossen werden. Das Image, das aktuell verteilt wurde, sowie ältere Images liefen allerdings ohne Problem durch.

Im SMSTS.log konnte ich folgende Zeilen entdecken:

Successfully completed the action (Setup Windows and ConfigMgr) with the exit win32 code 0
The action (Setup Windows and ConfigMgr) requested a retry

1 2	Successfully completed the action (Setup Windows and ConfigMgr) with the exit win32 code 0 The action (Setup Windows and ConfigMgr) requested a retry

Seltsam, wenn der Step erfolgreich ausgeführt wurde, wieso sollte er dann wiederholt werden? Am Ende des SMSTS.log fand ich dann diesen sich ständig wiederholenden Fehler:

Failed to create instance for IMTCTokenHandler interface, hr=0x80070005
Waiting for ccmexec process to start

1 2	Failed to create instance for IMTCTokenHandler interface, hr=0x80070005 Waiting for ccmexec process to start

Nach langer Fehlersuche und allerlei Troubleshooting-Maßnahmen (neues Image einbinden, ConfigMgr-Client neu verteilen usw.) bin ich dann auf die Fehlerursache gestoßen. Ich hatte kurz zuvor unsere ConfigMgr-Umgebung von 1602 auf 1606 aktualisiert, allerdings aus Unachtsamkeit nicht mein Custom Boot Image neuverteilt, was dann zu diesem Fehler führte. Nachdem das Bootimage upgedatet war lief alles wieder fehlerfrei durch.