Fehlende Applications im Software Center

Veröffentlicht am von

In System Center 2012 Configuration Manager (RTM und SP1) gibt es einen Bug, der verantwortlich dafür ist, daß im Software Center Applications nicht angezeigt werden, obwohl diese auf den Client zugewiesen sind.

Die Chance, von diesem Bug betroffen zu sein, ist meiner Meinung nach sehr gering. Ich selbst habe dies bisher nur in einer Umgebung gesehen, auf der über 1000 Applications auf einen Client zugewiesen sind. Laut Aussage eines Support Engineers von Microsoft gibt es aber einen weiteren Fall, bei dem dies “schon” bei 200 Applications aufgetreten ist. Ob die Anzahl der Deployments pro Client aber überhaupt eine Rolle spielt ist mir nicht bekannt. Außerdem ergaben Analysen von Microsoft, daß nur “high performance Clients” betroffen sind.

Wie erkannt man den Bug?
Direkt erst einmal gar nicht, d.h. man sieht client- und serverseitig erst einmal keine Fehlermeldung oder ähnliches. Ein Symptom ist, daß eine zugewiesene Applikation einfach nicht im Software Center angezeigt wird.

Für ein weiteres Troubleshooting kann das Deployment Monitoring Tool aus dem “System Center 2012 Configuration Manager Service Pack 1 Component Add-ons and Extensions” verwendet werden. Dieses listet zwar alle Applications, bei einem Klick auf eine betroffene Application bekommt man aber die Fehlermeldung “DT cannot be empty” und das Tool stürzt ab:

DMT

Entsprechend war es naheliegend, einen Automatismus zu verwenden, der die betroffenen Clients ermitteln kann.
Ich habe mich für eine Configuration Baseline mit einem Configuration Item (ehemals “DCM” / Desired Configuration Management) entschieden.
Das CI verwendet dazu ein Powershell-Skript (Powershell Version 3.0 erforderlich!) um die fehlenden DTs (Deployment Types) zu ermitteln:

CI-01

$ErrorActionPreference = "Stop"

$PSvers = $host.Version
if($PSvers.Major -lt 3)
{
Write-Host "Please install WMF 3.0 (kb2506143)."
write-host "Quit (255)"
exit 255
}

[int]$countMissingDTs = 0

try
{
$Applications = gwmi -namespace root\ccm\clientsdk -query "select * from ccm_application"
}
catch
{
exit 1
}

$AppsTotal = $Applications.Length

foreach($App in $Applications)
{
$AppDT = [wmi] $App.__Path

if($AppDT.AppDTs.Name.Length -eq 0)
{
$countMissingDTs = $countMissingDTs + 1
}
}

$countMissingDTs

Ich bin kein Powershell-Profi und konnte das Skript auch nur begrenzt testen, entsprechend ist es nur als Anregung für weitere Verbesserungen zu sehen 😉
Die Idee ist aber, die fehlenden DeploymentTypes (DT) zu ermitteln, diese zu summieren und am Ende des Skripts auszugeben.
Wenn kein DT fehlt, dann ist die Ausgabe 0 ($countMissingDTs) und der Rechner als “compliant” anzusehen. Ist die Ausgabe größer 0, so wird der Rechner als “non-compliant” angesehen:

CI-02

Als Ergebnis erhält man dann entsprechend alle Clients, die von dem Problem betroffen bzw nicht betroffen sind:

CI-Monitoring-01

Bei den betroffenen Clients entsprechend dann sogar mit Ausgabe der Anzahl der fehlenden Applications (in diesem Beispiel 5):

CI-Monitoring-02

Als “Lösung” für das Problem gibt es ein vbs-Skript (Quelle: Microsoft Support), welches auf den betroffenen Clients auszuführen ist.
Hier ist ebenfalls ein Automatismus denkbar. Die betroffenen Clients wurden per DCM/Compliance identifiziert, können entsprechend in einer Collection gruppiert und das Skript als Package/Program advertised werden.

'Trigger DCM Schedules for Applications
 Dim objWMI_MachinePolicy
 Dim query, AppCIAssignments
 'Connect to WMI
 Set objWMI_MachinePolicy = GetObject("wInmgmts:\\.\root\ccm\Policy\Machine")
 query=("select * from CCM_ApplicationCIAssignment")
 Set AppCIAssignments=objWMI_MachinePolicy.ExecQuery(query)
 For Each AppCIAssignment in AppCIAssignments
 'MsgBox "Starting schedule for " & AppCIAssignment.AssignmentID
 RunSchedule(AppCIAssignment.AssignmentId)
 WScript.Sleep 500
 Next
 Set objWMI_MachinePolicy=Nothing
 '--------------------
 'Function RunSchedule
 '
 'Purpose: Connects to WMI and triggers the supplied schedule.
 '
 '--------------------
 Function RunSchedule (ScheduleMessageId)
 Dim objWMI_RunSchedule
 'Connect to WMI
 Set objWMIService = GetObject("winmgmts:\\.\root\ccm:SMS_Client")
 objWMIService.TriggerSchedule(ScheduleMessageId)
 Set objWMIService=Nothing
 End Function

(Hinweis: dieser Blog-Artikel stellt keine fertige End-to-End-Lösung dar. Es soll nur prinzipiell gezeigt werden, wie ein ConfigMgr-Problem identifiziert und gelöst werden kann. Skript-Anpassungen können pro Umgebung ggfs. nötig sein.)

9 Gedanken zu „Fehlende Applications im Software Center“

  1. Pingback: SCCM: Fehlende Applications im Software Center | MS Tech BLOG

  2. Torsten

    The script does not fix the issues immediately. It just kicks off a DCM re-eval and that might take some time until it finishes (depending on the speed of the client and number of applications deployed. It took >10h on a client with 1.000 applications. See CI*.log. There’s an updated version of the script available though which has better logic. I can’t find it right now. Just call Microsoft support – this is a bug).

  3. Cédric Stainier

    Hi Torsten,

    Today I have run into the same issue as you described in your blog post. Our environment is running System Center Configuration Manager 2012 SP1 CU2 and contains +450 applications.

    The issue is not occurring on every application that has been deployed. Some applications that have been deployed as required were not showing up in the Software Center. I have used the Deployment Monitoring Tool to check what was happening and there I received ‘DT cannot be empty’ error message.
    I have changed the deployment type from ‘Required’ to ‘Available’ and at that moment the application was visible in Software Center.

    On another machine, the same required deployment was not showing up in Software Center. The Deployment Monitoring Tool returned the same error message. I have tried to run your scripts manually to fix the issue, but the application was not installing immediately. After 2 hours waiting, the installation process started. I don’t understand why the installation process kicked off after 2 hours. Even more strange, the deployment has been created around 10:11 AM, and in the deployment monitoring tool, on the Policy tab, the deadline is showing 12:11 PM.
    In the AppEnforce.log file the installation process starts just after 12:11 PM. The clients and server have the same date and time settings. There are maintenance windows configured, but the option to allow installations during the MWs has been checked in the deployments. From where is the 2 hours difference coming? Is this something you have experienced as well?

    Do you have more information if this behaviour is reported as a bug by Microsoft?

    Thanks!

    Kind regards,
    Cédric Stainier.

  4. Rob

    Hi Torsten-
    Ive had this issue for a long time in my environment, very very rarely. However since applying R2 it has become more prevalent. The script you provide here works well in getting the Software Center to populate with the applications, however mandatory applications will no install by themselves. Im wondering if you have an insight on this. Also if there is any more information out there available on this bug thats been plaguing us.

    Thanks-
    Rob

  5. Hermann

    Hallo

    Es ist definitiv ein Bug in SCCM 2012 R2. Call ist bei Microsoft auch offen.

    Wenn sie “required” Applikationen (auf Benutzer zugewiesen), muss Skript ein bisschen angepasst werden. Im Powershell habe ich ein Skript geschrieben, der dieses Problem behebt. Bei mir habe ich dieses Skript mit Configuration Items implementiert.

    $ErrorActionPreference = "Stop"
    try {
    $sidObjs = ( get-wmiobject -query "SELECT UserSID FROM CCM_UserLogonEvents WHERE LogoffTime = NULL" -namespace "ROOT\ccm")
    if ($sidObjs -ne $null) {
    foreach ($sidObj in $sidObjs) {
    $sid = $sidObj.UserSID.replace('-','_');
    $assignments = Get-WmiObject -query "select AssignmentName, AssignmentId from CCM_ApplicationCIAssignment" -namespace "ROOT\ccm\policy\$($sid)"
    if ($assignments -ne $null) {
    foreach ($assignment in $assignments) {
    #write-host "Processing Assignment $($assignment.AssignmentName) $($assignment.AssignmentId)"
    $sched=([wmi]"root\ccm\Policy\$sid\ActualConfig:CCM_Scheduler_ScheduledMessage.ScheduledMessageID='$($assignment.AssignmentId)'");
    $sched.Triggers=@('SimpleInterval;Minutes=1;MaxRandomDelayMinutes=0');
    $sched.Put()
    sleep -milliseconds 3000
    }
    }
    }
    }
    } catch {
    return $false
    }
    return $true

    Beim nächsten Client-Sync werden die geänderten Werte wieder auf Original gesetzt.

  6. Torsten

    Das Problem ist mit R2 definitiv *nicht* gelöst.
    Ich kann nur empfehlen, auf jeden Fall einen Call bei MS zu eröffnen (der dann meines Wissens ja kostenlos ist, da es sich um einen Bug handelt). Je mehr Leute solche Fehler melden, desto höher der Druck Richtung Product Group.

  7. Michael

    Hallo,

    leider sind wir auch von diesem Problem betroffen. Das VB-Script scheint aber keine Verbesserung herbei zu führen.
    Ist bekannt, ob mit Installation von R2 das Problem gefixt wird?

    Danke und Gruß

    Michael

  8. Torsten

    Ich kenne die Details (was aber an dem Problem nichts ändert) und es gibt leider keine andere Möglichkeit, das Problem zu lösen.

  9. Mario

    Hallo Torsten,

    nach einigen Tagen Problemanalyse bin ich auf deinen Blogeintrag gestoßen welcher mein Problem gelöst hat.

    Weißt du vielleicht auch wodurch dieser Fehler ausgelöst wird und wie er sich an der Wurzel beheben lässt und nicht mit dem VBScript im Nachhinein?

    Wir verwenden SCCM 2012 R2 mit ca. 1000 Windows 8 und XP Clients. Es sind etwa 30 Applications zugewiesen und etliche Updates.

    Danke, Mario

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert