Re: Read-Only Field Vulnerability

[Jonathan Young]

Thank you for your comments. I have slightly different outlook with regard to 
data security. I understand why the ars design means that the ui is vulnerable.

Thanks 
Jon


 Jason Miller wrote 

>** 
>
>I agree with LJ and BMC. Read Only functionality is not meant to be a data 
>security enforcing measure. It is a UI feature.
>
>
>True permissions and enforcing workflow is going to be even more critical 
>assuming a very easy to use RESTful web service is right around the corner. 
>Any user can simply install Postman and have their way with your data easier 
>that ever before.
>
>
>That makes me wonder if maybe there should be an option to disable RESTful web 
>services?  Maybe shutting down Jetty is sufficient enough? This will allow 
>organizations perform a security review prior to enabling this powerful 
>feature.
>
>
>Jason
>
>
>On Tue, Apr 21, 2015 at 1:00 PM, LJ LongWing  wrote:
>
>** 
>
>Jon,
>
>I unfortunately must agree with BMC on this oneif they have change 
>permission, they have change permission.  There are any number of ways to 
>update the data without using Mid-Tierso, if they truly should not be 
>modifying the data, you will need to either enforce it via permissions (give 
>ability to submit, but not ability to change), or, as you stated, build Filter 
>based workflow to lock the fields down from a change perspective.
>
>
>On Tue, Apr 21, 2015 at 1:29 PM, Jon Young  
>wrote:
>
>** 
>
>Hi Listers
>
> 
>
>Sorry if this has been discussed recently before;  I’ve got the tricky task of 
>explaining to clients that Read-Only fields can be modified by users by a 
>simple hack.  I wondered if any of your employers/ clients see this as a data 
>security risk and if you have any solutions for this?
>
> 
>
>Issue:
>
>-
>
>Sometimes, we want users to be able to modify a field so we give that field a 
>Change permission, and give the user that permission.  For example, we want a 
>user to enter a short description on a Change Request.
>
> 
>
>Later, we don’t want the user to modify that field.  For example, when a 
>Change Request has been approved.  We don’t really want the user to change 
>details.  To prevent this, we make the field Read-Only.
>
> 
>
>The vulnerability is that even though that field is Read-Only they can modify 
>the field using tools included in web browsers.  If our users are external to 
>our organisation we can not control what browsers they use.
>
> 
>
>So this is only an issue is a user is deliberately trying to misuse the system 
>– the sort or users we’d like to take security precautions against.
>
> 
>
>BMC’s Stance
>
>-
>
>BMC, the lead architect, has stated that Read-Only fields are a display 
>characteristic to assist the user interface.
>
> 
>
>Solutions
>
>-
>
>We could crate filters that fire when we know a fields are read-only for the 
>current user to check the TR value and prevent the commit.  This is a lot of 
>overhead for fixing this vulnerability in BMC’s ITSM application, let alone 
>customisations and bespoke applications.
>
> 
>
>Alternatively, we could audit the fields.  It doesn’t prevent the issue but 
>would at least help to check if the field was changed.
>
> 
>
>As BMC don’t see this as a bug or a vulnerability my hopes of mid tier/ server 
>fix for this are somewhat muted!
>
> 
>
>Thanks
>
>Jon
>
>_ARSlist: "Where the Answers Are" and have been for 20 years_ 
>
>
>_ARSlist: "Where the Answers Are" and have been for 20 years_ 
>
>
>_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: Read-Only Field Vulnerability

[Jason Miller]

I agree with LJ and BMC. Read Only functionality is not meant to be a data
security enforcing measure. It is a UI feature.

True permissions and enforcing workflow is going to be even more critical
assuming a very easy to use RESTful web service is right around the corner.
Any user can simply install Postman and have their way with your data
easier that ever before.

That makes me wonder if maybe there should be an option to disable RESTful
web services?  Maybe shutting down Jetty is sufficient enough? This will
allow organizations perform a security review prior to enabling this
powerful feature.

Jason

On Tue, Apr 21, 2015 at 1:00 PM, LJ LongWing  wrote:

> **
> Jon,
> I unfortunately must agree with BMC on this oneif they have change
> permission, they have change permission.  There are any number of ways to
> update the data without using Mid-Tierso, if they truly should not be
> modifying the data, you will need to either enforce it via permissions
> (give ability to submit, but not ability to change), or, as you stated,
> build Filter based workflow to lock the fields down from a change
> perspective.
>
> On Tue, Apr 21, 2015 at 1:29 PM, Jon Young  > wrote:
>
>> **
>> Hi Listers
>>
>> Sorry if this has been discussed recently before;  I’ve got the tricky
>> task of explaining to clients that Read-Only fields can be modified by
>> users by a simple hack.  I wondered if any of your employers/ clients see
>> this as a data security risk and if you have any solutions for this?
>>
>> Issue:
>> -
>> Sometimes, we want users to be able to modify a field so we give that
>> field a Change permission, and give the user that permission.  For example,
>> we want a user to enter a short description on a Change Request.
>>
>> Later, we don’t want the user to modify that field.  For example, when a
>> Change Request has been approved.  We don’t really want the user to change
>> details.  To prevent this, we make the field Read-Only.
>>
>> The vulnerability is that even though that field is Read-Only they can
>> modify the field using tools included in web browsers.  If our users are
>> external to our organisation we can not control what browsers they use.
>>
>> So this is only an issue is a user is deliberately trying to misuse the
>> system – the sort or users we’d like to take security precautions against.
>>
>> BMC’s Stance
>> -
>> BMC, the lead architect, has stated that Read-Only fields are a display
>> characteristic to assist the user interface.
>>
>> Solutions
>> -
>> We could crate filters that fire when we know a fields are read-only for
>> the current user to check the TR value and prevent the commit.  This is a
>> lot of overhead for fixing this vulnerability in BMC’s ITSM application,
>> let alone customisations and bespoke applications.
>>
>> Alternatively, we could audit the fields.  It doesn’t prevent the issue
>> but would at least help to check if the field was changed.
>>
>> As BMC don’t see this as a bug or a vulnerability my hopes of mid tier/
>> server fix for this are somewhat muted!
>>
>> Thanks
>> Jon
>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
>
> _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: Atrium SSO with load balancer

[Grunder, John F]

Thanks for the reply.  Not sure what the LB team’s reasoning is, but they seem 
very reluctant to allow https redirect.  It helps my case to let them know 
that’s how it’s working elsewhere.

John F. Grunder
Acuity, Inc.
CA/CST Remedy Team
Office of Consular Systems and Technology | Quality Management Branch
U.S. Department of State | Bureau of Consular Affairs
grunde...@state.gov |  
john.grun...@myacuity.com
cell  |  703-887-7167

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jayesh
Sent: Tuesday, April 21, 2015 2:39 PM
To: arslist@ARSLIST.ORG
Subject: Re: Atrium SSO with load balancer

**
Is there a specific reason for redirecting it to http traffic and not going 
with https? With https its working smooth for me.

We have both the sso nodes running on https. But the F5 LB SAN  signed  
certificate handles all the encryption.

This email is UNCLASSIFIED.




From: Grunder, John F
Sent: ‎21-‎04-‎2015 11:11 PM
To: 
arslist@ARSLIST.ORG
Subject: Atrium SSO with load balancer
**
We are attempting to configure Atrium SSO (9.0, latest patch) with ARS 8.1 in a 
complete HA environment.  We already have the load balancers configured for 
MidTier and ARS, but are having issues with the configuration for Atrium SSO.  
We are using F5 load balancers and the team responsible for the load balancers 
here wishes to have the F5 handle all SSL traffic, and redirect in http only to 
the SSO nodes.  However, we cannot get SSO to work with only http…attempts to 
reconfigure Tomcat to serve the page have resulted in failures (and forced a 
reinstall of the Atrium SSO product).  The F5 team rightly point out that this 
would mean that first the F5 encrypts, then the server encrypts again, which is 
inefficient.  Does anyone have SSO setup in a similar config, and if so, can 
you provide any information as to how to handle the redirect, and/or how to 
configure Atrium SSO to successfully handle non-https traffic?

Thanks in advance for any thoughts.

John F. Grunder


This email is UNCLASSIFIED.


_ARSlist: "Where the Answers Are" and have been for 20 years_
_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: Read-Only Field Vulnerability

[LJ LongWing]

Jon,
I unfortunately must agree with BMC on this oneif they have change
permission, they have change permission.  There are any number of ways to
update the data without using Mid-Tierso, if they truly should not be
modifying the data, you will need to either enforce it via permissions
(give ability to submit, but not ability to change), or, as you stated,
build Filter based workflow to lock the fields down from a change
perspective.

On Tue, Apr 21, 2015 at 1:29 PM, Jon Young 
wrote:

> **
> Hi Listers
>
> Sorry if this has been discussed recently before;  I’ve got the tricky
> task of explaining to clients that Read-Only fields can be modified by
> users by a simple hack.  I wondered if any of your employers/ clients see
> this as a data security risk and if you have any solutions for this?
>
> Issue:
> -
> Sometimes, we want users to be able to modify a field so we give that
> field a Change permission, and give the user that permission.  For example,
> we want a user to enter a short description on a Change Request.
>
> Later, we don’t want the user to modify that field.  For example, when a
> Change Request has been approved.  We don’t really want the user to change
> details.  To prevent this, we make the field Read-Only.
>
> The vulnerability is that even though that field is Read-Only they can
> modify the field using tools included in web browsers.  If our users are
> external to our organisation we can not control what browsers they use.
>
> So this is only an issue is a user is deliberately trying to misuse the
> system – the sort or users we’d like to take security precautions against.
>
> BMC’s Stance
> -
> BMC, the lead architect, has stated that Read-Only fields are a display
> characteristic to assist the user interface.
>
> Solutions
> -
> We could crate filters that fire when we know a fields are read-only for
> the current user to check the TR value and prevent the commit.  This is a
> lot of overhead for fixing this vulnerability in BMC’s ITSM application,
> let alone customisations and bespoke applications.
>
> Alternatively, we could audit the fields.  It doesn’t prevent the issue
> but would at least help to check if the field was changed.
>
> As BMC don’t see this as a bug or a vulnerability my hopes of mid tier/
> server fix for this are somewhat muted!
>
> Thanks
> Jon
> _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"

Read-Only Field Vulnerability

[Jon Young]

Hi Listers

Sorry if this has been discussed recently before;  I’ve got the tricky task of 
explaining to clients that Read-Only fields can be modified by users by a 
simple hack.  I wondered if any of your employers/ clients see this as a data 
security risk and if you have any solutions for this?

Issue:
-
Sometimes, we want users to be able to modify a field so we give that field a 
Change permission, and give the user that permission.  For example, we want a 
user to enter a short description on a Change Request.

Later, we don’t want the user to modify that field.  For example, when a Change 
Request has been approved.  We don’t really want the user to change details.  
To prevent this, we make the field Read-Only.

The vulnerability is that even though that field is Read-Only they can modify 
the field using tools included in web browsers.  If our users are external to 
our organisation we can not control what browsers they use.

So this is only an issue is a user is deliberately trying to misuse the system 
– the sort or users we’d like to take security precautions against.

BMC’s Stance
-
BMC, the lead architect, has stated that Read-Only fields are a display 
characteristic to assist the user interface.

Solutions
-
We could crate filters that fire when we know a fields are read-only for the 
current user to check the TR value and prevent the commit.  This is a lot of 
overhead for fixing this vulnerability in BMC’s ITSM application, let alone 
customisations and bespoke applications.

Alternatively, we could audit the fields.  It doesn’t prevent the issue but 
would at least help to check if the field was changed.

As BMC don’t see this as a bug or a vulnerability my hopes of mid tier/ server 
fix for this are somewhat muted!

Thanks
Jon

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Atrium SSO with load balancer

[Jayesh]

Is there a specific reason for redirecting it to http traffic and not going 
with https? With https its working smooth for me. 

We have both the sso nodes running on https. But the F5 LB SAN  signed  
certificate handles all the encryption.



-Original Message-
From: "Grunder, John F" 
Sent: ‎21-‎04-‎2015 11:11 PM
To: "arslist@ARSLIST.ORG" 
Subject: Atrium SSO with load balancer

** 
We are attempting to configure Atrium SSO (9.0, latest patch) with ARS 8.1 in a 
complete HA environment.  We already have the load balancers configured for 
MidTier and ARS, but are having issues with the configuration for Atrium SSO.  
We are using F5 load balancers and the team responsible for the load balancers 
here wishes to have the F5 handle all SSL traffic, and redirect in http only to 
the SSO nodes.  However, we cannot get SSO to work with only http…attempts to 
reconfigure Tomcat to serve the page have resulted in failures (and forced a 
reinstall of the Atrium SSO product).  The F5 team rightly point out that this 
would mean that first the F5 encrypts, then the server encrypts again, which is 
inefficient.  Does anyone have SSO setup in a similar config, and if so, can 
you provide any information as to how to handle the redirect, and/or how to 
configure Atrium SSO to successfully handle non-https traffic?
 
Thanks in advance for any thoughts.
 
John F. Grunder
 
 
This email is UNCLASSIFIED. 


_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: BIRT being deprecated?

[LJ LongWing]

I have no details, and if I did, I don't think I could discuss them :)
On Apr 21, 2015 12:36 PM, "John Baker" 
wrote:

> I feel old. I remember when BIRT was new and trendy. I even wrote some
> reporting solutions using it back in 2005 or so.
>
> LJ, why a new reporting solution? Any gossip to share with us?
>
>
> ___
> 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"

BIRT being deprecated?

[John Baker]

I feel old. I remember when BIRT was new and trendy. I even wrote some
reporting solutions using it back in 2005 or so. 

LJ, why a new reporting solution? Any gossip to share with us?

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Atrium SSO with load balancer

[Grunder, John F]

We are attempting to configure Atrium SSO (9.0, latest patch) with ARS 8.1 in a 
complete HA environment.  We already have the load balancers configured for 
MidTier and ARS, but are having issues with the configuration for Atrium SSO.  
We are using F5 load balancers and the team responsible for the load balancers 
here wishes to have the F5 handle all SSL traffic, and redirect in http only to 
the SSO nodes.  However, we cannot get SSO to work with only http...attempts to 
reconfigure Tomcat to serve the page have resulted in failures (and forced a 
reinstall of the Atrium SSO product).  The F5 team rightly point out that this 
would mean that first the F5 encrypts, then the server encrypts again, which is 
inefficient.  Does anyone have SSO setup in a similar config, and if so, can 
you provide any information as to how to handle the redirect, and/or how to 
configure Atrium SSO to successfully handle non-https traffic?

Thanks in advance for any thoughts.

John F. Grunder


This email is UNCLASSIFIED.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: BIRT being deprecated?

[LJ LongWing]

Bruce,
in ITSM 9 they are introducing a new type of reporting, but not deprecating
BIRT, as far as I'm aware at least

On Tue, Apr 21, 2015 at 11:31 AM, Bruce  wrote:

> **
> Hey listers,
>
> I have heard rumors that BIRT (Remedy Web reporting) is going to be
> deprecated in a very near future release. ITSM 9 or 10?
>
> Is this official or just a rumor?
>
> The client is investing a significant amount of work to build reports
> using BIRT.  They also have Business Objects, but that is not a great tool
> for day to day reporting.  Its like using a ferrari to go to the corner
> store a block away.  Its nice to drive but its not necessary.
>
> Thanks for any information the group can provide.
>
>
> _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"

BIRT being deprecated?

[Bruce]

Hey listers,

I have heard rumors that BIRT (Remedy Web reporting) is going to be
deprecated in a very near future release. ITSM 9 or 10?

Is this official or just a rumor?

The client is investing a significant amount of work to build reports using
BIRT.  They also have Business Objects, but that is not a great tool for
day to day reporting.  Its like using a ferrari to go to the corner store a
block away.  Its nice to drive but its not necessary.

Thanks for any information the group can provide.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ARS Patching Question

[Mueller, Doug]

Doug,

This is a multi-topic question.

There are different pieces of the system and there are different requirements 
for approaching updating with zero down time.

Mid-tier

Just do the upgrade/patch/whatever on them one at a time.  There is no issue 
with mixed versions.  The big issue here is that if you take down a mid-tier, 
you can cause a user to have to relogin if they are connected to that mid-tier.

You can eliminate that by bringing up new mid-tiers, pointing load balancer to 
the new ones and off the old ones, then a day later, remove the old ones (by 
then, people have rolled off them to the new ones).   If use VMs for your 
mid-tiers, this is a temporary set of additional VMs.  If you don't want that, 
just upgrade each in place and roll across them.  NO down-time, but users may 
need to relogin as the mid-tier they were connected to goes down.  And, they 
may be bumped a couple of times if they get redirected to one that is still 
awaiting upgrade.

AR Server/CMDB

We have customers upgrading/patching here today with zero down time.  We are 
going to be writing up a more formal document about this topic over the next 
few months, but we do know it works.

The key here is to take each server one at a time and upgrade.  There is no 
state in the server so no problem with having users redirect to other servers 
as one is down.  You can just go cowboy and upgrade one at a time and roll 
across or invest a bit more and be orderly.  Something like

For each server:

-  Take out of the load balancer

-  Take out of the server group  (this stops it from signaling other 
servers to recache)

-  Upgrade/patch/whatever

-  Put back in the server group

-  Put back in the load balancer

This gives you a rolling upgrade where you upgrade each server one at a time 
with other servers still active.   The one downside is that if a server not 
upgraded yet goes down for some reason during this process, if it is an 
upgrade, it will not come up until it is upgraded (if being patched, it will 
come up without issue).  This is because the version stamp of the DB has been 
changed.  But, this is unusual, it still doesn't take down other servers, and 
we are talking about a short time window - 1 hour or so for the first server 
upgrade (much less for patches), and 15 minutes for other than the first server 
upgrade (much less for patches).

We are going to formally document a set of steps to cover all bases, but this 
is the idea.

For patches, this is especially easy and straight-forward as there are not 
major changes being made to the system.


Applications

Upgades are not possible with zero-down time.  Someone has noted a feature that 
is on the Communities Ideas list around this.  We have a POC for this 
capability, it just has not made a release train at this point.  We can help 
minimize the outage time.

BUT, for patches.  There is generally very controlled change to specific 
workflow items and maybe some fields and the like.  There is definitely a clean 
way to upgrade without downtime.  Just install the patch on the first server 
with the signaling of other servers turned off.  When done, if the patch is all 
definitions (no executables, you can simply signal each other server one at a 
time (to avoid all going to the database simultaneously for new defs) and get 
the updates.  If there is an executable, just then run the patch on each 
secondary server and as you do that, if it doesn't recache definitions, tell it 
to as you are installing the patch.




This is not a definitive list of steps, just a conceptual overview, but we have 
quite a few customers using the types of techniques above to do live system 
updates.  It does work.

PLEASE OF COURSE install the patches and hotfixes in dev and test first and 
make sure all is working as expected and then upgrade production using the 
ideas above  And OF COURSE, make sure you have recent backups - just in 
case.

Doug Mueller

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Hynes, Douglas
Sent: Monday, April 20, 2015 8:57 AM
To: arslist@ARSLIST.ORG
Subject: ARS Patching Question

**
All,

Anyone ever come up with an idea for in-place ARS upgrades/patching? Something 
like using dual server groups so the system never has to go down during 
maintenance? (if that's even possible) I'm trying to come up with a way to 
decrease needed downtimes to handle the patch/upgrade load. (and reduce the 
need for me to be here during typical downtime window from 22:00-05:00).

Ideas?

Thanks,
-Doug

[cid:image001.jpg@01D07C1C.A0119620]


Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and d

Re: Archive form's view is not available in Database

[Mueller, Doug]

My first guess on this issue.

You have an EXISTING archive form for this form that at some point has been 
turned off.  We do not delete the archive form as it has data in it.

Now, you turn it back on and the system is creating the archive.  For the most 
part, it is already there.  However, at some point, you have added a unique 
index that was not there previously.  When the system is trying to create the 
archive form and apply the index, there is data in the archive that is 
violating the unique index so it cannot be created.  This is returning an error 
during create of the archive.  That causes the request to turn on archiving to 
return an error and then to deactivate archiving for that form as there is not 
a valid archive form.

So, what data is in your archive form already?
Is there a unique index on your form that is being violated by data already in 
the archive?
Can you clean the data that is not unique or remove the data from the archive 
form before you try and turn it on?
Is the unique index valid for the data (it seems to be as you are not having 
trouble with the production form, then why may there be dups in the archive 
data?)

At one point, we did not clone the indexes to the archive, only the form 
definition.  We do clone it now to keep the same rules on your archive as is on 
your regular data.

Anyway, this is my guess.  The second error that you are shown is the detail 
for why you are getting the first error.  It seems to come back to a unique 
index violation in the data when trying to apply an index.

Doug Mueller

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Madhu V
Sent: Sunday, April 19, 2015 7:10 AM
To: arslist@ARSLIST.ORG
Subject: Archive form's view is not available in Database

Hi,
 
We are facing some problems while saving a regular form and getting the below 
error (Screen shot).
The form has got archival form and but which is not visible after we got this 
warning message.

Few Observations:
 
We had verified that there is enough memory.
We tried disabling the archival feature and creating the new fields but same 
warning repeated.
Old Data still exists in the Archive table.
The archive from is not visible via Developer Studio.
The main form has no isues.
 
Please let me know your views on this.
 
Regards
Madhu

___
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: Timeout ARERR 93

[Mueller, Doug]

James,

Error 93 is a timeout error.  It is specific to search type commands -- 
GetList.  In addition, it is generally only for entry type operations.

Error 92 is also a timeout error.  It is specific to point entry access 
commands -- Create/Set/Merge/Delete/Get. In addition, you will get this for any 
data dictionary search type operations.

So, you are getting a timeout searching for entries.

This matches with your discussion that you are not having trouble getting 
individual incidents, but only on the console where you are doing a search.

You didn't mention your version and whether you are on the latest releases 
where we are keeping the top 10 (a configurable number) API and SQL commands 
for you automatically and you can drop them out at any time (or on a scheduled 
basis).  If you are, then you can simply drop out the longest commands and see 
what the timing is.

In any version, you can turn on SQL logging and just see what SQL is being 
issued and why it is taking so long.

Being error 93, it is keying off the LONG timeout which defaults to something 
like 3 or 5 minutes.  So, you should be seeing a long delay in response to 
going to the console and getting the error message.

The support team should be able to help isolate the issue.  They will want to 
look at the SQL that is taking the time (from one of the sources I note above).

The issue could be anything from very long searches due to indexes that are 
lost/missing to blocked threads to other similar issues.  The key is going to 
be seeing the command arrive and seeing what SQL is generated (or not and that 
is significant because it is not even getting to that point) and what is taking 
the time.

Some things to start with, and I would suggest that the support team is a 
resource that can help you with this type of situation.

Doug Mueller

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith
Sent: Friday, April 17, 2015 1:47 PM
To: arslist@ARSLIST.ORG
Subject: Timeout ARERR 93

Hi List,

It has been a long time since we interacted with each other. Hope entire list 
is doing fine.

Now let me describe you about my issue and grab some info if you can share. I 
am getting 93 error on Incident Console only but not on other console. I have 
checked API, SQL and Filter logs but couldn't find anything. 

Please let me know if you have any solution to fix it.

___
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: JOB: ActioNet, Inc. Remedy Administrator Developer - CMDB & Asset Specialty

[Mike Campbell]

Eric,
Would you pay a referral fee or placement fee for this opportunity.  I know two 
people looking right now.  What part of the country is opening located? Thanks,

Mike 

  From: Eric Chasteen 
 To: arslist@ARSLIST.ORG 
 Sent: Monday, April 20, 2015 3:21 PM
 Subject: JOB: ActioNet, Inc. Remedy Administrator Developer - CMDB & Asset 
Specialty
   
**Hello Listers,
I am looking for full-time Remedy Administrator Developer with Discovery, CMDB 
and Asset Management experience on Remedy versions >7.6.x to 8.x.  Experience 
with design, configuration, and daily operation of Discovery scans, Product 
Catalog normalization, and CMDB reconciliation processes for configuration 
items and related attributes.  Also familiar with maintaining hardware 
warranties, and software contracts, license agreements, and usage.
Public clearance and U.S. citizenship required. Includes health care, training, 
and retirement benefits. If interested in discussing further, please contact me 
at echast...@actionet.com and please include an up-to-date resume.
Thank you,
Eric Chasteen_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"