none
"Resolving TaskSequence Dependencies" dauert ewig nach Upgrade RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen, 

    seit dem Upgrad auf 1902 haben wir einige Probleme mit dem OSD-Prozess auf unseren Aussenstandorten.

    Die Probleme die ich jetzt beschreibe treten nur an den RemoteSites auf. Die Sites haben jeweils einen eigenen DP.

    Nach dem PxE Boot dauert es erstmal gefühlt ewig bis die Policys geladen und man zur Passworteingabe und der Auswahl der bereitgestellen TaskSequenzen kommt. 
    Nach Auswahl der gewünschten TaskSequenz dauert es um den Faktor 1000 mal länger bis alle "Tasksequenz Dependencies" geladen sind.

    An unserem Hauptstandort ( Standort MP) dauert es ca.3 Sekunden. An den Remotelocation's bis zu 30 Minuten.

    Das SMTS.log zeigt keine Fehler oder Timeouts. Das IIS-Log auf dem MP zeigt auch keine Fehler.

    Verbindungen der PxE-Clients kommen an, werden mit 200 quittiert und es fliessen Daten.

    Ich habe die Logs eines "lokalen" und eines "remote" PxE-Clients direkt miteinander verglichen und dort dann eben festgestellt, dass Sie das exakt selbe machen, der "remote" Pxe-Client allerdings wesentlich länger braucht. 

    Klingt erstmal alles sehr nach Netzwerk-Angelegenheit sag ich mir, aber unser Netzwerker sagt er hätte nichts verändert und der zeitliche Zusammenhang mit dem Upgrade ist eben auch gegeben.

    Hat irgendjemand eine Idee ? Meine Remote-Site Admins rebelieren im Moment schon fast :)

    Viele Grüsse

    Andreas

    Sonntag, 29. September 2019 15:15
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Ich habe die Logs eines "lokalen" und eines "remote" PxE-Clients direkt miteinander verglichen und dort dann eben festgestellt, dass Sie das exakt selbe machen, der "remote" Pxe-Client allerdings wesentlich länger braucht. 

    Du meinst das smsts.log von einem Client? Und was genau dauert da länger? Jeder einzelne Request, so dass sich das dann aufsummiert?

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

    Montag, 30. September 2019 09:22
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Ja genau, das smts.log

    Jeder einzelne request dauert einige Sekunden und das summiert sich dann extrem auf.

    Gruss 

    Andreas 

    Montag, 30. September 2019 10:51
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andreas

    hast Du HTTPS am start ? hat sich was an der Zertifikatskette geändert? 

    Ich kenne das Problem wenn es bei der Validierung der Zertifikate dauert, das steht aber im Log pro Aktion eigentlich klar drin. 

    erfolgt der Download denn ?

    kannst Du SMSTSLog mal zeigen - evtl. hilft das ja weiter..

    Klaus

    Montag, 30. September 2019 15:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo, 

    nein HTTPS ist nicht aktiv.

    Ja die Daten werden gedownloadet und nachdem das dann alles mal abgeschlossen und resolved ist startet auch die Installation. 

    ich lade das SMSTSLog  mal hier hoch : 

    https://drive.google.com/open?id=1xgerVihFsz2_xSR0rM8yVGSl71HlobeL

    Danke im Vorraus für jeden Tipp




    Montag, 30. September 2019 19:39
    |
  • Question
    Anmelden
    0
    Anmelden

    hi, 

    ich habe mir die "kleine" Log eben mal angesehen ;-)

    da wird schon einiges abgearbeitet. 

    Was passiert wenn Du mal eine einfach TS mit ganz wenige Aktion erstellst, dann ist der Vergleich deutlich einfach

    Die Log selbst sieht soweit aber gut aus, was mich ein wenig verwundert in der Log das teilweise unterschiedliche SCCM Server angesprochen werden, ich sehe mir das morgen nochmal an. 

    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" |


    Montag, 30. September 2019 20:22
    |
  • Question
    Anmelden
    0
    Anmelden

    Die Log selbst sieht soweit aber gut aus, was mich ein wenig verwundert in der Log das teilweise unterschiedliche SCCM Server angesprochen werden, ich sehe mir das morgen nochmal an. 



    Das sind doch mMn nur unterschiedliche DPs im Content Location Reply.
    Beim ersten schnellen Drüberschauen ist mir aber auch keine Ursache aufgefallen. Hast Du die Boot Images aktualisiert (sprich: ist da dann auch der aktualisierte Client enthalten)?

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

    Dienstag, 1. Oktober 2019 08:17
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    das mit dem DP sehe ich auch so

    was mir aber unklar bzw. aufgefallen ist das verschieden Package andere DP's verwenden - das kenne ich so eigentlich nicht, sobald der Client einmal einen DP hat verwendet er diesen - ausser wenn das Package nicht auf dem DP liegt und er damit dann mehr oder minder gezwungen wird einen alternativen DP zu verwenden. Aber wie gesagt in der PXE Phase kenne ich das - bisher - nicht

    evtl. wäre es hier hilfreich - als als Fehlereingrenzung - mal eine einfache TS zu erstellen und das im Detail zu vergleichen. diese große Log im Detail zu betrachten ist sehr sehr zeitaufwendig. 

    lg klaus

    Klaus

    Dienstag, 1. Oktober 2019 08:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen, 

    danke für euer Feedback schonmal !
    Die Bootimages sind mit dem neuesten Win10 ADK ( 1903) upgedatet und verteilt.

    Ich habe im GoogleDrive soeben ein neues SMSTSLog abgelegt einer ganz einfachen TS.

    --> small_smsts.log

    Dieser LOG ist von einem Remote-Client.

    Am Standort wo auch der MP steht geht es wie gesagt innerhalb einer Sekunde durch. Am Remote-Standort seht ihr ja selbst jetzt im Log.

    Viele Grüsse

    Andreas

    Dienstag, 1. Oktober 2019 08:51
    |
  • Question
    Anmelden
    0
    Anmelden

    hallo Andreas

    mal so eine "schnelle" Idee

    wie sind denn die Antwortzeiten wenn Du von dem PXE Client aus dem MP anpingst ?, ist Tracert möglich? stimmen die Netzwerk Routen ?

    hast Du mal auf dem IIS die eingehenden Verbindungen verglichen ?

    Kommt der Request hier zeitverzögert oder kommt der Request zeitnahe ?

    ist das Verhalten gleich wenn Du "testweise" mal über USB Stick das probierst ?

    lg k. 

    Klaus


    Dienstag, 1. Oktober 2019 09:10
    |
  • Question
    Anmelden
    0
    Anmelden

    was Du u.U. noch probieren kannst ist, 

    lege einfach mal ein Test Deployment an und starte das mal. 

    hast Du auf der Collection noch andere Deployments wie Windows Updates, Windows Defender Updates ?

    der Eintrag "

    DEP-ZO4201C5-ZO2001AB-6F6BCC28." deutet darauf hin.. 
    lg klaus

    Klaus

    Dienstag, 1. Oktober 2019 09:17
    |
  • Question
    Anmelden
    0
    Anmelden

    hast Du auf der Collection noch andere Deployments wie Windows Updates, Windows Defender Updates ?


    Hallo Klaus,

    das ist unsere "UNKNOWN COMPUTERS" Collection und auf der haben wir dutzende Deployments :)

    Ich werde aber mal eine Collection erstellen für den einen RemoteClient und dort die TS alleinig deployend.

    Viele Grüsse

    Andreas

    Dienstag, 1. Oktober 2019 09:51
    |
  • Question
    Anmelden
    0
    Anmelden


    das ist unsere "UNKNOWN COMPUTERS" Collection und auf der haben wir dutzende Deployments :)

    Deployments von was? Bei der Collection machen doch nur Task Sequence Deployments Sinn. Alle anderen können doch von den Clients gar nicht ausgeführt werden, da die dann nicht mehr unknown sind.

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

    Dienstag, 1. Oktober 2019 13:31
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten, 

    ja das ist korrekt. Es sind auch nur OSD-Deployments.
    Aber eben dutzende. Diverse OS-Build&Capture, verschiedene Betriebssysteme, standortspezifische OS-Versionen etc.etc.

    Wir sind mittlerweile übrigens schon etwas weiter gekommen und zwar haben wir im IIS Log sehen können, dass die Connections zustanden kommen, aber die Responsezeiten astronomisch sind. Wie gesagt, nur bei RemoteClients. 

    Irgendjemand eine Idee wieso der IIS so lange braucht ?


    Dienstag, 1. Oktober 2019 13:54
    |
  • Question
    Anmelden
    0
    Anmelden

    Irgendjemand eine Idee wieso der IIS so lange braucht ?


    Das sind doch nur Content Location Requests, die er beantwortet und keine Downloads von Files, richtig (also folglich auch die IIS Logs von MP)?

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

    Dienstag, 1. Oktober 2019 14:24
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Genau, aber eben diese Content Location Requests brauchen ewig.

    Ich habe das IISLog ausgewertet und mal auf den betreffenden Traffic vom MP zum besagten Remote-Client bereinigt. 
    Habe es hier abgelegt als IIS_RemoteClient.log 

    https://drive.google.com/open?id=1xgerVihFsz2_xSR0rM8yVGSl71HlobeL

    Danke und viele Grüsse

    Andreas

    Dienstag, 1. Oktober 2019 16:44
    |
  • Question
    Anmelden
    0
    Anmelden

    Hast Du mal probiert das ganze etwas zu isolieren ?

    ich habe sehr schlechte Erfahrungen über die Jahre gesammelt wenn "so viele" einwirkt. Hier gilt für mich strikt "weniger ist mehr". 

    was mir unklar ist - warum liegt auf der Collection unknown so viel ?
    wenn der SCCM Client nicht installiert und richtig zugewiesen ist, ist das aus meiner Sicht nur "Ballast" und sicher unnötig. 

    das wird auch bei der Kontrolle der Log sichtbar. da ist vieles was nicht notwendig ist und das kostet alles Zeit. 

    hast Du mal die Speicher Auslastung vom dem IIS Worker kontrolliert. Evtl. 

    schau Dir das u.U. mal an

    https://social.technet.microsoft.com/Forums/en-US/4c8e7a3f-bc29-49f1-b3f1-5bf1b77f171e/sccm-1710-iis-worker-process-taking-too-much-ram?forum=ConfigMgrCompliance 

    hilft Dir hier die Vergrößerung, das habe ich nun schon öfters gesehen und die Veränderung bewirkt wahre Wunder... 

    zumindest scheinst Du nun mit dem Tip vom IIS Log ein wenig weiter gekommen zu sein. 

    lg Klaus 

    Klaus


    Mittwoch, 2. Oktober 2019 06:29
    |
  • Question
    Anmelden
    0
    Anmelden

    https://drive.google.com/open?id=1xgerVihFsz2_xSR0rM8yVGSl71HlobeL

    Wie sieht denn so ein Request für einen Client am Hauptstandort aus?

    2019-10-01 08:28:32 10.3.18.125 GET /SMS_MP/.sms_pol ScopeId_9F2F07F6-3109-4FF0-A69F-011158DFEC05/RequiredApplication_9a8af8ff-13a5-4f82-809f-ab3f43df6906/VI.SHA256:BA5C7F49909896D52296DF72166B4A6DCAE6F28CDA76AEE80F259B940F74473F 80 - 10.111.64.10 SMS+CCM+5.0+TS - 200 0 0 9955 11992

    Das sind ca 10s, was extrem lange ist. Ich sehe da aber erst einmal keinen Zusammenhang zu einer Anfrage von zentral oder remote. Wenn IIS oder SQL der Flaschenhals wären, da würde der ja in beiden Fällen zutreffen.

    Von welcher Version hast Du denn aktualisiert?

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

    Mittwoch, 2. Oktober 2019 08:44
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten, 

    wir haben von 1806 aktualisiert.

    Ich habe ein IIS_locale_Client.log erstellt und wieder hier abgelegt : 

    https://drive.google.com/open?id=1xgerVihFsz2_xSR0rM8yVGSl71HlobeL

    Danke und viele Grüsse

    Andreas

    Mittwoch, 2. Oktober 2019 11:12
    |
  • Question
    Anmelden
    0
    Anmelden

    Hier mal der direkte Vergleich:

    2019-10-01 08:28:32             10.3.18.125 GET /SMS_MP/.sms_pol ScopeId_9F2F07F6-3109-4FF0-A69F-011158DFEC05/RequiredApplication_9a8af8ff-13a5-4f82-809f-ab3f43df6906/VI.SHA256:BA5C7F49909896D52296DF72166B4A6DCAE6F28CDA76AEE80F259B940F74473F 80 - 10.111.64.10 SMS+CCM+5.0+TS - 200 0 0 9955 11992

    2019-10-02 11:08:24 W3SVC1 zoMP 10.3.18.125 GET /SMS_MP/.sms_pol ScopeId_9F2F07F6-3109-4FF0-A69F-011158DFEC05/RequiredApplication_9a8af8ff-13a5-4f82-809f-ab3f43df6906/VI.SHA256:BA5C7F49909896D52296DF72166B4A6DCAE6F28CDA76AEE80F259B940F74473F 80 - 10.3.40.206 HTTP/1.1 SMS+CCM+5.0+TS - - XyZ.com 200 0 0 9955 1129 3

    Die vorletzte Spalte sollte "sc-bytes" sein, die letzte "time-taken". Im langsamen Fall also ca 10x länger: https://support.microsoft.com/en-us/help/944884/description-of-the-time-taken-field-in-iis-6-0-and-iis-7-0-http-loggin: "Beginning in IIS 6.0, the time-taken field typically includes network time". Sieht auf die Ferne also noch einer recht langsamen Verbindung zum entfernten Standort aus.

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

    Mittwoch, 2. Oktober 2019 12:06
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten, 

    ja genau, diese Felder habe ich so interpretiert. 
    Wir sind eigentlich "gut" angebunden, mittlerer 2 stelliger MBit Bereich durchgängig. 

    Site2Site VPN und eine Checkpoint Firewall. 

    Es ist auch relativ unabhängig von Traffic, soweit ich das eben bisher testen konnte. <-- verschiedene Tag/Nacht-Zeiten 

    Irgendwie habe ich die Firewall im Verdacht... Unser Admin verweist aber auf den zeitlichen Zusammenhang mit dem Upgrade und er hätte nichts geändert.

    Mittwoch, 2. Oktober 2019 12:23
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen, 
    wir haben die IIS Logs nochmal analysiert und festgestellt, dass schon weit vor dem Upgrade das Problem bestand.

    Diese ewigen Laufzeiten haben also nichts direkt mit dem Upgrade zu tun.

    Womit ich allerdings noch immer nicht näher an der Lösung bin.

    Viele Grüsse

    Andreas

    Dienstag, 8. Oktober 2019 13:07
    |
  • Question
    Anmelden
    0
    Anmelden
    Danke für das Feedback. Auf die Ferne wird's mit einer weiteren Diagnose eher schwer, da viele "moving parts" involviert sind und man live auf div. Dinge gleichzeitig schauen muss, um ein Gesamtbild zu erhalten. Ich tippe aber trotzdem drauf, dass weder Windows noch ConfigMgr oder SQL schuldig sind, sondern eher etwas Richtung Netzwerk.

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

    Dienstag, 8. Oktober 2019 14:45
    |
    Beantworter