none
SCCM 1810 - Deployment und Wake on LAN RRS feed

  • Frage

  • Guten Tag,
    wir wollen in den nächsten Wochen per SCCM (CB1810) Windows 10 Enterprise (Build 1809) per Inplace-Upgrade auf unsere Clients ausrollen.
    Die entsprechende Tasksequenz für das Inplace-Upgrade funktioniert inzwischen problemlos. 

    Wir möchten nun das Upgrade pro Standort nachts ausrollen und die Clients entsprechend per Wake ON LAN (WOL) aufwecken.
    WOL per SCCM Console funktioniert. Es lassen sich sowohl einzelne Clients als auch ganze Device-Collections über die SCCM Console per WOL aufwecken.

    Leider klappt es aber nicht mit dem WOL, wenn wir die Task-Sequenz auf eine Testcollection verteilen ('Send wake-up packtes').
    Natürlich sind die Zeiten im Deployment auch so gesetzt, dass das Ausrollen erst Nachts startet (23:30 Uhr).
    Beim Test waren 3 PC in der Collection. 2 waren ausgeschaltet und einer war aktiv. Bei dem aktiven PC wurde auch pünktlich um 23.30 mit dem Inplace-Upgrade begonnen. Die beiden ausgeschalteten PC wurden aber eben nicht per WOL aufgeweckt!

    In der SCCM-Console unter Monitoring\Overview\Client Operations sind keine Einträge für ein versuchtes WOL der beiden ausgeschalteten Clients zu finden.
    Manuell über die SCCM Console lassen sich die beiden Clients problemlos per WOL starten.

    Hat Jemand eine Idee, warum das mit dem WOL im Deployment der Tasksequenz nicht funktioniert!?

    Gruß
    Dirk

    PS: Crossposting im MCSE-Board


    Freitag, 31. Mai 2019 06:26

Antworten

  • Das Rätsel ist gelöst!
    Microsoft hat zwischenzeitlich die Dokumentation zum WOL SCCM 'angepasst'. Die neue Methode des WOL ab SCCM 1810 funktionert ausdrücklich nicht im Rahmen des SW-Deployments!
    https://docs.microsoft.com/de-de/sccm/core/clients/deploy/configure-wake-on-lan

    Vielen Dank auch MS und WTF soll so etwas!? Da brauchen die Jahre um endlich ein halbwegs funktionierendes WOL über Subnetzgrenzen hinweg in SCCM zu integrieren und dann ist das wieder nur halber kram!
    Vielen Dank trotzdem an alle für die Unterstützung.

    Gruß
    Dirk


    Mittwoch, 5. Juni 2019 05:47

Alle Antworten

  • hi 

    wie erfolgt denn das WoL ? verwendest Du ein Tool dafür ?

    wenn Du das in der Task Sequenz ausführst ist denn dann sichergestellt das der Client auch über das Netzwerk bootet ? was steht denn im Status Message Log auf dem Server ? ist die Task Sequenz überhaupt ausgeführt worden. ? Normalerweise solltest Du in Status Log einen Eintrag für die Task Sequenze sehen. 

    was mir noch eingefallen ist, hast Du auf der Collection ein Wartungsfenster ?

    https://docs.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/hh427342(v=technet.10)#BKMK_WOLLog

    https://www.systemcenterdudes.com/sccm-wake-on-lan-client-notification/ 


    weitere info zu diesem Thema 

    In ConfigMgr we have two logs on the site server to monitor Wake on LAN activity: Wolmgr.log and Wolcmgr.log. Wolmgr.log basically shows us the status of the Wake on LAN manager component but it’s the Wolcmgr.log which shows us the status of the Wake on LAN packets.

    If the wake-up packets are being sent out, we get STATMSG=6504 in wolcmgr.log as per the screenshot below.

    clip_image008

    Once the sending of the packets is completed we receive STATMSG=6505 in wolcmgr.log.

    clip_image009

    Below is a table of Message ID’s with the description you will find in Wolcmgr.log. These ID’s will assist you in understanding the status of wake-up packets in the event of a success or a failure.

    clip_image010

    Quelle: http://www.aitltd.com/2017/03/17/wake-on-lan-in-sccm/ 

    lg klaus


    Klaus


    | Please Mark This As Answer if it solved your issue |
    | Please Vote This As Helpful if it helps to solve your issue |
    | Disclaimer:
     This posting is provided with no warranties and confers no rights. |
    | N 48° 8' 39.8419" E 11° 36' 1.3359" |


    Freitag, 31. Mai 2019 09:45
  • wie erfolgt denn das WoL ? verwendest Du ein Tool dafür ?

    wenn Du das in der Task Sequenz ausführst ist denn dann sichergestellt das der Client auch über das Netzwerk bootet ? was steht denn im Status Message Log auf dem Server ? ist die Task Sequenz überhaupt ausgeführt worden. ? Normalerweise solltest Du in Status Log einen Eintrag für die Task Sequenze sehen. 

    was mir noch eingefallen ist, hast Du auf der Collection ein Wartungsfenster ?

    https://www.systemcenterdudes.com/sccm-wake-on-lan-client-notification/ 


    Vielen Dank für die Antwort.
    Nein, ein extra Tool für WOL verwenden wir nicht (mehr). Seit SCCM 1810 funktioniert WOL ja endlich auch über Subnetzgrenzen hinweg. Wir haben in jedem Subnetz einen Server mit DP-Rolle. Das WOL ist genau so konfiguriert, wie in Deinem obigen Link beschrieben!

    Und ja, über die SCCM Console funktioniert WOL auch. Sowohl auf einzelnen Devices als auch auf Collections. Leider kann ich hie noch keine Bilder hinzufügen! :-(

    Beim Deployment ist 'Send wake-up packets' aktiv und das Wartungsfenster konfiguriert (ab 23.30 Uhr). In unserer Test-Collection sind 3 PC enthalten. 1 PC war eingeschaltet und 2 aus. Der PC der Eingeschaltet war, hat um 23.30 Uhr mit dem ausführen der Task-Sequenz begonnen und das Windows 10 Upgrade auf Build 1809 ist durchgelaufen.
    Bei den beiden PC in der Collection die aus waren ist nichts passiert. Ich habe die PC dann am nächsten Tag per SCCM Console mit WOL geweckt und die Installation ist gelaufen.
    Nur dass kann es ja irgendwie nicht sein!?

    Im Log tauchen nur unsere manuellen WOL per SCCM Console auf.

    Gruß
    Dirk

    Freitag, 31. Mai 2019 10:32
  • Und was ist mit den wol*.log zu dem Zeitpunkt?

    Torsten Meringer | https://blog.meringer.de/

    Freitag, 31. Mai 2019 12:44
    Beantworter
  • also was ich kenne aber das war vor Windows 10, 

    wenn der PC nicht sauber runtergefahren wird, geht das WoL nicht wirklich. 

    was passiert denn wenn Du es mal manuell versucht ? geht das dann?

    wichtig wäre wie Torsten schon schreibt mal ein Auszug aus dem Log. 

    Bitte vertrauliche Daten hier entfernen... 

    lg klaus


    Klaus

    Freitag, 31. Mai 2019 13:03
  • Zunächst mal Danke für die gutgemeinten Hinweise.
    Das WOL und SCCM nicht gerade einfach war/ist, ist schon klar. Nicht umsonst wurde hier in der Vergangenheit ein externes Tools genutzt mit dem wir WOL gemacht haben (SCCM 1702). Damit war es aber nur möglich einzelne Rechner aufzuwecken und eine Integration in ein Deployment war damit auch nicht möglich.

    Für die Windows 10 Umstellung wurde auch SCCM komplett neu gemacht. Und seit SCCM 1810 wurde das WOL ja nun endlich überarbeitet.
    Und ja, bei uns funktioniert WOL nun endlich ohne 3'rd Party-Tools! Wir können sowohl einzelne PC in unseren Standorten als auch ganz Standorte über die SCCM Konsole aufwecken!
    WOL funktioniert also!

    Der nächste Punkt ist jetzt (endlich) die Integration von WOL in das Deployment. Und genau dabei hakt es. Testweise haben wir eine neue Collection erzeugt und 3 PC in diese Collection aufgenommen.
    Diese 3 PC wurden alle testweise per WOL (SCCM Console) aufgeweckt! -> Funktioniert
    Dann wurde ein Deployment für die Gruppe konfiguriert (Start 23.30 -> Wartungsfenster, Installation Required und Send Wake-up Pakets aktiv). 

    • PC 1 wurde nachts laufen gelassen -> Deployment wurde ab 23.30 Uhr ausgeführt
    • PC 2 aus -> kein Wake up
    • PC 3 aus -> kein Wake up

    Der PC 2 wurde am morgen per WOL eingeschaltet. Deployment wurde nach dem Start umgehend ausgeführt.
    Fazit: Das Deployment funktioniert aber es werden im Rahmen des Deployment keine Wake-Up Pakete gesendet!

    Hat Jemand von Euch das Deployment mit WOL schon einmal mit der 1810ff getestet!?

    Gruß
    Dirk


    Montag, 3. Juni 2019 06:13
  • Diese Infos sind ja nicht neu. Die Logs sind für eine weitere Analyse unabdingbar.

    Torsten Meringer | https://blog.meringer.de/

    Montag, 3. Juni 2019 08:56
    Beantworter
  • Moin,
    ich darf hier leider bis zur Prüfung meines Accounts keine Links/Bilder einfügen.
    Daher hier ein kurzer Auszug aus den Logs.

    wolmgr.log
    ++ Next WOL trigger for deployment P032008B and collection [16777576] is 05/28/2019  21:30:00 (UTC). SMS_WAKEONLAN_MANAGER 28.05.2019 09:12:26 5844 (0x16D4)
    STATMSG: ID=6510 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_WAKEONLAN_MANAGER" SYS=SCCM1810 SITE=SITE PID=3892 TID=5844 GMTDATE=Di Mai 28 07:12:26.934 2019 ISTR0="P032008B" ISTR1="3" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=2 AID0=421 AVAL0="3" AID1=415 AVAL1="P032008B" SMS_WAKEONLAN_MANAGER 28.05.2019 09:12:26 5844 (0x16D4)

    Das Deployment der Tasksequenz mit der Anforderung des WOL wurde erkannt.

    wolcmgr.log

    WOLCManager waking up to process new jobs. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    Persisting job data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_PROCESSDATA'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)

    WOLCManager processing data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    STATMSG: ID=6504 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_WAKEONLAN_COMMUNICATION_MANAGER" SYS=SCCM1810 SITE=SITE PID=3892 TID=5776 GMTDATE=Di Mai 28 21:30:00.738 2019 ISTR0="P032008B" ISTR1="3" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=3 AID0=422 AVAL0="16b3330d" AID1=421 AVAL1="3" AID2=415 AVAL2="P032008B" SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    WOLCManager waiting 5 seconds for work. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    WOLCManager waking up to process new jobs. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_PROCESSDATA'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    WOLCManager processing data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    WOLCManager waiting 5 seconds for work. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 5776 (0x1690)
    WOLCManager retry for job id='16b3330d' - 1 retries of 3 maximum completed). SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 7684 (0x1E04)
    Persisting job data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:00 7684 (0x1E04)
    WOLCManager one or more existing jobs is ready. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:05 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_PROCESSDATA'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:05 5776 (0x1690)
    WOLCManager processing data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:05 5776 (0x1690)
    WOLCManager job id='16b3330d' will execute next in at least 55 seconds. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:05 5776 (0x1690)
    WOLCManager waiting 55 seconds for work. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:30:05 5776 (0x1690)
    WOLCManager one or more existing jobs is ready. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:00 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_PROCESSDATA'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:00 5776 (0x1690)
    WOLCManager processing data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:00 5776 (0x1690)
    WOLCManager job id='16b3330d' will execute next in at least 1 seconds. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:00 5776 (0x1690)
    WOLCManager waiting 1 seconds for work. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:00 5776 (0x1690)
    WOLCManager one or more existing jobs is ready. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:01 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_PROCESSDATA'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:01 5776 (0x1690)
    WOLCManager processing data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:01 5776 (0x1690)
    WOLCManager waiting 5 seconds for work. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:01 5776 (0x1690)
    WOLCManager retry for job id='16b3330d' - 2 retries of 3 maximum completed). SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:01 7684 (0x1E04)
    Persisting job data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:01 7684 (0x1E04)
    WOLCManager one or more existing jobs is ready. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:06 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_PROCESSDATA'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:06 5776 (0x1690)
    WOLCManager processing data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:06 5776 (0x1690)
    WOLCManager job id='16b3330d' will execute next in at least 55 seconds. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:06 5776 (0x1690)
    WOLCManager waiting 55 seconds for work. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:31:06 5776 (0x1690)
    WOLCManager one or more existing jobs is ready. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:01 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_PROCESSDATA'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:01 5776 (0x1690)
    WOLCManager processing data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:01 5776 (0x1690)
    WOLCManager retry for job id='16b3330d' has completed (3 retries). SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:01 7684 (0x1E04)
    STATMSG: ID=6505 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_WAKEONLAN_COMMUNICATION_MANAGER" SYS=SCCM1810 SITE=SITE PID=3892 TID=7684 GMTDATE=Di Mai 28 21:32:01.758 2019 ISTR0="P032008B" ISTR1="3" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=3 AID0=422 AVAL0="16b3330d" AID1=421 AVAL1="3" AID2=415 AVAL2="P032008B" SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:01 7684 (0x1E04)
    Persisting job data for job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:01 7684 (0x1E04)
    WOLCManager waiting 5 seconds for work. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:01 5776 (0x1690)
    WOLCManager one or more existing jobs is ready. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:06 5776 (0x1690)
    WOLCManager executing job id='16b3330d' in state 'STATE_COMPLETE'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:06 5776 (0x1690)
    WOLCManager completing job id='16b3330d'. SMS_WAKEONLAN_COMMUNICATION_MANAGER 28.05.2019 23:32:06 5776 (0x1690)

    Es wird dann auch zur im Deployment konfigurierten Zeit ein Eintrag im log zum WOL erzeugt. Das passiert insgesamt 3 mal mit jeweils 1 Stunde Pause dazwischen. 

    Interessant auch, dass keiner der WOL-Vorgänge die per SCCM Konsole ausgelöst werden in den beiden Logs auftaucht! Die WOL-Vorgänge per SCCM Konsole sind im SCCM unter '\Monitoring\Overview\Client Operations' geloggt.

    Mir kommt da ein Gedanke. Kann es evtl sein, dass MS bei der Änderung des WOL (ab SCCM 1810) nur das WOL per SCCM Console überarbeitet bzw. integriert hat und nicht das WOL im Rahmen eines Deployments entsprechend modifiziert hat!? 
    Das würde zumindest erklären, warum WOL über die SCCM Konsole funktioniert aber nicht per Deployment. Würde auch die fehlenden LOG-Einträge zum WOL per SCCM Konsole erklären.

    Gruß
    Dirk



    Dienstag, 4. Juni 2019 06:42
  • Das Rätsel ist gelöst!
    Microsoft hat zwischenzeitlich die Dokumentation zum WOL SCCM 'angepasst'. Die neue Methode des WOL ab SCCM 1810 funktionert ausdrücklich nicht im Rahmen des SW-Deployments!
    https://docs.microsoft.com/de-de/sccm/core/clients/deploy/configure-wake-on-lan

    Vielen Dank auch MS und WTF soll so etwas!? Da brauchen die Jahre um endlich ein halbwegs funktionierendes WOL über Subnetzgrenzen hinweg in SCCM zu integrieren und dann ist das wieder nur halber kram!
    Vielen Dank trotzdem an alle für die Unterstützung.

    Gruß
    Dirk


    Mittwoch, 5. Juni 2019 05:47