While the user is not logged on from the machine they are trying to log in
from when receiving the error that they are logged in from another machine,
do you see any activity from that particular user on user logging? It might
just be a plain and simple case of the user actually having logged in
somewhere else and being automatically staying logged in from there.

 

What happens after the timeout?

 

Joe

 

  _____  

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II
Sent: Thursday, February 12, 2015 3:40 PM
To: arslist@ARSLIST.ORG
Subject: Re: USER_CACHE Problems

 

** 

Thanks Misi!  I was looking at that also.  This is one of the stranger
issues I have dealt with.

On Feb 12, 2015 2:33 PM, "Misi Mladoniczky" <m...@rrr.se> wrote:

Hi,

The user_cache does not seem to hold information about the IP of the last
login. It must reside somewhere else...

I have also tried to check the contents of the table without finding
anything...

SQL> describe user_cache;
 Namn                          Null?    Typ
 ----------------------------- -------- --------------------
 SERVERID                      NOT NULL NUMBER(15)
 ENTRYID                       NOT NULL VARCHAR2(15)
 USERNAME                      NOT NULL VARCHAR2(254)
 PASSWORD                               VARCHAR2(255)
 AUTHUSERNAME                           VARCHAR2(254)
 SHORTAUTHSTRING                        VARCHAR2(255)
 LONGAUTHSTRING                         CLOB
 LICENSEPOOL                            VARCHAR2(30)
 EMAIL                                  VARCHAR2(255)
 NOTIFYMECH                             NUMBER(15)
 LICTYPE                                NUMBER(15)
 LICTYPEFTEXT                           NUMBER(15)
 LICTYPERESERV1                         NUMBER(15)
 LICTYPEAPP                             CLOB
 TIMESTAMP                              NUMBER(15)
 VALIDATEKEY                            VARCHAR2(30)
 SHORTGROUP                             VARCHAR2(255)
 LONGGROUP                              CLOB
 SHORTCOMPGROUP                         VARCHAR2(255)
 LONGCOMPGROUP                          CLOB
 FIXEDLICCHANGE                         CLOB
 BADPWD                                 NUMBER(15)
 BADPWDTOTAL                            NUMBER(15)
 PWDCHANGE                              NUMBER(15)

I have tried to find another table that could potentially hold that
information, but I have not found any...

        Best Regards - Misi, RRR AB, http://rrr.se

> If you gave the person admin permissions and the problem went away and
then
> came back after you removed it.  Then the issue isn't the user_cache.  The
> issue is the permissions that the user has and the permissions required
for
> the screen you are trying to access.  Everything is changing when
> permissions are changed so the user_cache and that whole under lying
system
> is working fine.
>
> I am sorry I don't have better advice for you, but I would say find
someone
> who it is working for and making sure that this user has the same access.
> Another thing to look into is the data for their permissions in the db.
> You might see a bit of corruption in the group assignment.  I have found
> issues with manually pasting in values sometimes.  I hope some of that
> helps.
>
> Brian Goralczyk
>
> Brian Goralczyk
> Phone 574-643-1144
> Email bgoralc...@gmail.com
>
> On Thu, Feb 12, 2015 at 1:04 PM, Grooms, Frederick W <
> frederick.w.gro...@xo.com> wrote:
>
>> What error is the user getting?   9361 ?
>>
>> Also ... When updating a user I think the user cache only gets updated
>> when one of the following changes (so your checkbox may not have updated
it)
>>    Login Name, Password, License Type, Email Address, Default Notify
>> mechanism
>>
>>
>> You could change their license type to read, save, refresh, and change it
>> back to see if that user's record in the user_cache is updated
>>
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList) [mailto:
>> arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
>> Sent: Thursday, February 12, 2015 11:56 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Re: USER_CACHE Problems
>>
>> Hi,
>>
>> If you get ARERR 329, the user/password seems not to match. At least not
to
>> what is in the cache...
>>
>> You can use another program named arecache to add a new admin user that
you
>> can later use with arreload.
>>
>> Note that the -s option changed to/from -t at some point. I do not
remember
>> which version.
>>
>> Choose a Login Name and Request ID that does not exist.
>>
>>   arcache -Ua -d -e 00001500 -n loginname -s server -g "1;" -l1 -p passwd
>>
>> If you are out of fixed licenses, you might need to delete a current
Fixed
>> user before you add the new one.
>>
>>  arcache -Ud -d -e 0000000000000000x -s ServerName
>>
>> Finally try the arreload again.
>>
>> I also recall a bug with arreload together with the -d option. Try
avoiding
>> -d. I do not remember the exact version with this problem either...
>>
>>         Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>
>> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
>> Find these products, and many free tools and utilities, at http://rrr.se.
>>
>>
>> -----Original Message-----
>> > I did bounce the Remedy system after the problem started.  It didn't
work
>> > though....  I've been trying the following command:
>> >
>> > # ./arreload -a "[userid]" -p "[password]" -u "User" -s "[servername]"
>> -f -d
>> >
>> > I get the following:
>> >
>> > Action Request System  Reload Cache Manager   Version 6.03.00 patch 016
>> > Remedy, a BMC Software company.
>> > Copyright (c) 1991 - 2005 BMC Software, Inc.
>> > All rights reserved.
>> > Summary of command line arguments:
>> >    User form    : User
>> >    Group form   :
>> >    Admin user   : [userid]
>> >    Update server: [servername]
>> >    Flush items from CURRENT server only
>> > Verifying Admin access to 'source' server -- [servername]
>> >    FAILED!
>> > Message not in catalog; Message number = 329 (ARERR 329)
>> >    [servername]
>> >
>> >
>> > ARERR 329 :
>> >
>> > Invalid password or authentication string for an existing user
>> >
>> > The password you have specified for the user name is not recognized.
The
>> > problem can be
>> >
>> > either with the password or with the authentication string (if using NT
>> > authentication, the
>> >
>> > authentication string is the NT domain) or both. Enter the password
>> defined
>> > for this user
>> >
>> > name to access the system as that user.
>> >
>> > I've used both Demo with a Fixed license and Admin privs. as well as my
>> own
>> > user id that also has admin privs.  Am I missing something?
>> >
>> >
>> >
>> >-----Original Message-----
>> > On Thu, Feb 12, 2015 at 9:26 AM, Grooms, Frederick W wrote:
>> >
>> >> The logged in status for a user is only in memory (not stored in the
>> >> database) so have you restarted the AR System?
>> >>
>> >> When using the arreload utility make sure to turn off the max number
of
>> >> records returned limit (if you have one set on the server) before
>> running
>> >> or you will only get that number of users loaded into the user_cache
>> >>
>> >> Fred
>> >>
>> >> -----Original Message-----
>> >> From: Action Request System discussion list(ARSList) [mailto:
>> >> arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
>> >> Sent: Thursday, February 12, 2015 7:58 AM
>> >> To: arslist@ARSLIST.ORG
>> >> Subject: Re: USER_CACHE Problems
>> >>
>> >> Hi,
>> >>
>> >> Have you tried the arreload-program?
>> >> arreload -u User -f -a adminuser -p adminpassword
>> >>
>> >> The -f is supposed to flush the cache before reloading it.
>> >>
>> >>         Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> 2011)
>> >>
>> >> -----Original Message-----
>> >> From: Action Request System discussion list(ARSList) [mailto:
>> >> arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II
>> >> Sent: Thursday, February 12, 2015 8:06 AM
>> >> To: arslist@ARSLIST.ORG
>> >> Subject: Re: USER_CACHE Problems
>> >>
>> >> **
>> >> Gave it a shot....no joy in mudville I'm afraid....  Thanks for the
idea
>> >> though!
>> >>
>> >> -----Original Message-----
>> >> On Thu, Feb 12, 2015 at 8:37 AM, Karthik  wrote:
>> >> **
>> >> Deleting and recreating their user record works?
>> >>
>> >> - Karthik
>> >>
>> >> -----Original Message-----
>> >> On 12 February 2015 at 18:29, Warren R. Baltimore II  wrote:
>> >> **
>> >> ARS 6.3
>> >> Oracle 10x
>> >> Sun OS 5.1
>> >>
>> >> A little help please!
>> >>
>> >> My legacy server is showing an issue that I have not dealt with
before.
>> >>
>> >> A couple of days, my database started showing some problems related to
>> >> tablespace.  This caused a bunch of weird issues.  The tablespace
issue
>> has
>> >> been resolved.  A couple of my users had closed their clients during
>> that
>> >> time and when they came back received the error message that they were
>> >> still logged on and would they like the other session closed.  They
>> would
>> >> answer in the affirmative, but when they would then log back on, they
>> would
>> >> get the same message.  I then tried to kick them off from the admin
>> tool,
>> >> but they would still get the message.
>> >>
>> >> I then triggered (I think) a re-cache by adding a display only
checkbox
>> >> and then doing a modify all against all users with that checkbox
>> checked.
>> >> I did this based on kbase articles that talked about this type of
issue.
>> >> However I still have a couple of users who are getting this message.
>> >>
>> >> User logs don't show a need for them to be released, in fact they just
>> >> show them logging in as normal.
>> >>
>> >> They are able to work by just closing (using the x to close the
window).
>> >> None the less, it is very annoying!
>> >>
>> >> Any ideas?
>> >>
>> >> Thanks!
>> >>
>> >> --
>> >> Warren R. Baltimore II
>> >> Remedy Developer
>> >> 410-533-5367
>>
>>
>>
>>
>>
____________________________________________________________________________
___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> "Where the Answers Are, and have been for 20 years"
>>
>
>
____________________________________________________________________________
___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

_ARSlist: "Where the Answers Are" and have been for 20 years_ 


_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to