13 Replies Latest reply on Jun 29, 2011 3:53 AM by _Mel_

    User von Projekt ausschließen

    HE1 Apprentice
      Hallo zusammen,

      ich suche derzeit nach einer eleganten Lösung um User von der NI Installation auszunehmen und bei Bedarf wieder hinzuzunehmen.

      Die Situation:
      In der IT sitzen einige MAs, bei denen Netinstall aus mehreren Gründen nicht automatisch zuschlagen soll.
      Jetzt arbeiten die Entwickler allerdings auch mit virtuellen Maschinen und es kann vorkommen, dass sie entweder einzelne Netinstallpakete haben wollen, oder aber die volle Dröhnung einer kompletten Standardinstallation.

      Berechtigt und ausgeschlossen sind alle User über importierte AD-Gruppen, die seit DSM7 auch wunderbar funktionieren. Zugewiesen wird fast ausschließlich über Standardpolicies.

      Wie schaffe ich es jetzt (möglichst elegant), dass diese User den NI-Mechanismus selber temporär aktivieren und deaktivieren können?
      Am liebsten wäre mir eine Änderung pro Paket, aber wir sind hier ja nicht bei Wünsch-dir-Was

      Schöne Grüße
      Sven
        • 1. Re: User von Projekt ausschließen
          NicoS1 Master
          Hört sich nicht einfach an was du da vor hast.

          Was man mal versuchen könnte, ich bin mir aber nicht sicher ob das funktioniert:

          Einen Wartungsplan definieren, und kein Wartungszeitfenster angeben. Jetzt sollten die Policys theoretisch auf gelb stehen beleiben.

          Alles was man den Entwicklern dann geben müsste, wären die IDs der Policy Instanzen. Dann kann man via:

          niinst32.exe /EXECUTE:MDSID:PolicyInstance.xxxx (= ID, der Instanz)

          Das Paket von Hand anstarten.

          Ich weiß nur nicht ob dann der Wartungsplan berücksichtigt wird, oder nicht. Wenn er berücksichtigt wird, klappt das natürlich nicht.

          Ohne, dass die User Rechte in der Enteo Konsole haben seh ich nur die möglichkeit entweder selbst via SOAP was zu entwickeln, oder mit Drittanbieter-Tools selbst scripte zu bauen, die die Entwickler dann benutzen können.
          • 2. Re: User von Projekt ausschließen
            HE1 Apprentice
            Vielen Dank für die Idee. Das werde ich mir mal anschauen.

            Meine Idee war, dass ich per Loginskript den Frontrange Core Service einfach deaktiviere, wenn jemand in einer speziellen  AD-Gruppe ist. Dann muss ich einfach nur den User aus der Gruppe entfernen und schon läuft wieder alles los. Ich scheitere leider derzeit nur an den Berechtigungen des Loginskripts, das im Userkontext läuft. Und ein Startupskript würde ich mir gerne ersparen, da das dann alles ziemlich unübersichtlich wird.

            Ich befürchte, dass die Umsetzung mit NI Boardmitteln nahezu unmöglich sein wird und habe deswegen einen Feature Request abegegeben. Ich poste hier mal den Inhalt, falls sich jemand anschließen möchte
            Es kann doch eigentlich nicht sein, dass ich der einzige bin, dem das abgeht.

            Aktuelles Verhalten:
            Alle Pakete werden userbezogen per importierter AD Gruppe verteilt (nicht Computerbezogen! Das ist der springende Punkt, der ursächlich ist für dieses Problem). Fast alle Pakete haben vollständigen Deinstallationssupport.
            MA sitzt an einer WS und arbeitet dort. Anderer User mit höheren Rechten (bspw. Admin) muss sich kurz an diesem Rechner anmelden um irgendwas zu machen.
            Wenn der Admin ebenfalls über Netinstall bedient wird und andere Pakete zugewiesen bekam, dann beginnt jetzt eine Kaskade von neuen Installationen und Deinstallationen, bis der vermeintlich neue PC des Admins wieder NI compliant ist.
            Danach meldet sich der normale User wieder an und das Spielchen geht wieder in die andere Richtung.

            Herausforderung:
            Ausbau der Softwareverteilung per User statt per Computer.

            Gewünschtes Verhalten:
            Es wäre enorm hilfreich, wenn man dieses Verhalten ändern könnte. 2 Ansätze:
            1. Erweiterung der Testworkstations um User. Somit könnte man global festlegen, dass bestimmte User keine Netinstallaktion auslösen. Nachteil: Oft nicht granular genug
            2. Erweiterung der Policyarten um eine neue Art von Deny. Dieses „User-Deny“ würde dann einfach nur jede Netinstallaktion für ein spezielles Paket unterbinden, wenn sich ein bestimmter User anmeldet. Es passiert auf gut Deutsch einfach nichts mehr, wenn sich der Admin anmeldet. Vorteil dabei ist, dass diese „User-Deny“ Policy auf eine AD (oder NI) Benutzergruppe angewandt werden könnte. Wenn man jetzt also einen User von diesem Mechanismus ausnehmen will, dann muss man ihn nur noch aus der Gruppe entfernen und schon verrichtet NI wieder normal seinen Dienst.

            • 3. Re: User von Projekt ausschließen
              Frank.Scholer Master
              Hallo Sven,

              ich geh mit dir ne Wette ein, dass dieser FR abgelehnt wird - und wenn ich Product Manager wäre, würde ich ihn auch ablehnen (bin ich ja nicht - deswegen gibt's noch ne Chance ;-). Ich sag dir auch warum:

              1. Du willst Software Userbezogen verteilen - das ist zwar gegen die Best Practices und ich würde es dir auch nicht empfehlen, geht aber und wird auch unterstützt
              2. Du definierst für einen User (oder eine Gruppe) einen Soll-Zustand. Das System (also DSM) versucht nun logischerweise den Soll-Zustand (und damit die Compliance) herzustellen. Immerhin hast du das so definiert!
              3. Ein "mal eben schnell" gibt es nicht - entweder dein Zustand soll so sein, wie er definiert wurde oder eben nicht
              4. Definierte(!) Ausnahmen (z.B. "nur auf bestimmten Rechnern" oder "nicht auf bestimmten Rechnern" bzw. "nur für bestimmte User" oder "nicht für bestimmte User" bei computer-bezogenen Zuweisungen) kannst du heute schon über die Aus-/Einschlüsse der Policy (erweiterte Einstellungen bei der Policy-Erstellung) definieren.
              5. Deny-Policies gibt's ja auch schon und sollten sowohl für User als auch für Computer als Ziel funktionieren (korrigiere mich, wenn das für User nicht geht)

              Zu deinen Lösungsansätzen:
              1. kannst du leicht selbst implementieren, indem du im Login-Script (wo der Agent gestartet wird), prüfst, ob es sich um einen bestimmten User handelt oder ob der User Mitglied einer bestimmten Gruppe (z.B. Domain Admins) ist und dann den Agent-Aufruf überspringst
              2. Geht eigentlich genau in die gleiche Richtung wie 1. ;-)

              Lange Rede, kurzer Sinn: das Thema "temporär" (aus deinem ersten Post) widerspricht ganz einfach dem Konzept von Policies/Richtlinien. Entweder etwas soll so sein oder es soll nicht so sein - aber nicht "mal so, mal so".

              Was du machen könntest - wie Nico schon geschrieben hat - sind Dinge auf dem Client zu iniitieren (bzw. durch den Admin initiieren zu lassen), die normalerweise in der DSMC gemacht würden (also eine Delegation, was dem Policy-Konzept nicht widerspricht). Dazu musst du entweder
              - den betroffenen Usern/Admins das Recht geben, in der DSMC zu arbeiten
              - die SOAP-Schnittstelle direkt anprogrammieren
              - auf PowerShell-Scripting und unsere PSX-Erweiterung zurückgreifen

              Sorry, für die "deutlichen Worte", aber wenn du dich verrennst ich dir ja auch nicht geholfen :-)

              Grüße Frank
              • 4. Re: User von Projekt ausschließen
                HE1 Apprentice
                Auch dir vielen Dank, Frank. Wir haben ja bereits einmal die Dienste von NWC in Anspruch genommen und es ist gut möglich, dass wir darauf nochmal zurückkommen werden.

                Ich versuche mal deine Punkte aufzugreifen.

                Zu 1. Best Practise ist immer so eine Sache. Es mag vielleicht Best Practise aus der Sicht des aktuellen Netinstall-Releases sein, aber nicht zwangsläufig, wenn man das aus einer objektiven Vogelperspektive betrachtet. Quasi losgelöst von den Fesseln der Realität
                Denn es ist schon die Frage, ob eine ausschließliche Policyzuweisung auf Computerobjekte der Weisheit letzter Schluß ist. Ich sage nur Roaming User. Das ist ja auch der Grund, warum es überhaupt Benutzergruppen in NI gibt. Aber es ist getrickst. Es wird keine Instanz auf einen User angelegt, sondern immer auf den Computer. Auch diese Sicht kann man verargumentieren, aber ich glaube nicht, dass das die in Stein gemeißelte letzte Meinung sein muss. Wer weiß, vielleicht gibt es in DSM 8 auch Instanzen auf User. Wir werden sehen... Es hätte zumindest einige charmante Vorteile.

                Zu 2. Da sind wir wieder bei dem Problem Userinstanzen - Computerinstanzen. Es gibt einfach keine tatsächliche Unterscheidung in NI, was die Behandlung meiner Ansicht nach ziemlich verkompliziert.
                Denn aktuell ist es ja so, dass ich einen Soll-Zustand für einen Computer definiere an dem ein bestimmter Mitarbeiter sitzt und dieser Zustand soll erhalten bleiben auch wenn sich ein spezieller anderer User aus berechtigtem Grund kurz anmelden möchte bzw. muss.
                Gleichzeitig will ich aber auch dass der ursprüngliche User sich jederzeit an einen anderen Rechner setzen kann und dort ebenfalls seine Winzip Lizenz bekommt, auch wenn sie bisher nicht an diesen Computer gebunden war.
                Du siehst, eigentlich brauche ich einfach beides. User und Computer.

                Zu 3. Wer redet denn von "mal eben Schnell"? Selbstverständlich ist dieser Zustand wohlüberlegt und gewünscht. Die Software soll das umsetzen und kann es nicht leisten. De facto muss ich also die Arbeitsprozesse an die Software anpassen. Das ist kein akuter Vorwurf an Frontrange. Immerhin ist das ja das tägliche Los in der It.
                Äußerst exotisch finde ich meinen Anspruch im übrigen nicht. Ich bin mit meinem Useraccount in der Gruppe der Domänenadmins und ich bin für NI zuständig. Jetzt würde ich natürlich gerne auch selber in den Genuß der Segnungen von NI kommen und mich auch selber bedienen lassen. Ich habe auch ziemlich viele virtuelle Maschinen am Laufen und die sollen ebenfalls bedient werden. Und eine VM geht so schnell wie sie entstanden ist. Ich will nicht jedes Mal eine VM in NI aufnehmen müssen, die Gruppen zuweisen (bei statischen Gruppen für jedes einzelne Paket ist das ziemlich viel Geklicke...) und danach, wenn ich die VM wieder lösche, weil sie nach 4 Stunden ihre Daseinsberechtigung verloren hat, muss ich sie aus NI wieder rausnehmen.
                Also will ich alle Pakete an mich als User binden.
                Wenn ich mich dann aber am nächsten Tag an dem PC eines Entwicklers anmelden muss, um irgendwelche Einstellungen vorzunehmen, dann will ich nicht, dass seine ganze Software deinstalliert wird, weil sich seine Pakete natürlich dramatisch von meinen unterscheiden.
                Und dass ich mich an seinem Rechner anmelden muss, ist Teil der Arbeitsprozesse, die in meiner Firma eben so festgelegt wurden.

                Zu 4. Ja, das ist in der Tat ein guter Punkt. Das Verhalten dort werde ich mir auf jeden Fall genauer anschauen. Auf Anhieb fällt mir nur ein, dass es eben nicht besonders übersichtlich ist, wenn es so versteckt ist. Aber bei dem Umfang der betroffenen Spezialuser ist das wohl zu vernachlässigen. Gute Anregung; Danke dafür.

                Zu 5. Deny Policies muss ich meiden wie der Teufel das Weihwasser. Denn Deny bedeutet Deinstallation und genau das will ich ja verhindern.


                Zu 6. (ich nummeriere einfach mal weiter durch): Das verstehe ich nicht so ganz. Ich dachte der Dienst läuft im Hintergrund und muss nicht speziell angestoßen werden. Wenn er einmal installiert ist, dann läuft er doch auch, wenn ich den Installationsaufruf aus dem Loginskript entferne? Oder täusche ich mich da?

                Zu 7. Keine Ahnung was ich dazu schreiben kann

                Zu 8. "Mal so, mal so" ist es nicht. Siehe 3.

                Zu 9. Ich darf und will auch keine Rechte auf die DSMC vergeben. Die sollen da gar nicht rumpfuschen dürfen. Am Schluß wars wieder keiner, aber ich bin schuld

                Zu 10. Ich kann kein Soap und die Entwickler auch nicht, abgesehen davon haben die dafür eh keine Zeit.

                Zu 11. Wie gesagt. Eventuell geht da noch was.

                Zu 12. Ich fand deinen Post super und er hat mir auch weitergeholfen. Wir haben halt streckenweise andere Ansichten.


                Grüße
                Sven
                • 5. Re: User von Projekt ausschließen
                  Frank.Scholer Master
                  Hallo Sven,

                  erstmal prima, dass du mir meinen Post nicht "krumm genommen" hast :-).

                  Ich bin mir übrigens der Diskrepanz zwischen Theorie (aka "best practices") und der realen Welt durchaus bewusst und habe natürlich auch nicht für alles eine Antwort parat, die alle Probleme löst. Wie immer in der realen Welt läuft's halt auf Kompromisse raus ;-)

                  Was fällt mir noch ein:
                  zu 3. mach doch für die Admin-Gruppen einfach Shop-Policies. Dann wird erstens nix automatisch nachgezogen und du (und Kollegen) kommen trotzdem in den Genuss der "Segnungen" (da wird sich FrontRange aber freuen ;-) von NetInstall

                  zu 5. FULL ACK ;-)) - wollte es nur erwähnt haben...

                  zu 6. ich denke, da hast du dann was falsch verstanden! Wenn du auf User zuweist, werden ja - wie du weiter oben richtig geschrieben hast - Policy-Instanzen für den Computer erstellt. Also wird vom DSM Runtime Service sowieso nichts deinstalliert, auch wenn sich ein anderer User an der Maschine anmeldet.

                  Davon abgesehen, das das technisch garnicht gehen kann (wenn der Service-Installer startet, ist in der Regel noch garkein User angemeldet und der Dienst weiß logischerweise auch nicht, wer sich da anmelden wird. Und auch wenn schon ein User da ist, kümmert das den Dienst nicht), werden User-bezogene Zuweisungen immer nur über den AutoInstaller (der vom Agent gestartet wird, der wiederum vom Login-Script angeschmissen wird) installiert. Der Service-Installer hat da seine Hände nicht im Spiel.

                  Außerdem könnten sich ja ansonsten niemals mehrere User mit verschiedenen Applikations-Profilen einen Computer teilen (was aber durchaus vorkommt - Teilzeitkräfte, etc.), weil das in einer endlosen Deinstallations-Installations-Orgie enden würde.

                  FAZIT: hast du womöglich garkein Problem und es nur noch nicht gemerkt???

                  zu 9. schon wieder FULL ACK ;-))

                  zu 11. Würde mich freuen :-)

                  zu 12. Ich finde solche kontroversen Diskussionen (sofern sachlich geführt, was ja hier absolut der Fall ist) auch super. Ich glaub sogar nichtmal, dass wir andere Ansichten haben. Die Frage ist nur, wie man Anforderungen umsetzen kann (bzw. ob es eben überhaupt geht oder ggfs. auch Sinn macht) und darüber zu debattieren ist ja eine gute Sache.

                  Grüße Frank
                  • 6. Re: User von Projekt ausschließen
                    _Mel_ Master
                    eine möglichkeit wäre auch an den paketen eine clientsite prerequisite zu definieren, die bei den rechnern wo nicht automatisch installiert werden soll eben nicht greift, und die der nutzer ändern kann, wenn er doch pakete installieren will (registry wert, file)
                    • 7. Re: User von Projekt ausschließen
                      HE1 Apprentice
                      Und schon wieder kommt eine neue "Problemdimension" hinzu.
                      Klar, dem Serviceinstaller ist es prinzipiell egal, welcher User sich anmeldet, aber da greifen ja die Policies, die bereits auf dem Computer liegen und das ist auch gut und richtig so. Schließlich will ich ja nichts ändern.
                      Ich will den Core und Runtime Service beim Login beenden, damit eben nichts weiteres mehr passiert. Oder sehe ich das falsch? Wird eine Installation über NI angestoßen, auch wenn ich die Dienste beendet habe? Ich bin bisher immer davon ausgegangen, dass dem nicht so ist, aber ich habe es nicht explizit getestet.


                      Und ja, mich würde es auch freuen, wenn es eine Diskussion darüber gibt. Ich habe schon ziemlich viel in diesem Forum gelesen und ich glaube es gibt eine schweigende Minderheit, die die Sache ähnlich sieht wie ich und auch gerne auf User berechtigen würde, statt auf Computer. Und ich glaube diese Idee hätte ihre Berechtigung in der NI Welt. Vielleicht entscheidet der Product Manager ja doch anders als du

                      Mich würden noch mehr Meinungen darüber freuen. Es wäre hilfreich, wenn ich ungefähr verorten könnte, ob ich mit diesem Wunsch gänzlich alleine stehe, oder ob es Sympathisanten gibt. Eventuell ist das ja auch für besagten Product Manager bei Frontrange interessant..

                      Schöne Grüße
                      Sven


                      edit: Danke @Mel. Ich habe mal deine und Franks Anregung aufgenommen und versucht über die Client Computervoraussetzungen User auszunehmen. Ich werde berichten
                      • 8. Re: User von Projekt ausschließen
                        Frank.Scholer Master
                        Und nochmal ich...

                        Ich will den Core und Runtime Service beim Login beenden, damit eben  nichts weiteres mehr passiert. Oder sehe ich das falsch?


                        Ja, das siehst du leider falsch...

                        Wird eine  Installation über NI angestoßen, auch wenn ich die Dienste beendet habe?  Ich bin bisher immer davon ausgegangen, dass dem nicht so ist, aber ich  habe es nicht explizit getestet.


                        Doch - der Agent wird über's Login-Script gestartet und der startet den AutoInstaller (AI). Sind dem User (oder der Maschine) nun Pakete zugewiesen, die noch garnicht installiert sind, installiert der AI Maschinen- und Userteil. Sind die Maschinenteile schon da, werden von diesen Paketen nur die Userteile installiert.

                        Braucht's im Rahmen dieser Ausführungen lokalen Admin-Rechte (bzw. genauer: entsprechend der Klassifikation der Befehle in den Scripts), dann "bittet" der AI den Service um eine Installer-Instanz - den sogenannten "Named Pipe Installer", NPI), an den dann die einzelnen Befehle zur Ausführung übergeben werden.

                        Wenn der Service nicht läuft, kann der NPI nicht gestartet werden und du würdest eine Fehlermeldung "Verbindung zum NetInstall Service unterbrochen" erhalten.

                        Du siehst: das mit dem Stoppen des Service ist kein so brillianter Plan ;-)

                        Grüße Frank
                        • 9. Re: User von Projekt ausschließen
                          HE1 Apprentice
                          @Frank: Wenn ich meinen Plan für brilliant gehalten hätte, dann hätte ich hier gar keinen Post geschrieben

                          Aber das vereinfacht die "Problembehebung" ja enorm. Das Loginskript machen wir über Kix und die Installation des Clients ist ein separates Kix-File, das aufgerufen wird.
                          Und selbstverständlich hast du Recht. Da lasse ich den Niagnt32 auch aufrufen

                          Das bedeutet ich mache den Aufruf des NI Kix Skriptes einfach abhängig von einer Domänengruppe und schon passiert nichts mehr.

                          Und dann kombiniere ich noch - wie weiter oben angeregt - Standard mit Shoppolicies für diese Ausnahmegruppe und mein akutes Problem ist gelöst. Sieht irgendjemand Denkfehler?
                          • 10. Re: User von Projekt ausschließen
                            Frank.Scholer Master
                            Genau so würde ich es auch machen!

                            Wenn du's auf die Spitze treiben willst, kannst du ja noch irgendwie abfragen, ob es sich bei dem aktuellen Rechner um den "Standard-Rechner" des Admin-Kollegen handelt (vielleicht indem du das in einer Schema-Erweiterung im AD pflegst) und dann den Agent trotzdem startest... aber das würde ich mal als optional sehen ;-)

                            Grüße Frank
                            • 11. Re: User von Projekt ausschließen
                              HE1 Apprentice

                              vielleicht indem du das in einer Schema-Erweiterung im AD pflegst und dann den Agent trotzdem startest... aber das würde ich mal als optional sehen



                              Ich sehs genauso. Optional...

                              Aber danke fürs Feedback. Ich werd das mal so umsetzen und davon berichten.

                              Ansonsten lasse ich den Feature Request trotzdem offen. Eine NI-interne Lösung wäre natürlich noch besser und ich glaube, dass Netinstall im Gesamten auch von einer Erweiterung der "Ideologie" hin zu echten Userinstanzen profitieren würde.
                              Es kann für eine Deploymentlösung nie verkehrt sein mehrere Wege zum Ziel anzubieten, so daß sich jeder in seiner Umgebung das Beste raussuchen kann.

                              Mir ist auch klar, dass so eine Erweiterung, wie ich sie angefragt habe, nicht einfach eine Kleinigkeit ist, die in irgendeinem Hotfix gelöst werden kann. Das hat weitreichende Konsequenzen, die alle erstmal durchdacht werden müssen. Aber ich glaube auch die Consultants hier finden sicherlich viele Fälle, in denen sie gerne auf diese Option zurückgreifen würden. (Das hab ich schön gesagt, oder? )

                              Grüße
                              Sven
                              • 12. Re: User von Projekt ausschließen
                                NicoS1 Master
                                Hallo HE1,

                                ich muß jetzt zugeben, ich hab den Thread hier jetzt nicht komplett gelesen, sondern nur überflogen. Aber mir ist ein Teil ins Auge gestochen:

                                Zu 2. Da sind wir wieder bei dem Problem Userinstanzen - Computerinstanzen. Es gibt einfach keine tatsächliche Unterscheidung in NI, was die Behandlung meiner Ansicht nach ziemlich verkompliziert.
                                Denn aktuell ist es ja so, dass ich einen Soll-Zustand für einen Computer definiere an dem ein bestimmter Mitarbeiter sitzt und dieser Zustand soll erhalten bleiben auch wenn sich ein spezieller anderer User aus berechtigtem Grund kurz anmelden möchte bzw. muss.
                                Gleichzeitig will ich aber auch dass der ursprüngliche User sich jederzeit an einen anderen Rechner setzen kann und dort ebenfalls seine Winzip Lizenz bekommt, auch wenn sie bisher nicht an diesen Computer gebunden war.
                                Du siehst, eigentlich brauche ich einfach beides. User und Computer.



                                Das ist schön, dass du das willst, das ist auch nett dem User anzubieten. Aber das hat leider auch ein ganz schönes Manko aufgrund des Enteo Standard verhaltens. Wie du schon richtig sagtest, wird eine Software Policy auf den Computer erzeugt. Leider wird die Software aber auch nicht mehr deinstalliert, wenn ein anderer User sich anmeldet.

                                Das Problem an der Sache ist: Lizenzen
                                In der Regel lizensiert man eine Software ja pro Installation. Aber, nun hast du z.B. eine WinZip Lizenz gekauft, es paketiert und dem User per Autoinstall zugewiesen, oder per Shop. Nun geht der User munter durch die Firma, meldet sich an 5 weiteren Rechnern an weil er gerade etwas schauen will oder so, und jedes mal installiert sich Winzip mit. Und zack... bist du um 5 Lizenzen unterlizensiert.

                                Ok, es kommt natürlich noch auf die Unternehmensprozesse an, wie das bei euch gehandhabt wird. Bei uns muß lizpfl. Software, für die keine Corperate License besteht immer vom Lizenzmanagement vorher freigegeben werden und ggf. beschafft werden.

                                Und wenn man nicht gerade Centennial oder so zur Überwachung der Lizenzen sauber einsetzt... ja... dann bekommt man das gar nicht sooo leicht mit.

                                Und glaub mir, die User MACHEN dass, wenn sie mal schnell ne Software brauchen, und das wissen. "Ach, lass mich mal schnell anmelden, ich kann die Visio aus dem Shop installieren, dann brauchst nicht auf die IT Abteilung warten".

                                Nur als Hinweis am Rande, den man bei Userbezogenen zuweisungen unbedingt beachten muß.
                                • 13. Re: User von Projekt ausschließen
                                  HE1 Apprentice
                                  Ja, danke für den Hinweis. Allerdings setzen wir Centennial ein und tatsächlich haben wir auch ein davon losgelöstes Lizenzmanagment. Wie du schon sagtest, wenn wir keine Unternehmenslizenz haben, dann wird jede einzelne Lizenzvergabe bei uns beantragt und von uns freigegeben.

                                  Und ich möchte mich gleich bei allen mitlesenden Damen entschuldigen, aber wir haben hier ein Frauenquote von sicherlich mehr als 70% und ich befürchte viel eher, dass die allermeisten gar nicht wissen, dass man sich auch an einem anderen Rechner anmelden *kann*. Zumindest blicke ich regelmäßig in ungläubige Gesichter, wenn ich das erkläre

                                  Aber ich möchte die User hier bei mir in Schutz nehmen. Tatsächlich sind sie im Schnitt äußerst kooperativ und folgsam. Selbst die Chefs haben IT technisch keinen Deut mehr Rechte als eine normale Sekräterin. Die dürfen teilweise nicht mal ihre Handys anstecken (Treiber) und akzeptieren das im Normalfall auch klaglos.

                                  Wir hatten zumindest noch nie derartige Probleme und haben im letzten Jahr auch ein MS Audit überstanden