A common SBC scenario is one where certain drive mappings need to occur when accessing published applications or logging in to remote desktops. One reason for this is that some line-of-business applications were written is such a way that requires specific drive letters to exist. Another reason is that some organizational work procedures associate user-specific folders on servers with fixed drive letters. For example, we have a large PowerTerm WebConnect customer that maps users’ folders on Netware servers in such a way.
An obvious approach to mapping such drives is to create a login script that performs the mapping operation. Unfortunately this approach does not always work. One significant problem is that login scripts generally run asynchronously. What this means is that the script is indeed launched before the published application, but Windows (or Citrix) does not wait for it to finish before launching the published application. Instead both the script and the application run in parallel. As a result, if the application launches quickly and attempts to access the mapped drives as one of its first operations, it may do so before the drives were actually mapped by the script. The same can happen if the script needs to perform a relatively lengthy operation before mapping the drives or to interact with the user in some way.
A common solution for this problem is to create a script that maps the drives and then launches the application. In this case, instead of publishing the actual application, you publish the script. In other words, instead of creating a login script you create a “launch script”. Such launch scripts typically have the following structure:
(Thanks to Patrick Rouse for providing this information)
When we designed script support in PowerTerm WebConnect we decided to do our best to avoid the need for such launch scripts. There were several reasons for this:
Because of all these issues we decided to find a way to enable login scripts to properly perform such operations without requiring launch scripts.
Our solution was to augment the Windows scripting infrastructure with additional custom scripts specific to PowerTerm WebConnect. What this means is that in addition to the standard Windows login scripts, PowerTerm WebConnect runs its own custom login scripts whenever a session is created. The interesting twist is that these login scripts are completely synchronous with the applications. In other words, the published application will not be launched until the script is done. This facility makes it very simple to create login scripts that perform such operations successfully.
We did not stop with this. PowerTerm WebConnect’s scripting functionality is very robust providing many additional features such as:
Over the upcoming weeks I will provide more information about the PowerTerm WebConnect scripting infrastructure so stay tuned.