Troubleshooting: the Case of the missing Link

Mark Russinovich erklrt in seinen "the case of the..."-Blogposts unter anderem die IT-Probleme seiner Mutter, ich erklre meine bzw. die Probleme meiner Kunden rund um Windows und Ivanti DSM (ehemals HEAT DSM, Frontrange DSM, enteo, NetInstall). Es war einmal... ein DSM-Paket, das eine Verknpfung auf dem Benutzer-Desktop anlegt. Man sollte meinen, dass es kaum einfacher geht aber auch einfaches kann schiefgehen. "Die Verknpfung wird nicht bei allen Benutzern angelegt, z.B. nicht bei Benutzer 1" OK, also mal sehen. Schritt 1: offensichtliche Grnde Was ist das fr ein Paket? Gibt es offensichtliche Grnde, warum es nicht installiert wurde? Der Benutzerteil des Pakets, nennen wir es Paket A, wird nur installiert, wenn der Benutzer Mitglied einer AD-Gruppe ist. Alles klar. Das war ja einfach. Fertig. Das wird ein ziemlich langweiliger Blogpost. Nicht ganz. Benutzer 1 ist Mitglied der Gruppe im Active Directory und auch in der externen DSM-Gruppe. Na gut, dann also doch etwas genauer hinschauen. Schritt 2: RTFL Das htte man auch gleich am Anfang machen knnen aber seis drum - also Log lesen. Hier geht es um einen Benutzerteil. Der wird per Agent installiert, relevant ist hier also das Autoinstaller-Log NIAI32_*.log. Ich verwende vorzugsweise LogShark. Damit werden die Logs sinnvoll gefiltert und besonders relevante Eintrge farbig hervorgehoben. Ein Blick gengt um zu sehen wo welcher Fehler aufgetreten ist. Ein bisschen weniger komfortabel geht es per Notepad. Log ffnen und nach " E " (inklusive der Leerzeichen) suchen um Fehler zu finden oder nach "starting installation of" um von Paket zu Paket zu springen immer zum Installationsstart. Alternativ kann man auch nach dem Paketnamen, der Paket ID oder Policyinstanz ID suchen. Der Blick ins Log sagt mir, dass die Installation von Paket A berhaupt nicht gestartet wurde. Kein Wunder, dass die Verknpfung nicht angelegt wird. Tatschlich bricht die Installationssession bereits vorher bei der Installation von Paket B ab. Schade, dass man davon in der DSM-Konsole nicht viel sieht. Wre der Fehler im Computerteil passiert, wre die Policyinstanz rot oder zumindest nicht grn geworden. Immerhin gibt es mittlerweile in den "Policy-Instanz (Client)"-Eigenschaften u.a. eine Eigenschaft"Installation der Benutzerteile fehlgeschlagen". Wenn man da reinschaut, sieht man bei welchem Benutzer es ein Problem mit dem Benutzerteil dieser Policyinstanz gab. Und warum wird die Installationssession abgebrochen anstatt mit dem nchsten Paket weiterzumachen? Weil "Fehlgeschlagene Paket-Installationen berspringen" auf Nein gesetzt ist. Nur so ist sichergestellt, dass die Installationsreihenfolge auch im Falle eines Fehlers beibehalten wird, so dass Abhngigkeiten gewahrt bleiben. OK, das eigentliche Problem liegt also bei der Installation von Paket B. 1 11:56:04.988 1 Evaluating condition "not Exist('_InstallationParameters.UserDir_')" 2 11:56:04.989 2 SwmsTpExtenderScript: Couldn't find Property Definition INSTALLATIONPARAMETERS.USERDIR 3 11:56:04.989 1 SwmsTpExtenderScript: Couldn't resolve variable on object 5942 at value INSTALLATIONPARAMETERS.USERDIR 4 11:56:04.989 0 SwmsTpExtenderScript: Object: 2176 5 11:56:04.989 0 SwmsTpExtenderScript: Propertygroup: INSTALLATIONPARAMETERS 6 11:56:04.989 0 SwmsTpExtenderScript: Propertyname: USERDIR 7 11:56:04.989 2 Condition TRUE -> entering IF part 8 11:56:04.989 2 SwmsTpExtenderScript: Couldn't find Property Definition INSTALLATIONPARAMETERS.USERDIR 9 11:56:04.989 1 SwmsTpExtenderScript: Couldn't resolve variable on object 5942 at value INSTALLATIONPARAMETERS.USERDIR 10 11:56:04.989 0 SwmsTpExtenderScript: Object: 2176 11 11:56:04.989 0 SwmsTpExtenderScript: Propertygroup: INSTALLATIONPARAMETERS 12 11:56:04.989 0 SwmsTpExtenderScript: Propertyname: USERDIR 13 11:56:04.990 2 -> MakeDir('H:\daten\PaketB')/TU 14 11:56:04.990 0 siClnt32: Creating dir H:\daten... 15 11:56:04.990 1 Logging up ExR event 3106 (0x00000c22) 16 11:56:04.994 E Error (Module:Main, Severity:0x0b): Fehler beim Anlegen des Verzeichnisses H:\daten\PaketB 17 Das System kann den angegebenen Pfad nicht finden. (0x00000003) 18 11:56:04.995 2 Messagebox suppressed (No output allowed), output is written to the log files 19 11:56:04.995 2 MsgBox: [Fehler beim Anlegen des Verzeichnisses H:\daten\PaketB 20 Das System kann den angegebenen Pfad nicht finden. (0x00000003) 21 Installation wird beendet.] Ausschnitt aus dem NIAI32-Log mit zustzlich eingefgten Zeilennummern. Was passiert da? Konnte die Installationsparameter-Variable, ber die der Pfad konfiguriert wurde einfach nicht aufgelst werden? Kein Wunder, dass der Versuch das Verzeichnis entsprechend des Parameters anzulegen nicht klappt! Ah nein, das ist es nicht. In Zeile 13 ist zu sehen, dass die Variable schon den richtigen Inhalt hat, das Verzeichnis wird nur nicht gefunden. "not exist" wird wahr und entsprechend wird versucht das Verzeichnis anzulegen. Das scheitert aber genauso wie der lesende Zugriff davor. Mehr gibt das DSM-Log nicht her und auch die Windows Eventlogs bringen mich hier nicht weiter. Schritt 3: Vergleich von "funktioniert nicht" mit "funktioniert" Bei Benutzer 1 funktioniert der Zugriff auf das gemappte Laufwerk nicht. Aber es gibt auch Benutzer, bei denen alles tut wie es soll. Also nochmal auf dem gleichen Computer mit Benutzer 2 testen geht. Im Zuge der Tests schaue ich mir neben der automatisch beim Login, d.h. beim Start des Agents, gestarteten Installation der Benutzerteile auch die Situation spter an. "nderungen ausfhren" fordert ein erneutes Polling des Service und des Agents an und siehe da, das funktioniert auch bei Benutzer 1. Es gibt also ein Problem beim Zugriff auf ein gemapptes Verzeichnis, das nur manche Benutzer betrifft und auch nur beim ersten Start des Autoinstallers. Worin unterscheiden sich Benutzer 1 und Benutzer 2? Beide haben ein frisch auf dem gleichen Computer erzeugtes Benutzerprofil. Die zugewiesenen GPOs sind ebenfalls identisch. Also mal Gruppenmitgliedschaften prfen. Bingo es gibt einen aufflligen Unterschied: Benutzer 1 ist Mitglied einer administrativen Gruppe, die lokale Adminrechte auf allen Clients hat. Benutzer 1 ist also lokaler Admin, Benutzer 2 nicht. Schritt 4: Test der Admin-Hypothese Wenn die lokalen Adminreche das Problem verursachen wrden, dann msste das auch mit Benuzter 2 nachvollziehbar sein, bei dem es ja funktioniert. Also Benutzer 2 direkt in die Gruppe der lokalen Admins aufnehmen, Test Fehler. Benutzer 2 wieder aus der Admingruppe entfernen, Test geht wieder. Aha, Benutzer mit administrativen Rechten haben also ein Problem, die anderen nicht. Adminrechte und Probleme beim Zugriff auf gemappt Laufwerke - das kommt mir bekannt vor. Sollte das etwa ein Problem mit der Elevation (UAC) sein? Schritt 5: Analyse der Prozesse Werfen wir also mal einen genaueren Blick auf die Prozesse. Wer luft denn hier mit welchen Rechten und vor allem elevated oder normal? Ergebnis: Adminuser starten den Agent (NiAgnt32.exe) elevated, normale Benutzer nicht bei Adminusern wird auch der Installer (NiInst32.exe) elevated gestartet auch bei Adminusern wird der Installer nicht elevated gestartet wenn man "nderungen ausfhren" whlt Das erklrt das beobachtete Verhalten. Wenn der Installerprozess elevated luft hat er keinen Zugriff auf das vom Benutzer ohne Elevation gemappte Laufwerk. Schritt 6: die Lsung / der Workaround Ich umgehe das Problem, indem ich auch elevated Prozessen den Zugriff auf gemappte Laufwerke erlaube. EnableLinkedConnections per Registry aktiviert und geht. Paket B und in der Folge auch Paket A lassen sich jetzt auch fr Admins installieren. Der Workaround wird in ein DSM-Paket gegossen und auf alle Clients installiert. Das hat in diesem Fall auch ganz nebenbei den Vorteil, dass damit das immer mal wieder auch auerhalb von DSM-Paketen auftretende Problem mit dem Zugriff von Prozessen mit erhhten Rechten auf gemappte Laufwerke erledigt ist. Ich bin der Meinung, dass Agent und Installer mindestens dann nicht elevated starten sollten, wenn - wie in der betroffenen Umgebung der Fall -auch Admins zwecks Rechteerhhung den Service verwenden. Eingesetzt wird im vorliegenden Fall DSM 2016.2. Nachdem die Release Notes von 2016.2 R2 keinen passenden Fix listen und auch die aktuelle Patch Collection nichts dergleichen enthlt, erstelle ich einen entsprechenden Incident beim Hersteller Ivanti um herauszufinden, ob das Verhalten des Agents "by design" ist. Schritt 7: die Ursache Der Ivanti Support sagt sinngem "der Agent luft elevated wenn du ihn elevated startest - sonst nicht". Was? Ach so. Leuchtet irgendwie ein. DSM ist zwar durchaus in der Lage den Agent selbst neu zu starten aber naheliegend ist schon, dass der Agent eben elevated gestartet wurde und das liegt auerhalb des Einflussbereichs des Herstellers. In unserem Fall wird der Agent per GPO logon script gestartet. Und genau dieser Startmechanismus ist fr die Elevation verantwortlich. Wenn man das nicht mchte, muss man wohl einen anderen Startmechanismus whlen, z.B. ein klassisches Logonscript oder Start ber den Run Key. Letzteres kann man auch per Aktivierung der Einstellung "NiAgnt32.exe per 'Run' Registrierungssschlssel starten" in der ICDB automatisch einrichten lassen. Der Start des Agent ber ein GPO-Logonscript hat allerdings den Vorteil, dass man recht flexibel und bersichtlich konfigurieren kann, wer den Agent auf welchem Computer starten soll und wer nicht. Einfach elevated lassen und den oben beschriebenen Workaround zur endgltigen Lsung machen hat also auch was. Was war wichtig In diesem Fall haben diese Faktoren besonders zur Lsung beigetragen: systematisch Schritt fr Schritt vorgehen das Troubleshooting beginnt mit der Loganalyse Vergleich der Situation funktioniert / funktioniert nicht Wissen und Erfahrung zu DSM und Windows der Ivanti Support Das kann man womglich auch in anderen Fllen gebrauchen. Fragen oder Anregungen gerne per Kommentar.

zum Artikel gehen

Engineering

Wir legen großen Wert auf umfassende Dienstleistungen. Durch Einsatz neuer Technologien bekommen unsere Kunden einen Vorsprung im Mitbewerb. Wir unterstützen und beraten unsere Kunden von der Idee bis zum fertigen Produkt. Schwerpunkt der Dienstleistungen

zum Artikel gehen

Zahl der Auslösungen feststellen

Hallo allerseits! Ich bin mir sicher, daß es hier früher einmal einen Link zu einer Webseite gab, die nach Hochladen eines Bildes die Zahl der Auslösungen feststellte. Ich kann den Link nicht mehr finden. Welches Tool gibt es hierfür bzw. vllt

zum Artikel gehen

Mobile oberservation with our portable video system

Our MULTIEYE MOVES (Mobile Observation Video System) is made for mobile video surveillance and observation applications. It consists of LTE transmitter and receiver units in sturdy heavy duty cases. The cases as well as all connection plugs are waterproof

zum Artikel gehen

Bücherrettung Bilddokumentation

Ich habe viele Anfragen und Rückmeldungen zu meinem Bericht im Rahmen der Vollversammlung 2023 des VAR bekommen mit der Bitte, die PPP hier auf der Netzseite einzustellen. Das tue ich gern, weise jedoch darauf hin, dass es nur die Präsentation ist. Der fr

zum Artikel gehen

kann kein Gespräch annehmen

Zitat von textilfreshgmbh wenn ich deinen Link verfolge- aber Android 11/12 und 13- nicht aber Android 9, Trift aber auch auf Android9 zu bei dem Handy.

zum Artikel gehen