Well.... You guys all rock. But it turned out to be workflow related! I don't know if this is out of the box, but there are some active links that fire when a person first logs in to my system and checks if they logged in from some where else. My suspicion is that it is custom and related to the addition of a government warning that pops up when a user first logs in. This workflow checks a form to see if a person is still logged in. There is some workflow that is supposed to delete the form entry when you log out, but because of the initial dbase issues I was having, that didn't happen for these 2 users (supposition on my part). This is separate from whatever process Remedy installed to check the licensing requirements, but it gives the same error message when tripped! Once I deleted the 2 users entries from this form, they were able to log in without issue (without the admin privs). Problem solved.
I've been here for 6 years almost, and this is the first time I've run into this! Thank you again for everyone's kind suggestions. I now know more about how Remedy cache's users then I ever thought possible! Take care! Warren On Fri, Feb 13, 2015 at 12:22 PM, Joe D'Souza <jdso...@shyle.net> wrote: > ** > > Great point.. > > > > With a recent Windows update, my outlook client using pop/smtp to connect > to my mail server, would not connect to the incoming mail server. > > > > Ptroblem turned out to be outlook no longer likes IPv6 to be enabled at > the time of an initial connect. So I have to disable IPv6, have outlook > connect to the incoming mail server, and then re-enable IPv6 after which it > works fine. This happens everytime I restart my machine and seems to be a > flaw with one of the updates. > > > > I know that is not the same issue as you, but could be a related issue? > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Grooms, Frederick W > *Sent:* Friday, February 13, 2015 11:53 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: USER_CACHE Problems > > > > Here is an off-hand thought … Does the machine the user is on have > multiple network cards? Could it be some weird multi-home network issue > (one transaction the sever see the connection from IP a.b.c.x and another > from IP a.b.c.y)? > > > > Fred > > > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Warren R. Baltimore II > *Sent:* Friday, February 13, 2015 10:47 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: USER_CACHE Problems > > > > ** > > Good morning/afternoon/evening/night my fellow listers! > > First off, I apologize for not responding sooner to everyone's kind offer > of support. It was a bit chilly this morning here in Maryland, so my kids > schools went to a 2 hour delay to prevent the little darlings from having > to wear gloves and a hat (insert sarcastic eye roll here)! > > The issue is not spawned by a user still being logged on to a separate > machine. In fact, I had them log out, go to another machine, and then come > back and log back in. They got the message, and the user.log reflected the > other machine. But even after they are logged out from that machine and > they just focus on the one. It keeps happening. That's why I gave him the > admin license just so he wouldn't keep receiving the message. > > I've just finished working with my 2 problem children. I've taken quite a > bit of logging and I am hoping I can track down where Remedy tracks this > info and fix it there. I'll let you know what I find. Might be kind of > interesting! > > Take care for now! > > Happy Friday! > > Warren > > > > > > On Fri, Feb 13, 2015 at 8:32 AM, Misi Mladoniczky wrote: > > 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 > > > > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: > "Where the Answers Are" and have been for 20 years_ -- 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"
