12 Replies Latest reply on Feb 12, 2018 5:51 AM by derniwi

    Best Practise aufbau OUs / Gruppen / Zuweisung

    kertus Rookie

      Hallo DSM-Community,

       

      wir wollen in einer bestehenden DSM Umgebung den Aufbau von Gruppen, OUs und Paket zuweisungen im zuge der Windows 10 Migration optimieren.

      Gibt es hierzu ein Whitepaper? Auch wenn jede Struktur Kundenspezifisch anders ist wäre ich über gute ansätze und beisbiele dankbar.

       

      Beispiel:

      Treiber zuweisung eines Rechnermodells auf eine Dynamische Gruppen mit Filter PCModell=xyz

       

       

      SG
      Lukas

        • 1. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
          derniwi Master

          Hallo Lukas,

           

          das ist etwas schwierig. Wie wollt Ihr die Installation handhaben? Komplett über DSM oder mit anderen Systemen gekoppelt und per SOAP-Schnittstelle das DSM steuern?

           

          Ich habe in "meiner" Umgebung die Treiber so angelegt, wie Du das beschrieben hast. Ich habe folgende Ordnerstruktur aufgebaut:

          Software:

          Driver Library
          - Hersteller 1
          -- Modell 1
          --- Windows 7 x64
          --- Windows 7 x86
          --- Windows 10 x64
          -- Modell 2
          --- Windows 7 x64
          --- Windows 7 x86
          --- Windows 10 x64
          - Hersteller 2
          ...
          

           

          Und in der ORG-Struktur ein paar dynamische Gruppen, da ich die Installation über eine Schmeaerweiterung steuere:

          - 10 Windows
          -- 100 Windows 7 driver
          --- 1000 Hersteller 1
          ---- 1000 Modell 1
          ---- 1000 Modell 2
          --- 1000 Hersteller 2
          ...
          

           

          Die ORG-Struktrur muss hier nicht nach der OS-Variant x64 oder x86 unterschieden werden, da das ja über die Treiberpakete automatisch geschieht.

          Man muss nur darauf achten, dass man bei den Filtern für die Gruppen auch alle Benennungen erwischt, sich bei unterschiedlichen BIOS-Version anders lauten können, z.B. Hersteller "HP" oder "Hewlett-Packard". DELL ist da nicht besser...

           

          Zu bedenken ist, dass ein LDAP-Filter max. sechs Abfragen enthalten darf.

           

          Ein "white paper" oder "best practice" kenne ich diesbzgl. nicht.

           

          Gruß

          Nils

          1 of 1 people found this helpful
          • 2. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
            derniwi Master

            Ach ja, bei Applikationen ist das wieder etwas anders: da hier die AD-Gruppen nicht automatisch übertragen werden, haben wir im Prinzip zwei Medthoden:

            - freie Software oder welche, für die wir genügend Lizenzen haben, gibt es über den Shop

            - Lizenzpflichtige Anwendungen werden manuell im DSM über Gruppen gepflegt, zu denen dann die entsprechenden Rechner zugeordnet werden

             

            Als dritte Verteilart gibt es noch, was auf alle Rechner installiert wird, das zähle ich jetzt aber nicht...

            1 of 1 people found this helpful
            • 3. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
              kertus Rookie

              Hallo Nils,

               

              zu deiner ersten Frage wir Verteilen Software auschließlich per DSM keine Koppelung mit anderen Systemen.

              Bezgl. deiner Ansätze für Treiber gehen wir ähnlich vor trotzdem danke für die Infos!

               

              Zu deinen Zweiten Post:
              Wie geht ihr mit Abteilungswechsel eines MAs um? Arbeitet ihr mit Deinstallations unterstützten Paketen? Oder lasst ihr die Abteilungsbezogene Software bei einen Wechsel auf den PC drauf?

              die Übersicht über den aufbau vom Treiber Post wäre für die Applikationen für micht fast noch intressanter.

               

              Danke & Gruß

              Lukas

              • 4. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                derniwi Master

                Hallo Lukas,

                 

                in der Regel ist die kritische Software diejenige, welche Lizenzen benötigt. Die wird dann meist eher einer Abteilung zugeordnet und somit PCs. Die Software wird in solchen Fällen dann deinstalliert.

                Und damit ergibt sich schon die Antwort auf die Frage, ob wir mit Deinstallationen arbeiten: tun wir. :-)

                 

                Bei den Applikationen habe ich ebenfalls eine Liste aufgebaut (so ähnlich):

                - 1000 System
                -- 1100 Nach der Betriebssysteminstallation
                -- 1150 Microsoft (.NET Framework, VC++ Runtime)
                -- 1200 HP
                -- 1200 DELL
                -- 1300 Language Packs
                -- 1400 PowerShell
                - 2000 Standardanwendungen
                -- 2100 Adobe Reader
                -- 2200 Adobe Flash
                -- 2300 MS Office
                -- 2400 SAP
                - 3000 Notebook-Anwendungen
                - 4000 Konfiguration
                - 5000 Lizenzkontrolle
                -- 5100 Anwendung 1
                -- 5200 Anwendung 2
                - 8000 zusätzlichen Anwendungen
                -- 8100 Freeware 1 (z.B. Firefox)
                -- 8110 Freeware 2
                -- 8120 Anwendung mit Konzernlizenz 1
                - 9000 Ende
                - 9100 Aufräumarbeiten...
                - Jobs
                

                 

                Entsprechend gibt es in der ORG-Struktur eine statische Gruppe

                - Anwendungen
                -- Anwendung 1
                -- Anwendung 2
                ...
                

                 

                Alles unter 5xxx findet sich somit auch irgendwie in der ORG-Gruppe unter den Anwendungen wieder. Und alles unter 8xxx ist im Software-Shop verfügbar.

                Die Pakete unter 1200 sind hardweare-abhängig, aber keine Treiber... diese werden dann auf dynamische Gruppen zugeordnet, die aus dem ersten Post die passenden Filter besitzen.

                 

                Gruß

                Nils

                1 of 1 people found this helpful
                • 5. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                  kertus Rookie

                  Vielen Dank für die ausführlichen Infos!

                  • 6. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                    derniwi Master

                    Gern geschehen.

                     

                    Es kommt halt darauf an, wie Ihr Euch organisieren wollt.

                    Denkbar ist auch eine weitere Unterteilung nach Standorten. Die Unternehmensorganisation würde ich ungern abbilden wollen, dafür ändert sich zu oft etwas... wie fein man etwas gleidert, ist auch noch ein Thema. Man muss nicht unbedingt für jede Applikation einen Ordner anlegen, das habe ich hier auch nicht. Aber bei den meisten, die aus mehr als einem Paket bestehen, ist das der Fall.

                     

                    Letztlich spiegelt die Darstellung im groben auch die Installationsreihenfolge wieder (die Infos sind dementsprechend gesetzt), aber bei kritischen Paketen gibt es hier auch Abhängigkeiten. SAP Gui wird zum Beispiel erst nach MS Office installiert, da es hier ein paar Einträge im SAP dazu gibt (Pfade...). Ebenso habe ich das Flash Plugin für Firefox nicht bei Firefox abgelegt, sondern beim ActiveX-Flash... es greift immer mal irgend ein Paket irgendwo anders rein...

                    • 7. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                      _Mel_ Master

                      kertus wrote:

                       

                      Wie geht ihr mit Abteilungswechsel eines MAs um?

                       

                      also wenn ihr da einen gründlichen umbau vorhabt, dann könntet ihr auch mal die benutzerbezogenen zuweisungen anschauen

                      ihr hättet also z.B. eine benutzergruppe für die abteilung, und die software wird auf diese gruppe zugewiesen

                      das benutzerobjekt ist in der gruppe und der rechner ist mit dem benutzer verknüpft.

                       

                      wenn dann der rechner ausgetauscht wird verknüpft ihr einfach den neuen rechner mit dem benutzer und die software für den benutzer wird auf dem rechner installiert

                      wenn der benutzer die abteilung wechselt schiebt ihr ihn einfach in eine andere gruppe und auf dem rechner wird die software angepaßt

                      und als netten nebeneffekt sieht man in der DSMC an jedem computer zu welchem benutzer er gehört und an jedem benutzer welche computer er hat

                       

                      kommt halt drauf an ob man lieber sagen will "Her Müller bekommt Office" oder "Herr Müllers Computer bekommt Office"

                      • 8. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                        derniwi Master

                        @Mel:

                        Das macht Sinn, wenn sich die Benutzer nicht auf unterschiedlichen Rechnern anmelden. Und evtl. auch, wenn Programme für die gesamte Abteilung oder Gruppe zur Verfügung stehen. Haben jetzt in einer Gruppe von 10 Leuten nur fünf ein bestimmtes Programm und die Leute melden sich mal hier und mal dort an, dann ist das leider eine endlise Installiererei / Deinstalliererei (je nach Lizenzmodell reicht es ja leider nicht, die Programmausführung nur auf best. Personen einzuschränken, dies ginge ja z.B. mit NTFS-Sicherheitseinstellungen...).

                        • 9. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                          _Mel_ Master

                          was du meinst sind die benutzerpolicies, die die software immer auf dem rechner installieren auf dem sich ein benutzer anmeldet (unterster punkt in dem screenshot) - die würde ich in der regel nicht empfehlen.

                           

                          ich meine die, die für die rechner gelten, die explizit mit einem benutzer verknüpft sind (mittlerer punkt in dem screenshot)

                          die können wie die alten benutzerbezogenen zuweisungen verwaltet werden, verhalten sich aber im betrieb wie computerbezogene zuweisungen.

                          d.h. die software wird nicht deinstalliert wenn sich mal jemand anders anmeldet und sie wird auch nicht auf alle rechner installiert an denen sich ein benutzer anmeldet.

                           

                          das einzige mögliche problem das ich sehe hat man dann, wenn ein benutzer mehrere rechner hat, man die software aber nicht auf allen haben will. wobei man das ggf auch mit include/exclude listen lösen könnte

                          • 10. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                            derniwi Master

                            Stimmt, das hatte ich glatt übersehen.

                             

                            Worin besteht dann der Vorteil zwischen einer Zuweisung auf Computer und Zuweisung auf zu einer Person assoziierten Computern? Bei 1:1-Beziehungen ist hier kein Unterschied, außer einem etwas höheren Verwaltungsaufwand. Und bei n:m-Beziehungen wird die lizenztechnische Sache kompliziert... gibt es sonst noch Vor- oder Nachteile dieser Zuordnungsart?

                            • 11. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                              _Mel_ Master

                              ich denke es kommt darauf an wie man arbeitet.

                              wie bekommst du zum beispiel zu einem rechner heraus welchem benutzer er gehört ? wenn du die information in DSM haben willst, dann muß sie da auch gepflegt werden und dann ist es kein extraaufwand wenn man die info auch für policies verwendet - machst du das in einem externen system, dann wäre es extraaufwand das in dsm zu pflegen (wobei man es dann natürlich über die soap schnittstelle automatisieren könnte, womit es wieder kein aufwand wäre)

                               

                              wenn du die computer-benutzer beziehung aber in dsm gepflegt hast, dann ist mit benutzerpolicies aber vieles einfacher, weil du dann für viele sachen nur noch mit den benutzerobjekten arbeiten mußt - und wenn die software auf den benutzer zugewiesen ist, dann kannst du z.B. dem benutzer einfach einen neuen rechner zuordnen und der bekommt die ganze software des benutzers installiert. wenn man rechnerbezogen arbeitet, dann muß man halt die gruppenmitgliedschaften des alten computers kopieren.

                               

                              und wenn ein rechner mehrere benutzer hat, dann ist es damit viel einfacher einen benutzer zu entfernen, weil man sich dann nicht überlegen muß welche software jetzt deinstalliert werden muß und welche bleiben muß.

                              1 of 1 people found this helpful
                              • 12. Re: Best Practise aufbau OUs / Gruppen / Zuweisung
                                derniwi Master

                                Ja, so gesehen hast Du vollkommen recht.

                                 

                                Ich glaube, ich muss mich mal näher mit SOAP befassen. :-)

                                Vielleicht kann man das "führende" System für die Verwaltung der Benutzer und Computer sowie Anwendungen damit aufbohren.