Warren,
When the user went to machine 2, did they still get the warning?

On Fri, Feb 13, 2015 at 9:46 AM, Warren R. Baltimore II <
[email protected]> wrote:

> **
> 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 <[email protected]> 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 [email protected]
>> >
>> > On Thu, Feb 12, 2015 at 1:04 PM, Grooms, Frederick W <
>> > [email protected]> 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:
>> >> [email protected]] On Behalf Of Misi Mladoniczky
>> >> Sent: Thursday, February 12, 2015 11:56 AM
>> >> To: [email protected]
>> >> 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:
>> >> >> [email protected]] On Behalf Of Misi Mladoniczky
>> >> >> Sent: Thursday, February 12, 2015 7:58 AM
>> >> >> To: [email protected]
>> >> >> 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:
>> >> >> [email protected]] On Behalf Of Warren R. Baltimore II
>> >> >> Sent: Thursday, February 12, 2015 8:06 AM
>> >> >> To: [email protected]
>> >> >> 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"
>>
>
>
>
> --
> Warren R. Baltimore II
> Remedy Developer
> 410-533-5367
>  _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