none
SCCM 2012 Ankündigung wird von Client nicht gefunden, Meldung: "there are no task sequences available for this computer" RRS feed

  • Frage

  • Hallo,

    ich habe zwei Tasksequenzen erstellt und diese auf zwei Sammlungen mit jeweils drei Mitgliedern verteilt. Das hat auch erstmal so funktioniert, wie es sollte, doch nachdem ich die Testrechner einige Male durch die TS installiert hatte, wird plötzlich keine TS mehr am DP gefunden. Weder bei dem einen Rechnermodell noch bei dem anderen. Ich habe schon nachgeschaut, ob evtl. doppelte Einträge vorhanden sind, konnte allerdings keine finden. In einem anderen Beitrag, der das gleiche Problem behandelt, habe ich den Hinweis gefunden, eine Sammlung zu erstellen, welche die BIOS GUID anzeigt, diese zeigt allerdings nur einen Treffer an.

    Kennt jemand dieses Problem bzw. kann weiterhelfen?

    Danke,

    Gruß
    Olaf

    Nachtrag: Den Server habe ich schon durchgestartet, alle Sammlungen aktualisiert und bei der Überwachung nachgeschaut, ob es in Konflikt stehende Datensätze gibt... da war aber nichts.
    Beim Standortstatus ist mir jetzt noch aufgefallen, das bei "Verwaltungspunkt" kritisch steht, dass aber keine kritischen Meldungen angezeigt werden..



    • Bearbeitet olaf81 Freitag, 1. Februar 2013 06:42
    Freitag, 1. Februar 2013 06:15

Antworten

  • "Genehmigen" kann man nur Resourcen, die Client=yes sind. Es ist nicht verfügbar für PKI-Clients und Client=no-Objekte (Discovery Objekte).
    Normalerweise werden Clients automatisch approved, wenn diese in Trusted Domains sind (bzw je nach Einstellung; siehe \Administration\Overview\Site Configuration\Sites -> Hierarchy Configuration). Dies könnte tatsächlich ein Grund für das Problem sein.


    Torsten Meringer | http://www.mssccmfaq.de


    Freitag, 1. Februar 2013 12:26
    Beantworter

Alle Antworten

  • Hast du den problematischen Client mal neu angelegt? Könnte ein obsoleter/veralteter Eintrag sein.

    David O'Brien | MCITP/MCSE/MCSA, CCEE | My blog: www.david-obrien.de | me on Twitter: @david_obrien | sepago GmbH

    • Als Antwort vorgeschlagen david_obrienMVP Freitag, 1. Februar 2013 08:10
    • Nicht als Antwort vorgeschlagen david_obrienMVP Freitag, 1. Februar 2013 08:10
    Freitag, 1. Februar 2013 07:27
  • Fehler im mpcontrol.log?
    Wird per PXE gebootet? Wenn ja, dann im smspxe.log nachschauen. Dort siehst Du die anfragende MAC/SMBIOS-Guid und die ResourceID, die verwendet wird (http://www.mssccmfaq.de/2010/04/08/pxe-boot-szenarien/). Anhand der ResourceID kannst Du dann (eindeutig) kontrollieren, ob der Rechner wirklich in der Collection ist, auf die die Task Sequence angekündigt ist.

    Torsten Meringer | http://www.mssccmfaq.de

    Freitag, 1. Februar 2013 07:44
    Beantworter
  • Neu angelegt habe ich ihn noch nicht. Ich könnte ihn gleich mal aus der DB löschen und neu importieren.
    Er wird allerdings auch nicht als "Veraltet" angezeigt. Ich habe noch eine Sammlung erstellt mit einer MAC-Abfrage, wo ich nur die MAC-Adresse des entsprechenden Clients eingetragen habe, um herauszufinden, ob er evtl. zweimal in der DB gelandet ist...,  ist er aber nicht. Das Merkwürdige ist, dass es nur bei Clients auftritt, die ich jetzt gestern testweise 3-4 instaliert habe. Vorhin habe ich einen anderen Rechner der gleichen Modellreihe über PXE booten lassen und er hat die TS sofort gefunden.


    • Bearbeitet olaf81 Freitag, 1. Februar 2013 07:46
    Freitag, 1. Februar 2013 07:46
  • Danke für den Hinweis, David.

    Ich habe das entsprechende Rechnerobjekt vorhin gelöscht und neu importiert, wobei ich die MAC und die BIOS GUID angegegeben habe. Als Sammlung habe ich gleich die Zielsammlung angegeben, sonst habe ich immer "Alle Systeme" gewählt und darauf das Objekt verknüpft. Nun startet die TS auch wieder...

    Es funktioniert zwar nun wieder, aber gibt es da vielleicht auch noch einen anderen Weg?

    Freitag, 1. Februar 2013 07:58
  • Es funktioniert zwar nun wieder, aber gibt es da vielleicht auch noch einen anderen Weg?


    Ja, der andere Weg ist der, den Torsten vorschlägt. Meiner ist quick & dirty (und teilweise offenbar nicht korrekt gewesen bzgl obsolet) und zeigt, dass wohl irgendwas mit dem Objekt nicht stimmte. Genauer findest du es über die Logfiles heraus.

    David O'Brien | MCITP/MCSE/MCSA, CCEE | My blog: www.david-obrien.de | me on Twitter: @david_obrien | sepago GmbH

    Freitag, 1. Februar 2013 08:10
  • Hallo Torsten,

    ich habe mir die smspxe.log aus dem Verzeichnis SMS_CCM\Logs angeschaut und dort diesen Eintrag zu dem Client gefunden, den ich vor wenigen Minuten dazu bringen wollte, die TS zu installieren.

    Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777471" ServerName="" ServerRemoteName=""><Machine><ClientID>GUID:FFCED611-35B3-4B75-9F23-06DC88908DB3</ClientID><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="20120029" OfferIDTime="31.01.2013 09:18:00" PkgID="20100030" PackageVersion="" PackagePath="http://sccm.xxx.de/SMS_DP_SMSPKG$/2010000B" BootImageID="2010000B" Mandatory="0"/></ClientIDReply>

    Trage ich diese BIOS-GUID nun in eine Sammlungs-Abfrage ein, bekomme ich kein Ergebnis.
    Den Eintrag OfferIDTime="31.01.2013 09:18:00" verstehe ich auch nicht, ist das der Zeitpunkt des ersten Rollouts?

    Danach wird noch die Zeile Client Identity: 271ab9c1-5d31-4076-88d8-b29ac5d5a5e5    SMSPXE    01.02.2013 09:03:32    3304 (0x0CE8)
    angezeigt, weißt Du, wie ich die Client Identity abfragen kann bzw. welches Attribut dafür steht?


    • Bearbeitet olaf81 Freitag, 1. Februar 2013 08:20
    Freitag, 1. Februar 2013 08:17
  • ich habe jetzt nochmal den Eintrag der ClientId mit den Eigesnchaften des Objekts in der entsprechenden Sammlung verglichen und dort steht folgendes:

    Vorherige ConfigMgr-UUID GUID:FFCED611-35B3-4B75-9F23-06DC88908DB3

    Also der Eintrag passt, nur warum steht hier nun "Vorherige..."?

    Freitag, 1. Februar 2013 08:23
  • Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777471" ServerName="" ServerRemoteName=""><Machine><ClientID>GUID:FFCED611-35B3-4B75-9F23-06DC88908DB3</ClientID><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="20120029" OfferIDTime="31.01.2013 09:18:00" PkgID="20100030" PackageVersion="" PackagePath="http://sccm.xxx.de/SMS_DP_SMSPKG$/2010000B" BootImageID="2010000B" Mandatory="0"/></ClientIDReply>

    Der PXE-Service Point antwortet mit Task Sequenz(en), die diesem Objekt (siehe Markierung) zugeordnet sind. In diesem Fall sollte der Boot ja geklappt haben, oder und das Deployment (OfferID="20120029") startbar gewesen zu sein?

    Torsten Meringer | http://www.mssccmfaq.de

    Freitag, 1. Februar 2013 09:53
    Beantworter
  • Ja richtig, einmal hat es nun mit diesem Rechner funktioniert..., boote ich jedoch nochmal über PXE, wird wieder keine TS gefunden.

    Die Tasksequenz ansich habe ich als "Verfügbar" bereitgestellt, mit F12 bootet der Rechner ins PE, die Kennwortabfrage kommt noch und dann werden keine TS gefunden...

    Der Item-Key ist auch korrekt, steht so unter den Eigenschaften des Rechnerobjekts im SCCM

    Setze ich einen Filter mit der Ressourcen-ID, wird mir auch nur genau dieses eine Objekt angezeigt
    • Bearbeitet olaf81 Freitag, 1. Februar 2013 10:26
    Freitag, 1. Februar 2013 10:23
  • boote ich jedoch nochmal über PXE, wird wieder keine TS gefunden.


    Was steht denn dann im smspxe.log?


    Torsten Meringer | http://www.mssccmfaq.de

    Freitag, 1. Februar 2013 11:18
    Beantworter
  • den Auszug, den ich eingefügt hatte, finde ich dann immer zu dem Zeitpunkt des Versuchs und dann folgen diese Zeilen..

    Looking for bootImage 2010000B    SMSPXE    01.02.2013 08:53:59    3304 (0x0CE8)
    PXE::CBootImageCache::FindImage    SMSPXE    01.02.2013 08:53:59    3304 (0x0CE8)
    PXE::CBootImageInfo::UpdateAccessTime    SMSPXE    01.02.2013 08:53:59    3304 (0x0CE8)
    Set media certificate in transport    SMSPXE    01.02.2013 08:53:59    3304 (0x0CE8)
    Set authenticator in transport    SMSPXE    01.02.2013 08:53:59    3304 (0x0CE8)
    Set authenticator in transport    SMSPXE    01.02.2013 08:53:59    3304 (0x0CE8)
    PXE::CNotifyTimer::TimerSignalFunc    SMSPXE    01.02.2013 08:54:19    4304 (0x10D0)
    PXE::CNotifyTimer::ProcessTimer    SMSPXE    01.02.2013 08:54:19    4304 (0x10D0)
    PXE::CBootImageManager::PerformMaintenenceTasks    SMSPXE    01.02.2013 08:54:19    4304 (0x10D0)
    PXE::CBootImageManager::PurgeOldImages    SMSPXE    01.02.2013 08:54:19    4304 (0x10D0)
    PXE::CNotifyTimer::Init    SMSPXE    01.02.2013 08:54:19    4304 (0x10D0)
    PXE::CNotifyTimer::CancelTimer    SMSPXE    01.02.2013 08:54:19    4304 (0x10D0)
    PXE::CNotifyTimer::RegisterTimeout    SMSPXE    01.02.2013 08:54:19    4304 (0x10D0)

    Freitag, 1. Februar 2013 11:39
  • ich habe nun nochmal in alle Sammlungen geschaut, ob das Rechnerobjekt noch irgendwo verknüpft ist... dabei habe ich das Objekt in der Sammlung "Alle Systeme" über einen Rechtsklick "genehmigt" Mir war aufgefallen, dass bei anderen Objekten diese Funktion gar nicht zur Verfügung stand. Kann dieser Schritt das Problem schon gelöst haben? Wenn es so wäre, könnte dieser Prozess dann nicht auch irgendwie automatisiert werden?
    • Bearbeitet olaf81 Freitag, 1. Februar 2013 12:24
    Freitag, 1. Februar 2013 12:18
  • "Genehmigen" kann man nur Resourcen, die Client=yes sind. Es ist nicht verfügbar für PKI-Clients und Client=no-Objekte (Discovery Objekte).
    Normalerweise werden Clients automatisch approved, wenn diese in Trusted Domains sind (bzw je nach Einstellung; siehe \Administration\Overview\Site Configuration\Sites -> Hierarchy Configuration). Dies könnte tatsächlich ein Grund für das Problem sein.


    Torsten Meringer | http://www.mssccmfaq.de


    Freitag, 1. Februar 2013 12:26
    Beantworter
  • Achso, dann könnte es ja evtl. auch daran gelegen haben, dass bei der ersten Verteilung der Rechner nicht in die Domäne aufgenommen wurde, oder?
    Freitag, 1. Februar 2013 12:31
  • Hallo,

    ja, eine erneute Installation funktioniert nun bei Clients, die nach der TS in die Domäne aufgenommen wurden, ohne Probleme. Nur bei einem Rechnermodell, dass nach der TS nicht in die Domäne aufgenommen wurde (warum weiss ich noch nicht, es sind alle Treiber installiert worden) muss ich immer erst das Rechnerobjekt löschen, da es dann zwei davon gibt. Einmal nicht veraltet, einmal veraltet. Ich gehe ja eigentlich nicht davon aus, dass ich das Rechnerobjekt noch im AD löschen muss, da die gleiche TS bei einem anderen Rechnermodell ja auch ohne Weiteres so funktioniert...  oder könnte das bestehende Rechnerobjekt im AD noch ein Grund sein?

    Diesen Fall kenne ich eigentlich nur, wenn bspw. ein Rechner defekt ist und ein neuer mit gleichem Namen in die Domäne aufgenommen werden soll.

    Dienstag, 5. Februar 2013 08:22
  • Normalerweise sollte das AD-Computerobjekt in Deinem Fall nicht stören. Ausnahme: es kommt zu komischen Timing-Effekten mit AD System Discovery und dem OSD.

    Torsten Meringer | http://www.mssccmfaq.de

    Dienstag, 5. Februar 2013 09:21
    Beantworter
  • Mittlerweile klappt es mit dem Verteilen ganz gut, es muss nur ab und an wieder ein Client genehmigt werden oder ein veralteter Eintrag gelöscht werden, damit eine TS gefunden wird.
    Dass einige Rechner nicht in die Domäne aufgenommen wurden, lag wohl daran, dass in der TS bei der "OU-Zuweisung" etwas eingetragen war. Nachdem ich den Eintrag entfernt hatte bzw. das Feld leer war, hat es funktioniert. So landen die installierten Rechner in der allgemeinen OU "Computers", was auch völlig i.O. ist.

    Danke für eure Hilfe,

    Gruß
    Olaf

    Mittwoch, 6. Februar 2013 09:57
  • Kleiner Hinweis: "Computers" ist keine OU, sondern ein "Container". Normalerweise sollte das Aufnehmen in eine OU klappen. Was nicht geht: Umziehen eines Clients von OU1 in OU2 während OSD mit Bordmitteln. Ist aber ein AD-Thema; für dasbeschriebene Verhalten kann ConfigMgr nichts.

    Torsten Meringer | http://www.mssccmfaq.de

    Mittwoch, 6. Februar 2013 10:26
    Beantworter