Login Scripts Good, Launch Scripts Bad

DAN SHAPPIR on July 29, 2014 | 1899

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:

  1. Delete current drive mappings – this is in case the application is being launched a second time and the drives are already mapped
  2. Map the drive letters that are needed
  3. Launch the application
  4. Exist the script

(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:

  1. Launch scripts make the process of application publishing unwieldy – since you publish a script instead of the actual application browsing for it is more difficult and you need to manually adjust properties such as the icon
  2. They invalidate multiple application publishing – PowerTerm WebConnect has a cool feature that scans the Start menu on the Terminal Server, and enables you to publish multiple applications simply by selecting them. If you need to publish scripts instead of the actual applications this feature cannot be used
  3. Bugs in the scripts – in particular a script may launch the application with wrong command-line arguments or in an incorrect folder
  4. Script maintenance – whenever an application is upgraded its launch script may need to be updated as well
  5. Synchronization problems – if you launch the published application twice at the same time session sharing will place both instances in the same session. This will results in two instances of the launch script running at the same time and stepping on each other’s toes
  6. More Synchronization problems – if one instance of the application is already running (its launch script is already done), and you run another instance in the same session, the new script will unmap the drives from under the first instance’s feet (see step 1 of the script),
  7. Increased maintenance overhead – several applications may require identical mappings. Yet each application will utilize its own script, so you end up with duplicate code in several files that must always be in sync (yes, you could create a script that runs another script, but that is even more complicated and error-prone),

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:

  1. Logout scripts, which are also synchronous (session does not end until they are done),
  2. Application scripts – scripts that are run for specific published applications. This reduces the need for launch scripts even more. Such scripts are synchronous both with the application and other instances of themselves
  3. Connect/disconnect scripts
  4. Scripting API – the scripts can directly interact with PowerTerm WebConnect to receive information and perform operations. For example, if the mapping fails the script can use an API method to abort the session

Over the upcoming weeks I will provide more information about the PowerTerm WebConnect scripting infrastructure so stay tuned.

Author | 180 Blog Posts

Dan Shappir

Dan Shappir is responsible for all aspects of product design, software development and maintenance of the Ericom's product lines. | Ericom Software

Recommended Articles