Want to get rid of Google Ads, click here.
  • Section Widget

  • Recent Article Comments Widget

    drjf4

    I have picked up a copy of the new book. (Also own a copy of the 6.2 version.) I have started... Go to last post

    New book by Mike Sanders: Service Manager 9 Tailoring Techniques

    drjf4 on 2012-02-03
  • Kill User Sessions without being SysAdmin

    I've seen a question like this float around this forum and that other forum (http://forums13.itrc.hp.com/service/...categoryId=695) and it seemed like something that should be possible, and should be included OOB, but for some reason, was never done.

    Let's say you have a user call your Helpdesk group, because they've somehow managed to lock themselves out of Service Manager, and the helpdesk needs to kill that user's session. You don't want to give the Helpdesk access to the System Status where they can do all kinds of harm, but they do need to be able to kill a session. This is my attempt at a solution.

    (I had wanted to do the coding for this in Javascript, but I had a hard time with the structured arrays... so good old-fashioned expressions is what I ended up using.)

    You're going to create one link record, two forms, and three wizard records to accomplish this. You'll also need to put this on a menu so your users can access it. For my purposes, we'll just use the HOME menu, but feel free to make whatever modifications you need.

    First, we'll start with the two forms.
    The first provides a place for your operator to enter which user to kill.

    Form Name: cg.KillUserSessions.User
    Form Element: Label
    Caption: User ID:

    Form Element: Comfill
    Input: $cg.user.id
    Fill Button Visible: true

    Form Element: Comfill
    Input: $cg.user.name
    Fill Button Visible: true

    The second form, is a mimic of the System Status, with information about the specific user's session(s).

    Form Name: cg.KillUserSessions.Sessions
    Form Element: Table
    Columns: Kill, User ID, Date, Idle Time, PID, Host
    Show Columns: true

    Form Element: Column
    Column Title: Kill
    Input: $cg.killSession

    Form Element: Column
    Column Title: User ID
    Input: $cg.sessionInfo.user
    Read Only: true

    Form Element: Column
    Column Title: Date
    Input: $cg.sessionInfo.date
    Read Only: true

    Form Element: Column
    Column Title: Idle Time
    Input: $cg.sessionInfo.idle
    Read Only: true

    Form Element: Column
    Column Title: PID
    Input: $cg.sessionInfo.pid
    Read Only: true

    Form Element: Column
    Column Title: Host
    Input: $cg.sessionInfo.host
    Read Only: true


    Then the link - this is just so users can enter either an operator ID or a user's full name, to bring the ID back for the rest of the wizard.

    Link Name: cg.KillUserSessions.User
    -----------------------------------------------------
    Source Field: $cg.user.id
    Target File: operator
    Target Field: name
    Query: $query
    Expressions -
    if (not null($cg.user.id)) then ($query="name=\"+$cg.user.id+"\"")

    Source Field | Target Field
    $cg.user.id | name
    $cg.user.name | full.name
    -----------------------------------------------------
    Source Field: $cg.user.name
    Target File: operator
    Target Field: full.name
    Query: $query
    Expressions -
    if (not null($cg.user.name)) then ($query="full.name=\""+$cg.user.name+"\"")

    Source Field | Target Field
    $cg.user.id | name
    $cg.user.name | full.name


    Then, the meat of the work, are the three wizards.

    The first gets the information about who is going to be killed, and checks to make sure that user is logged in to SM. Once we get the operator id, the system gathers information about that operator, like the time they logged in, how long they've been idle, etc.

    Wizard Name: cg.KillUserSession.1
    Start Node: true
    Window Title: Kill User Session
    Title: Select User:
    Prompt: Enter the User ID or the User Name of the user whose session you want to kill.

    File Selection -
    Select $L.file by: No $L.file (use typecheck)
    Wizard Usage -
    Request User Input
    Subformat to display: cg.KillUserSessions.User
    Actions -
    Perform Actions On: Current File ($L.file)
    Actions to Perform:
    Expressions:
    $L.processes=processes("USER");$cg.sessionInfo.use r={};$cg.sessionInfo.date={};$cg.sessionInfo.idle= {};$cg.sessionInfo.pid={};$cg.sessionInfo.name={}; $cg.sessionInfo.id={}

    $cg.i=0;while ($cg.i<lng($L.processes)) do ($cg.i=$cg.i+1;if (4 in $cg.i in $L.processes=$cg.user.id) then ($L.not.on=false;$cg.sessionInfo.user=insert($cg.s essionInfo.user, 1, 1, 4 in $cg.i in $L.processes);$cg.sessionInfo.date=insert($cg.sess ionInfo.date, 1, 1, 1 in $cg.i in $L.processes);$cg.sessionInfo.idle=insert($cg.sess ionInfo.idle, 1, 1, 5 in $cg.i in $L.processes);$cg.sessionInfo.pid=insert($cg.sessi onInfo.pid, 1, 1, 6 in $cg.i in $L.processes);$cg.sessionInfo.tid=insert($cg.sessi onInfo.tid, 1, 1, 7 in $cg.i in $L.processes);$cg.sessionInfo.host=insert($cg.sess ionInfo.host, 1, 1, 8 in $cg.i in $L.processes);$cg.sessionInfo.id=insert($cg.sessio nInfo.id, 1, 1, 2 in $cg.i in $L.processes)))
    Messaging -
    Messages when complete:
    Message | Condition | Type | Level
    Please enter a User ID. | null($cg.user.id) | Pop Up | Error
    No one with that ID is logged in to the system. | nullsub($L.not.on, true)=true | Pop Up | Error

    Next Wizard -
    Wizard Name | Condition
    cg.KillUserSession.2 | not null($cg.user.id) and $L.not.on=false
    cg.KillUserSession.1 | true


    Once the system gathers this information, it presents it to the operator in a form similar to the system status, but it only shows _that_ user's information.

    Wizard Name: cg.KillUserSession.2
    Window Title: Kill User Session
    Title: Select Session:
    Prompt: Enter "k" by each session you want to kill.
    File Selection -
    Select $L.file by: $L.file passed in
    Initial Expressions -
    $cg.k.index=lng($cg.sessionInfo.user)
    for $L.vi = 1 to $cg.k.index do ($cg.killSession=insert($cg.killSession, 1, 1, ""))
    Wizard Usage -
    Request User Input
    Subformat to display: cg.KillUserSessions.Sessions
    Next Wizard -
    Wizard Name | Condition
    cg.KillUserSession.3 | true


    Then the third wizard actually sends the signal command to kill that particular session.

    Wizard Name: cg.KillUserSession.3
    File Selection -
    Select $L.file by: No $L.file (use typecheck)
    Wizard Usage -
    Skip Display.
    Actions -
    Perform Actions On: Current File ($L.file)
    Actions to Perform:
    Expressions:
    $cg.killSession.length=lng($cg.killSession);for $cg.k.index = 1 to $cg.killSession.length do (if ($cg.k.index in $cg.killSession"k" then ($L.void=rtecall("callrad", $L.rc, "signal", {"name"}, {$cg.k.index in $cg.sessionInfo.id}, true)))
    Messaging -
    Messages when complete:
    Message | Condition | Type | Level
    The user's Session(s) were successfully killed. | $L.void=true | Pop Up | Info

    Then, just add an option to the Menu so your users have access:
    Menu: HOME
    Description: Kill User Session
    Application: wizard.run
    Parameter Name: name
    Parameter Value: cg.KillUserSession.1
    Condition: true

    Or, instead of true, put whatever condition you want, so that only the users you need have access to this feature.


    And that should be it. A functional way to kill a user's session while preventing them from accidentally killing processes needed by the system.

    Feel free to modify as needed; and good luck to us all.
    Comments 21 Comments
    1. leonv's Avatar
      Very nice post Jacob, excellent work. Any chance of unload files as well?
    1. Lukus's Avatar
      Great post Jacob, very useful for most ServiceDesk type environments.
    1. Jacob.Heubner's Avatar
      The cg.KillUserSessions.zip file contains an unload of the forms, the link, and the wizards. You will need to still add your own menu item with your own conditions to determine who should have access.

      Glad you're finding it helpful.
    1. leonv's Avatar
      Thanks Jacob. A small tweak I made was to put "$L.void=false;" at the start of the Expressions for the 3rd wizard. If it's not there and you don't put a 'k' in any session and just hit next, it still pops up the message saying the session(s) for user x were killed successfully"
    1. jmbetty's Avatar
      I'm running SM 7.02.046. After running the kill wizards, I get 1 error and 1 warning message and no kill processing occurring.

      Error - A host name was not provided by the RAD signal panel. Signal request ignored.
      Warning - Could not send signal to the session

      I do see a correct value in the hostname column of the user list, but the kill signal does not seem to be getting what it wants.

      EDIT: I also noticed that when I am at the displayed user sessions wizard (wizard 2), and hit the back button then next button (essentially go 1 step back and 1 step forward), I see an incremental number of rows in the hostname column being added. So if the first time I got back 3 rows, the second time I get 6 rows, then 9 rows, etc. Always in the hostname column. Could this have something to do with why I am getting the error? Or just logic in the way the array variables are being assigned?

      Any thoughts?
    1. Jacob.Heubner's Avatar
      Quote Originally Posted by jmbetty View Post
      I'm running SM 7.02.046. After running the kill wizards, I get 1 error and 1 warning message and no kill processing occurring.

      Error - A host name was not provided by the RAD signal panel. Signal request ignored.
      Warning - Could not send signal to the session

      I do see a correct value in the hostname column of the user list, but the kill signal does not seem to be getting what it wants.

      EDIT: I also noticed that when I am at the displayed user sessions wizard (wizard 2), and hit the back button then next button (essentially go 1 step back and 1 step forward), I see an incremental number of rows in the hostname column being added. So if the first time I got back 3 rows, the second time I get 6 rows, then 9 rows, etc. Always in the hostname column. Could this have something to do with why I am getting the error? Or just logic in the way the array variables are being assigned?

      Any thoughts?

      As far as your edit goes, I saw that too. I apparently don't reset the host array in cg.KillUserSession.1

      After: $cg.sessionInfo.id={}

      There should be: ;$cg.sessionInfo.host={}

      As far as your first issue, that I haven't seen.
    1. jmbetty's Avatar
      I added the variable reset and that cleared up that part of the issue. I'm still getting the hostname error.

      Out of curiousity, can you confirm the release level and date of your "signal" RAD application? Mine seems rather old.
    1. krisman's Avatar
      I put this into our DEV environment and did the minor code fixes I saw here and voila!

      Works like a charm!

      Jacob, you are a genius!
    1. jmbetty's Avatar
      I would really like to get this working. I'm still thinking my "signal" RAD app may be out of date. Can anyone who is running this successfully under 7.0x confirm the release level and date of their "signal" RAD app? Thanks!
    1. Jacob.Heubner's Avatar
      Quote Originally Posted by jmbetty View Post
      I would really like to get this working. I'm still thinking my "signal" RAD app may be out of date. Can anyone who is running this successfully under 7.0x confirm the release level and date of their "signal" RAD app? Thanks!
      Release date of the "signal" RAD app on my system is 10/30/2007
    1. tommy's Avatar
      Quote Originally Posted by jmbetty View Post
      I would really like to get this working. I'm still thinking my "signal" RAD app may be out of date. Can anyone who is running this successfully under 7.0x confirm the release level and date of their "signal" RAD app? Thanks!
      There are known issues with killing some users / processes on 7.0.x. A customer is running 7.0.2 on AIX and have a problem with idle uses not getting killed and lokoing interactions so we have to restart the server when the number of locked interactions get too high.
    1. F41X's Avatar
      Great post Jacob! Works great. One of our users had a question though...Is there a way to expand the results, or have an option to look at all users logged in? For instance, if we want to have our desk perform any idle session 'clean up' , would they be able to kill multiple sessions based on idle time rather than userID. Thanks!!
    1. tommy's Avatar
      Quote Originally Posted by F41X View Post
      Great post Jacob! Works great. One of our users had a question though...Is there a way to expand the results, or have an option to look at all users logged in? For instance, if we want to have our desk perform any idle session 'clean up' , would they be able to kill multiple sessions based on idle time rather than userID. Thanks!!
      Inactivity timer is for just that. It kills idle users after xx number of minutes.
    1. F41X's Avatar
      We use it at 60mins, but still have too many sessions sometimes (users not logging out correctly, bypassed users, idle sessions, etc). Anyway, I figured out some mods if anyone else would like this functionality:

      Wizard Name: cg.KillUserSession.1
      Actions - Line 2:
      Replace: if (4 in $cg.i in $L.processes=$cg.user.id) then
      With: if ($cg.user.id=NULL or 4 in $cg.i in $L.processes=$cg.user.id) then

      Messaging:
      Replace: null($cg.user.id)
      With: false

      Next Wizard:
      Replace: not null($cg.user.id) and $L.not.on=false
      With: true

      This removes the validation on NULL user Id or Name, and will return a list of all users logged in.
    1. jmbetty's Avatar
      I thought my "signal" RAD app was oddly old -- Release date: 9/15/1998 03:00:00. I'm thinking that's the reason for my problem. Unfortunately, I don't have an out-of-box 7.0x system in order to retrieve the latest version.
    1. jmbetty's Avatar
      Oddly I did finally get a 7.00 out-of-box environment running, unloaded the "signal" RAD app and loaded it into my custom 7.02 system, unfortunately it did not resolve my resulting error message:

      Error - A host name was not provided by the RAD signal panel. Signal request ignored.
      Warning - Could not send signal to the session
    1. johnydoey's Avatar
      Thanks for sharing Jacob !!!
    1. Jacob.Heubner's Avatar
      Quote Originally Posted by jmbetty View Post
      Oddly I did finally get a 7.00 out-of-box environment running, unloaded the "signal" RAD app and loaded it into my custom 7.02 system, unfortunately it did not resolve my resulting error message:

      Error - A host name was not provided by the RAD signal panel. Signal request ignored.
      Warning - Could not send signal to the session

      John -
      I looked into this, and have made some changes. Try the following:

      on the "cg.KillUserSession.3" in the expressions, replace the code that's there with:

      $L.rc="prompt";$cg.killSession.length=lng($cg.kill Session);for $cg.k.index = 1 to $cg.killSession.length do (if ($cg.k.index in $cg.killSession="k") then ($L.void=rtecall("callrad", $L.rc, "signal", {"name", "string1"}, {$cg.k.index in $cg.sessionInfo.id, $cg.k.index in $cg.sessionInfo.host}, true)))

      The "string1" parameter and the position in the $cg.sessionInfo.host variable passes a host name along with the session id. See if that resolves your issue.
    1. gracemely's Avatar
      Applaud. THANK YOU Jacob.
    1. seawind198107's Avatar
      Amazing Jacob.
  • Google search

    Google
     
  • Support ServiceCenter Resources - Make a donation

    Acceptance Mark