Here are some more details about how Support Automation (SA) works.
The secure web launch process:
When launching the live chat client, the web launch process will always start by handling certification validation. First, it will check whether the certificate of the SupportBridge.exe binary is valid. It must be a signed application and should not have an expired certificate. If there is anything wrong with the certificate while launching the application, the launcher process will throw an error such as “Unknown Publisher”.
Second, the launcher process will always validate that all the downloadable executables are signed by the same certificate. So for each file downloaded, if there is any mismatch between its certificate and the certificate of SupportBridge.exe, the live chat client will not be launched. This provides confirmation that the files and processes launching the live chat client have not been modified.
Each time the live chat is launched, it becomes associated with a specific session id. This means that once the live chat client is started, a user cannot run that executable again. It is a one-time application.
There are three components that make up the Support Automation feature.
1. SA Server
2. SA Analyst
3. SA Live Chat
From a technical perspective, when a user clicks on the live chat link, the webengine process of Service Desk Manager sends a request to the object manager, or domsrvr, process. This in turn sends the request to the Support Automation server through the DAL layer. The initial communication with the user will then be established using http communication between the Support Automation Analyst, the Live Chat Client and the Server.
Once this initial communication is successful and the session is established, the SA Server will communicate between the analyst and the end user through a socket port. This provides a secure and fast communication.
Every communication between the above three Support Automation components will pass through the SA server. So if the SA Live Chat Client sends a message to the analyst, that message will go to the SA Server and then will be passed to the analyst.
Below you may find the list of files that gets downloaded when launching the live chat client, along with a description of their function:
Supportbridge.exe: This is the process responsible for initiating the live chat launch by communicating to the SA Server using the details parsed from the URL. It will hand over the session to the Controller.exe process.
Controller.exe: This process runs in the background with system privileges and is completely responsible for the communication between the SA Server and the Customer.exe presentation process.
Customer.exe: This process is responsible for presenting the Live Chat UI on the client machine using the logged in user’s privileges.
SoftwareUpdater.exe: The software updater comes into the picture before the live chat UI is launched. It is responsible for downloading the latest files from the SA Server based on the version information located in the sa_tool_version table. If there is a mismatch between the table and files existing on the server, this process will keep on running and spawning threads; it will never be able to launch the live chat UI.
rcUtlcmd.exe: This process is responsible for providing the remote control feature. Whenever the analyst clicks on the Remote Control button, the server sends a request to the Controller.exe which in turn spawns the rcUtilcmd.exe. This latter process initiates the complete Remote Console UI and its features.
Tools.ART.Client.dll: The supporting dll for the advanced remote control tools/operations like Shutdown, Logoff, Restart, screenshot generation, etc.
Tools.Scripting.Client.dll: The supporting dll for scripting related tools, such as executing scripts and bringing the results back to the analyst.
Tools.Sharing.Client.dll: The supporting dll for the Remote Sharing features.
During the web launch process, the files are always downloaded to a temporary location on the client machine. The actual temporary location is dependent on the OS. The reason the files are downloaded to a temporary location is because the OS will not give extra permissions to applications downloaded to temporary locations, as opposed to more secure or permanent locations on the local hard disk.
Once the session is completed or ended in any direction, most of the files downloaded to the temporary location will be deleted or made non-usable since they are part of a one-time application launch.