5 Replies Latest reply on Jun 14, 2008 11:48 AM by dei

    Best Practice

    B.Marxer Expert
      Eine Fage an die Experten hier.

      Ich habe eine OU angelegt auf die ich alle benötigten Pakete die die Clients benötigen zugewiesen habe. Darunter auch die OS-Pakete. Wenn ich nun einen Clietns aus der V5.8x in die v6 übernhemen bekommt dieser für alle diese Pakete eine Policyinstanz zugewiesen auch für die OS-Pakete. Dies bedeutet dann ja auch dass das OS neu installiert wird.
      Nun wollen wir das ja nicht.
      Daher die Frage.
      Wie kann man dieses Problem am besten abfangen?

      Soll man dazu eine eigene OS-Setup OU anlegen?
      Allerdings muss man dann die ganzen Treiberpakete zwei OU's zuweisen und den Client bei jeder Neuinstallation verschieben.
      Oder ist es möglich die OS-Pakete vorgängig als PreInstalled Apps auf den Clients zu definieren?
      Oder man kann den Rollout der OS-Pakete bei jedem Client stopen. Dann muss man allerdiengs den Rollout der OS-Pakete wieder starten.
      Oder gibt es eine "geniale" Lösung die ich noch nicht gefunden habe.

      Besten Dank und Gruss
        • 1. Re: Best Practice
          FrankScholer Master
          Hallo Brian,

          ich würde empfehlen, die OS-Policies auf ne statische Gruppe zu legen. Alle Rechner, die du dann in diese Gruppe ziehst kriegen ne Instanz der Policy auf das zugehörige OS Installation Set und werden neu installiert...

          Gruß Frank
          • 2. Re: Best Practice
            Michi Expert
            Servus,

            so wie Frank schreibt, hab ich das auch gemacht.
            Ich habe eine OU Laptops und eine OU Workstations.
            Die beiden OU´s sind beide auf einer Ebene. Auf dieser Ebene habe ich eine statische OS Install Gruppe, in die die Clients kommen, die neu installiert werden sollen. Die Treiber werden auch der Gruppe zugewiesen. Plattenverschlüsselung z.B. weise ich dann nur der OU Laptops zu.
            • 3. Re: Best Practice
              dei Specialist
              Hi,

              die statischen Gruppe ist schonmal was. Eine weitere Möglichkeit besteht es über eine Schema-Erweiterung + Dynamische Gruppe zu steuern. Einfach eine Property dessen Standard-Wert "ex 5.8 Client" ist und ein Wert der sag ist kein migrierter Client, also neu. Danach das OS auf die Gruppe zuweisen und den Filter entsprechend setzen. Dann braucht man nicht mehr zu wissen wie die Gruppen Struktur ist wenn man neue Clients ins System holt.

              Grüße
              • 4. Re: Best Practice
                B.Marxer Expert
                Hallo,

                das sind ja schon mal zwei gute Vorschläge. Vorallem die Variante über die Schema-Erweiterung mit Dynamischen Gruppen gefällt mir im Moment recht gut.

                Damit könnte ich auch das Problem mein anderes Problem vorläufig abfangen. http://forum.enteo.com/showthread.php?t=5565
                Dazu habe ich einen Call bei enteo eröffnet.

                Schon mal besten Dank an alle.
                • 5. Re: Best Practice
                  dei Specialist
                  Hi,

                  naja das ist ja leider nicht ein Problem sonder eine Kette von Problemen . Ich kann dich da zumindest für das kommende 6.2 Release beruhigen, dort haben wir die ganzen Problem bei der Arbeit mit SWSets und OSSets gelöst und das Arbeiten mit Revisionen wird einfacher.

                  Grüße