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 some of the best practices listed in the following section:
Develop specific use case scenarios with the users on the multi-user workstation.
If your current network login scripts are use, 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 log out event.
If a use case requires applications to be shut down as part of user log out or a time-out event, access each applications carefully to ensure that Desktop Automation Service does not have any adverse effect in the application sessions. For example, terminal emulator sessions or unsaved log out (graceful log out).
Analyze each application to determine the best way to handle a fast shut down.
When updating actions.xml files, if you want to activate the latest changes without having to reboot the workstation, issue a command to the workstation to ARS.exe to reload the actions.xml: "C:\Program Files\Novell\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. So, ensure that you follow a common naming convention. For example, use lowercase always.
The DASlog.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 4 (verbose) on the 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 DASlog.txt file after you have tested at the log level 4 as the file size is large.
eDirectory can centrally store different workstation behavior 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, it is recommended that you provide a pause before forcing the shutdown.
When DAS tries to shutdown the ICA Client, it sends a WM_CLOSE message to the Citrix* client. The Citrix client re-sends the message to the published application that is delivered to shutdown. If it is a time out or slow to respond, DAS quickly forces the shutdown and does not allow the Citrix application to gracefully shutdown. 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. We recommend that there might be some timing issues with certain event executions. So, ensure that you set the correct values for the serial = true or false parameters.