The following Validation Logic Types are available for use with User Management Profiles and Profile objects. Some Validation Logic Types allow the use of the * and ? wildcards.
The asterisk (*) wildcard means that at least one occurrence of the specified characters must exist in the entry field. When a profile or profile object element is being validated based on an entry field using the *, validation will return true and valid if the specified characters prior to the asterisk exist anywhere in the text field.
For example, if the specified Active Directory group is [ AC* ], then any group that begins with AC, followed by any other characters will be valid for the validation.
The question mark (?) wildcard is used often used as a placeholder for unknown data. One or more ? may be used in a text field in conjunction with other characters. If the pattern of characters matches the field being validated, where a ? represents any other character, the validation will return true and valid.
For example, if a Computer Name is specified in the validation entry field as [ SHP??01 ], then any computer with a name that starts with SHP and is then followed by any two characters plus 01. A computer name SHPAB10 would match and validate true for this example.
|
Note: Validation Logic type allows use of wildcards |
Select Authenticating Domain to execute a configuration element for all computers that log on to the specified Domain. Find the Authenticating Domain Validation Logic type under the Network Membership category. In the Select Domain box, enter the name of the Domain. Optionally press the Resource Browser button to locate the Domain. The supplied Authenticating Domain value is compared against the domain the client machine is attempting to log on to and must match for the configuration element to be processed.
Examples:
BENE |
Validates true for all computers authenticated in the BENE domain |
BE* |
Validates true for all computers authenticated in any domain beginning with the letters BE |
|
Note: Validation Logic type allows use of wildcards |
Select Organizational Unit (User) to execute a configuration element for all users belonging to a specific OU. Find the OU (User) Validation Logic type under the Network Membership category. In the Select Organizational Unit box, enter the name of the OU or press the OU Browser button . The supplied OU value is compared against the OU the client machine is a part of during the logon process and must match for the configuration element to be processed.
Select the box Include child OUs to include all child OUs in the validation logic.
Examples:
\Florida\Boca\Accounting |
Validates true for any computer belonging to the \Florida\Boca\Accounting OU. Child OU's will be included if the "Include child OUs" box is selected. |
\Florida\Boca\Tech* |
Validates true for any users in any OU that begins with the letters Tech and also belong to the \Florida\Boca\ OU. |
|
Note: Validation Logic type allows use of wildcards |
Select Primary Group to execute a configuration element for all users of the specified Primary Group. Find the Primary Group Validation Logic type under the Network Membership category. In the Select Group box, enter the name of the Group or press the Browse button to locate it. The supplied Primary Group value is compared against the primary group of the user during the logon process and must match for the configuration element to be processed.
Example:
Sales |
Validates true for all users that have Sales defined as their primary group |
ST* |
Validates true for all users that have a primary group of ST followed by any characters. |
|
Note: Validation Logic type does not allow the use of wildcards |
Select User Group to execute a configuration element for all users belonging to a specific network group. Find the User Group Validation Logic type under the Network Membership category. In the Select Group box, enter the name of the Group or press the Resource Browser button to locate the group. The supplied group membership value is compared against the groups that the user is a part of during the logon process and must match for the configuration element to be processed.
Examples:
Marketing |
Validates true for all users that are part of the Marketing group. |
Sales |
Validates true for all users that are part of the Sales group. |
Marketing;Sales |
Validates true for users of both the Marketing and Sales groups. |
* |
Validates true for all groups |
User Group does not support the wildcards * (asterisk) and ? (question mark) with the exception of a single * meaning "all groups".
|
Note: Validation Logic type allows use of wildcards |
Select User Name to execute a configuration element for a specific User Name(s). Find the User Name Validation Logic type under the User Information category. In the Select User box, enter the name of the User(s) or press the Browse button. The supplied User Name value is compared against the User Name used during the logon process and must match for the configuration element to be processed.
Use the User Name validation type to execute a configuration element for a particular user regardless of the computer from which they log on to. For example, if the configuration element should execute any time Mary Jones (user name mjones) logs into the network, specify mjones as the user name.
Examples:
mjones |
Validates true for user mjones only. |
mjones; tsmith |
Validates true for user mjones and tsmith. |
* |
Validates true for all users. |
|
Note: Validation Logic type does not allow the use of wildcards |
Select Frequency to validate a configuration element for users based on the specified timing. Find the Frequency Validation Logic type under the Timing and Events category. The specified Cycle and/or Frequency values are compared against the user, computer and UID. If the timing and UID conditions match, the configuration element will be processed.
The UID entry is used to make each element that uses a Frequency Validation Logic type, a unique item, regardless of its configurations. This is helpful when the Frequency is set to Once Per Day or One Time. The data in the UID entry is automatically generated and should not be modified. However, if there is an element that is set to execute Once Per Day or One Time, and if it must execute a second time, the UID can manually be changed by clicking Generate New.
Select a logon frequency from the list. Select from Every Time, Once Per Day (User), Once Per Day (Computer), One Time (User) and One Time (Computer).
Select a logon frequency from the list. Select from Every Time, Once Per Day (User) and One Time (User).
Every time is used to validate an element at the specified cycle, each time.
Select Once Per Day (User) to validate an element at the specified cycle, one time per day for the current user.
Select Once Per Day (Computer) to validate an element at the specified cycle, one time per day for the computer.
Select One Time (User) to validate an element at the specified cycle, a single time for the current user.
Select One Time (Computer) to validate an element at the specified cycle, a single time for the computer.
Select a time interval for which the element will validate. Choose from Every time, Day of Week, Monthly (Day of Week), Monthly (Day of Month) and Specific Date
Selecting Every time as the cycle, will force the element to validate each day at the specified frequency.
Selecting Day of Week as the cycle, presents a new list allowing the selection of a day from Sunday to Saturday.
Selecting Monthly (Day of Week) as the cycle, presents a new list allowing the selection of a day in the month ranging from 1st Sunday, 1st Monday, ... to the last Saturday of the month.
Selecting Monthly (Day of Month) as the cycle, presents a new list allowing the selection of a date within the month.
Selecting Specific Date Range as the cycle presents a start date and end date in which the date range should be entered. Click the calendar icon to make your date selection from a popup calendar.
Select Time Range to execute a configuration element if the current time is within the Time Range specified. Find the Time Range Validation Logic type under the Timing and Events category. Enter the beginning of the time range in the first box and the ending time range in the second box. The current time is compared to the time range values and must fall into the range for the configuration element to be processed.
|
Note: Validation Logic type allows use of wildcards |
Select TS Application Name in order to execute a configuration element based on the name of the Terminal Server (TS) published application that is currently in use. Find the TS Application Name Validation Logic type under the Terminal Services category. In the Value box, enter the TS Application Name. The supplied TS Application Name is compared against the running applications during the logon process and must be found for the configuration element to be processed.
Examples:
Outlook |
Validates true for the published application Outlook |
Outlook* |
Validates true for any published application starting with the name Outlook. This may be used for different versions of the application. |
Some Citrix environments precede the published application name with a # symbol. For example, if the application name is published as Outlook, the name on the client side may be represented as #Outlook. Therefore, the Validation Logic must be set to #Outlook (in this instance) for the element to validate properly.
#Outlook* |
Validates true for any published application starting with the name Outlook. This may be used for different versions of the application. |
To determine the actual published application name that is being used on the client, review the sltrace.htm log file.
Note: A value will not be returned for the Terminal Service Application Name on a Windows 2008/2008 R2/2012/2016/2019 server using RemoteApp. It will work, however, if Citrix Xen Server is installed on the 2012 server.
|
Note: Validation Logic type allows use of wildcards |
Select TS Client Name in order to execute a configuration element based on the name of the TS Client. Find the TS Client Name Validation Logic type under the Terminal Services category. In the Value box, enter the TS Client Name. If the supplied name matches the name of the client logging onto the Terminal Server the configuration element is processed.
Examples:
PC221 |
Validates true for the client named PC221. |
*LAPTOP* |
Validates true for any client with LAPTOP in its name. |
*221 |
Validates true for any client ending with 221 in its name. |
PC* |
Validates true for any client starting with PC as its name. |
PC2?? |
Validates true for any client starting with PC2 in its name and is followed by two additional characters. |
A??-PCxxx-ACCTG |
Validates true for any client belonging to the ACCTG department, in building A, on any floor (??). This particular example denotes the granularity possible when used in conjunction with the corporate computer naming standards. |
|
Note: Validation Logic type allows use of wildcards |
Select TS Client TCP/IP Address in order to execute a configuration element based on the IP Address of the client connecting to the Terminal Server (TS). Find the TS Client TCP/IP Address Validation Logic type under the Terminal Services category. Specify the TS Client TCP/IP Address by entering it into the Value entry. If both IP Addresses match the configuration element will be processed.
The asterisk (*) and question mark (?) wildcards may be used to match TCP/IP addresses. This wildcard technique and simplified string manipulation should be effective on most networks. Keep in mind that you are not required to specify complete octets. Specifying 192.168.1* would attempt to match the first two octets completely and the first character of the third octet to the client's TCP/IP address.
Examples:
192.168.100.5 |
Validates true for the client computer whose TCP/IP address is 192.168.100.5. |
192.168.100.* |
Validates true for any client computers whose TCP/IP address matches the first three octets. |
192.168.* |
Validates true for any client computers whose TCP/IP address matches the first two octets. |
192.168.1??.5 |
Validates true for any client computers whose TCP/IP address matches 192.168.1xx.5, where xx is any number. |
10::1 |
Validates true for the client computer whose TCP/IP address is 10:0:0:0:0:0:0:1. |
True subnetting is supported. Use true subnetting values to selectively specify certain groups of IP addresses. Specify the IP address and subnet mask in the TCP/IP in the Value entry. The subnet mask can be specified in either dotted decimal format or by specifying the number of mask bits.
Examples:
10.0.0.4/255.255.255.0 |
Validates true for the client computers whose IP address is in the range of 10.0.0.1 - 10.0.0.254. |
10.0.0.4/24 |
Validates true for the client computers whose IP address is in the range of 10.0.0.1 - 10.0.0.254. |
10.0.0.4/255.255.255.240 |
Validates true for the client computers whose IP address is in the range of 10.0.0.1 - 10.0.0.14. |
10.0.1.4/28 |
Validates true for the client computers whose IP address is in the range of 10.0.1.1 - 10.0.1.14. |
10.0.0.39/28 |
Validates true for the client computers whose IP address is in the range of 10.0.0.33. |
To determine the IP Address for a computer, run IPCONFIG.
|
Note: Validation Logic type allows use of wildcards |
Select TS Initial Program in order to execute a configuration element based on the name of the Terminal Server (TS) Initial Program currently in use. Find the TS Initial Program Validation Logic type under the Terminal Services category. In the Value box, enter the TS Initial Program name. If the supplied TS Initial Program is running during the logon process, the configuration element is processed.
Examples:
appver71.exe |
Validates true for the initial program appver71.exe only. |
appver7?.exe |
Validates true for any initial program name beginning with the characters appver7 followed by a single character and an .exe extension. |
|
Note: Validation Logic type allows use of wildcards |
Select TS Session Name in order to execute a configuration element based on the connection name that is in use between the client and the Terminal Server (TS). The TS Session Name is made up of a combination of the Terminal Server Connection Name#Session Id. Find the TS Session Name Validation Logic type under the Terminal Services category. In the Value box, enter the TS Session Name. If a connection occurs on the supplied session, the configuration element will be processed.
Examples:
RDP-TCP#1 |
Validates true for the RDP-TCP#1 session. |
RDP-TCP* |
Validates true for any RDP-TCP session. |
ICA-TCP* |
Validates true for any ICA-TCP session. |
|
Note: Validation Logic type does not allow the use of wildcards |
Select Custom Function in order to execute a configuration element based on the return value of the function. Find the Custom Function Validation Logic type under the Custom Validation category. Custom functions are defined in the Profile's Definitions tab. All custom functions must return a TRUE or FALSE value. Specify the Custom Variable by entering it into the Value entry. If the custom function returns TRUE (or any value other than 0), the configuration element will be processed. A FALSE return value will cause the configuration element to be unprocessed.
Example:
The function below is used to determine if the specified version ($version) of DirectX is greater, equal or less than ($operand) the currently installed version of DirectX. The function returns a value ($DXVersion) based on the parameters passed to the function. This function is defined in the Profile's Definitions tab.
; Custom Script File
; File Name: SLP00001.sld
; Description: SLP00001.sld
;
;----------------------------------------------------------
function DXVersion($operand, $version)
if slVersionCompare(ReadValue('SOFTWARE\Microsoft\Directx','Version'),$operand,$version)
$DXVersion = 1
else
$DXVersion = 0
endif
endfunction
;----------------------------------------------------------
RETURN ; Must be last line of file. Do not remove this line
To use this function within the Validation Logic, select Custom Function from the Validation Logic dialog box. Specify the function name and parameters (if necessary) in the Value entry. In this example, an operand of '<' (less than) and a version of 7.0 is passed to the function. This is compared to the version of DirectX on the workstation. The return value is set accordingly. If the version of DirectX on the workstation is less than 7.0 than the script entry will be processed.
Desktop Authority provides no error control over custom functions. A syntax error in your custom function will cause Desktop Authority to unexpectedly terminate.
|
Note: Validation Logic type does not allow the use of wildcards |
Select Custom Variable in order to execute a configuration element based on the value of the defined variable. Find the Custom Variable Validation Logic type under the Custom Validation category. Custom variables are defined in the profile's Definitions tab. All custom variables must evaluate to a TRUE or FALSE value. Specify the Custom Variable by entering it into the Value field. If the custom variable equals to TRUE (or any value other than 0), the configuration element will be processed. A FALSE value will cause the configuration element not to be processed.
Example:
The value of the variable below ($DASystemTray) is evaluated with the code below. This variable is defined in the Profile's Definitions tab.
; Custom Script File
; File Name: SLP00001.sld
; Description: SLP00001.sld
;
;----------------------------------------------------------
$DASystemTray = ReadValue($DAKeyLM+'\v5\GUI\','EnableSystemTray')
;----------------------------------------------------------
RETURN ; Must be last line of file. Do not remove this line
To use this variable within Validation Logic, select Custom Variable from the Validation Logic dialog box. Specify the variable name in the Value entry. In this example, the registry key can either equal a 1 or 0. When the registry key is read, the value is stored in the $DASystemTray variable. If the value of the variable is True (or any other non-zero value), the script element will be processed.
Figure 4: Using a custom variable within Validation Logic
If the variable does not result in a Boolean value and will be used as comparison to a string, the variable must be wrapped within quotes. In the following example, $SiDesktopSize, the variable results in the size of the computer desktop as a string. For example, "1024x768". This variable is expressed within quotes and compared to a string (within quotes) in the Validation Logic dialog.
Figure 5: Example of custom variable
Desktop Authority provides no error control over custom variables. A syntax error in your custom variable will cause Desktop Authority to unexpectedly terminate.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Términos de uso Privacidad Cookie Preference Center