Each deployment of DAS is unique to your use case, user target group, application mix, and other factors.
In the following sections, we list some of the best practices and some common debugging issues that you can consider during your deployment.
When deploying DAS, we recommend that you read and follow the best practices listed here:
Develop specific use case scenarios with the users on multi-user workstations.
If you are currently using network login scripts, analyze them to determine the steps that can be streamlined or determine specific actions such as mapping the drives that can be accounted.
Prepare an inventory of all the applications and their versions on the workstation.
Determine if there are any security policies or other technical aspects that might affect the deployment.
Make a note of the processes running in the task manager when a user is logged in to the network. This helps to determine whether there are any applications that must be auto-launched or excluded during a logout event.
If a use case requires applications to be shut down as part of user logout or a time-out event, access each applicationcarefully to ensure that Desktop Automation Service does not have any adverse effect in the application sessions. For example, terminal emulator sessions or unsaved logout (graceful logout).
Analyze each application to determine the best way to handle a fast shutdown.
When updating actions.xml files, if you want to activate the latest changes without rebooting the workstation, issue a command to the workstation to ARS.exe to reload the actions.xml: "C:\Program Files\NetIQ\SecureLogin\Desktop Automation Services\ars.exe" /refresh
Following are some of the common debug issues that you might encounter when deploying DAS:
The action names are case-sensitive. Ensure that you follow a common naming convention, such as always using lowercase.
The DAS log file(SSODebug.txt) indicates the syntax errors (if any) in the actions.xml file. If the syntax errors are not indicated, run each section separately to determine the error while parsing the actions.xml is executed.
Enable the log file and set the log level to 3 (Fatal) on development workstations to help debug the issues. After you have completed the testing, set the log level to zero to have minimal logging.
Delete the SSODebug.txt file after you have tested at log level 3 because the file size is large.
eDirectory can centrally store different workstation behaviors that require different DAS configuration files.
Configure the client in the registry to point to the desired DAS configuration object in the eDirectory.
You can also have the different actions.xml files managed locally on the unique workstations and have the other common workstations point to eDirectory.
When forcing the ICA Client to shut down with DAS, you should provide a pause before forcing the shutdown.
When DAS tries to shut down the ICA Client, it sends a WM_CLOSE message to the Citrix client. The Citrix client resends the message to the published application t If there is a timeout or if the application is slow to respond, DAS quickly forces the shutdown and does not allow the Citrix application to gracefully shut down. Adding a pause addresses the timing requirement.
Add pauses in the actions.xml file if you notice any unusual behavior or observe that some use cases are not met as expected. There might be some timing issues with certain event executions, so you should ensure that you set the correct values for the serial = true or false parameters.