Hi,
An admin can login from multiple machines, that is why the error disappears
when changing to admin.
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"
