WEM Filter Conditions, Actions und dynamische Tokens

Ein toller Vorteil von WEM ist die Möglichkeit, die Benutzerumgebung dynamisch basierend auf einer Vielzahl von Werten, Einstellungen und Variablen zu konfigurieren. Dazu können Filter Conditions verwendet werden, aber auch dynamische Token.

Filter Conditions

Filter Conditions sind in WEM das Pendant zu Item Level Targeting in GPPs und ein häufig genutzter Weg, um Actions dynamisch und bedingt zuzuweisen. Hierfür bietet WEM eine Vielzahl an Filter-Optionen, meistens auch mit negiertem Pendant („No …“). Im Folgenden gehe ich auf die wichtigsten Filter Condition Types ein.

Active Directory Group Match

Der häufig genutzter Weg, um Actions zu Filtern, sind Active Directory Group Match Filter, also Filter basierend auf einer AD-Gruppenmitgliedschaft. Das Setting Matching Result in der Filter Condition ist in diesem Fall als String im Format <Domain>\<Groupname> anzugeben, also z.B. CORP\CitrixUsers. Der Wert ist Case-sensitiv.

Active Directory Attribute Match

Eine weitere Option, um Actions zu Filtern, sind Active Directory Attribute Match Filter Conditions, also Filter basierend auf einem AD-Attribut und dessen Wert. In diesem Fall sind beide Settings, also Tested Active Directory Attribute und Matching Result als String anzugeben, also z.B. company als Attribut und CORP Inc. als Matching Result. Auch hier wieder: beides ist Case-sensitiv.

Die Filter Condition ist i.d.R. statisch, da Attribute und Matching Result feste Werte haben. Das Matching Result ? kann eine gewisse Dynamik ermöglichen, denn es bewirkt einen Filter für alle User, in denen das AD-Attribut nicht leer ist (unabhängig davon, was tatsächlich als Wert drin steht), wird also von WEM interpretiert als NOT NULL.

User UI Language Match

Häufig in Multilanguage Umgebungen verwendet sind die Filter-Condition User UI Language Match. Das Matching Result soll laut Citrix Referenz als zweistelliger ISO Code angegeben werden, also z.B. DE für Deutschland oder ES für Spanien. Bei mir hat das so NICHT funktioniert! Bei mir hat der Filter nur dann gegriffen, wenn ich ihn als 2 mal zweistellig mit Sprach-und Ländercode angegeben habe, also z.B. de-DE für Deutschland, es-ES für Spanien, en-US für United States pt-BR für Brasilen und so weiter. Prüfen konnte ich das über das Log des Resultant Action Viewers, dort steht eine Zeile „Expected Value“ drin, aus der hervorgeht, welchen Wert WEM erwartet.

Registry Value Match

Der Klassiker! Existiert ein bestimmter Registry Key, bzw. hat einen bestimmten Wert, wird die Action mit dem entsprechenden Filter angewendet. Die Werte in den Settings Tested Registry Value und Matching Result sind auch hier Strings. So lässt sich dadurch z.B. ein Filter bauen, der bewirkt, dass eine Action nur angewendet wird, wenn der User ein Deutsches Keyboard Layout verwendet, indem als Tested Registry Value der Wert HKCU\Keyboard Layout\Preload\1 und als Matching Result der Wert 00000407 angegeben wird.

Virtual Desktops Desktop Group Name Match

Wie der Name schon sagt: mit dieser Filter Condition können Actions für verschiedene Virtual Desktops Desktop-Gruppen gefiltert werden. Der Wert für das Matching Result ist wieder ein String und muss den Namen eines Desktops innerhalb einer Delivery Group enthalten, nicht den Namen der Delivery Group selbst! Dadurch lassen sich Actions granular auf Desktop Ebene filtern, selbst wenn man nur über eine Delivery Group verfügt, die mehrere Desktops enthalten. Ein Beispiel aus der Praxis ist z.B. wenn man in einer Delivery Group einen Desktop für den normalen Arbeitsplatz bereitstellt und aus der selben Delivery Group einen weiteren Desktop für Mobilgeräte, der nur über XenMobile, bzw. Netscaler erreichbar ist. Im folgenden Beispiel konfiguriere ich eine Filter Condition für meinen Desktop Virtual Desktop:

Sonstige

Über die o.g. Möglichkeiten hinaus gibt es noch eine Vielzahl an Filterbedingungen, die wesentlich umfangreicher ist, als die der GPPs. Insbesondere die Möglichkeit, auf Eigenschaften der Virtual Apps & Desktops Infrastruktur zu filtern, ist eine schöne Funktion für Citrix Administratoren. Eine komplette Liste inkl. der jeweiligen Syntax findet ihr in der Referenz von Citrix.

Dynamische Tokens

Hashtags

Hashtags sind eine Möglichkeit Variable Werte zu verwenden und erweitert die Möglichkeiten von Umgebungsvariablen in WEM.

Beispiel: %UserName% vs. ##UserName##

Man möchte eine Datei erstellen, die so heißt, wie der Username, also z.B. für den Usernamen johndoe eine Datei johndoe.txt. In diesem Fall macht es keinen Unterschied, ob Umgebungsvariable oder Hashtag verwendet wird. Windows und WEM lösen beides korrekt auf und erstellen in beiden Fällen eine Datei namens johndoe.txt. Anders verhält es sich, wenn man IN eine Datei den Usernamen eintragen möchte, z.B. in eine .ini-Datei. In diesem Fall wird bei Benutzung der Umgebungsvariable ein String %UserName% eingetragen und nicht aufgelöst, wohingegen WEM mit dem Hashtag ##UserName## diesen korrekt auflöst und den String johndoe in die Datei schreibt.

Hashtags können darüber hinaus auch an anderer Stelle in WEM verwendet werden, unter Anderem auch um die Helpdesk Optionen des WEM Agents variabel zu gestalten und bestimmte Infos zu Benutzer, Client und Server vorzubelegen. Konfiguriert wird dies in der WEM Management Konsole unter Advanced Settings -> UI Agent Personalization -> Helpdesk Options.

Aktuell sind folgende Hashtags verfügbar:

##UserName##
##UserProfile##
##FullUserName##
##UserInitials##
##UserAppData##
##UserPersonal##
##UserDocuments##
##UserDesktop##
##UserFavorites##
##UserTemplates##
##UserStartMenu##
##UserStartMenuPrograms##
##ComputerName##
##ClientName##
##ClientIPAddress##
##ADSite##
##DefaultRegValue##
##UserLDAPPath##
##VUEMAgentFolder##
##RDSSessionID##
##RDSSessionName##
##ClientRemoteOS##
##ClientOSInfos##

Wichtig! Die Hashtags sind im Gegensatz zu Umgebungsvariablen Case-sensitiv!

String Operations

Ein weiterer Unterschied zwischen WEM Hashtags und GPPs ist die Möglichkeit, die Hashtags dynamisch und in Real-Time zu manipulieren und die Ergebnisse als String Operations zu verwenden. So lassen sich z.B. bei Bedarf Leerzeichen entfernen oder Werte nach bestimmten Kriterien aufsplitten.

Folgende String Operations stehen aktuell zur Verfügung – wobei mir selbst noch nicht alle Funktionen klar sind :-):

#Left(string,length)#                   -> verwendet die ersten X Zeichen
#Right(string,length)#                  -> verwendet die letzten X Zeichen
#Truncate(string,length)#
&Trim(string)&
&RemoveSpaces(string)&                  -> entfernt alle Leerzeichen
&Expand(string)&
$Split(string,[splitter],index)$        -> splittet den Hashtag anhand eines Kriteriums auf und verwendet das im Index angegebenen X-te Ergebnis
#Mid(string,startindex)#
!Mid(string,startindex,length)!

Ein Beispiel:
Ich möchte aus dem Full User Name im AD eine Umgebungsvariable FUNnoSpaces anlegen lassen. Dazu entferne ich aus dem AD Attribut alle Leerzeichen in der entsprechenden Environment Variable Action in WEM. Dazu verwende ich den Operator &RemoveSpaces()&.

Ein weiteres Beispiel ist die Verwendung der X ersten Zeichen eines Hashtags. Bei mir fangen alle Desktop Computernamen mit PC an, während alle Notebook Computernamen mit NO beginnen. Jetzt möchte ich die ersten 2 Zeichen des Hashtags ##ClientName## in eine Umgebungsvariable ClientType ausgeben, die ich an anderer Stelle dann weiterverwenden kann. Hierzu nutze ich den Operator #Left()#.

Dynamische Tokens aus Active Directory Attributen

In Actions ist die Verwendung von dynamisch generierten Token noch weitaus ausprägungsfähiger. Ein Beispiel dafür ist es, Home-Laufwerke in einer Netzwerkfreigabe in einem Unterordner zu speichern, der nach dem Firmennamen benannt ist. Der Syntax des Tokens lautet dabei [ADAttribute:<Attribut-Name>], also im Falle des company-Attributs [ADAttribute:company].

Wichtig dabei ist:

• das angegeben Attribut muss genau so geschrieben sein (Case-sensitiv!), wie es im AD Schema geschrieben wird
• das Ziel des Tokens muss genau so lauten, wie der Wert im Attribut steht (Case-sensitiv!)

So lässt sich mit folgenden Werten eine dynamische Network Drive Action anlegen:

\\Fileserver\Homes\[ADAttribute:company]\%username%

Lautet  nun der Wert für das company-Attribut z.B. FirmaXY und der Username john.doe, ergibt sich daraus folgender dynamischer Token:

\\Fileserver\Homes\FirmaXY\john.doe

Die entsprechende Network Drive Action in WEM sieht dann wie folgt aus:

Statt mit der Umgebungsvariable %username% lässt sich das natürlich auch mit dem Hashtag ##UserName## konfigurieren, wenn man komplett auf die WEM Bordmittel setzen möchte:

\\Fileserver\Homes\[ADAttribute:company]\##UserName##

Quellen:
https://docs.citrix.com/