Login

Blog

Hier blogge ich über Themen, die mich - und vielleicht auch andere - interessieren (könnten)

User Centric Management in DSM

Mit DSM 2016.2 wurde das Konzept des "User Centric Managements" in DSM vorgestellt. Dabei geht es unter anderem darum, dass Benutzer sogenannte "assoziierte Computer" haben können (und umgekehrt haben Computer natürlich auch assoziierte Benutzer). Bei der Zuweisung von Software-Paketen auf Benutzer oder Benutzergruppen kann dann festgelegt werden, dass die Pakete nicht mehr auf allen Maschinen, auf denen sich diese Benutzer anmelden, installiert werden, sondern nur noch auf den assoziierten Geräten. Damit wird der Wildwuchs und die unkontrollierte Installation von eventuell lizenzpflichtiger Software auf einer unbekannten Anzahl von Systemen unterbunden.

b2ap3_thumbnail_AssociatedUserPolicy.png

Die Frage ist aber nun, wie Computer- und Benutzer-Objekte in DSM assoziiert werden können und wie diese Assoziationen bei Bedarf automatisiert und über PSX-basierte PowerShell-Scripts gepflegt werden können.

Die Pflege dieser m:n-Beziehungen zwischen Benutzern und Computern – jeder Benutzer kann mehrere assoziierte Computer haben und jedem Computer können mehrere assoziierte Benutzer zugeordnet sein – kann manuell erfolgen. Dazu müssen im Eigenschaften-Dialog des jeweiligen Objekts im Register "Zugehörige Computer" (beziehungsweise "Zugehörige Benutzer") die zu verknüpfenden Objekte ausgewählt und eingetragen werden.

b2ap3_thumbnail_AssociatedComputerOfUser.png

Dies erzeugt natürlich einen hohen manuellen Pflegeaufwand und wird maximal in kleineren Umgebungen oder zu Testzwecken umgesetzt werden können.

Die zweite Möglichkeit, diese Beziehungen zu pflegen, besteht in der Zuweisung des mitgelieferten System-Scripts "Determine Main User" per Job-Policy auf alle Maschinen. Im Rahmen dieses Scripts wird geprüft, ob der aktuell angemeldete Benutzer bereits der zu der Maschine assozierte Benutzer ist, und falls nicht, wird dieser nach einer konfigurierbaren Anzahl von Anmeldungen – die auch in einem festlegbaren zeitlichen Abstand stehen müssen – zum assozierten Benutzer gemacht.

b2ap3_thumbnail_DetermineMainUserScript.png

Nachteil dieses Scriptes ist einerseits, dass es immer auf allen Maschinen im Rahmen des AutoInstallers ausgeführt werden muss (aus naheliegenden Gründen kann eine Ausführung im Hintergrund durch den Service-Installer nicht funktionieren) und dass auch ein einmal vorhandener assozierter Benutzer des Computers nie ersetzt oder durch einen neuen assozierten Benutzer ergänzt wird, da in dem Script zu Beginn geprüft wird, ob bereits ein User zugeordnet ist und falls ja, das Script beendet wird. Das Script sorgt also dafür, dass mit einem Computer nur ein Benutzer verknüpft sein kann, wobei in vielen Szenarien auch Modelle vorstellbar sind, wo sich beispielsweise zwei oder mehrere Benutzer ein System teilen.

Schließlich besteht natürlich die Möglichkeit, die manuelle Pflege über die DSM Konsole durch ein PSX-basiertes PowerShell-Script zu automatisieren. Nachdem das PSX-Modul geladen und das Emdb-Laufwerk gemappt wurde, muss ein neues Assoziations-Objekt zwischen einem Benutzer- und einem Computer-Objekt erzeugt werden:

$MyUser = Get-EmdbUser "Albert Tross" –Recurse
$MyComputer = Get-EmdbComputer "WIN10-01" -Recurse
$MyAssociation = $MyUser.NewAssociation($MyComputer)
$MyAssociation.Create() 

Die Assoziation muss also zunächst über die Methode NewAssociation() erzeugt und dann mit der Create()-Methode praktisch in die Datenbank geschrieben werden. Sowohl Computer- als auch User-Objekte (und andere) haben diese NewAssociation()-Methode.

Alternativ lässt sich die Erzeugung mit einem Befehl realisieren, indem die Create()-Methode gleich angehängt wird, also wie folgt (das ersetzt die beiden letzten Zeilen aus dem obigen Beispiel):

$MyUser.NewAssociation($MyComputer).Create()

Allerdings klappt das in diesem Fall "nur", weil der Business Logic Server "weiß", dass wenn eine Assoziation zwischen einem Objekt vom Typ "Benutzer" und einem vom Typ "Computer" erzeugt werden soll, dass es dann eben der zu dem Computer assoziierte User ist (und nicht z.B. ein fehlender Patch oder was auch immer). Um genau zu definieren, welcher Typ von Assoziation erzeugt werden soll, kann das bei der NewAssociation()-Methode auch folgendermaßen angegeben werden:

$MyUser.NewAssociation($MyComputer, "ComputerAssociatedUser").Create()

Soll die Verknüpfung zwischen einem Benutzer und einem Computer wieder aufgehoben werden, so muss dazu das zugehörige Assoziations-Objekt gelöscht werden. Da in diesem nur die IDs sowohl des Quell- als auch des Zielobjekts gespeichert sind, müssen also auch hier zunächst die jeweiligen Objekte abgerufen werden, da darüber dann die Objekt-ID verfügbar ist. Dann kann das zu löschende Beziehungs-Objekt ausgewählt, und mittels der Delete()-Methode entfernt werden:

$MyUser = Get-EmdbUser "Albert Tross" –Recurse
$MyComputer = Get-EmdbComputer "WIN10-01" -Recurse
$MyComputer.GetAssociations("ComputerAssociatedUser") | Where-Object {$_.TargetObjectId -eq $MyUser.ID} | ForEach-Object {$_.Delete()}

 

Anzahl der in einem Durchlauf installierten Patche...
PSX-Version 4.0 verfügbar

Related Posts

 

Comments 2

Klaus Salger (website) on Wednesday, 22 March 2017 19:07

Hallo Frank,

was die Funktion des mitgelieferten "Determine Main User"-Pakets betrifft bin ich anderer Meinung.
Am Anfang steht sowas wie:
If HasComputerAssociatedUser
ExitProcEx Done
Das führt dazu, dass ein einmal gesetzter Benutzer dauerhaft der (einzige) assoziierte Benutzer bleibt. (Nicht dass ich's etwas ausprobiert hätte...)

Immerhin hat man die Möglichkeit seine eigene Logik mit Hilfe eines eigenen eScripts zu implementieren und den oder die assoziierten Benutzer anders zu konfigurieren.

Ciao
Klaus

Hallo Frank, was die Funktion des mitgelieferten "Determine Main User"-Pakets betrifft bin ich anderer Meinung. Am Anfang steht sowas wie: If HasComputerAssociatedUser ExitProcEx Done Das führt dazu, dass ein einmal gesetzter Benutzer dauerhaft der (einzige) assoziierte Benutzer bleibt. (Nicht dass ich's etwas ausprobiert hätte...) Immerhin hat man die Möglichkeit seine eigene Logik mit Hilfe eines eigenen eScripts zu implementieren und den oder die assoziierten Benutzer anders zu konfigurieren. Ciao Klaus
Frank Scholer (website) on Wednesday, 22 March 2017 20:01

Hallo Klaus,

danke für dein Feedback - du hast natürlich recht! - ich habe den Artikel entsprechend angepasst.

Grüße Frank

Hallo Klaus, danke für dein Feedback - du hast natürlich recht! :) - ich habe den Artikel entsprechend angepasst. Grüße Frank
Already Registered? Login Here
Guest
Sunday, 08 December 2019

Captcha Image