Troubleshooting: the Case of the missing Link

Mark Russinovich erklärt in seinen "the case of the..."-Blogposts unter anderem die IT-Probleme seiner Mutter, ich erkläre 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 Verknüpfung auf dem Benutzer-Desktop anlegt. 

Man sollte meinen, dass es kaum einfacher geht aber auch einfaches kann schiefgehen.

 

"Die Verknüpfung wird nicht bei allen Benutzern angelegt, z.B. nicht bei Benutzer 1"

 

OK, also mal sehen.

 

Was ist das für ein Paket? Gibt es offensichtliche Gründe, 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.

 

Das hätte man auch gleich am Anfang machen können aber sei’s 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 Einträge farbig hervorgehoben. Ein Blick genügt 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 Verknüpfung nicht angelegt wird. Tatsächlich bricht die Installationssession bereits vorher bei der Installation von Paket B ab.

 

Schade, dass man davon in der DSM-Konsole nicht viel sieht. Wäre der Fehler im Computerteil passiert, wäre die Policyinstanz rot oder zumindest nicht grün 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 nächsten 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 Abhängigkeiten 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 zusätzlich eingefügten Zeilennummern.

 

Was passiert da? Konnte die Installationsparameter-Variable, über die der Pfad konfiguriert wurde einfach nicht aufgelöst 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.

 

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 später an. "Änderungen ausführen" 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 prüfen.

Bingo – es gibt einen auffälligen Unterschied: Benutzer 1 ist Mitglied einer administrativen Gruppe, die lokale Adminrechte auf allen Clients hat.

 

Benutzer 1 ist also lokaler Admin, Benutzer 2 nicht.

 

Wenn die lokalen Adminreche das Problem verursachen würden, dann müsste 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?

 

Werfen wir also mal einen genaueren Blick auf die Prozesse. Wer läuft 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 ausführen" wählt

Das erklärt das beobachtete Verhalten. Wenn der Installerprozess elevated läuft hat er keinen Zugriff auf das vom Benutzer ohne Elevation gemappte Laufwerk.

 

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 für 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 außerhalb von DSM-Paketen auftretende Problem mit dem Zugriff von Prozessen mit erhöhten 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 Rechteerhöhung 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 enthält, erstelle ich einen entsprechenden Incident beim Hersteller Ivanti um herauszufinden, ob das Verhalten des Agents "by design" ist.

 

Der Ivanti Support sagt sinngemäß "der Agent läuft 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 außerhalb des Einflussbereichs des Herstellers.

 

In unserem Fall wird der Agent per GPO logon script gestartet.

Und genau dieser Startmechanismus ist für die Elevation verantwortlich.

 

Wenn man das nicht möchte, muss man wohl einen anderen Startmechanismus wählen, z.B. ein klassisches Logonscript oder Start über den Run Key. Letzteres kann man auch per Aktivierung der Einstellung "NiAgnt32.exe per 'Run' Registrierungssschlüssel 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 endgültigen Lösung machen hat also auch was.

 

In diesem Fall haben diese Faktoren besonders zur Lösung beigetragen:

• systematisch Schritt für 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 womöglich auch in anderen Fällen gebrauchen.

 

Fragen oder Anregungen gerne per Kommentar.