Jim, I'm almost certain that taking action 1 will eventually result in timeout errors, even if it's not the cause of what you're currently seeing. That is essentially the same as what BMC recommended as Tauf outlined in his e-mail (having 1=1 or no Run If qualification will both cause the action to be taken every time).
Are you certain the SessionID didn't change? The session ID is really just a munged up date/time stamp, so if you look at two Session IDs generated closely in time, they will be almost the same with only one or two numbers changing. What I've had to do is copy the original session ID out into something like Notepad, and then copy it out again after refreshing the record and pasting it directly below the original. Then it's easier to see if something actually changed. Otherwise, I'll try to explain what I understood to be going on in our case, along with what the changes Tauf or your vendor suggested making do vs. what I ended up with in the end. As I understand it, in order to avoid making you log in to RKM when getting to it via Remedy (that is, via the User tool, in an Incident record, etc.), Remedy generates a session ID for you if you don't already have one (that's the OOB behavior). If you already have a SessionID, then it doesn't do anything. Then, in the URL it generates to get to RKM, it includes this session ID as part of the URL. RKM then looks up the session ID in the KMS:Session form and checks the value of the Groups field. If it doesn't have a value, it puts the IP address of the machine that you're coming from in there. If it does have a value, it makes sure that your current IP address matches the value stored in the form. If it doesn't match, it makes the user login. That seems to work fine so long as the IP address you're coming from never changes. However, in a help desk situation where people may not always be at the same computer from day to day, as soon as someone changes to a different computer to work, they are now forced to log into KB every time they want to use it, because their IP address doesn't match what was previously stored with the SessionID. We ran into this issue here. As a fix, BMC recommended making the changes that Tauf outlined. The "fix" is essentially to make it always generate a new SessionID (which happens to set the Groups field to $NULL$ at the same time). That way, every time you open a form that you can get to the KB from (in our case, it was always from the Help Desk form), you have a fresh new SessionID with the Groups field empty. You can now switch machines and the fact that your IP address has changed is no longer an issue. So, we thought that was working great for a while, and then we started getting tickets about RKM timeouts, and it was often on the order of minutes. We had it set to timeout after something like 2 hours, so I knew something was up. After digging into it some more and doing some debugging with one of our help desk agents, I figured out what was going on. What was happening was that they were opening up a window to create a new KB article based on the last call, but had to leave it there while they took the next call. As part of taking the next call, they opened the Help Desk form again to log the ticket. This cause a new session ID to be created. So, everything they did with KB during that call worked fine (because they went to the KB tab in that ticket or opened an article from that ticket, which all used the new session ID). However, when they went back to the original article that they had started to write, when they went to save the article, RKM reverified the Session ID used for that window, found that it wasn't valid anymore, and reported to the user that their session had timed out, even though it had only been a few minutes since they opened the window. So, the crux of the problem now is that a person's session ID needs to stay the same for the entire duration of their session logged into Remedy and KB, or they need to always close old windows and start fresh with new ones. No more keeping windows open while you do other things. The fix to this was to undo the "fix" that BMC recommended so that it only created a new SessionID when the user didn't already have one. I then added an active link that clears the Groups field when they open the Help Desk form (you would have equivalent ALs for each of the forms that you open KB from - In your case, you might have something like KMS:Main:Clear Session ID Groups). This ensures that their session ID never changes from when it was created, but clears the Groups field so that, if they change machines, they can still use KB, because it won't think they should be coming from a different machine. So, what I was thinking was that if your timeout problems started after making either the change recommended by your vendor, or the one recommended by BMC, then you could be having the same issue we had. In that case, the problem was in fact the "fix" recommended. The solution is not to have a new Session ID created every time, but instead to clear out the Groups field if they already have a SessionID. Does that make any more sense? Cheers, Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Nowak, James Sent: Friday, January 08, 2010 12:15 PM To: arslist@ARSLIST.ORG Subject: Re: RKM Timeouts On a recommendation from our support vendor we made the following change to the AL KMS:HD_Create_SessionID and KMS:Main_Create_SessionID. This was due to an issue where we were getting Invalid Session errors: They recommended one of the following solutions: 1. Make sure AL KMS:Main:Create_Session_ID has a qualification that causes it to fire every time kms:main form opened by qual 1=1. 2. Make sure the KMS:Session form has the Groups field on it. 3. Make sure the push field of AL KMS:Main:Create_Session_ID has an extra push field action to push Groups = 4. Active Link KMS:Main_Create_SessionID has a Push Field action... Make sure the "If ANY requests match" section is not set to "TAKE NO ACTION" We chose #1 and set the RunIf with a qualifier of 1=1. The actions have not changed. I have read the other replies from Lyle and Tauf and now I am even more confused... Looking at what happens to the KMS:SessionID table, I see my session ID stay the same, but the modified date does change. Also I will look into cleaning out the HOME directory for the User tool. Finally, we did go to patch 3. I'm gonna have one of the agents clear their home dir and I'll report back on how that worked. Thanks again for all the hints and help! Jim Nowak Infrastructure Tools OfficeMax Inc. 630-864-5366 w 630-414-0193 c -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Friday, January 08, 2010 11:35 AM To: arslist@ARSLIST.ORG Subject: Re: RKM Timeouts Did you make any changes or do any customizations related to the values stored in the SessionID or Groups fields on KMS:Session? We had issues due to the IP address of the client being stored in the Groups field, where the recommended change by BMC caused a new SessionID to be created every time the Help Desk form was opened. The net result of this was that users saw frequent timeouts on the order of minutes, because their session ID kept changing while they still had windows open. So the next time they went to do something in an already open window, the session ID used when that window was opened no longer matched what was stored in Remedy, and it presented that as a session timeout error. Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Nowak, James Sent: Friday, January 08, 2010 9:59 AM To: arslist@ARSLIST.ORG Subject: RKM Timeouts We are having an issue with RKM getting timeout errors in the Remedy User tool. Our configuration is the following: RKM 7.2 patch 3 integrated with Remedy ARS 6.3 We are seeing the timeouts in both the RKM home page in the User tool as well as from the KnowledgeBase tab that is created in the HelpDesk form. The error is the following: "Session is invalid or has timed out. Close (Refresh) you browser and Login again" We have made the following changes in the RKM environment: 1. Set the RKM config of session-timeout value to 0. This is suppose to disable timeouts 2. Set the Tomcat session-time value to 240 in web.xml and restarted Tomcat After both of these changes (which were done at different times) we continue to see the timeout error. Any help that can be given would be greatly appreciated. Thanks, Jim Nowak Infrastructure Tools OfficeMax Inc. 630-864-5366 w 630-414-0193 c ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
