Classification: UNCLASSIFIED
Caveats: NONE
Chris,
I've been following this thread and I had the same issues, but have been
able to overcome the export definitions and Sync Search with various
versions of the 7.x Admin Tool. Perhaps your issue is related:
The Remedy database I inherited a few months ago had many issues. After
working through all the issues, the export definitions and Sync Search
runs relatively quickly on all our servers.
A brief list of the things I found that contributed to the inability to
sync or export definitions.
- Workflow that points to non-existent Hard Coded Server Reference
Names.
- Workflow that references non-existent fields, forms, groups or
other workflow.
- Damaged workflow. Sometimes opening the workflow in the latest
usertool and saving again fixes this one.
- Group ID's in the permissions of workflow/forms that reference
Non-existent Groups.
- Lot's of other similar issues that are too painful to recall.
ARERR 92 93 errors are the result, these seem to send the process into
limbo so it may not be able to finish. The arxref.log file in ARAdmin
directory shows many of these issues that contribute to the delays.
Hope this helps,
Scott.
FYI:
P R O B L E M
------------------------------------------------------------------------
--------
Is there a way to run the Admin Tool Sync Search Database from the
command line?
S O L U T I O N
------------------------------------------------------------------------
--------
There is a command line option that allows you to run the Tools >> Sync
Search Database outside of the Graphical User Interface (GUI). The the
Syntax is:
aradmin -x {Server Name} -u {User Name} -p {Password} -s (For Version
5.+
Sync Search Database is not a server function. It is an Remedy Admin
function. Remedy Admin issues API calls to the server, prepares the data
for the object_search_admin, object_search_details, and
object_search_ref forms, and creates entries within those forms. The
main processing is done in the Admin Tool.
The Sync Search Database runs in a separate thread leaving the Remedy
Admin available for other functions such as opening and working with
another AR objects. Because of the intensity of object crossreferencing,
AR Server performance becomes a concern. It is recommended that the
Synchronization be run during non-peak hours and with minimal
applications running on the client at the time when the synch is
started. When using the Admin tool on a system where physical memory is
scarce, it is recommended that the command line option be used instead
as it uses less memory.
The Sync Search Database log, called arxref.txt in 4.5.2 and 5.0.1,
arxref.log in 5.1, is located in the same directory as aradmin.exe.
========================================================================
=========
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of strauss
Sent: Friday, November 30, 2007 10:32 AM
To: [email protected]
Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED)
The last time I tried to export all to def the 7.1 Admin Tool crashed,
much as it does on any attempt to sync. I'll try again today with just
the forms, as you suggest.
Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center http://itsm.unt.edu/
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
> Sent: Friday, November 30, 2007 6:19 AM
> To: [email protected]
> Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED)
>
> Robert and Christopher,
>
> I have been watching this thread and wondering if you two(Robert and
> Chris) could do a test for me to find out if a "related problem" might
> be the root cause of your issues?
>
> I have observed on a v7.x server (with only Service Desk
> installed) that it is not capable of exporting all ARS objects at one
> time. Not even if you only try to export one object class at a time. I
> have reported this to BMC, they are saying "as designed". (Bullux if
> you ask me. Install an OOB application and suddenly a "feature of the
> system" stops working? How can that be "as designed"?) So I am
> wondering if this is the underlying issue with your abilities to not
> sync or partially sync the Search DB data?
>
> I have observed that if you enable API logs on the ARS server before
> you do an export operation that you will see that the Admin tool
> "times out" (after about 30 minutes, or was it 60
> minutes?) and the ARS server keeps on going for well over an hour (in
> my case) and the Admin Tool produces no file and looks to be "hung"
> from the time it times out and the time the ARS server stops doing
> whatever it was asked to do.
>
> I would be very interested to know if either of you can do either of
> the following:
> 1) "Export All" ( All objects into one Def file in one pass)
> 2) "Export" All of each class of ARS objects in to separate files (one
> pass per object class: Form, Active Link, Filter, etc..)
> If not which one(s) fail to export?
>
> My hypothesis is that Christopher might not be able to even export all
> forms in one batch.
> However Robert might be able to export all object classes except
> Active Links.
>
> I just can not help but think that our problems could be related.
>
> --
> Carey Matthew Black
> Remedy Skilled Professional (RSP)
> ARS = Action Request System(Remedy)
>
> Love, then teach
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
>
>
> On Nov 30, 2007 4:53 AM, Robert Page <[EMAIL PROTECTED]> wrote:
> > **
> >
> > Hi
> >
> > I'm running a 7.0.1 patch 3 admin tool and our synch works,
> not fully
> > but it does do some form of sync, we leave a PC on and
> start the sync,
> > go home, come back in the morning to the message sync completed
> > successfully, its best to have only the admin tool running
> as we find
> > it grabs loads of memory and loads of processor.
> >
> > The only problem we have found so far is that it does not
> sync Active
> > Links, not a single one, everything else seems fine but no
> AL's. We
> > are going to run it again and if we get the same result
> we'll bug it.
> >
> > Cheers
> >
> > Robert
> > On Thu, 29 Nov 2007, strauss wrote:
>
>
>
> > > I have had tickets open on this for 7.0.0.003 since June
> 2007. The
> > > main ticket was closed in an unresolved state and replaced with
> > > another ticket for 7.1 GA in September 2007, which was
> then closed
> > > and a defect SW00276070 was created that still has not been fixed
> > > even though its status is closed. That's as near as I can tell
> > > after retracing the steps through the labyrinth of
> supportweb issue and defect displays.
> > > There were even duplicate tickets for the same problem manifested
> > > differently for 7.0.x and 7.1 beta along the way. I don't think
> > > support is tracking this stuff correctly since they went to a
> > > process of closing the ticket upon creating a defect. If
> the defect
> > > from my ticket was also closed, there is no way to tell if they
> > > consolidated it into another defect, or addressed it in
> some other
> > > way. They sure as hell have NOT fixed it yet!
> > >
> > > Christopher Strauss, Ph.D.
> > > Call Tracking Administration Manager University of North Texas
> > > Computing & IT Center http://itsm.unt.edu/
>
> ______________________________________________________________
> _________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
> Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
>
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Classification: UNCLASSIFIED
Caveats: NONE
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
