There are many reasons why an Application Launcher element may not execute as desired. This article explains the various components of the application launcher object and how to troubleshoot a problem encountered with an application launcher element in a practical manner.
There are five main components of a user based management application launcher element. The two primary components of an application launcher element are the “Target” and “Argument” fields. The three secondary components are the “Hide Output”, “Run as Admin”, and “Run Asynchronously” options. The “Hide Output” and “Run as Admin” options are not found on the computer based management application launcher since they are not necessary. Each of these components will be discussed in more detail below followed by a comprehensive summary on how to effectively troubleshoot an application launcher element.
Design and Scope:
The application launcher object was originally designed to allow Administrators to centrally launch common applications for their users without intervention by the user. As time progressed, the object gained popularity as a catch-all utility to allow administrators to perform virtually any task, in any security context, in an automated fashion, without user intervention. The scope of support is limited to the point at which the application is launched.
File name including path:
The target specified must include the executable that is being run and the path to the executable if the system does not know where to locate it. For instance, if the target is CMD or CMD.exe, either entry can be used without a path because CMD resides in the %Windir% directory and the path statement for every Windows based operating system includes the Windows directory (or %Windir%) by default. Therefore, no path is necessary to run any executable that resides in the Windows directory. On the other hand, an application that is not in the path statement must have a path defined as part of the Target field (i.e. C:\Directory\Executablename.exe or \\Server\Share\Executablename.exe). When launching a computer based management element, the entire path must always be specified.
Arguments:
The arguments are defined as any parameters (switches, paths, etc..) used in a command line that normally follow the executable. For example, if the Administrator wanted to launch a text file to be displayed to the user, then Notepad or Notepad.exe can be specified for the target (because it resides in the Windows directory) and the argument would be entered as the full path to the desired text file inclusive of the text file itself (i.e. C:\textfiledirectory\mytextfile.txt or \\Server\Share\mytextfile.txt).
Hide any screen Output:
The option to hide output prevents the user from seeing the output generated by the item being launched. It does not suppress the output as a silent or quiet switch might do, but rather hides the output so that the user cannot see it. The default setting of this feature (deselected) is that any output generated by the launched application will be displayed to the user. This option is not included in the CBM application launcher object since there must be no output because it runs in the machine space only.
Launch asynchronously:
The option to run asynchronously instructs the main script to launch the element without stopping the main script. Therefore, no return code is available when launching asynchronously. The default setting (deselected) is to run synchronously which means the main script will halt and wait for the application to complete processing before continuing. Therefore, a return code will be available when launching synchronously.
Run as administrator:
The run as admin option allows the element to be launched in the context of a local administrator. This allows the domain administrator to centrally launch applications in the security context of a local administrator even though the user logging on possesses only user privileges. If the application is being launched with the run as admin option selected, the administrative context is also passed to any child processes launched by the parent application. The default setting of this feature (deselected) is that run as admin will not be used and the setting will be launched in the security context of the interactive logged on user. The “Run as Admin” option is not included in the CBM application launcher object since it will always run as Local System which has local admin privileges on the workstation.
Troubleshooting:
The easiest method to troubleshoot the application launcher is to create an element with CMD.exe specified as the target. Do not specify any arguments. Do not select the option to hide the output or to launch the element asynchronously. The run as admin box may or may not be selected depending upon what security context is desired to launch the application in. Once the element has been created according to the guidelines above, simply save and replicate the changes and logon to the client machine to test. The expected behavior is that the main script will stop and launch a command prompt. At the command prompt, type SET U [Enter] in order to see what security context the command prompt was launched in. If the selection to run as admin was not selected, the SET U command will return the interactive logged on user’s name. On the contrary, if the selection to run as admin was selected, the SET U command will return the Domain User service account that was provided for the Desktop Authority Administrative service (which is a local administrator on the client machine). Once it is determined which security context is being used, simply enter the desired target and arguments and press the enter key to see if the command completes successfully (Return Code: 0) or if a problem is encountered. When troubleshooting a computer based element, there is no output so there must be a reliance on the log files to view the return code.
Log Files:
The %temp%\Desktop Authority\SLtrace.htm file can be viewed for all user based application launcher settings in order to determine if the application or command was launched. For computer based application launcher settings, the %Windir%\Temp\Desktop Authority\ComputerManagementTrace_dayofweek_date can be viewed in order to determine if the application or command was launched.
Return Codes:
All return codes recorded to the log files are Microsoft return codes. The text for a return code can be obtained by dropping to a command prompt and typing NET HELPMSG followed by the return code number. For example: If a Return code: 5 is encountered, typing NET HELPMSG 5 [Enter] will return the text “Access is denied.”
Additional Considerations:
If a vendor supplied switch is being used to run the application silently, the hide output option should not be used as it may create unintended problems. The method to discover what switches are available for an executable is to drop to a command prompt and make the directory where the executable resides the current directory and then type the executable name followed by a forward slash question mark or a forward slash help switch. (i.e. C:\Testapp>Testapp.exe/? or C:\Testapp>Testapp.exe /help).
It is important to note that if the specified target resides on a network share, that the user launching the application must possess the appropriate privileges to access the target share. Likewise, if the run as admin option is selected, then the Domain User service account that was supplied for the Desktop Authority Administrative service (who is a local administrator of the client machine) must possess the appropriate privileges to access the target share.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center