Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

ReconnAct

Introduction

Update: ReconnAct is now part of the Immidio Resource Kit

There are several users at companies whose are travel around locations and/or buildings. Often these users take over their existing session (which is in disconnected mode or still active on the other workstation) especially with new improved Workspace control options within Web Interface and PN Agent.




Because the user is taken over a session al settings are already configured like for example printer settings or other location specific settings. It would be nice to detect that the client machine is changed and that some settings should be changed based on the movement of the session to another machine.

Checking variables within the session you will notice the variable CLIENTNAME, but unfortunately this variable is not checked if an session is being moved from one client to another. So the client name stays the same till the session is logged off (the client name variable holds the name of the client the session is initiated on).

So this variable can not be used for noticing a client change. Dennis Damen has created ReconnAct for this challenge.

Installing ReconnAct

ReconnAct does not to be installed; it is only one single executable. Because of the different behavior between Windows 2000 en Windows 2003 operating system there is a different executable for each operating system (ReconnAct!.exe for Windows 2003 and ReconnAct!2K.exe for Windows 2000).

ReconnAct should be loaded during user logon. After logon the executable stays active listening for an invent mentioning that the user is disconnecting or reconnecting. A good way to load ReconnAct is to start the executable in a logon script or equivalent.

How does it work?

If ReconnAct is loaded two new variables are introduced called CURRENT_CLIENTIP and CURRENT_CLIENTNAME. If a user reconnects ReconnAct is checking the client information and represents the actual client IP address and client name into these variables. Also ReconnAct is noticing that the session is going into disconnected state or the session is reconnected (during an invent mentioned by the operating system) and can start a defined script if one of the described states is noticed.

Using ReconnAct

As already mentioned ReconnAct needs to be started during the initiation of the user session. In the (for example) login script ReconnAct  needs to be added with parameters.

The following parameters are available:

  • /l:<filename to execute>
    The filename specified after the /l: parameter will be run at start-up of the session.
  • /d:<filename to execute>
    The file specified after the /d: parameter will be run when the session reaches the disconnect state.
  • /r:<filename to execute>
    After the /r: parameter the file need to be specified which will be run when the session is reconnected.
  • /a
    When the /a parameter is specified the reconnect script will always run when the session is reconnected. Default behavior is that the reconnect script only runs when the name or IP address from the client is changed.
  • /h
    The scripts will be run ‘hidden’
  • /s
    Enables speed logoff. This option disconnects the session immediately so the user does not see the complete logoff process when the user stops his session.

In the scripts used at the different session states can also use the variables CURRENT_IP and CURRENT_CLIENTNAME for determining settings like connected printers or application availability.

Conclusion

ReconnAct fills the gap that is still open when using Terminal Server (and Citrix) with reconnected sessions, because the default variables do not notice the change of the actual client station. With ReconnAct you can notice the reconnection with the actually client IP and name. Using this information you can create scripts that can for example connect the closest printer at that location or (re)configure an application.

ReconnAct can be downloaded from the Login Consultants homepage.