9 Replies Latest reply on Feb 16, 2016 9:14 AM by _Mel_

    Sich ausschließende Policys

    Felix1 Apprentice
      Hat jemand schon mal sowas hinbekommen?
      Ich versuche zu erreichen, dass bei Installation eines Software-Paketes ein anderes deinstalliert wird.
      Es soll also eine Abhängigkeit geben und betrifft die Pakete Adobe Reader und Acrobat.
      Mit der Funktion Policy Properties – Execution Restrictions klappt es jedenfalls nicht.
        • 1. Re: Sich ausschließende Policys
          Klaus Salger Expert
          Hallo Felix,

          der übliche Weg das zu realisieren ist m.E. eine Deny-Policy.
          Also, Du weist den Adobe Reader als Standard auf alle zu und Du hast eine extra Gruppe mit der Acrobat-Policy.
          Auf die Acrobat-Gruppe machst Du jetzt einfach eine Deny-Policy für den Adobe Reader.

          Das führt dann dazu, dass Computer, die der Acrobat-Gruppe hinzugefügt werden zunächst den Reader deinstallieren bevor der Acrobat installiert wird.
          Wenn die Gruppenmitgliedschaft schon vor der OS-Installation passt wird der Reader von Anfang an nicht installiert.

          Das sollte Dein Problem doch lösen, oder?

          Ciao
            Klaus
          • 2. Re: Sich ausschließende Policys
            _Mel_ Master
            da fallen mir spontan 4 möglichkeiten ein

            1. auf die gruppe mit acrobat noch zusätzlich eine deny policy für den acrobat reader setzen

            2. dem acrobat reader eine clientseitige voraussetzung geben, daß acrobat nicht installiert sein darf (nicht so ganz schick und funktioniert wohl erst erst ab 2015.2 richtig)

            3. in den scripten von beiden paketen die acrobat reader policyinstanz manuell anpassen - z.B. wenn acrobat installiert wird, fordert das paket eine deinstallation von acrobat reader an (eher unelegant und fehleranfällig und geht erst ab 2015.2)

            4. die beiden pakete als sich gegenseitig ausschließend definieren (voraussichtlich ab 2016.1 möglich)
            • 3. Re: Sich ausschließende Policys
              derniwi Master
              Hallo,

              ich habe so eine Umsetzung schon an ein paar Stellen gemacht, hierbei habe ich die von Klaus sowie die von Mel mit Nummer 1. vorgeschlagene Variante im Einsatz.

              Das klappt gut und ist relativ übersichtlich. hierfür kannst du dynamische oder statische Gruppen verwenden.

              Weiterhin funktioniert das auch schon, wenn Du irgendwann ein Upgrade durchführen und nicht auf einen Schlag alle Rechner umstellen möchtest. Dann legst Du einfach eine temporäre Upgrade-Gruppe an, die die neue Version installiert (neue Policy) und eine Deny-Policy auf die alte Version beinhaltet. Dann kannst Du alle Rechner nach und nach dort reinschieben und die bekommen die alte Version entfernt und die neue installiert. Am Ende tauschst Du die Ziele der Policies aus - also nicht einfach die Policies löschen, denn sonst werden die Pakete erst wieder entfernt und neu installiert.

              Gruß
              Nils
              • 4. Re: Sich ausschließende Policys
                Felix1 Apprentice
                Hallo Klaus, Mel und Nils,

                besten Dank für die Tipps. Was soll ich sagen - es funktioniert!
                Ich habe die Variante mit der Deny-Policy gewählt.
                Klingt eigentlich einfach. Nur bin ich nicht drauf gekommen. Bin bisher immer davon ausgegangen, dass Deny-Policies dazu dienen eine Installation gar nicht erst zuzulassen, also nicht im Nachhinein wirken.

                Die Antwort von Frontrange auf meine Frage war übrigens:

                "Ich kann Ihnen hierzu nur kostenpflichtige Hilfe durch unser Consulting anbieten. Eine Möglichkeit in DSM 2015.2 wäre z.B. Planung und Referenz › Variablen, Eigenschaften, Einstellungen › Befehle › eScript › ChangeSWAssignment ."

                Viele Grüße, Felix
                • 5. Re: Sich ausschließende Policys
                  solmera Apprentice

                  ...  Bin bisher immer davon ausgegangen, dass Deny-Policies dazu dienen eine Installation gar nicht erst zuzulassen, also nicht im Nachhinein wirken.


                  Alsooo, als ich noch bei FrontRange war, wurden Deinstallationen durch Deny Policies explizit in der Einsteigerschulung vorgestellt


                  Die Antwort von Frontrange auf meine Frage war übrigens:
                  "Ich kann Ihnen hierzu nur kostenpflichtige Hilfe durch unser Consulting anbieten. Eine Möglichkeit in DSM 2015.2 wäre z.B. Planung und Referenz › Variablen, Eigenschaften, Einstellungen › Befehle › eScript › ChangeSWAssignment ."


                  Das erklärt sich durch das oben gesagte. Support soll eben nicht eine Schulung ersetzen, da erfolgt eben oft der Hinweise auf Consulting (oder Training).

                  Der Ansatz mit dem eScript Befehl ist ja dann so gesehen auch korrekt, die anderen Optionen hat Mel hier aufgezeigt.

                  Schwierig bleibt es immer noch.
                  Wenn nun auf beiden (angenommen statischen) Gruppen eine Deny Policy für das andere Paket definiert wird, was passiert wenn ein Computer versehentlich in beide Gruppen eingefügt wird?
                  Oder ein Computer soll von der Reader in die Pro Gruppe verschoben werden, es wird aber vergessen den Computer aus der alten Gruppe zu löschen?

                  Es werden einfach beide Pakete deinstalliert, weil eine Deny Policy immer Priorität hat. Dies ist derzeit noch nicht lösbar (offenbar dann ab 2016.1 :cool,
                  Daher arbeite ich in solchen "entweder-oder" Situationen gerne mit Schemaerweiterungen und dynamischen Gruppen.

                  Als Installationsvoraussetzungen könnte man einstellen dass das andere Paket nicht installiert sein darf, aber dann gewinnt immer das erste Paket und das zweite wird nie ausgeführt. Das kann also nicht funktionieren, wie Du schon gemerkt hast.

                  Und zu guter Letzt: Im Forum wird Dir geholfen :-)

                  Frohes DSMen,
                  Axel
                  • 6. Re: Sich ausschließende Policys
                    derniwi Master
                    Hallo,

                    Schwierig bleibt es immer noch.
                    Wenn nun auf beiden (angenommen statischen) Gruppen eine Deny Policy für das andere Paket definiert wird, was passiert wenn ein Computer versehentlich in beide Gruppen eingefügt wird?
                    Oder ein Computer soll von der Reader in die Pro Gruppe verschoben werden, es wird aber vergessen den Computer aus der alten Gruppe zu löschen?

                    Es werden einfach beide Pakete deinstalliert, weil eine Deny Policy immer Priorität hat.


                    Das stimmt. Aber wann ist das wirklich schlimm? Unsere Anwender melden, sich, wenn der Adobe Reader fehlt. Der Fehler würde dann relativ schnell gefunden werden, da man auf dem entsprechenden Computerobjekt ja beide Deny-Policies sehen würde.

                    Schemaerweiterungen sind natürlich auch eine Möglichkeit, diese habe ich für ein paar wenige Programme in Verwendung, bei denen es verschiedene Versionen und Konfigurationen gibt, wie z.B. die SAP Gui. Somit kann man über eine Auswahl am Computerobjekt eine andere Version oder eine spezielle Konfiguration verteilen. Ein Nachteil hierbei ist aber, dass man auch alte Installationen verteilen kann, die man vielleicht nicht mehr möchte. Man kann in der Schemaerweiterung zwar Einträge deaktiveren, auf den Computerobjekten bleiben die Zuweisungen aber erhalten - auch bei einer Neu-Installation. Aber das ist ein anderes Kapitel.

                    Viele Wege führen nach Rom.

                    Gruß
                    Nils
                    • 7. Re: Sich ausschließende Policys
                      _Mel_ Master


                      Schwierig bleibt es immer noch.
                      Wenn nun auf beiden (angenommen statischen) Gruppen eine Deny Policy für das andere Paket definiert wird, was passiert wenn ein Computer versehentlich in beide Gruppen eingefügt wird?

                      die frage ist doch: was soll passieren ?
                      soll acrobat oder acrobat reader gewinnen ?
                      wenn acrobat gewinnen soll, dann machst du eine deny policy für acrobat reader auf die gruppe für acrobat - wichtig: keine deny policy für acrobat auf der acrobat reader gruppe.

                      wobei in der 2015.2 kannst du selbst das machen, denn du kannst auch den deny policies eine priorität geben.

                      z.B.
                      acrobat gruppe
                      - policy für acrobat (prio 1000)
                      - deny policy für acrobat reader (prio 1000)

                      acrobat reader gruppe
                      - policy für acrobat reader (prio 2000)
                      - deny policy für acrobat (prio 2000)

                      funktioniert auch
                      • 8. Re: Sich ausschließende Policys
                        derniwi Master

                        z.B.
                        acrobat gruppe
                        - policy für acrobat (prio 1000)
                        - deny policy für acrobat reader (prio 1000)

                        acrobat reader gruppe
                        - policy für acrobat reader (prio 2000)
                        - deny policy für acrobat (prio 2000)


                        Heißt das, dass die Deny-Policy für Acrobat innerhalb der Acrobat Reader Gruppe weniger "wert" ist als die Policy Acrobat in der Acrobat-Gruppe?

                        Oh je, das kann aber ganz schnell äußerst komplex werden, wenn da die richtigen Spieler ans System kommen.

                        Da wäre es mit lieber, es würde -nennen wir sie mal- Hütchenspieler-Gruppen geben, die miteinander verbunden sind, aber ein Objekt (Benutzer oder Computer) kann nur in höchstens einer Gruppe innerhalb des Verbundes sein. Oder in gar keiner.

                        Aber schauen wir erst einmal, wie sich DSM 2015.2 in der Praxis zeigt.

                        Gruß
                        Nils
                        • 9. Re: Sich ausschließende Policys
                          _Mel_ Master

                          Heißt das, dass die Deny-Policy für Acrobat innerhalb der Acrobat Reader Gruppe weniger "wert" ist als die Policy Acrobat in der Acrobat-Gruppe?

                          yo

                          Oh je, das kann aber ganz schnell äußerst komplex werden, wenn da die richtigen Spieler ans System kommen.

                          dsm erlaubt dir dir selbst in den fuß zu schießen - es zwingt dich nicht dazu

                          für so einen fall sollte man es auch nicht verwenden - die möglichkeit ist mehr dafür da eine policy mit ziel "managed users and computers" denien zu können ohne z.B. eine fachbereichbezogene policy für dasselbe paket ebenfalls zu blocken.

                          und in diesem fall wäre

                          acrobat gruppe
                          - policy für acrobat
                          - deny policy für acrobat reader (default prio)

                          acrobat reader gruppe
                          - policy für acrobat reader

                          ja auch völlig ausreichend

                          aber wenn du mit geschachtelten mengen von rechnern arbeitest, siehts anders aus.
                          also sowas wie
                          - alle rechner bekommen acrobat reader
                          - verwaltungsrechner bekommen acrobat
                          - IT (gehört zur verwaltung) bekommt nur acrobat reader (weil man bei der IT ja sparen kann)

                          jetzt brauchst du für die verwaltung eine deny policy für acrobat reader, die nicht die zuweisung von acrobat reader für die IT blockt.

                          Da wäre es mit lieber, es würde -nennen wir sie mal- Hütchenspieler-Gruppen geben, die miteinander verbunden sind, aber ein Objekt (Benutzer oder Computer) kann nur in höchstens einer Gruppe innerhalb des Verbundes sein. Oder in gar keiner.

                          ja, die hätte ich auch gerne... mach doch nen Feature Request