7 Replies Latest reply on Jul 21, 2010 11:29 AM by Frank.Scholer

    benutzerbezogene Softwarezuweisung

    alexander.knopp Apprentice
      hi enteo v6 Gemeinde,

      Wie würdet ihr euch auf einer grünen Wiese eine ideale Lösung im Zusammenhang mit benutzerbezogenen Zuweisungen vorstellen?

      Momentan werden in der v6 bei benutzerbezogenen Zuweisungen im Fall einer Anmeldung Maschinenpolicies erzeugt.

      Zu diesem Vorgehen gibt es immer wieder Rückfragen, Anregungen, usw.

      Deswegen stelle ich diese Frage mal hier in den Raum.
      Wie stellt ihr euch das vor?

      Ich sehe folgende Schwierigkeiten:
      Unterschiede zwischen servergespeicherten vs. lokalen Profilen
      Ping / Pong Effekt (Installation - / Deinstallation) der Software; gewünscht / nicht gewünscht?

      Soll Software komplett deinstalliert werden oder nur der Userteil?
      Wenn nur der Userteil deinstalliert wird, welche Auswirkung hat dies dann auf die Compliance?

      Welchen Sinn macht Compliance bei benutzerbezogener Zuweisung überhaupt?

      Wäre Interessant hier ein paar Anregung zu bekommen…

      Gruß
        • 1. Re: benutzerbezogene Softwarezuweisung
          SBRUTSCH Expert
          Hi Alex,

          ich zäume das Pferd mal von der anderen Seite auf.

          Folgende Anforderungen werden heute von v6 nicht abgedeckt:

          1. Externe Gruppe enthält User oder Usergruppen. Obwohl eine Policie auf der Gruppe liegt sehe ich für den User keine Instanz. Egal ob das Paket benutzerbezogen oder maschinenbezogen geflaggt ist. Sehr, sehr unübersichtlich. Schließlich weiß ich nicht auswendig auf welchem PC der Anwender angemeldet ist.

          2. Das abarbeiten der Policieinstanzen beim anmelden eines Anwenders dauert wesentlich länger als unter v5.x. Ist primär dadurch verursacht das die Pakete erst wieder lokal runter geladen werden bzw. der Cache überprüft wird. Bei mobilen Anwender möglicherweise sinnvoll bei Terminal Servern sehr aufwendig.

          3. Statische Usergruppen in v6 müssen wie früher die Maschinengruppen in der Struktur über dem Useraccount hängen damit er Mitglied davon werden kann.

          4. Bei der Installation eines Paketes ist in der eMMC nicht erkennbar ob der Userteil schon gelaufen ist oder nicht.

          Gruß
          Stefan
          • 2. Re: benutzerbezogene Softwarezuweisung
            alexander.knopp Apprentice
            Hi Stefan,

            das hast du jetzt "tricki" gemacht

            Zu deinen Punkten ist jetzt genau die Frage wie manche Dinge eigentlich gehen sollten, ich geh mal die Punkte durch...

            zu 1.
            1. gibt es noch die Möglichkeit benutzerbezogen oder maschinenbezogen zu flaggen? nicht das ich wüsste.
            2. welche Aussage hätte denn eine benutzerbezogene Instanz?
            - auf welchem PC wurde die Installation durchgeführt?
            - ohne servergespeicherte Profile muss das mehrfach ausgeführt werden. Was bringt dann die Information "wurde ausgeführt". Willst du dann eine liste auf welchen Rechnern das durchgeführt wurde? Und falls ja, was machen wir dann wenn wir servergespeicherte Profile haben.

            Zitat:
            Schließlich weiß ich nicht auswendig auf welchem PC der Anwender angemeldet ist.

            Genau das ist das Problem. Eine Idee wie man das lösen kann?

            zu 2.
            Freu dich auf v7.
            Dann geht so schnell wie früher...

            zu 3.
            wusste ich nicht. Usergruppen sollten genauso wie Maschinengruppen zwischenzeitlich kontextfrei sein!?

            zu 4. wie soll eine solche Darstellung aussehen?
            Willst du eine maschinenpolicy aufklappen können und dort die User sehen?
            was passiert wenn dieser userteil auf einem anderen PC wieder gelöscht wird (bei Verwendung von servergespeicherten Profilen).

            Gruß
            Alex
            • 3. Re: benutzerbezogene Softwarezuweisung
              SBRUTSCH Expert
              1. Ich meine hier die "Execution Restriction = Only, when user is logged on" --> das ist für mich in v6 Userbezogen.

              2. Ob die Userkonfiguration überhaupt ablief. Vielleicht ist ja der Agent nicht gestartet oder der Anwender hat sich gar nicht am Netz angemeldet. Gerade bei der Profil Neuerstellung eine wichtig Information.

              3. Tja, zumindest nicht unter Patch 6. Kann es später mal mit Patch 7 nachprüfen.

              4. Wenn der Benutzer sich anmeldet kann ja der Autoinstaller der eMMC zurück melden an welchem PC/Server das gerade passiert. Dies würde ich dann auch bei dem Useraccount anzeigen. Eine Policieinstanz mit einem Usericon davor und dem PC Namen dahinter.
              Der Zusammenhang zwischen PC Policie und dem Anwender würde ich dann über den Reiter "Associations" auflösen. Hier bin ich gewohnt etwas zu warten wenn ich die Zusammenhänge aufklappe. Unterhalb der PC Policie würde ich das nicht machen weil dies ja 1.000 Einträge enthalten kann.
              Super wäre es dann bei der Userpolicieinstanz zu sehen ob das Profil als Servergespeichertes Profil angelegt wurde oder nicht. Ob das noch drauf ist kann eh nur der Autoinstaller überprüfen. Und dann auch agieren falls das Serverprofil gelöscht wurde.

              Da fällt mir noch Nr. 5 ein:

              5. Eine Policieinstanz die über einen User berechtigt ist taucht jetzt beim PC auf und bleibt immer auf Pending solange der Benutzer nicht angemeldet ist. Dies ist in der Anzeige nicht nachvollziehbar. Und im Logfile taucht auch das Projekt nicht auf. Das würde mit der Lösung über Userpolicies nicht passieren.
              • 4. Re: benutzerbezogene Softwarezuweisung
                Frank.Scholer Master
                Hi zusammen,

                nur ganz kurz (bin noch beim Kunden):
                Habe 3. gerade (mit Patch 7) am Live-System ausprobiert - funzt so, wie man es erwarten würde (Gruppe ist kontext-unabhängig).

                Ich melde mich nochmal zu den restlichen Themen...

                Grüße Frank
                • 5. Re: benutzerbezogene Softwarezuweisung
                  alexander.knopp Apprentice
                  Hi,

                  ich möchte diesen Thread quasi gerne noch mal anschubsen.

                  Was wäre das (ideale) Wunschverhalten?
                  Eine User Policy Instanz die auf grün geht?
                  Aber dann wüsste ich nicht auf welcher Maschine etwas installiert wurde und in wie weit bringt mir die Info "User ist grün" etwas, wenn der "Schwerpunkt" der Anwendung ein Maschinenteil ist?

                  Und anderst herum dein Argument noch mal aufgegriffen.
                  Maschine ist grün, du weißt aber nicht ob der Userteil gelaufen ist.
                  Was sollte NI deiner Meinung nach "protokollieren" und wie soll es sich unter unterschiedlichen Rahmenbedingungen (servergespeicherte Profile <> lokale Profile) verhalten.

                  Und welches Verhalten erwartet man im "out of scope Fall"
                  Konkret:
                  Policy ist zugewiesen, Paket ist auf der Maschine installiert und für 3 Benutzer wurden die Benutzerteile ebenfalls installiert.
                  Policy wird wieder entfernt, Anwendung unterstützt keine Deinstallation.
                  Was soll passieren?
                  - Ab dem Moment gar nichts mehr (da ja keine Deinstallation unterstützt wird), d.h. bestehende Installationen (inkl. deren Benutzerteile bleiben erhalten) und es werden für weitere sich anmeldende Benutzer die Userparts nicht nachinstalliert.
                  - oder sollen die Userparts dann in diesem Fall dennoch nachinstalliert werden (bei MSI wäre das ja über das Apprepair auch so)
                  - Userteile versuchen zu deinstallieren, aber nicht den Maschinenteil?
                  - oder gar eine weitere Variante, die mir gerade nicht einfällt?
                  Ideen/Vorschläge?

                  Und angenommen, die Deinstallation wird unterstützt, wann soll die Compliance
                  auf "erfolgreich deinstalliert" gehen.
                  - wenn der Maschinenteil deinstalliert ist?
                  - wenn der Userteil deinstalliert ist?
                  wie ist hier der Unterschied zwischen einer benutzerbezogenen und einer maschinenbezogenen Policy zu betrachten (und auch hier wie immer das Thema lokale <-> servergespeicherte Profile).

                  Anregungen jeder Art sind willkommen

                  Gruß

                  Gruß
                  Alex
                  • 6. Re: benutzerbezogene Softwarezuweisung
                    Frank.Scholer Master
                    '>'>'>'>'>'>'>'>'>'>'>Hallo zusammen,'>'>'>'>'>'>'>'>'>'>'>endlich komme ich mal dazu, mir ein paar Gedanken zu dem Thema zu machen… ich fange einfach mal an ein bisschen zu brainstormen:

                      [*]I'>'>'>'>'>'>'>'>'>'>'>[COLOR=#1f497d]n Enteo v6 (und in v7 bestimmt auch) besteht jedes Paket implizit aus einem User- und einem Maschinenteil (früher: TUS) – im Prinzip sind’s also zwei Teil-Pakete, die zusammen verwaltet werden.


                      [*]Eine Policy entspricht einer „Berechtigung“, definiert also auf welchen Maschinen bzw. für welche User ein  Paket ausgeführt werden soll. Wichtig zu verstehen ist, dass die Policy NICHT den Soll-Zustand definiert, weil dieser immer nur für ein konkretes Zuweisungsziel (Computer oder User) berechnet werden kann, sondern nur das Regelwerk darstellt.
                      [*]Eine Policy-Instanz dagegen enthält sowohl den Soll-Zustand (das ist bereits die Existenz der Policy-Instanz, falls die existiert soll auch das entsprechende Teil-Paket installiert werden) als auch dem Ist-Zustand (Compliance-Status der Policy-Instanz)
                      [*]Wenn es sich also bei Paketen immer um zwei Teilpakete (die aus Compliance-Sicht auch getrennt betrachtet werden) handelt, dann wäre es meiner Ansicht nach grundsätzlich eine gute Idee, dass wenn ich ein Paket zuweise, den Maschinenteil als Computer-spezifische Policy-Instanz sehe, den Userteil aber auch als User-spezifische Instanz
                      [*]Zu beachten ist, dass in der Regel (oder zumindest recht häufig) die Beziehung Maschine <-> User eine m:n Beziehung ist, d.h. ein User meldet sich an mehreren Maschinen an und an einer Maschine melden sich mehrere User an. '>'>'>'>'>'>'>'>'>'>'>[COLOR=#1f497d]

                      Daraus folgt, dass eine User-spezifische Instanz auch Informationen enthalten muss, für welchen Computer sie gilt, während eine Computer-spezifische Instanz diese Informationen NICHT benötigt (melden sich mehrere User an derselben Maschine an, wird der Computerteil nicht nochmals ausgeführt).

                      Aus Enteo-Sicht ist es also keine m:n Beziehung, sondern eine 1:n Beziehung.
                    '>'>'>'>'>'>'>'>'>'>'>Nun etwas konkreter:

                      [*]Wird also eine Policy für ein Paket auf Computer (oder Gruppen-Objekte, die Computer enthalten) erstellt, dann werden ja vom BLS die Policy-Instanzen für die einzelnen Computer berechnet – so weit, so gut.

                      Es wäre aber, wie oben beschrieben, auch sinnvoll, Instanzen für die Userteile zu erzeugen. Da der BLS natürlich nicht im Voraus wissen kann, welche User an dem/den Gerät(en) arbeiten, müssten diese User-Policy-Instanzen zur Laufzeit (im Rahmen des Client-Sync des Agents) erstellt werden, sofern die Voraussetzungen passen (z.B. es in der Policy keine Einschränkungen auf bestimmte User gibt) und es für diesen User und diese Maschine noch keine User-Policy-Instanz gibt.
                      [*]Dieses Konzept existiert ja eigentlich bereits in v6, nämlich sowohl bei PnP-Policies, wo auch erst Policy-Instanzen erzeugt werden, wenn im Rahmen des Client-Sync ein entsprechendes Gerät als vorhanden erkannt wird, oder auch bei Patch-Policies. Das wäre dann analog.'>'>'>'>'>'>'>'>'>'>'>
                      [*]'>'>'>'>'>'>'>'>'>'>'>Umgekehrt wäre es natürlich auch so, dass wenn die Policy auf einen User oder eine User-Gruppe erzeugt wird, dass die Policy-Instanzen für die Userobjekte erzeugt werden, und zur Laufzeit für die Maschinen, an denen sich diese User anmelden.

                      Sollten die sich teilweise an Maschinen anmelden, wo irgendwelche Voraussetzungen nicht erfüllt sind (z.B. Plattform passt nicht), dann wird natürlich die Maschinen-Policy-Instanz nicht erzeugt und die User-Policy-Instanz bleibt gelb (stimmt ja auch – der User soll es eigentlich haben, aber an den Maschinen, an denen er sich angemeldet hat, durfte das Paket nicht ausgeführt werden, daher ist der Soll-Zustand noch nicht dem Ist-Zustand – Compliance pending also).
                    '>'>'>'>'>'>'>'>'>'>'>Jetzt gibt’s natürlich noch das Thema, dass in vielen Umgebungen die User wandern (das ist TUS!) und entweder Roaming Profiles eingesetzt werden oder eben nicht. Dazu fallen mir folgende Möglichkeiten und die von mir erwarteten Verhalten ein:'>'>'>'>'>'>'>'>'>'>'>

                      [*]keine servergespeicherten Profile / Software ist auf Maschinen zugewiesen:
                      meldet sich ein neuer User an einer Maschine an (Maschinen-spezifische Policy-Instanz existiert bereits), dann muss auf dieser Maschine logischerweise mindestens der Userteil  nachgezogen werden. Daher muss zur Laufzeit eine User-Policy-Instanz erzeugt werden für diese Maschine und entweder nur der Userteil ausgeführt werden (wenn die Maschinen-Policy-Instanz bereits compliant ist) oder eben beide
                      [*]keine servergespeicherten Profile / Software ist auf User zugewiesen:
                      meldet sich ein solcher User an einer Maschine an, wird eine Maschinen-Policy-Instanz erzeugt (sofern nicht bereits vorhanden) und die entsprechenden Teile (also in der Regel beide!) werden installiert
                      [*]servergespeicherte Profile / Software ist auf Maschinen zugewiesen:
                      meldet sich ein neuer User an einer Maschine an (Maschinen-spezifische Policy-Instanz existiert bereits), dann wird zwar eine neue User-Policy-Instanz für diese Maschine erzeugt, in der Regel wird aber garnichts ausgeführt (Userteil kommt über das Roaming Profile, Maschinenteil ist bereits vorhanden). D.h. am Ende des Installer-Laufs wird die user-Policy-Instanz einfach auf compliant gesetzt'>'>'>'>'>'>'>'>'>'>'>
                      [*]'>'>'>'>'>'>'>'>'>'>'>servergespeicherte Profile / Software ist auf User zugewiesen:
                      meldet sich ein solcher User an einer Maschine an, wird eine Maschinen-Policy-Instanz erzeugt (sofern nicht bereits vorhanden) und falls der Maschinenteil noch fehlt, wird dieser Installiert
                      '>'>'>'>'>'>'>'>'>'>'>[COLOR=#1f497d]Fortsetzung im nächsten Posting (wird zu lang - das Forum erlaubt nicht mehr als 10.000 Zeichen pro Post ;-)...
                    • 7. Re: benutzerbezogene Softwarezuweisung
                      Frank.Scholer Master
                      Verallgemeinert könnte man auch sagen:

                        [*]„früher“ (also in NI 5.x) hat sich jeder Client in der Registry selbst gemerkt, ob der User-oder Maschinenteil eines Pakets bereits installiert war (getrennt in HKLM und HKCU unterhalb von „InstalledApps“ – wir kennen das alle).
                        [*]Dieses „lokale Gedächtnis“ wurde nun in Enteo v6 in die CMDB verlagert (in Form von Policy-Instanzen), es hat sich jedoch nichts Grundlegendes daran geändert, dass Pakete weiterhin einen User- und einen Maschinenteil besitzen, deren Installationsstatus getrennt verwaltet werden muss.
                        [*]Das sich ggfs. mehrere User an einem Rechner anmelden, merkt sich die CMDB aber nicht nur den „CurrentUser“-Teil, sondern von allen „lokalen Profilen“ auf dem Computer.
                        [*]Für den Fall von servergespeicherten Profilen, ist dem BLS/der CMDB im Rahmen des Client-Sync bekannt, dass der Userteil für diesen User bereits installiert ist – es muss daher ggfs. lediglich eine Maschinen-Policy-Instanz ausgeführt werden. Die User-Policy-Instanz wird zwar auch erzeugt, aber ohne Ausführung auf compliant gesetzt.
                      Würde man das so implementieren, dann hätte man das aus NI 5.x bekannte Verhalten (das sich dort extrem bewährt hat) auf die v6/v7 wieder übertragen, mit dem Vorteil der zentralen Datenhaltung und der daraus resultierenden Compliance-Aussage.

                      Ein weiterer Vorteil wäre, dass dediziert z.B. Userteile zur Reinstallation eingestellt werden könnten (oder auch nur Maschinenteile), was in etlichen Situationen wünschenswert wäre.

                      Das meines Erachtens aber schlagende Argument ist, dass dadurch, dass im Rahmen des Client-Sync gemeldet wird, welche Teile bereits installiert sind und welche nicht und die darauffolgende dynamische Erzeugung von Policy-Instanzen, wieder das Konzept des Regelkreises implementiert wird. Es entscheidet also nicht mehr allein der „allwissende BLS“, welche Pakete / Paketteile ausgeführt werden, sondern die Instanz, die am besten Wissen kann, welche Pakete auf dem System bereits installiert sind und welche nicht (nämlich der Client). Führt man dieses Konzept konsequent weiter, dann kann man sogar so weit gehen, dass eine bereits in der CMDB vorhandene „grüne“ Policy-Instanz (die laut Datenbank also compliant ist), wieder auf gelb („Compliance pending“) geht, wenn im Rahmen des Client-Sync die Information übermittelt wird, dass der betreffende Paketteil fehlt! Und in dem Zuge könnte man dann auch gleich das Desired-State-Management einbauen, nämlich die „IsCompliant“-Bedingung an Paketen definieren, sodass ggfs. ein Paket nochmals ausgeführt wird, obwohl der BLS meint, der entsprechende Teil wäre korrekt installiert.

                      Dem Top-Management könnte man das ganze als „User-centric computing“ verkaufen (was ja gerade sehr hipp ist und alle Großen gehen aktuell in diese Richtung), sodass ggfs. Budget für die Implementierung genehmigt wird ;-)

                      So, das war man ne ganze Menge – zum Thema Deinstallation und „out-of-scope“ kriege ich bei 35° C jetzt keinen klaren Gedanken mehr zusammen. Dazu schreibe ich (vielleicht) morgen was.

                      Würde mich aber auch über Feedback sehr freuen. Wir können auch gerne mal telefonieren (Telko oder so) oder uns zu dem Thema auch mal wieder treffen und heiß diskutieren…

                      Viele Grüße
                      Frank