9 Replies Latest reply on Feb 7, 2019 4:09 AM by Klaus Salger

    Site Determination bei Änderung des Netzwerks (Win10 1709)

    RuedigerJ Specialist

      Hallo,

       

      ich habe Notebooks, die in unterschiedlichen Umgebungen (LAN) angeschlossen werden.

      Dabei werden sie natürlich nicht immer "abgeschaltet".

       

      Wenn jetzt der Netzadapter ein neues LAN findet oder eine neue IP-Adresse bekommt, dann müsste ja eigentlich eine neue Site-Ermittlung laufen.

      In einer Log ...\ClientServices\CMSRpcPerformSiteDetermination_SYSTEM_0000000188.log finde ich auch die Zeilen:

      08:09.03.697  : --------------------------------------------------------------------------------

      08:09.03.698  : --------------------------------------------------------------------------------

      08:09.03.698  : --------------------------------------------------------------------------------

      08:09.03.698  : LogFile C:\Program Files (x86)\Common Files\enteo\NiLogs\ClientServices\CMSRpcPerformSiteDetermination_SYSTEM_0000000188.log, started 18.01.2019 08:09.03

      08:09.03.698  : Application : c:\program files (x86)\netinst\mgmtagnt.exe(PID: 3708 [8860])

      08:09.03.698  : Version : 7.3.3.3830

      08:09.03.698  :

      08:09.03.698  : Params: "c:\program files (x86)\netinst\mgmtagnt.exe"

      08:09.03.698  :

       

      08:09.03.698  : Windows NT 10.0 x64 (Build 9600)

       

      08:09.03.698  : Product Type: WinNT, Terminal Server

       

      08:09.03.698  : Registered for ....

       

      08:09.03.698  : User lang: German, System lang: German

      08:09.03.699  :

      08:09.03.699  : Reportlevel: 0

      08:09.03.699  : Username: SYSTEM (is local admin), Workstation: ....

      08:09.03.699  :

      08:09.03.699  : --------------------------------------------------------------------------------

      08:09.03.699  :

       

      08:09.03.699  :

      08:09.03.699  :

       

      08:09.03.697  0 cmsext.dll  Extension c:\program files (x86)\netinst\magntext\cmsext.dll has version 7.3.3.3830

      08:09.03.699  2 cmsext.dll  Trigger site determination and wait for result

      08:09.08.961  2 cmsext.dll  Site determination finished with status 0

      08:09.08.961  : End Of Logfile

       

      Aber weiteres dazu finde ich nicht. Es scheint auch keine Site determination zu laufen.

       

      Wo finde ich die entsprechenden Logs? Unter DSMLogs$ selbst ist von dem Tag nur die NISRV32_*.log zu finden. Sonst keine. Die letzte cmsextSvc_SYSTEM_*.log ist über eine Woche alt.

      Kann ich die Site determination selbst anstoßen? Evtl. über die Windows-Aufgabenplanung?

       

      Gruß

      Rüdiger

        • 2. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
          RuedigerJ Specialist

          Hallo,

           

          also der NiAgnt32 wird bei uns im AD-LogonScript gestartet und läuft damit in aller Regel.

           

          Ich habe jetzt gesehen, dass mit einer Änderung am LAN-Anschluss doch etwas passiert.

          1. Die neue IP-Adresse wird sofort in den Eigenschaften des Compuerobjekts eingetragen.

          2. Die Site-Definition wird im Computerobjekt nicht sofort geändert. Das passiert erst später.

          3. Beim nächsten Start des Installers (NiInst32) finde ich in den Logs meistens den neuen/richtigen DSM-Server.

          Das Problem scheint also kleiner zu sein, als ich angenommen hatte.

           

          Allerdings geht bei der Site-Ermittlung "manchmal" doch noch etwas schief.

          In der cmsextSvc_SYSTEM_*.log ermittelt er dann die Site und prüft dann den Server/das Depot auf Erreichbarkeit. Ist es nicht erreichbar, dann nimmt er die Ausfallsite.

          Das Depot kann er wohl nicht immer erreichen. Hier der Part aus der Log:

           

          Erst ermittelt er die Site richtig, dann kommt so etwas:

          08:25.19.294  0 cmsext.dllA LAN connection is established, using site 66496

          08:25.19.294  1 cmsext.dll  --------------------------------------------------------------------------------

          08:25.19.294  1 cmsext.dll  Checking server availability

          08:25.19.294  1 cmsext.dll  --------------------------------------------------------------------------------

          08:25.19.310  0 cmsext.dll  Found context in registry: DSM-Server.Site.....

          08:25.19.326  0 cmsext.dll 

          08:25.19.326  0 cmsext.dll  Checking the availability of \\DSM-Server\DSM$\ (66497)

          08:25.19.326  1 cmsext.dll--------------------------------------------------------------------------------
          08:25.19.326  1 cmsext.dllChecking protocol configuration for depot 66497
          08:25.19.326  1 cmsext.dll--------------------------------------------------------------------------------
          08:25.19.326  1 cmsext.dllChecking SMB...
          08:25.19.326  0 cmsext.dllChecking NOaaaaa (IP_NAME) <--> * - * (IP_NAME)
          08:25.19.326  0 cmsext.dll  Address-Entry passed the test
          08:25.19.388  0 cmsext.dllChecking if all groups of rules are passed the test
          08:25.19.388  0 cmsext.dll  Address-Type: IP_NAME passed
          08:25.19.388  2 cmsext.dllSMB protocol definition matches.
          08:25.19.388  1 cmsext.dllChecking depot state...
          08:25.19.435  0 nwcmclnt.dllRole based login succeeded with domain\User
          08:25.19.435  E Warning (Module:mgmtagnt.exe, Severity:0x03): FPS.dllFailed to get attributes for '\\?\UNC\DSM-Server\DSM$\Update.$$$'

          Der Netzwerkpfad wurde nicht gefunden. (0x00000035)

          08:25.19.435  E Warning (Module:mgmtagnt.exe, Severity:0x03): FPSClnt.dllFailed to access the depot.

          Der Netzwerkpfad wurde nicht gefunden. (0x00000035)

          08:25.19.435  0 nwcmclnt.dllLogout Nwcm succeeded with domain\user
          08:25.19.435  E Warning (Module:mgmtagnt.exe, Severity:0x03): FpsClntHlp.dllUnable to determine if the depot is in update mode

          Der Netzwerkpfad wurde nicht gefunden. (0x00000035)

          08:25.19.435  2 cmsext.dllDepot is not accessible

          08:25.19.435  2 cmsext.dll  No server is accessible

          08:25.19.435  2 cmsext.dll  Found 1 neighbor sites

          08:25.19.435  2 cmsext.dll  Checking neighbor site 1: zz_Auffangsite

          08:25.19.451  0 cmsext.dll 

          08:25.19.451  0 cmsext.dll  Checking the availability of \\DSM-Ausfallserver\DSM$\ (66553)

          08:25.19.451  1 cmsext.dll--------------------------------------------------------------------------------
          08:25.19.451  1 cmsext.dllChecking protocol configuration for depot 66553
          08:25.19.451  1 cmsext.dll--------------------------------------------------------------------------------
          08:25.19.451  1 cmsext.dllChecking SMB...
          08:25.19.451  0 cmsext.dllChecking NOaaaaa (IP_NAME) <--> * - * (IP_NAME)
          08:25.19.451  0 cmsext.dll  Address-Entry passed the test
          08:25.19.498  0 cmsext.dllChecking if all groups of rules are passed the test
          08:25.19.498  0 cmsext.dll  Address-Type: IP_NAME passed
          08:25.19.498  2 cmsext.dllSMB protocol definition matches.
          08:25.19.498  1 cmsext.dllChecking depot state...
          08:25.19.529  0 nwcmclnt.dllRole based login succeeded with domain\user
          08:25.19.529  0 nwcmclnt.dllLogout Nwcm succeeded with domain\user
          08:25.19.529  2 cmsext.dllDepot is usable

           

          (Warum das Forum hier zum Teil eine Tabelle aus dem Text macht, weiss ich nicht. Aber ich glaube, man kann es lesen.)

           

          Dir Frage ist, warum kann der User nicht auf das Depot zugreifen? An den Rechten des Users liegt es auf jeden Fall nicht.

          Wo kann ich denn hier weitersuchen?

           

          Gruß

          Rüdiger

          • 3. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
            Klaus Salger Expert

            Hallo Rüdiger,

             

            prüf doch mal die Events in den Windows Eventlogs zu dem Zeitpunkt.

            Womöglich ist das Netzwerk zu dem Zeitpunkt noch nicht vollständig funktionsfähig.

             

            Ciao

              Klaus

            • 4. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
              RuedigerJ Specialist

              Hallo,

               

              Auf einem anderen Rechner habe ich jetzt die Windowsprotokolle dazu analysiert.

               

              In der cmsextSvc_SYSTEM_0000000029.log vom 22.1.2019 steht nach der erfolgreichen Ermittlung der Site:

              20:18.33.470  1 cmsext.dllChecking depot state...
              20:18.33.482  0 nwcmclnt.dllRole based login succeeded with Domäne\DSM-Adminuser
              20:18.33.482  E Warning (Module:mgmtagnt.exe, Severity:0x03): FPS.dllFailed to get attributes for '\\?\UNC\DSM-Server\DSM$\Update.$$$'

              Der Netzwerkpfad wurde nicht gefunden. (0x00000035)

               

              Im Windows-Security-Log finde ich Einträge dazu, oder besser kurz vorher.

              20:18:32 Ein Konto wurde erfolgreich angemeldet.

              Sicherheits-ID: Domäne\DSM-Adminuser

              Kontoname: DSM-Adminuser

              Kontodomäne: Domäne

              Prozessname: C:\Program Files (x86)\netinst\NIInst32.exe

              20:18:32 Einer neuen Anmeldung wurden besondere Rechte zugewiesen.

              20:18:32 Ein Konto wurde abgemeldet

               

              Also wurde kurz vorher ein Login mit dem DSM-Adminuser in die AD gemacht. Und zwar erfolgreich.

               

              Danach finde ich nur noch Eintrage zum System-Konto, bis er die Auffangsite prüft. Da steht dann eine explizite Anmeldung an den Depot-Server der Auffangsite.

              20:18:33 Anmeldeversuch mit expliziten Anmeldeinformationen.

              Hier ist dann ein Zielserver explizit angegeben, der Depot-Server der Auffangsite.

               

              Diese Einträge "Anmeldeversuch mit expliziten Anmeldeinformationen" sind hier zu dem richtigen Depot-Server nicht vorhanden. Weder erfolgreiche noch fehlgeschlagene.

              Das Netzwerk mit einer Verbindung zur Domäne scheint zu dem Zeitpunkt da zu sein.

               

              Mehr kann ich aus den Logs nicht ersehen.

               

              Gruß

              Rüdiger

              • 5. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
                Klaus Salger Expert

                Hallo Rüdiger,

                 

                der Login mit dem Service Account funktioniert auch offline (mit cached Credentials).

                Das heißt also nicht, dass eine Netzverbindung vorhanden ist.

                 

                Wie sieht's denn im System Eventlog aus?

                Gibt es da GPO- und TimeService-Events?

                 

                Dein Problem stellt sich so dar, dass beim Wechsel des LANs manchmal alles OK ist und machmal geht's schief.

                Und wenn es schief geht, dann funktioniert es aber später beim nächsten Polling.

                Ist das so richtig?

                 

                Die "Failed to get attributes for Update.$$$"-Meldung ist jedenfalls typisch für "es kann nicht auf das Share zugegriffen werden".

                Und wenn ich dein Problem richtig verstanden habe, dann würde sich das durch eine Verzögerung beim Herstellen der Netzverbindung ganz gut erklären lassen.

                Manchmal geht's schnell genug -> alles gut, der Zugriff auf das normale Depot funktioniert. Machmal dauert's einen Tick länger -> Zugriff auf das normale Depot funktioniert nicht.

                 

                Dass die NIC eine normale IP-Adresse hat siehst du im cmsextSvc-Log vor der Site Determination, richtig?

                Ach ja, eine Prüfung der Eventlogs auf der Serverseite wäre auch nützlich. Für den Fall, dass der Client z.B. ein Authentifizierungsproblem hätte, sollte man es da sehen.

                 

                Wenn es sich nicht um eine Verzögerung beim generellen Netzzugriff handelt (z.B. wg. Spanning Tree), dann käme z.B. auch so etwas wie "langsame Namensauflösung" in Frage.

                Zum Thema Verzögerungen beim Netzzugriff gibt es einen ganz interessanten Artikel von MS: https://support.microsoft.com/en-us/help/938449/netlogon-event-id-5719-or-group-policy-event-1129-is-logged-when-you-s

                Da geht es zwar um's Booten und NetLogon, da könnte für dich aber womöglich auch etwas interessantes dabei sein.

                 

                Schön wäre es, wenn man den DSM Core Service überreden könnte nach Erkennung einer Änderung an der Netzverbindung noch ein paar Sekunden zu warten.

                Ich sehe da allerdings keine Möglichkeit.

                Das wäre evtl. ein Feature Request an Ivanti.

                 

                Ciao

                  Klaus

                • 6. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
                  luckydevil Specialist

                  Moin,

                  hmmm...  "Update.$$$" ist das ein Überbleibsel von einem Update auf dem Depot?

                  Normalerweise werden "Update.$$$" nach einem Update ja wieder gelöscht.

                  Hintergrund:

                  Während des Updates wird automatisch eine Datei namens "Update.$$$" im deinem DSM$ Share abgelegt.

                  Solange "Update.$$$" dort liegt ist der Server bzw. das Depot im "Wartungsmodus" und die Clients machen nichts damit, auch kein Update.

                   

                  HTH

                  lucky devil

                  • 7. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
                    Klaus Salger Expert

                    Nee, das täuscht in diesem Fall.

                    Es wird ja gemeldet, dass auf Update.$$$ NICHT zugegriffen werden kann.

                    Der Hintergrund ist wohl, dass der erste Zugriffsversuch auf das Depot immer die Prüfung auf die Update.$$$ ist.

                    Und der Zugriff geht schief weil nicht auf das Share zugegriffen werden kann, daher die Fehlermeldung.

                    Ist "ein wenig" missverständlich...

                     

                    Ciao

                      Klaus

                    • 8. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
                      RuedigerJ Specialist

                      Hallo,

                       

                      ich habe mit dem User von dem Rechner gesprochen. Der User war zu der Zeit nicht da. Der Rechner wurde vorher in den Energiesparmodus "Energie sparen" versetzt.

                      Im Systemprotokoll kommen GPO-Events im Stundentakt. Evtl. trotz Energiesparmodus, evtl. wurde der Rechner auch schon vorher wieder aufgeweckt. Gefunden habe ich zu einem Aufwecken nichts.

                      Timeservice-Events sind keine im Systemprotokoll. Zumindest nicht zu der Zeit. Im Anwendungsprotokoll sind zu der Zeit auch laufend Einträge.

                       

                      Ein Wechsel des LANs hat hier nicht stattgefunden. Das ist ein normaler PC der nicht bewegt wird. Der ist an der LAN-Buchse angeschlossen und da ändert sich nichts.

                      Bei der Site-Emittlung ist manchmal alles OK und machmal geht's schief. Wobei es meistens funktioniert. Momentan hat der Rechner auch die richtige Site.

                       

                      In der cmsextSvc-Log stand die richtige IP-Adresse, die dann der richtigen Site zugeordnet worden ist. Was nicht funktioniert hat, war die Prüfung des Depots/Shares.

                       

                      Da auf dem Client im Securiry-Log kein Loginversuch an den Depot-Server der richtigen Site protolliert worden ist, wird das Gegenstück auf dem Depot Server wahrscheinlich nicht zu finden sein. Das Log geht aber auch nicht weit genug. vom 22.1.19 ist da nichts mehr. Das Login des DSM-Adminusers geht in die AD. Auf dem "%LOGONSERVER%" des Clients ist das Security-LOG aber auch nicht lang genug.

                       

                      An ein Problem mit der Namensauflösung (DNS) glaube ich eigentlich nicht. Am LAN hat sich ja nichts geändert. Das müsste alles im DNS-Cache sein.

                       

                      Mein Favorit ist momentan eine "eingeschlafene Netzwerkkarte". Aber dafür gibt es eigentlich zu viele Events in den Eventlogs, die das Netzwerk brauchen.

                      Um 20:18 Uhr hatte er das Problem. Um 19:32 Uhr und um 20:44 Uhr hat der Rechner die GPOs geprüft.

                       

                      Gruß

                      Rüdiger

                      • 9. Re: Site Determination bei Änderung des Netzwerks (Win10 1709)
                        Klaus Salger Expert

                        Ah, OK.

                        Wenn nach dem "Energie sparen" regelmäßig Events geschrieben werden, dann interpretiere ich das so, dass er nach dem Start des Standby wieder aufgewacht ist und gar nicht erfolgreich in den Standby gegangen ist.

                        Der Wechsel in den Energiesparmodus und auch der zurück sollte sich anhand der Kernel-Power-Events im System Eventlog nachvollziehen lassen.

                        Wenn kein Aufweck-Event im relevanten Zeitraum vorhanden ist, liegt es vermutlich daran, dass der Computer bereits lief.

                         

                        Wenn in regelmäßigen Abständen problemlos die GPOs aktualisiert werden, dann würde ich das als "es war ständige eine Netzverbindung da" interpretieren. Manche NICs bzw. Treiber schreiben entsprechende Events bei Verbindung und Trennung - das wäre hier natürlich hilfreich um Aktivitäten nachzuvollziehen. Kannst ja mal schauen.

                         

                        Damit ergibt sich folgendes Fehlerbild:

                        - der Computer lief, wurde aber nicht benutzt

                        - das Netzwerk stand zur Verfügung

                        Damit würde das ganze Thema "Verzögerungen beim Aufbau der Netzverbindung" als Ursache ausscheiden.

                         

                        Ich vermute, dass der DSM Service aktiv wurde weil ein reguläres Polling fällig war.

                        Das sollte sich anhand der DSM-Logs verifizieren lassen.

                         

                        Um das Fehlerbild etwas klarer zu bekommen würde ich jetzt mal prüfen wer wann wo betroffen ist etc.

                        • An welchen Standorten und welchen Depots tritt der Fehler auf?
                        • Seit wann tritt der Fehler auf?
                        • Was wurde in dem relevanten Zeitraum geändert? (Treiber, Virenscanner, DNS, Netzwerkkomponenten, etc.)
                        • Sind die Depots in der Virenscanner-Konfiguration ausgeschlossen?
                        • Wann und bei welchen Gelegenheiten tritt der Fehler auf?
                        • Welche Geräte sind betroffen? (Hersteller, NIC-Typ)

                         

                        Sollte der Fehler regelmäßig oder reproduzierbar auftreten, könnte man auch per ProcMon Daten sammeln und mal genauer prüfen, was um den missglückten Depotzugriff herum passiert.

                        Aber wie gesagt, ich würde jetzt erstmal weg von einem Einzelfall gehen und versuchen mehr Überblick zu gewinnen.

                         

                        Ciao

                          Klaus