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"