Re: USER_CACHE Problems
For those times you are Tomb Raiding I would like to plug LJ's parsing tools: http://remedylegacy.com/tools. I cannot believe how much these have change my troubleshooting life. The combination of these tools and leaving server API/SQL/Filter/ESC logging on full time to a single file has resulted in finding the root of complex issue again and again. I can typically weed through gigabytes of logs and parse (and reparse) it down to just the interesting section in minutes. Jason On Tue, Feb 17, 2015 at 5:30 AM, Warren R. Baltimore II < warrenbaltim...@gmail.com> wrote: > ** > That's the beauty of an inherited system! You get to play Tomb Raider > everytime you run into a problem. This one was just plain weird because I > NEVER would have thought to look for workflow. Like Doug said earlier, > this isn't supposed to be an issue at that level! > > Soon this thing is going to be retired > > I will not shed a tear! > > On Mon, Feb 16, 2015 at 4:41 PM, Joe D'Souza wrote: > >> ** >> >> Mine too. It brings out my “Sheldon-ism” when I see some developers leave >> a fully developed system with the default note, warning and error number >> which makes it that much more harder to trace the cause of these messages. >> >> >> >> I have an approach with those numbers that tells me 1) if it was a filter >> or active link, 2) which form it might be originating from (which is very >> useful if the error is from some other forms happening from a push or set >> field to or from some other form) and 3) identifies it right off the bat if >> it’s a note, warning or error (as some users have a difficult time >> reporting these messages accurately). >> >> >> >> Just that number should be able to convey information such as this and >> other information if possible. Sometimes it may need additional info such >> as what kind of a client it is coming from, etc. So depending on your need, >> it is a nice idea to design message numbers that tell you a brief story. >> >> >> >> My 2 cents. >> >> >> >> Joe >> >> >> ------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Rick Westbrock >> *Sent:* Monday, February 16, 2015 10:08 AM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> This is a great example of why I always create unique custom error >> messages and store them in a form so that I can easily reference them. One >> of my pet peeves is re-using message numbers (especially the default value) >> for multiple unrelated functions. >> >> >> >> -Rick >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Mueller, Doug >> *Sent:* Saturday, February 14, 2015 1:12 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> ** >> >> Warren, >> >> >> >> Just to confirm behavior. >> >> >> >> The AR System does not record anywhere in the DB where you are logged in >> from. So, there is no relationship here to USER_CACHE or anything else. >> There is an in memory list of connections. That in memory list is what >> holds where you are connected from and would complain if it was different >> systems. No amount of reloading or resetting or reviewing or anything of >> the user_cache table would have made any difference – and you found that >> out. >> >> >> >> IF the error was being caused by something within Remedy itself, >> restarting the system would have cleared this in memory list and corrected >> the problem. >> >> >> >> Nowhere in our logic do we have workflow that records where a user is >> logging in from. The logic you found is custom logic as you suspected. It >> looks like whoever implemented it coopted our error message and issued the >> same error as we would issue. >> >> >> >> I am glad that you found the custom logic causing the problem in this >> situation. >> >> >> >> Doug Mueller >> >> >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:arslist@ARSLIST.ORG ] *On Behalf Of *Warren >> R. Baltimore II >> *Sent:* Friday, February 13, 2015 10:00 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> ** >> >> Well You guys all
Re: USER_CACHE Problems
That's the beauty of an inherited system! You get to play Tomb Raider everytime you run into a problem. This one was just plain weird because I NEVER would have thought to look for workflow. Like Doug said earlier, this isn't supposed to be an issue at that level! Soon this thing is going to be retired I will not shed a tear! On Mon, Feb 16, 2015 at 4:41 PM, Joe D'Souza wrote: > ** > > Mine too. It brings out my “Sheldon-ism” when I see some developers leave > a fully developed system with the default note, warning and error number > which makes it that much more harder to trace the cause of these messages. > > > > I have an approach with those numbers that tells me 1) if it was a filter > or active link, 2) which form it might be originating from (which is very > useful if the error is from some other forms happening from a push or set > field to or from some other form) and 3) identifies it right off the bat if > it’s a note, warning or error (as some users have a difficult time > reporting these messages accurately). > > > > Just that number should be able to convey information such as this and > other information if possible. Sometimes it may need additional info such > as what kind of a client it is coming from, etc. So depending on your need, > it is a nice idea to design message numbers that tell you a brief story. > > > > My 2 cents. > > > > Joe > > > -- > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Rick Westbrock > *Sent:* Monday, February 16, 2015 10:08 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: USER_CACHE Problems > > > > This is a great example of why I always create unique custom error > messages and store them in a form so that I can easily reference them. One > of my pet peeves is re-using message numbers (especially the default value) > for multiple unrelated functions. > > > > -Rick > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Mueller, Doug > *Sent:* Saturday, February 14, 2015 1:12 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: USER_CACHE Problems > > > > ** > > Warren, > > > > Just to confirm behavior. > > > > The AR System does not record anywhere in the DB where you are logged in > from. So, there is no relationship here to USER_CACHE or anything else. > There is an in memory list of connections. That in memory list is what > holds where you are connected from and would complain if it was different > systems. No amount of reloading or resetting or reviewing or anything of > the user_cache table would have made any difference – and you found that > out. > > > > IF the error was being caused by something within Remedy itself, > restarting the system would have cleared this in memory list and corrected > the problem. > > > > Nowhere in our logic do we have workflow that records where a user is > logging in from. The logic you found is custom logic as you suspected. It > looks like whoever implemented it coopted our error message and issued the > same error as we would issue. > > > > I am glad that you found the custom logic causing the problem in this > situation. > > > > Doug Mueller > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:arslist@ARSLIST.ORG ] *On Behalf Of *Warren > R. Baltimore II > *Sent:* Friday, February 13, 2015 10:00 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: USER_CACHE Problems > > > > ** > > 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 eve
Re: USER_CACHE Problems
Mine too. It brings out my "Sheldon-ism" when I see some developers leave a fully developed system with the default note, warning and error number which makes it that much more harder to trace the cause of these messages. I have an approach with those numbers that tells me 1) if it was a filter or active link, 2) which form it might be originating from (which is very useful if the error is from some other forms happening from a push or set field to or from some other form) and 3) identifies it right off the bat if it's a note, warning or error (as some users have a difficult time reporting these messages accurately). Just that number should be able to convey information such as this and other information if possible. Sometimes it may need additional info such as what kind of a client it is coming from, etc. So depending on your need, it is a nice idea to design message numbers that tell you a brief story. My 2 cents. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Monday, February 16, 2015 10:08 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems This is a great example of why I always create unique custom error messages and store them in a form so that I can easily reference them. One of my pet peeves is re-using message numbers (especially the default value) for multiple unrelated functions. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Saturday, February 14, 2015 1:12 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** Warren, Just to confirm behavior. The AR System does not record anywhere in the DB where you are logged in from. So, there is no relationship here to USER_CACHE or anything else. There is an in memory list of connections. That in memory list is what holds where you are connected from and would complain if it was different systems. No amount of reloading or resetting or reviewing or anything of the user_cache table would have made any difference - and you found that out. IF the error was being caused by something within Remedy itself, restarting the system would have cleared this in memory list and corrected the problem. Nowhere in our logic do we have workflow that records where a user is logging in from. The logic you found is custom logic as you suspected. It looks like whoever implemented it coopted our error message and issued the same error as we would issue. I am glad that you found the custom logic causing the problem in this situation. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Friday, February 13, 2015 10:00 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** 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 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 . Doe
Re: USER_CACHE Problems
This is a great example of why I always create unique custom error messages and store them in a form so that I can easily reference them. One of my pet peeves is re-using message numbers (especially the default value) for multiple unrelated functions. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Saturday, February 14, 2015 1:12 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** Warren, Just to confirm behavior. The AR System does not record anywhere in the DB where you are logged in from. So, there is no relationship here to USER_CACHE or anything else. There is an in memory list of connections. That in memory list is what holds where you are connected from and would complain if it was different systems. No amount of reloading or resetting or reviewing or anything of the user_cache table would have made any difference – and you found that out. IF the error was being caused by something within Remedy itself, restarting the system would have cleared this in memory list and corrected the problem. Nowhere in our logic do we have workflow that records where a user is logging in from. The logic you found is custom logic as you suspected. It looks like whoever implemented it coopted our error message and issued the same error as we would issue. I am glad that you found the custom logic causing the problem in this situation. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Friday, February 13, 2015 10:00 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: USER_CACHE Problems ** 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 mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Grooms, Frederick W Sent: Friday, February 13, 2015 11:53 AM To: arslist@ARSLIST.ORG<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Warren R. Baltimore II Sent: Friday, February 13, 2015 10:47 AM To: arslist@ARSLIST.ORG<mailto: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 t
Re: USER_CACHE Problems
Warren, Just to confirm behavior. The AR System does not record anywhere in the DB where you are logged in from. So, there is no relationship here to USER_CACHE or anything else. There is an in memory list of connections. That in memory list is what holds where you are connected from and would complain if it was different systems. No amount of reloading or resetting or reviewing or anything of the user_cache table would have made any difference – and you found that out. IF the error was being caused by something within Remedy itself, restarting the system would have cleared this in memory list and corrected the problem. Nowhere in our logic do we have workflow that records where a user is logging in from. The logic you found is custom logic as you suspected. It looks like whoever implemented it coopted our error message and issued the same error as we would issue. I am glad that you found the custom logic causing the problem in this situation. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Friday, February 13, 2015 10:00 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** 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 mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Grooms, Frederick W Sent: Friday, February 13, 2015 11:53 AM To: arslist@ARSLIST.ORG<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Warren R. Baltimore II Sent: Friday, February 13, 2015 10:47 AM To: arslist@ARSLIST.ORG<mailto: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!
Re: USER_CACHE Problems
Hi Warren, What is the name of the form from which you deleted the user entries, so that the user was able to login with out the error? ...Nayeem Sent from my Windows Phone From: Warren R. Baltimore II<mailto:warrenbaltim...@gmail.com> Sent: 14-02-2015 00:46 To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: USER_CACHE Problems And there was in fact an active link that first checked if the user was in the Admin group. On Fri, Feb 13, 2015 at 1:25 PM, Joe D'Souza wrote: > ** > > There would be one subtle but important difference when an error such as > that comes out of workflow.. > > > > It would happen even with an Administrative user, UNLESS in the Run If > condition, there is a check for group membership or if you have used the > results of APPLICATION-CONFIRM-GROUP to exclude certain groups from running > that workflow. > > > > With the out of the box message, you would not get that error with > Administrative users having a Fixed License. > > > > Cheers > > > > Joe > > > -- > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Warren R. Baltimore II > *Sent:* Friday, February 13, 2015 1:00 PM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: USER_CACHE Problems > > > > ** > > 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 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.
Re: USER_CACHE Problems
And there was in fact an active link that first checked if the user was in the Admin group. On Fri, Feb 13, 2015 at 1:25 PM, Joe D'Souza wrote: > ** > > There would be one subtle but important difference when an error such as > that comes out of workflow.. > > > > It would happen even with an Administrative user, UNLESS in the Run If > condition, there is a check for group membership or if you have used the > results of APPLICATION-CONFIRM-GROUP to exclude certain groups from running > that workflow. > > > > With the out of the box message, you would not get that error with > Administrative users having a Fixed License. > > > > Cheers > > > > Joe > > > -- > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Warren R. Baltimore II > *Sent:* Friday, February 13, 2015 1:00 PM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: USER_CACHE Problems > > > > ** > > 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 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
Re: USER_CACHE Problems
There would be one subtle but important difference when an error such as that comes out of workflow.. It would happen even with an Administrative user, UNLESS in the Run If condition, there is a check for group membership or if you have used the results of APPLICATION-CONFIRM-GROUP to exclude certain groups from running that workflow. With the out of the box message, you would not get that error with Administrative users having a Fixed License. Cheers Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Friday, February 13, 2015 1:00 PM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** 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 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
Re: USER_CACHE Problems
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 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
Re: USER_CACHE Problems
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 1500 -n loginname -s server -g
Re: USER_CACHE Problems
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 < warrenbaltim...@gmail.com> 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 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 1500 -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 x -s ServerN
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<mailto:bgoralc...@gmail.com> > > On Thu, Feb 12, 2015 at 1:04 PM, Grooms, Frederick W < > frederick.w.gro...@xo.com<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Misi >> Mladoniczky >> Sent: Thursday, February 12, 2015 11:56 AM >> To: arslist@ARSLIST.ORG<mailto: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 1500 -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 x -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|Lic
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 1500 -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 x -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. > &
Re: USER_CACHE Problems
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 1500 -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 x -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 >&
Re: USER_CACHE Problems
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" 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) SHORTAUTHSTRINGVARCHAR2(255) LONGAUTHSTRING CLOB LICENSEPOOLVARCHAR2(30) EMAIL VARCHAR2(255) NOTIFYMECH NUMBER(15) LICTYPENUMBER(15) LICTYPEFTEXT NUMBER(15) LICTYPERESERV1 NUMBER(15) LICTYPEAPP CLOB TIMESTAMP NUMBER(15) VALIDATEKEYVARCHAR2(30) SHORTGROUP VARCHAR2(255) LONGGROUP CLOB SHORTCOMPGROUP VARCHAR2(255) LONGCOMPGROUP CLOB FIXEDLICCHANGE CLOB BADPWD NUMBER(15) BADPWDTOTALNUMBER(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 1500 -n loginname -s server -g "1;" -l1 -p passwd >> >>
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" 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) > SHORTAUTHSTRINGVARCHAR2(255) > LONGAUTHSTRING CLOB > LICENSEPOOLVARCHAR2(30) > EMAIL VARCHAR2(255) > NOTIFYMECH NUMBER(15) > LICTYPENUMBER(15) > LICTYPEFTEXT NUMBER(15) > LICTYPERESERV1 NUMBER(15) > LICTYPEAPP CLOB > TIMESTAMP NUMBER(15) > VALIDATEKEYVARCHAR2(30) > SHORTGROUP VARCHAR2(255) > LONGGROUP CLOB > SHORTCOMPGROUP VARCHAR2(255) > LONGCOMPGROUP CLOB > FIXEDLICCHANGE CLOB > BADPWD NUMBER(15) > BADPWDTOTALNUMBER(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 1500 -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
Re: USER_CACHE Problems
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) SHORTAUTHSTRINGVARCHAR2(255) LONGAUTHSTRING CLOB LICENSEPOOLVARCHAR2(30) EMAIL VARCHAR2(255) NOTIFYMECH NUMBER(15) LICTYPENUMBER(15) LICTYPEFTEXT NUMBER(15) LICTYPERESERV1 NUMBER(15) LICTYPEAPP CLOB TIMESTAMP NUMBER(15) VALIDATEKEYVARCHAR2(30) SHORTGROUP VARCHAR2(255) LONGGROUP CLOB SHORTCOMPGROUP VARCHAR2(255) LONGCOMPGROUP CLOB FIXEDLICCHANGE CLOB BADPWD NUMBER(15) BADPWDTOTALNUMBER(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 1500 -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 x -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
Re: USER_CACHE Problems
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 1500 -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 x -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 h
Re: USER_CACHE Problems
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 1500 -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 x -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 shotno joy in mudville I'm afraid Thanks for the idea >> though! >> >> -Original Message- >> On Thu, Feb 12, 2015 at 8:37 AM, Karthik
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 1500 -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 x -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. > 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? > > > > > On Thu, Feb 12, 2015 at 9:26 AM, Grooms, Frederick W < > frederick.w.gro...@xo.com> 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 shotno 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
Re: USER_CACHE Problems
Not mid-tier I'm afraid. They are using a Windows User Client (ARS 6.3 ITSM 5.5) I've had the user clear the local cache. Nothing seems to work. And I can't get the darn arreload to run. It's very frustrating! On Thu, Feb 12, 2015 at 12:02 PM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS wrote: > Could it be a simple case of clearing the their browser cache after > clearing the MidTier cache? Make sure Preserver Favorite website data is > NOT checked in IE, and then clear the browsing history. > > Lisa > > -Original Message- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W > Sent: Thursday, February 12, 2015 11:08 AM > To: arslist@ARSLIST.ORG > Subject: Re: USER_CACHE Problems > > ** > > For Solaris I have always had to use the “export VARIABLE=VALUE” method > in order for later applications to see the data in the environment (but > that is probably just me and script files) > > > > As long as there are no spaces or special characters in the values of the > arreload try not using the quotes > > > > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II > Sent: Thursday, February 12, 2015 9:30 AM > To: arslist@ARSLIST.ORG > Subject: Re: USER_CACHE Problems > > > > ** > > Disable-Admin-Ops is set to F > > I set the port using: set ARTCPPORT [portid] > > > > It's not a server group > > > > -Original Message- > > On Thu, Feb 12, 2015 at 10:04 AM, Grooms, Frederick W wrote: > > Are you in a server group or have the config entry > Disable-Admin-Ops turned on? > > Are you using a specific port for your server? If so set the > ARTCPPORT environment variable first > export ARTCPPORT=123456 > > Fred > > -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:41 AM > To: arslist@ARSLIST.ORG > Subject: Re: USER_CACHE Problems > > ** > 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
Re: USER_CACHE Problems
Could it be a simple case of clearing the their browser cache after clearing
the MidTier cache? Make sure Preserver Favorite website data is NOT checked in
IE, and then clear the browsing history.
Lisa
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Thursday, February 12, 2015 11:08 AM
To: arslist@ARSLIST.ORG
Subject: Re: USER_CACHE Problems
**
For Solaris I have always had to use the “export VARIABLE=VALUE” method in
order for later applications to see the data in the environment (but that is
probably just me and script files)
As long as there are no spaces or special characters in the values of the
arreload try not using the quotes
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II
Sent: Thursday, February 12, 2015 9:30 AM
To: arslist@ARSLIST.ORG
Subject: Re: USER_CACHE Problems
**
Disable-Admin-Ops is set to F
I set the port using: set ARTCPPORT [portid]
It's not a server group
-Original Message-
On Thu, Feb 12, 2015 at 10:04 AM, Grooms, Frederick W wrote:
Are you in a server group or have the config entry Disable-Admin-Ops
turned on?
Are you using a specific port for your server? If so set the
ARTCPPORT environment variable first
export ARTCPPORT=123456
Fred
-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:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: USER_CACHE Problems
**
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
<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 shotno joy in mudville I'm afraid Thanks for the
idea though!
-Original Message-
On Thu, Feb 12, 2015 at 8:37 AM, Karthik wrote:
**
Re: USER_CACHE Problems
For Solaris I have always had to use the “export VARIABLE=VALUE” method in order for later applications to see the data in the environment (but that is probably just me and script files) As long as there are no spaces or special characters in the values of the arreload try not using the quotes From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Thursday, February 12, 2015 9:30 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** Disable-Admin-Ops is set to F I set the port using: set ARTCPPORT [portid] It's not a server group -Original Message- On Thu, Feb 12, 2015 at 10:04 AM, Grooms, Frederick W wrote: Are you in a server group or have the config entry Disable-Admin-Ops turned on? Are you using a specific port for your server? If so set the ARTCPPORT environment variable first export ARTCPPORT=123456 Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Warren R. Baltimore II Sent: Thursday, February 12, 2015 8:41 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: USER_CACHE Problems ** 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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Misi Mladoniczky Sent: Thursday, February 12, 2015 7:58 AM To: arslist@ARSLIST.ORG<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Warren R. Baltimore II Sent: Thursday, February 12, 2015 8:06 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: USER_CACHE Problems ** Gave it a shotno 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 checkb
Re: USER_CACHE Problems
I tried that Mark by utilizing a display only check box on the form. I figured that would workmaybe not? I also tried giving the user Administrator level privileges. As I expected, the problem went away. But the moment I took them back, the problem was back. If he just clicks the x in the warning box, he can work. The funny thing is that it pops back up when he opens his helpdesk case form. I suspect this may have something to do with the Helpdesk license assigned to him. Just a guess though. On Thu, Feb 12, 2015 at 10:26 AM, Walters, Mark wrote: > If you're having problems with arreload you can force a reload of the > user_cache table by doing a Modify All on all of the records in the User > form - select them all and change a field such as the Creator/Submitter - > one that you're not worried about. This will cause a delete from/insert > into the user_cache table for each user. > > Mark > > -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:41 AM > To: arslist@ARSLIST.ORG > Subject: Re: USER_CACHE Problems > > ** > 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 shotno 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 t
Re: USER_CACHE Problems
Disable-Admin-Ops is set to F I set the port using: set ARTCPPORT [portid] It's not a server group On Thu, Feb 12, 2015 at 10:04 AM, Grooms, Frederick W < frederick.w.gro...@xo.com> wrote: > Are you in a server group or have the config entry Disable-Admin-Ops > turned on? > > Are you using a specific port for your server? If so set the ARTCPPORT > environment variable first > export ARTCPPORT=123456 > > Fred > > -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:41 AM > To: arslist@ARSLIST.ORG > Subject: Re: USER_CACHE Problems > > ** > 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 shotno 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 m
Re: USER_CACHE Problems
If you're having problems with arreload you can force a reload of the user_cache table by doing a Modify All on all of the records in the User form - select them all and change a field such as the Creator/Submitter - one that you're not worried about. This will cause a delete from/insert into the user_cache table for each user. Mark -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:41 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** 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 shotno 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" -- Warren R. Baltimore II Remedy Developer 410-533-5367 _ARSlist: "Where the Answers Are" and have been for 20 year
Re: USER_CACHE Problems
Another thing that I delete when weird things happen is the AR System User Preference record. Julia James From: Tommy Morris To: arslist@ARSLIST.ORG Date: 02/12/2015 08:51 AM Subject:Re: USER_CACHE Problems Sent by:"Action Request System discussion list(ARSList)" ** Have you tried to delete the local user cache on their machine? When odd things occur on my users’ clients I just have them delete the local user cache and it resolves those anomalies. From: Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Thursday, February 12, 2015 8:41 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** 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? On Thu, Feb 12, 2015 at 9:26 AM, Grooms, Frederick W < frederick.w.gro...@xo.com> 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 shotno 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 yea
Re: USER_CACHE Problems
Are you in a server group or have the config entry Disable-Admin-Ops turned on? Are you using a specific port for your server? If so set the ARTCPPORT environment variable first export ARTCPPORT=123456 Fred -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:41 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** 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 shotno 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" -- 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"
Re: USER_CACHE Problems
Have you tried to delete the local user cache on their machine? When odd things occur on my users’ clients I just have them delete the local user cache and it resolves those anomalies. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Thursday, February 12, 2015 8:41 AM To: arslist@ARSLIST.ORG Subject: Re: USER_CACHE Problems ** 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? On Thu, Feb 12, 2015 at 9:26 AM, Grooms, Frederick W mailto:frederick.w.gro...@xo.com>> 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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Misi Mladoniczky Sent: Thursday, February 12, 2015 7:58 AM To: arslist@ARSLIST.ORG<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Warren R. Baltimore II Sent: Thursday, February 12, 2015 8:06 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: USER_CACHE Problems ** Gave it a shotno 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<http://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 2
Re: USER_CACHE Problems
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? On Thu, Feb 12, 2015 at 9:26 AM, Grooms, Frederick W < frederick.w.gro...@xo.com> 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 shotno 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" > -- 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"
Re: USER_CACHE Problems
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 shotno 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"
Re: USER_CACHE Problems
I'll give it a shot It's been awhile since I've tried one of these triggers On Thu, Feb 12, 2015 at 8:58 AM, Misi Mladoniczky wrote: > 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) > > 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. > > > Deleting and recreating their user record works? > > > > - Karthik > > > > On 12 February 2015 at 18:29, Warren R. Baltimore II < > > warrenbaltim...@gmail.com> 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_ > > > > > > > > > > -- > > - Karthik > > > > > ___ > > 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: USER_CACHE Problems
Gave it a shotno joy in mudville I'm afraid Thanks for the idea though! On Thu, Feb 12, 2015 at 8:37 AM, Karthik wrote: > ** > Deleting and recreating their user record works? > > - Karthik > > On 12 February 2015 at 18:29, Warren R. Baltimore II < > warrenbaltim...@gmail.com> 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_ > > > > > -- > - Karthik > _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"
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) 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. > Deleting and recreating their user record works? > > - Karthik > > On 12 February 2015 at 18:29, Warren R. Baltimore II < > warrenbaltim...@gmail.com> 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_ > > > > > -- > - Karthik > > ___ > 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"
Re: USER_CACHE Problems
Deleting and recreating their user record works? - Karthik On 12 February 2015 at 18:29, Warren R. Baltimore II < warrenbaltim...@gmail.com> 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_ -- - Karthik ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
USER_CACHE Problems
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"
