**
Well,
I think you all can see by my previous posts that I often find myself in a situation trying to implement things in the AR System that I don't have the skills for, and I seem to mess things up as often as I fix them.

I started with AR back in 1998 with the Helpdesk application so that we could moving more quickly. I went Administering AR and Helpdesk back in those days and got the rudimentary setup in place and customized the Remedy Support app that we still continue to use. I went back around 2003 and took the Administering #3 in ARS 6.3 and after that was able to get the MidTier functioning properly.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
I would also like to sync the current SHR:People form with LDAP instead of Oracle HRIS data. And I would definitely like to sync login with our LDAP system. All of these things- I just don't know where to start.

I am the only AR admin here and I also manage our Helpdesk call center, our student and faculty computer labs and act as assistant supervisor to the tech support group. My time is limited.

Can you all help me establish what I need to be studying? I think I am all over the map- just shooting at problems as they come around and eventually I am going to break this darn thing if I am not careful. I have a lot of manuals- but I don't seem to have much documentation on the Helpdesk application right now.

I have not been able to set up a proper development server either so my changes really do have bad effects (if I don't tell the DBA to set aside a copy of the DB before doing them).

Thank you list, for all your invaluable help up to this point. You have been very kind. Regards,
Brad

ARS 6.3
Helpdesk 5.5
Windows Server 2003
Remote Oracle database


On 2/14/06, Stephen Earl wrote:

**
In our team we try to avoid working 'outside' AR System wherever possible, this is usually due to skills shortages and of course the fact that people are very very poor at documenting things.

To date we have not needed to write any 'code' for the work we do, and have several tie ins to other systems from our AR System, the only thing we've needed to add has been the croom consulting ARDBC plugins, which have helped us no end with many issues of data portability and enabled us to remove some old legacy scripts that did exist prior to their installation.

It may sometimes be slower or maybe a little harder to build rather than whipping out the Perl or Java API swiss army knife but so far we haven't come up against anything we haven't been able to handle 'inside' AR System.

Stephen


On 14/02/06, Will Du Chene wrote:

Personally, I would recommend some sort of programming - or at the very
least some sort of scripting - course.

There are many things which the AR System can do for you, but there is a
definite line in front of some of things that it cannot. If you want to
stretch past that point, you need to do some sort of API programming.

If you want to bridge the AR System and some of the applications on the
desktop, or develop new ones, then it is a necessity. Similarly, you can
write prorgrams or scripts to parse through large amounts of data, or
update x number of records in fairly short order.

Now before anyone starts holding their breath, let me say that programming
or scripting itself as it applies to the API does not have to be painful.
There are a number of resources available to make it an easy thing to pick
up. Hey - it looks great on the resume as well.

Some of the courses that are available from some of the external vendors
are not that bad. I remember one vendor had an intro to Perl class that
was three days. Another had an intro to VB that was about a week.

In short - it's not that bad and can really go a long ways into making
life easier.

I will also say that one of the things - perhaps this is a take off from
the other thread that I saw out here the other day and does not belong
here, but it is related - that one of things that really bugs me about the
AR System is that there is a good deal of promotion that depicts it as a
system that you can program without needing to know how to program. (The
other is that people call it 'coding' but I digress...)

IMHO - that is just so wrong on so many levels... Sure you can get by with
the basics (which is exactly what it is). Sure, you could do all of the
development within the AR System and tell yourself that it is for reasons
'portability.' Then again, you could still be using a horse and buggy
rather than a car. You could also walk to work instead of driving. My
question is: why would you?






On Tue, February 14, 2006 2:39 pm, Brad Terhune wrote:
> I seem to get really hung up on moving data from other sources into
> Remedy
> (big example, our LDAP data).
>
>
> I have taken some Remedy courses but it has been a couple of years. Do
> you have any training recommendations for me? I am going to go the
> Education
> site now and look some things over. Thanks,
> Brad
>
>
>
> On 2/14/06, Susan Palmer < suzanpalmer@gmail.com> wrote:
>
>>
>> ** Brad,
>>
>>
>> NEVER show fear. Don't let the application own you, you must own it
>> and become it's master (so to speak). Make the application work for
>> you. Doesn't mean everything you do will work at first try, then you try
>> again. Part of it is designing, write it out on paper ... do a story
>> board showing all the steps, then add to it what workflow you think is
>> needed.
>>
>> Have you had any classes lately, maybe some are in order to give you
>> more confidence. Now that you are somewhat familiar with Remedy, you'll
>> grasp the concepts better. If they don't want to put out for education,
>> start reading the manuals (especially the concepts, tips and tricks,
>> then look up what needs to be done). Experiment. Don't think of it as
>> lost time, just learning curve. But, do put it on paper first!
>>
>> Now we want updates so we know how it is progressing,
>> Susan
>>
>>
>>
>> On 2/14/06, Brad Terhune < brad.terhune@gmail.com> wrote:
>>
>>>
>>> ** I have had a request from someone from another department who
>>> wants to utilize the Remedy system as a technician. They also want
>>> anyone on campus to be able to submit tickets into the Remedy system
>>> and have those tickets assigned to them automagically.
>>>
>>> Right now, our Helpdesk sets up Remedy tickets and assigns them to
>>> technicians, so this is something I have not tried before. I have
>>> eight fixed licenses and five floating licenses. I don't have a whole
>>> lot of space for new fixed or floating licenses to be assigned.
>>>
>>> Has anyone set up a system using Remedy Helpdesk where their entire
>>> user base (we have 4000 or so) creates tickets in Remedy Helpdesk and
>>> the tickets are routed automatically. I am really afraid of this
>>> project. Frankly, I am afraid it is beyond my skill (and time
>>> allocation) to implement. What do you all think? Thank you, Brad
>>> 20060125This posting was submitted with HTML
>>> in it
>>
>>
>> 20060125This posting was submitted with HTML
>> in it
>>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it

**
Hi Brad,
First of all Chill. I am sure with all that experience that you carry, It would be an easy piece of cake.

LDAP integration:
You can do an external authentication on Remedy using the AREA
LDAP plugin. Get in touch with your LDAP Administarator and get the
connection strings required for LDAP. This is a smooth Integration without
any problems. have a look at the Advanced guide for more details.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
With the submitter Mode as Locked you can allow any user with a Read Licence to submit any number of tickets.

If you change the Submitter mode to locked then each user can view his own
tickets and modify them without a fixed licence on the user tool as well as
on the mid tier.

Submitter Mode : Locked: Allows users who have their name in the Submitter
field to modify requests without a write license. This does not apply to
users with a Restricted Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is submitted,
the value in the Submitter field cannot be changed.

Sync the current SHR:People form with LDAP:
You can get this done by writing an escalation to run every night so that there can be a mass upload that could happen from the LDAP directory to the SHR:People form. let me know if you require more information on how to achieve this.



Can you all help me establish what I need to be studying?
You can read the ARS PDF Guides which clearly explains all kind of development need within ARS. You can also refer you Part 2 and Part 3 Admin Guides which is a very useful resource. You can also check out a couple of websites like the remedy support web, Buyoant Solution, Matt reinfields site to get some sample code. In case you need any, I believe tat you are just nervous, take some time off and start working I am sure with all your experience on ARS you would do a great job. And All of us on the ARSList are always there to help you.


Regards,
Roney Samuel Varghese



On 2/15/06, Brad Terhune wrote:

**
Well,
I think you all can see by my previous posts that I often find myself in a situation trying to implement things in the AR System that I don't have the skills for, and I seem to mess things up as often as I fix them.

I started with AR back in 1998 with the Helpdesk application so that we could moving more quickly. I went Administering AR and Helpdesk back in those days and got the rudimentary setup in place and customized the Remedy Support app that we still continue to use. I went back around 2003 and took the Administering #3 in ARS 6.3 and after that was able to get the MidTier functioning properly.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
I would also like to sync the current SHR:People form with LDAP instead of Oracle HRIS data. And I would definitely like to sync login with our LDAP system. All of these things- I just don't know where to start.

I am the only AR admin here and I also manage our Helpdesk call center, our student and faculty computer labs and act as assistant supervisor to the tech support group. My time is limited.

Can you all help me establish what I need to be studying? I think I am all over the map- just shooting at problems as they come around and eventually I am going to break this darn thing if I am not careful. I have a lot of manuals- but I don't seem to have much documentation on the Helpdesk application right now.

I have not been able to set up a proper development server either so my changes really do have bad effects (if I don't tell the DBA to set aside a copy of the DB before doing them).

Thank you list, for all your invaluable help up to this point. You have been very kind. Regards,
Brad

ARS 6.3
Helpdesk 5.5
Windows Server 2003
Remote Oracle database



On 2/14/06, Stephen Earl wrote:

**
In our team we try to avoid working 'outside' AR System wherever possible, this is usually due to skills shortages and of course the fact that people are very very poor at documenting things.

To date we have not needed to write any 'code' for the work we do, and have several tie ins to other systems from our AR System, the only thing we've needed to add has been the croom consulting ARDBC plugins, which have helped us no end with many issues of data portability and enabled us to remove some old legacy scripts that did exist prior to their installation.

It may sometimes be slower or maybe a little harder to build rather than whipping out the Perl or Java API swiss army knife but so far we haven't come up against anything we haven't been able to handle 'inside' AR System.

Stephen


On 14/02/06, Will Du Chene wrote:

Personally, I would recommend some sort of programming - or at the very
least some sort of scripting - course.

There are many things which the AR System can do for you, but there is a
definite line in front of some of things that it cannot. If you want to
stretch past that point, you need to do some sort of API programming.

If you want to bridge the AR System and some of the applications on the
desktop, or develop new ones, then it is a necessity. Similarly, you can
write prorgrams or scripts to parse through large amounts of data, or
update x number of records in fairly short order.

Now before anyone starts holding their breath, let me say that programming
or scripting itself as it applies to the API does not have to be painful.
There are a number of resources available to make it an easy thing to pick
up. Hey - it looks great on the resume as well.

Some of the courses that are available from some of the external vendors
are not that bad. I remember one vendor had an intro to Perl class that
was three days. Another had an intro to VB that was about a week.

In short - it's not that bad and can really go a long ways into making
life easier.

I will also say that one of the things - perhaps this is a take off from
the other thread that I saw out here the other day and does not belong
here, but it is related - that one of things that really bugs me about the
AR System is that there is a good deal of promotion that depicts it as a
system that you can program without needing to know how to program. (The
other is that people call it 'coding' but I digress...)

IMHO - that is just so wrong on so many levels... Sure you can get by with
the basics (which is exactly what it is). Sure, you could do all of the
development within the AR System and tell yourself that it is for reasons
'portability.' Then again, you could still be using a horse and buggy
rather than a car. You could also walk to work instead of driving. My
question is: why would you?






On Tue, February 14, 2006 2:39 pm, Brad Terhune wrote:
> I seem to get really hung up on moving data from other sources into
> Remedy
> (big example, our LDAP data).
>
>
> I have taken some Remedy courses but it has been a couple of years. Do
> you have any training recommendations for me? I am going to go the
> Education
> site now and look some things over. Thanks,
> Brad
>
>
>
> On 2/14/06, Susan Palmer < suzanpalmer@gmail.com> wrote:
>
>>
>> ** Brad,
>>
>>
>> NEVER show fear. Don't let the application own you, you must own it
>> and become it's master (so to speak). Make the application work for
>> you. Doesn't mean everything you do will work at first try, then you try
>> again. Part of it is designing, write it out on paper ... do a story
>> board showing all the steps, then add to it what workflow you think is
>> needed.
>>
>> Have you had any classes lately, maybe some are in order to give you
>> more confidence. Now that you are somewhat familiar with Remedy, you'll
>> grasp the concepts better. If they don't want to put out for education,
>> start reading the manuals (especially the concepts, tips and tricks,
>> then look up what needs to be done). Experiment. Don't think of it as
>> lost time, just learning curve. But, do put it on paper first!
>>
>> Now we want updates so we know how it is progressing,
>> Susan
>>
>>
>>
>> On 2/14/06, Brad Terhune < brad.terhune@gmail.com> wrote:
>>
>>>
>>> ** I have had a request from someone from another department who
>>> wants to utilize the Remedy system as a technician. They also want
>>> anyone on campus to be able to submit tickets into the Remedy system
>>> and have those tickets assigned to them automagically.
>>>
>>> Right now, our Helpdesk sets up Remedy tickets and assigns them to
>>> technicians, so this is something I have not tried before. I have
>>> eight fixed licenses and five floating licenses. I don't have a whole
>>> lot of space for new fixed or floating licenses to be assigned.
>>>
>>> Has anyone set up a system using Remedy Helpdesk where their entire
>>> user base (we have 4000 or so) creates tickets in Remedy Helpdesk and
>>> the tickets are routed automatically. I am really afraid of this
>>> project. Frankly, I am afraid it is beyond my skill (and time
>>> allocation) to implement. What do you all think? Thank you, Brad
>>> 20060125This posting was submitted with HTML
>>> in it
>>
>>
>> 20060125This posting was submitted with HTML
>> in it
>>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it

**
All right. Going to try and tackle this thing one issue at at time.
I have ARDBC configured properly (can see the LDAP tables). I have picked one that seems to have all the demographics I need through the creation of a vendor form. I had an LDAP administrator check to make sure my distinguished name was correct as well. When I try to run a query I get "ARERR 100 Entry ID parameter is empty". It seemed too easy- was there something else I was supposed to do? Thanks,
Brad


On 2/15/06, Brad Terhune wrote:

Thanks guys. I think I needed that.

I have Submitter mode locked as of about an hour ago, and am trying right now to get the Remedy Requester application up on the MidTier to test it out. Little problem right off the bat- I had Work Log required and it gave me an error indicating it could not be blank even though it is not on the form. I made it optional and that went away. I logged in and submitted a case and it went to my service queue, as do all cases that Remedy wants to assign to someone but it doesn't know who.

Right now, everyone has a blank password in SHR:People and and their Remedy Login Name is their Net ID in upper case (LDAP uid).

I met with the LDAP fellow a while back and think I have AREA configured right, but I am not sure how to run a good test on it. Is there some way that I can test that interface? Right now, everything seems to authenticate out of the user form in Remedy. I went through the Advanced guide yesterday and have Cross Ref. and Unregistered users checked on the server. I also changed External Authentication RPC to 390695.

I will be checking out Buoyant Solutions and I am going to go grab some PDFs at the support site. Thanks again! You guys are excellent.



On 2/15/06, Roney Samuel wrote:

**
Hi Brad,
First of all Chill. I am sure with all that experience that you carry, It would be an easy piece of cake.

LDAP integration:
You can do an external authentication on Remedy using the AREA
LDAP plugin. Get in touch with your LDAP Administarator and get the
connection strings required for LDAP. This is a smooth Integration without
any problems. have a look at the Advanced guide for more details.


However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
With the submitter Mode as Locked you can allow any user with a Read Licence to submit any number of tickets.

If you change the Submitter mode to locked then each user can view his own
tickets and modify them without a fixed licence on the user tool as well as
on the mid tier.

Submitter Mode : Locked: Allows users who have their name in the Submitter
field to modify requests without a write license. This does not apply to
users with a Restricted Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is submitted,
the value in the Submitter field cannot be changed.

Sync the current SHR:People form with LDAP:
You can get this done by writing an escalation to run every night so that there can be a mass upload that could happen from the LDAP directory to the SHR:People form. let me know if you require more information on how to achieve this.




Can you all help me establish what I need to be studying?
You can read the ARS PDF Guides which clearly explains all kind of development need within ARS. You can also refer you Part 2 and Part 3 Admin Guides which is a very useful resource. You can also check out a couple of websites like the remedy support web, Buyoant Solution, Matt reinfields site to get some sample code. In case you need any, I believe tat you are just nervous, take some time off and start working I am sure with all your experience on ARS you would do a great job. And All of us on the ARSList are always there to help you.


Regards,
Roney Samuel Varghese



On 2/15/06, Brad Terhune wrote:

**

Well,
I think you all can see by my previous posts that I often find myself in a situation trying to implement things in the AR System that I don't have the skills for, and I seem to mess things up as often as I fix them.

I started with AR back in 1998 with the Helpdesk application so that we could moving more quickly. I went Administering AR and Helpdesk back in those days and got the rudimentary setup in place and customized the Remedy Support app that we still continue to use. I went back around 2003 and took the Administering #3 in ARS 6.3 and after that was able to get the MidTier functioning properly.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
I would also like to sync the current SHR:People form with LDAP instead of Oracle HRIS data. And I would definitely like to sync login with our LDAP system. All of these things- I just don't know where to start.

I am the only AR admin here and I also manage our Helpdesk call center, our student and faculty computer labs and act as assistant supervisor to the tech support group. My time is limited.

Can you all help me establish what I need to be studying? I think I am all over the map- just shooting at problems as they come around and eventually I am going to break this darn thing if I am not careful. I have a lot of manuals- but I don't seem to have much documentation on the Helpdesk application right now.

I have not been able to set up a proper development server either so my changes really do have bad effects (if I don't tell the DBA to set aside a copy of the DB before doing them).

Thank you list, for all your invaluable help up to this point. You have been very kind. Regards,
Brad

ARS 6.3
Helpdesk 5.5
Windows Server 2003
Remote Oracle database



On 2/14/06, Stephen Earl wrote:

**
In our team we try to avoid working 'outside' AR System wherever possible, this is usually due to skills shortages and of course the fact that people are very very poor at documenting things.

To date we have not needed to write any 'code' for the work we do, and have several tie ins to other systems from our AR System, the only thing we've needed to add has been the croom consulting ARDBC plugins, which have helped us no end with many issues of data portability and enabled us to remove some old legacy scripts that did exist prior to their installation.

It may sometimes be slower or maybe a little harder to build rather than whipping out the Perl or Java API swiss army knife but so far we haven't come up against anything we haven't been able to handle 'inside' AR System.

Stephen


On 14/02/06, Will Du Chene wrote:

Personally, I would recommend some sort of programming - or at the very
least some sort of scripting - course.

There are many things which the AR System can do for you, but there is a
definite line in front of some of things that it cannot. If you want to
stretch past that point, you need to do some sort of API programming.

If you want to bridge the AR System and some of the applications on the
desktop, or develop new ones, then it is a necessity. Similarly, you can
write prorgrams or scripts to parse through large amounts of data, or
update x number of records in fairly short order.

Now before anyone starts holding their breath, let me say that programming
or scripting itself as it applies to the API does not have to be painful.
There are a number of resources available to make it an easy thing to pick
up. Hey - it looks great on the resume as well.

Some of the courses that are available from some of the external vendors
are not that bad. I remember one vendor had an intro to Perl class that
was three days. Another had an intro to VB that was about a week.

In short - it's not that bad and can really go a long ways into making
life easier.

I will also say that one of the things - perhaps this is a take off from
the other thread that I saw out here the other day and does not belong
here, but it is related - that one of things that really bugs me about the
AR System is that there is a good deal of promotion that depicts it as a
system that you can program without needing to know how to program. (The
other is that people call it 'coding' but I digress...)

IMHO - that is just so wrong on so many levels... Sure you can get by with
the basics (which is exactly what it is). Sure, you could do all of the
development within the AR System and tell yourself that it is for reasons
'portability.' Then again, you could still be using a horse and buggy
rather than a car. You could also walk to work instead of driving. My
question is: why would you?






On Tue, February 14, 2006 2:39 pm, Brad Terhune wrote:
> I seem to get really hung up on moving data from other sources into
> Remedy
> (big example, our LDAP data).
>
>
> I have taken some Remedy courses but it has been a couple of years. Do
> you have any training recommendations for me? I am going to go the
> Education
> site now and look some things over. Thanks,
> Brad
>
>
>
> On 2/14/06, Susan Palmer < suzanpalmer@gmail.com> wrote:
>
>>
>> ** Brad,
>>
>>
>> NEVER show fear. Don't let the application own you, you must own it
>> and become it's master (so to speak). Make the application work for
>> you. Doesn't mean everything you do will work at first try, then you try
>> again. Part of it is designing, write it out on paper ... do a story
>> board showing all the steps, then add to it what workflow you think is
>> needed.
>>
>> Have you had any classes lately, maybe some are in order to give you
>> more confidence. Now that you are somewhat familiar with Remedy, you'll
>> grasp the concepts better. If they don't want to put out for education,
>> start reading the manuals (especially the concepts, tips and tricks,
>> then look up what needs to be done). Experiment. Don't think of it as
>> lost time, just learning curve. But, do put it on paper first!
>>
>> Now we want updates so we know how it is progressing,
>> Susan
>>
>>
>>
>> On 2/14/06, Brad Terhune < brad.terhune@gmail.com> wrote:
>>
>>>
>>> ** I have had a request from someone from another department who
>>> wants to utilize the Remedy system as a technician. They also want
>>> anyone on campus to be able to submit tickets into the Remedy system
>>> and have those tickets assigned to them automagically.
>>>
>>> Right now, our Helpdesk sets up Remedy tickets and assigns them to
>>> technicians, so this is something I have not tried before. I have
>>> eight fixed licenses and five floating licenses. I don't have a whole
>>> lot of space for new fixed or floating licenses to be assigned.
>>>
>>> Has anyone set up a system using Remedy Helpdesk where their entire
>>> user base (we have 4000 or so) creates tickets in Remedy Helpdesk and
>>> the tickets are routed automatically. I am really afraid of this
>>> project. Frankly, I am afraid it is beyond my skill (and time
>>> allocation) to implement. What do you all think? Thank you, Brad
>>> 20060125This posting was submitted with HTML
>>> in it
>>
>>
>> 20060125This posting was submitted with HTML
>> in it
>>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it



20060125This posting was submitted with HTML in it

**
Yea...you need to associate the entry id field with a field from the ldap source....dn is usually too long...so I've been using 'usncreated'



From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brad Terhune
Sent: Wednesday, February 15, 2006 10:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: Submitter Mode and the Helpdesk Applications


**
All right. Going to try and tackle this thing one issue at at time.
I have ARDBC configured properly (can see the LDAP tables). I have picked one that seems to have all the demographics I need through the creation of a vendor form. I had an LDAP administrator check to make sure my distinguished name was correct as well. When I try to run a query I get "ARERR 100 Entry ID parameter is empty". It seemed too easy- was there something else I was supposed to do? Thanks,
Brad


On 2/15/06, Brad Terhune wrote:

Thanks guys. I think I needed that.

I have Submitter mode locked as of about an hour ago, and am trying right now to get the Remedy Requester application up on the MidTier to test it out. Little problem right off the bat- I had Work Log required and it gave me an error indicating it could not be blank even though it is not on the form. I made it optional and that went away. I logged in and submitted a case and it went to my service queue, as do all cases that Remedy wants to assign to someone but it doesn't know who.

Right now, everyone has a blank password in SHR:People and and their Remedy Login Name is their Net ID in upper case (LDAP uid).

I met with the LDAP fellow a while back and think I have AREA configured right, but I am not sure how to run a good test on it. Is there some way that I can test that interface? Right now, everything seems to authenticate out of the user form in Remedy. I went through the Advanced guide yesterday and have Cross Ref. and Unregistered users checked on the server. I also changed External Authentication RPC to 390695.

I will be checking out Buoyant Solutions and I am going to go grab some PDFs at the support site. Thanks again! You guys are excellent.



On 2/15/06, Roney Samuel wrote:

**
Hi Brad,
First of all Chill. I am sure with all that experience that you carry, It would be an easy piece of cake.

LDAP integration:
You can do an external authentication on Remedy using the AREA
LDAP plugin. Get in touch with your LDAP Administarator and get the
connection strings required for LDAP. This is a smooth Integration without
any problems. have a look at the Advanced guide for more details.


However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
With the submitter Mode as Locked you can allow any user with a Read Licence to submit any number of tickets.

If you change the Submitter mode to locked then each user can view his own
tickets and modify them without a fixed licence on the user tool as well as
on the mid tier.

Submitter Mode : Locked: Allows users who have their name in the Submitter
field to modify requests without a write license. This does not apply to
users with a Restricted Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is submitted,
the value in the Submitter field cannot be changed.

Sync the current SHR:People form with LDAP:
You can get this done by writing an escalation to run every night so that there can be a mass upload that could happen from the LDAP directory to the SHR:People form. let me know if you require more information on how to achieve this.




Can you all help me establish what I need to be studying?
You can read the ARS PDF Guides which clearly explains all kind of development need within ARS. You can also refer you Part 2 and Part 3 Admin Guides which is a very useful resource. You can also check out a couple of websites like the remedy support web, Buyoant Solution, Matt reinfields site to get some sample code. In case you need any, I believe tat you are just nervous, take some time off and start working I am sure with all your experience on ARS you would do a great job. And All of us on the ARSList are always there to help you.


Regards,
Roney Samuel Varghese



On 2/15/06, Brad Terhune wrote:

**

Well,
I think you all can see by my previous posts that I often find myself in a situation trying to implement things in the AR System that I don't have the skills for, and I seem to mess things up as often as I fix them.

I started with AR back in 1998 with the Helpdesk application so that we could moving more quickly. I went Administering AR and Helpdesk back in those days and got the rudimentary setup in place and customized the Remedy Support app that we still continue to use. I went back around 2003 and took the Administering #3 in ARS 6.3 and after that was able to get the MidTier functioning properly.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
I would also like to sync the current SHR:People form with LDAP instead of Oracle HRIS data. And I would definitely like to sync login with our LDAP system. All of these things- I just don't know where to start.

I am the only AR admin here and I also manage our Helpdesk call center, our student and faculty computer labs and act as assistant supervisor to the tech support group. My time is limited.

Can you all help me establish what I need to be studying? I think I am all over the map- just shooting at problems as they come around and eventually I am going to break this darn thing if I am not careful. I have a lot of manuals- but I don't seem to have much documentation on the Helpdesk application right now.

I have not been able to set up a proper development server either so my changes really do have bad effects (if I don't tell the DBA to set aside a copy of the DB before doing them).

Thank you list, for all your invaluable help up to this point. You have been very kind. Regards,
Brad

ARS 6.3
Helpdesk 5.5
Windows Server 2003
Remote Oracle database



On 2/14/06, Stephen Earl wrote:

**
In our team we try to avoid working 'outside' AR System wherever possible, this is usually due to skills shortages and of course the fact that people are very very poor at documenting things.

To date we have not needed to write any 'code' for the work we do, and have several tie ins to other systems from our AR System, the only thing we've needed to add has been the croom consulting ARDBC plugins, which have helped us no end with many issues of data portability and enabled us to remove some old legacy scripts that did exist prior to their installation.

It may sometimes be slower or maybe a little harder to build rather than whipping out the Perl or Java API swiss army knife but so far we haven't come up against anything we haven't been able to handle 'inside' AR System.

Stephen


On 14/02/06, Will Du Chene wrote:

Personally, I would recommend some sort of programming - or at the very
least some sort of scripting - course.

There are many things which the AR System can do for you, but there is a
definite line in front of some of things that it cannot. If you want to
stretch past that point, you need to do some sort of API programming.

If you want to bridge the AR System and some of the applications on the
desktop, or develop new ones, then it is a necessity. Similarly, you can
write prorgrams or scripts to parse through large amounts of data, or
update x number of records in fairly short order.

Now before anyone starts holding their breath, let me say that programming
or scripting itself as it applies to the API does not have to be painful.
There are a number of resources available to make it an easy thing to pick
up. Hey - it looks great on the resume as well.

Some of the courses that are available from some of the external vendors
are not that bad. I remember one vendor had an intro to Perl class that
was three days. Another had an intro to VB that was about a week.

In short - it's not that bad and can really go a long ways into making
life easier.

I will also say that one of the things - perhaps this is a take off from
the other thread that I saw out here the other day and does not belong
here, but it is related - that one of things that really bugs me about the
AR System is that there is a good deal of promotion that depicts it as a
system that you can program without needing to know how to program. (The
other is that people call it 'coding' but I digress...)

IMHO - that is just so wrong on so many levels... Sure you can get by with
the basics (which is exactly what it is). Sure, you could do all of the
development within the AR System and tell yourself that it is for reasons
'portability.' Then again, you could still be using a horse and buggy
rather than a car. You could also walk to work instead of driving. My
question is: why would you?






On Tue, February 14, 2006 2:39 pm, Brad Terhune wrote:
> I seem to get really hung up on moving data from other sources into
> Remedy
> (big example, our LDAP data).
>
>
> I have taken some Remedy courses but it has been a couple of years. Do
> you have any training recommendations for me? I am going to go the
> Education
> site now and look some things over. Thanks,
> Brad
>
>
>
> On 2/14/06, Susan Palmer < suzanpalmer@gmail.com> wrote:
>
>>
>> ** Brad,
>>
>>
>> NEVER show fear. Don't let the application own you, you must own it
>> and become it's master (so to speak). Make the application work for
>> you. Doesn't mean everything you do will work at first try, then you try
>> again. Part of it is designing, write it out on paper ... do a story
>> board showing all the steps, then add to it what workflow you think is
>> needed.
>>
>> Have you had any classes lately, maybe some are in order to give you
>> more confidence. Now that you are somewhat familiar with Remedy, you'll
>> grasp the concepts better. If they don't want to put out for education,
>> start reading the manuals (especially the concepts, tips and tricks,
>> then look up what needs to be done). Experiment. Don't think of it as
>> lost time, just learning curve. But, do put it on paper first!
>>
>> Now we want updates so we know how it is progressing,
>> Susan
>>
>>
>>
>> On 2/14/06, Brad Terhune < brad.terhune@gmail.com> wrote:
>>
>>>
>>> ** I have had a request from someone from another department who
>>> wants to utilize the Remedy system as a technician. They also want
>>> anyone on campus to be able to submit tickets into the Remedy system
>>> and have those tickets assigned to them automagically.
>>>
>>> Right now, our Helpdesk sets up Remedy tickets and assigns them to
>>> technicians, so this is something I have not tried before. I have
>>> eight fixed licenses and five floating licenses. I don't have a whole
>>> lot of space for new fixed or floating licenses to be assigned.
>>>
>>> Has anyone set up a system using Remedy Helpdesk where their entire
>>> user base (we have 4000 or so) creates tickets in Remedy Helpdesk and
>>> the tickets are routed automatically. I am really afraid of this
>>> project. Frankly, I am afraid it is beyond my skill (and time
>>> allocation) to implement. What do you all think? Thank you, Brad
>>> 20060125This posting was submitted with HTML
>>> in it
>>
>>
>> 20060125This posting was submitted with HTML
>> in it
>>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it



20060125This posting was submitted with HTML in it
20060125This posting was submitted with HTML in it

**
Dear Brad,

You have to change the request id field on the vendor form
The Request ID field (field ID 1) must be a non-NULL, unique character or numeric field that is 15 characters or less in length.

! If the value for any field is greater than 15 characters, the first 30
characters will show on the Results List but the data will not be
retrieved.

! If any values are NULL, you will receive ARERR (106) Entry ID list is empty.


! If more than one record has the same value, you will only retrieve data for the first matching entry.

! For most LDAP servers, uid is the attribute of choice for the Request ID.
For MS Active Directories, sAMAccountName is usually a good choice.

Hope this information from the guide helps.

Regards,
Roney Samuel Varghese




On 2/15/06, Brad Terhune wrote:

**
All right. Going to try and tackle this thing one issue at at time.
I have ARDBC configured properly (can see the LDAP tables). I have picked one that seems to have all the demographics I need through the creation of a vendor form. I had an LDAP administrator check to make sure my distinguished name was correct as well. When I try to run a query I get "ARERR 100 Entry ID parameter is empty". It seemed too easy- was there something else I was supposed to do? Thanks,

Brad



On 2/15/06, Brad Terhune wrote:

Thanks guys. I think I needed that.

I have Submitter mode locked as of about an hour ago, and am trying right now to get the Remedy Requester application up on the MidTier to test it out. Little problem right off the bat- I had Work Log required and it gave me an error indicating it could not be blank even though it is not on the form. I made it optional and that went away. I logged in and submitted a case and it went to my service queue, as do all cases that Remedy wants to assign to someone but it doesn't know who.

Right now, everyone has a blank password in SHR:People and and their Remedy Login Name is their Net ID in upper case (LDAP uid).

I met with the LDAP fellow a while back and think I have AREA configured right, but I am not sure how to run a good test on it. Is there some way that I can test that interface? Right now, everything seems to authenticate out of the user form in Remedy. I went through the Advanced guide yesterday and have Cross Ref. and Unregistered users checked on the server. I also changed External Authentication RPC to 390695.

I will be checking out Buoyant Solutions and I am going to go grab some PDFs at the support site. Thanks again! You guys are excellent.



On 2/15/06, Roney Samuel wrote:

**
Hi Brad,
First of all Chill. I am sure with all that experience that you carry, It would be an easy piece of cake.

LDAP integration:
You can do an external authentication on Remedy using the AREA
LDAP plugin. Get in touch with your LDAP Administarator and get the
connection strings required for LDAP. This is a smooth Integration without
any problems. have a look at the Advanced guide for more details.


However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
With the submitter Mode as Locked you can allow any user with a Read Licence to submit any number of tickets.

If you change the Submitter mode to locked then each user can view his own
tickets and modify them without a fixed licence on the user tool as well as
on the mid tier.

Submitter Mode : Locked: Allows users who have their name in the Submitter
field to modify requests without a write license. This does not apply to
users with a Restricted Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is submitted,
the value in the Submitter field cannot be changed.

Sync the current SHR:People form with LDAP:
You can get this done by writing an escalation to run every night so that there can be a mass upload that could happen from the LDAP directory to the SHR:People form. let me know if you require more information on how to achieve this.




Can you all help me establish what I need to be studying?
You can read the ARS PDF Guides which clearly explains all kind of development need within ARS. You can also refer you Part 2 and Part 3 Admin Guides which is a very useful resource. You can also check out a couple of websites like the remedy support web, Buyoant Solution, Matt reinfields site to get some sample code. In case you need any, I believe tat you are just nervous, take some time off and start working I am sure with all your experience on ARS you would do a great job. And All of us on the ARSList are always there to help you.


Regards,
Roney Samuel Varghese



On 2/15/06, Brad Terhune wrote:

**

Well,
I think you all can see by my previous posts that I often find myself in a situation trying to implement things in the AR System that I don't have the skills for, and I seem to mess things up as often as I fix them.

I started with AR back in 1998 with the Helpdesk application so that we could moving more quickly. I went Administering AR and Helpdesk back in those days and got the rudimentary setup in place and customized the Remedy Support app that we still continue to use. I went back around 2003 and took the Administering #3 in ARS 6.3 and after that was able to get the MidTier functioning properly.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
I would also like to sync the current SHR:People form with LDAP instead of Oracle HRIS data. And I would definitely like to sync login with our LDAP system. All of these things- I just don't know where to start.

I am the only AR admin here and I also manage our Helpdesk call center, our student and faculty computer labs and act as assistant supervisor to the tech support group. My time is limited.

Can you all help me establish what I need to be studying? I think I am all over the map- just shooting at problems as they come around and eventually I am going to break this darn thing if I am not careful. I have a lot of manuals- but I don't seem to have much documentation on the Helpdesk application right now.

I have not been able to set up a proper development server either so my changes really do have bad effects (if I don't tell the DBA to set aside a copy of the DB before doing them).

Thank you list, for all your invaluable help up to this point. You have been very kind. Regards,
Brad

ARS 6.3
Helpdesk 5.5
Windows Server 2003
Remote Oracle database



On 2/14/06, Stephen Earl wrote:

**
In our team we try to avoid working 'outside' AR System wherever possible, this is usually due to skills shortages and of course the fact that people are very very poor at documenting things.

To date we have not needed to write any 'code' for the work we do, and have several tie ins to other systems from our AR System, the only thing we've needed to add has been the croom consulting ARDBC plugins, which have helped us no end with many issues of data portability and enabled us to remove some old legacy scripts that did exist prior to their installation.

It may sometimes be slower or maybe a little harder to build rather than whipping out the Perl or Java API swiss army knife but so far we haven't come up against anything we haven't been able to handle 'inside' AR System.

Stephen


On 14/02/06, Will Du Chene wrote:

Personally, I would recommend some sort of programming - or at the very
least some sort of scripting - course.

There are many things which the AR System can do for you, but there is a
definite line in front of some of things that it cannot. If you want to
stretch past that point, you need to do some sort of API programming.

If you want to bridge the AR System and some of the applications on the
desktop, or develop new ones, then it is a necessity. Similarly, you can
write prorgrams or scripts to parse through large amounts of data, or
update x number of records in fairly short order.

Now before anyone starts holding their breath, let me say that programming
or scripting itself as it applies to the API does not have to be painful.
There are a number of resources available to make it an easy thing to pick
up. Hey - it looks great on the resume as well.

Some of the courses that are available from some of the external vendors
are not that bad. I remember one vendor had an intro to Perl class that
was three days. Another had an intro to VB that was about a week.

In short - it's not that bad and can really go a long ways into making
life easier.

I will also say that one of the things - perhaps this is a take off from
the other thread that I saw out here the other day and does not belong
here, but it is related - that one of things that really bugs me about the
AR System is that there is a good deal of promotion that depicts it as a
system that you can program without needing to know how to program. (The
other is that people call it 'coding' but I digress...)

IMHO - that is just so wrong on so many levels... Sure you can get by with
the basics (which is exactly what it is). Sure, you could do all of the
development within the AR System and tell yourself that it is for reasons
'portability.' Then again, you could still be using a horse and buggy
rather than a car. You could also walk to work instead of driving. My
question is: why would you?






On Tue, February 14, 2006 2:39 pm, Brad Terhune wrote:
> I seem to get really hung up on moving data from other sources into
> Remedy
> (big example, our LDAP data).
>
>
> I have taken some Remedy courses but it has been a couple of years. Do
> you have any training recommendations for me? I am going to go the
> Education
> site now and look some things over. Thanks,
> Brad
>
>
>
> On 2/14/06, Susan Palmer < suzanpalmer@gmail.com> wrote:
>
>>
>> ** Brad,
>>
>>
>> NEVER show fear. Don't let the application own you, you must own it
>> and become it's master (so to speak). Make the application work for
>> you. Doesn't mean everything you do will work at first try, then you try
>> again. Part of it is designing, write it out on paper ... do a story
>> board showing all the steps, then add to it what workflow you think is
>> needed.
>>
>> Have you had any classes lately, maybe some are in order to give you
>> more confidence. Now that you are somewhat familiar with Remedy, you'll
>> grasp the concepts better. If they don't want to put out for education,
>> start reading the manuals (especially the concepts, tips and tricks,
>> then look up what needs to be done). Experiment. Don't think of it as
>> lost time, just learning curve. But, do put it on paper first!
>>
>> Now we want updates so we know how it is progressing,
>> Susan
>>
>>
>>
>> On 2/14/06, Brad Terhune < brad.terhune@gmail.com> wrote:
>>
>>>
>>> ** I have had a request from someone from another department who
>>> wants to utilize the Remedy system as a technician. They also want
>>> anyone on campus to be able to submit tickets into the Remedy system
>>> and have those tickets assigned to them automagically.
>>>
>>> Right now, our Helpdesk sets up Remedy tickets and assigns them to
>>> technicians, so this is something I have not tried before. I have
>>> eight fixed licenses and five floating licenses. I don't have a whole
>>> lot of space for new fixed or floating licenses to be assigned.
>>>
>>> Has anyone set up a system using Remedy Helpdesk where their entire
>>> user base (we have 4000 or so) creates tickets in Remedy Helpdesk and
>>> the tickets are routed automatically. I am really afraid of this
>>> project. Frankly, I am afraid it is beyond my skill (and time
>>> allocation) to implement. What do you all think? Thank you, Brad
>>> 20060125This posting was submitted with HTML
>>> in it
>>
>>
>> 20060125This posting was submitted with HTML
>> in it
>>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it

**
Look in the definition of your vendor form. What do you have mapped for the EntryID (FieldID=1) field? The 2 most popular LDAP fields to map to are: uSNCreated or sAMAccountName. uSNCreated is probably the best since it is possible that sAMAccountName could be longer than 15 characters.

The error is stating that the LDAP field you have mapped to FieldID 1 does not have any data for the record you pulled up.

Fred



From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brad Terhune
Sent: Wednesday, February 15, 2006 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: Submitter Mode and the Helpdesk Applications


**
All right. Going to try and tackle this thing one issue at at time.
I have ARDBC configured properly (can see the LDAP tables). I have picked one that seems to have all the demographics I need through the creation of a vendor form. I had an LDAP administrator check to make sure my distinguished name was correct as well. When I try to run a query I get "ARERR 100 Entry ID parameter is empty". It seemed too easy- was there something else I was supposed to do? Thanks,
Brad


On 2/15/06, Brad Terhune wrote:

Thanks guys. I think I needed that.

I have Submitter mode locked as of about an hour ago, and am trying right now to get the Remedy Requester application up on the MidTier to test it out. Little problem right off the bat- I had Work Log required and it gave me an error indicating it could not be blank even though it is not on the form. I made it optional and that went away. I logged in and submitted a case and it went to my service queue, as do all cases that Remedy wants to assign to someone but it doesn't know who.

Right now, everyone has a blank password in SHR:People and and their Remedy Login Name is their Net ID in upper case (LDAP uid).

I met with the LDAP fellow a while back and think I have AREA configured right, but I am not sure how to run a good test on it. Is there some way that I can test that interface? Right now, everything seems to authenticate out of the user form in Remedy. I went through the Advanced guide yesterday and have Cross Ref. and Unregistered users checked on the server. I also changed External Authentication RPC to 390695.

I will be checking out Buoyant Solutions and I am going to go grab some PDFs at the support site. Thanks again! You guys are excellent.



On 2/15/06, Roney Samuel wrote:

**
Hi Brad,
First of all Chill. I am sure with all that experience that you carry, It would be an easy piece of cake.

LDAP integration:
You can do an external authentication on Remedy using the AREA
LDAP plugin. Get in touch with your LDAP Administarator and get the
connection strings required for LDAP. This is a smooth Integration without
any problems. have a look at the Advanced guide for more details.


However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
With the submitter Mode as Locked you can allow any user with a Read Licence to submit any number of tickets.

If you change the Submitter mode to locked then each user can view his own
tickets and modify them without a fixed licence on the user tool as well as
on the mid tier.

Submitter Mode : Locked: Allows users who have their name in the Submitter
field to modify requests without a write license. This does not apply to
users with a Restricted Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is submitted,
the value in the Submitter field cannot be changed.

Sync the current SHR:People form with LDAP:
You can get this done by writing an escalation to run every night so that there can be a mass upload that could happen from the LDAP directory to the SHR:People form. let me know if you require more information on how to achieve this.




Can you all help me establish what I need to be studying?
You can read the ARS PDF Guides which clearly explains all kind of development need within ARS. You can also refer you Part 2 and Part 3 Admin Guides which is a very useful resource. You can also check out a couple of websites like the remedy support web, Buyoant Solution, Matt reinfields site to get some sample code. In case you need any, I believe tat you are just nervous, take some time off and start working I am sure with all your experience on ARS you would do a great job. And All of us on the ARSList are always there to help you.


Regards,
Roney Samuel Varghese



On 2/15/06, Brad Terhune wrote:

**

Well,
I think you all can see by my previous posts that I often find myself in a situation trying to implement things in the AR System that I don't have the skills for, and I seem to mess things up as often as I fix them.

I started with AR back in 1998 with the Helpdesk application so that we could moving more quickly. I went Administering AR and Helpdesk back in those days and got the rudimentary setup in place and customized the Remedy Support app that we still continue to use. I went back around 2003 and took the Administering #3 in ARS 6.3 and after that was able to get the MidTier functioning properly.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
I would also like to sync the current SHR:People form with LDAP instead of Oracle HRIS data. And I would definitely like to sync login with our LDAP system. All of these things- I just don't know where to start.

I am the only AR admin here and I also manage our Helpdesk call center, our student and faculty computer labs and act as assistant supervisor to the tech support group. My time is limited.

Can you all help me establish what I need to be studying? I think I am all over the map- just shooting at problems as they come around and eventually I am going to break this darn thing if I am not careful. I have a lot of manuals- but I don't seem to have much documentation on the Helpdesk application right now.

I have not been able to set up a proper development server either so my changes really do have bad effects (if I don't tell the DBA to set aside a copy of the DB before doing them).

Thank you list, for all your invaluable help up to this point. You have been very kind. Regards,
Brad

ARS 6.3
Helpdesk 5.5
Windows Server 2003
Remote Oracle database



On 2/14/06, Stephen Earl wrote:

**
In our team we try to avoid working 'outside' AR System wherever possible, this is usually due to skills shortages and of course the fact that people are very very poor at documenting things.

To date we have not needed to write any 'code' for the work we do, and have several tie ins to other systems from our AR System, the only thing we've needed to add has been the croom consulting ARDBC plugins, which have helped us no end with many issues of data portability and enabled us to remove some old legacy scripts that did exist prior to their installation.

It may sometimes be slower or maybe a little harder to build rather than whipping out the Perl or Java API swiss army knife but so far we haven't come up against anything we haven't been able to handle 'inside' AR System.

Stephen


On 14/02/06, Will Du Chene wrote:

Personally, I would recommend some sort of programming - or at the very
least some sort of scripting - course.

There are many things which the AR System can do for you, but there is a
definite line in front of some of things that it cannot. If you want to
stretch past that point, you need to do some sort of API programming.

If you want to bridge the AR System and some of the applications on the
desktop, or develop new ones, then it is a necessity. Similarly, you can
write prorgrams or scripts to parse through large amounts of data, or
update x number of records in fairly short order.

Now before anyone starts holding their breath, let me say that programming
or scripting itself as it applies to the API does not have to be painful.
There are a number of resources available to make it an easy thing to pick
up. Hey - it looks great on the resume as well.

Some of the courses that are available from some of the external vendors
are not that bad. I remember one vendor had an intro to Perl class that
was three days. Another had an intro to VB that was about a week.

In short - it's not that bad and can really go a long ways into making
life easier.

I will also say that one of the things - perhaps this is a take off from
the other thread that I saw out here the other day and does not belong
here, but it is related - that one of things that really bugs me about the
AR System is that there is a good deal of promotion that depicts it as a
system that you can program without needing to know how to program. (The
other is that people call it 'coding' but I digress...)

IMHO - that is just so wrong on so many levels... Sure you can get by with
the basics (which is exactly what it is). Sure, you could do all of the
development within the AR System and tell yourself that it is for reasons
'portability.' Then again, you could still be using a horse and buggy
rather than a car. You could also walk to work instead of driving. My
question is: why would you?






On Tue, February 14, 2006 2:39 pm, Brad Terhune wrote:
> I seem to get really hung up on moving data from other sources into
> Remedy
> (big example, our LDAP data).
>
>
> I have taken some Remedy courses but it has been a couple of years. Do
> you have any training recommendations for me? I am going to go the
> Education
> site now and look some things over. Thanks,
> Brad
>
>
>
> On 2/14/06, Susan Palmer < suzanpalmer@gmail.com> wrote:
>
>>
>> ** Brad,
>>
>>
>> NEVER show fear. Don't let the application own you, you must own it
>> and become it's master (so to speak). Make the application work for
>> you. Doesn't mean everything you do will work at first try, then you try
>> again. Part of it is designing, write it out on paper ... do a story
>> board showing all the steps, then add to it what workflow you think is
>> needed.
>>
>> Have you had any classes lately, maybe some are in order to give you
>> more confidence. Now that you are somewhat familiar with Remedy, you'll
>> grasp the concepts better. If they don't want to put out for education,
>> start reading the manuals (especially the concepts, tips and tricks,
>> then look up what needs to be done). Experiment. Don't think of it as
>> lost time, just learning curve. But, do put it on paper first!
>>
>> Now we want updates so we know how it is progressing,
>> Susan
>>
>>
>>
>> On 2/14/06, Brad Terhune < brad.terhune@gmail.com> wrote:
>>
>>>
>>> ** I have had a request from someone from another department who
>>> wants to utilize the Remedy system as a technician. They also want
>>> anyone on campus to be able to submit tickets into the Remedy system
>>> and have those tickets assigned to them automagically.
>>>
>>> Right now, our Helpdesk sets up Remedy tickets and assigns them to
>>> technicians, so this is something I have not tried before. I have
>>> eight fixed licenses and five floating licenses. I don't have a whole
>>> lot of space for new fixed or floating licenses to be assigned.
>>>
>>> Has anyone set up a system using Remedy Helpdesk where their entire
>>> user base (we have 4000 or so) creates tickets in Remedy Helpdesk and
>>> the tickets are routed automatically. I am really afraid of this
>>> project. Frankly, I am afraid it is beyond my skill (and time
>>> allocation) to implement. What do you all think? Thank you, Brad
>>> 20060125This posting was submitted with HTML
>>> in it
>>
>>
>> 20060125This posting was submitted with HTML
>> in it
>>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it



20060125This posting was submitted with HTML in it
20060125This posting was submitted with HTML in it

**
I know I am missing something really stupid, but I don't see where to map the field IDs to the LDAP values. I have moved all the tables over when I created the form based on inetorgperson (the fields start with Request ID, then move to fields out of the LDAP system). I have looked in the form properties and the properties of the fields but I just don't see where to map manually define what Request ID populates from. Thanks,
Brad


On 2/15/06, Grooms, Frederick W wrote:

**
Look in the definition of your vendor form. What do you have mapped for the EntryID (FieldID=1) field? The 2 most popular LDAP fields to map to are: uSNCreated or sAMAccountName. uSNCreated is probably the best since it is possible that sAMAccountName could be longer than 15 characters.

The error is stating that the LDAP field you have mapped to FieldID 1 does not have any data for the record you pulled up.

Fred



From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG ] On Behalf Of Brad Terhune
Sent: Wednesday, February 15, 2006 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: Submitter Mode and the Helpdesk Applications


**

All right. Going to try and tackle this thing one issue at at time.
I have ARDBC configured properly (can see the LDAP tables). I have picked one that seems to have all the demographics I need through the creation of a vendor form. I had an LDAP administrator check to make sure my distinguished name was correct as well. When I try to run a query I get "ARERR 100 Entry ID parameter is empty". It seemed too easy- was there something else I was supposed to do? Thanks,
Brad


On 2/15/06, Brad Terhune wrote:

Thanks guys. I think I needed that.

I have Submitter mode locked as of about an hour ago, and am trying right now to get the Remedy Requester application up on the MidTier to test it out. Little problem right off the bat- I had Work Log required and it gave me an error indicating it could not be blank even though it is not on the form. I made it optional and that went away. I logged in and submitted a case and it went to my service queue, as do all cases that Remedy wants to assign to someone but it doesn't know who.

Right now, everyone has a blank password in SHR:People and and their Remedy Login Name is their Net ID in upper case (LDAP uid).

I met with the LDAP fellow a while back and think I have AREA configured right, but I am not sure how to run a good test on it. Is there some way that I can test that interface? Right now, everything seems to authenticate out of the user form in Remedy. I went through the Advanced guide yesterday and have Cross Ref. and Unregistered users checked on the server. I also changed External Authentication RPC to 390695.

I will be checking out Buoyant Solutions and I am going to go grab some PDFs at the support site. Thanks again! You guys are excellent.



On 2/15/06, Roney Samuel wrote:

**
Hi Brad,
First of all Chill. I am sure with all that experience that you carry, It would be an easy piece of cake.

LDAP integration:
You can do an external authentication on Remedy using the AREA
LDAP plugin. Get in touch with your LDAP Administarator and get the
connection strings required for LDAP. This is a smooth Integration without
any problems. have a look at the Advanced guide for more details.


However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
With the submitter Mode as Locked you can allow any user with a Read Licence to submit any number of tickets.

If you change the Submitter mode to locked then each user can view his own
tickets and modify them without a fixed licence on the user tool as well as
on the mid tier.

Submitter Mode : Locked: Allows users who have their name in the Submitter
field to modify requests without a write license. This does not apply to
users with a Restricted Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is submitted,
the value in the Submitter field cannot be changed.

Sync the current SHR:People form with LDAP:
You can get this done by writing an escalation to run every night so that there can be a mass upload that could happen from the LDAP directory to the SHR:People form. let me know if you require more information on how to achieve this.




Can you all help me establish what I need to be studying?
You can read the ARS PDF Guides which clearly explains all kind of development need within ARS. You can also refer you Part 2 and Part 3 Admin Guides which is a very useful resource. You can also check out a couple of websites like the remedy support web, Buyoant Solution, Matt reinfields site to get some sample code. In case you need any, I believe tat you are just nervous, take some time off and start working I am sure with all your experience on ARS you would do a great job. And All of us on the ARSList are always there to help you.


Regards,
Roney Samuel Varghese



On 2/15/06, Brad Terhune wrote:

**

Well,
I think you all can see by my previous posts that I often find myself in a situation trying to implement things in the AR System that I don't have the skills for, and I seem to mess things up as often as I fix them.

I started with AR back in 1998 with the Helpdesk application so that we could moving more quickly. I went Administering AR and Helpdesk back in those days and got the rudimentary setup in place and customized the Remedy Support app that we still continue to use. I went back around 2003 and took the Administering #3 in ARS 6.3 and after that was able to get the MidTier functioning properly.

However, I have 4000 people on this campus and would like them to be able to get in with a Read license and submit their own tickets.
I would also like to sync the current SHR:People form with LDAP instead of Oracle HRIS data. And I would definitely like to sync login with our LDAP system. All of these things- I just don't know where to start.

I am the only AR admin here and I also manage our Helpdesk call center, our student and faculty computer labs and act as assistant supervisor to the tech support group. My time is limited.

Can you all help me establish what I need to be studying? I think I am all over the map- just shooting at problems as they come around and eventually I am going to break this darn thing if I am not careful. I have a lot of manuals- but I don't seem to have much documentation on the Helpdesk application right now.

I have not been able to set up a proper development server either so my changes really do have bad effects (if I don't tell the DBA to set aside a copy of the DB before doing them).

Thank you list, for all your invaluable help up to this point. You have been very kind. Regards,
Brad

ARS 6.3
Helpdesk 5.5
Windows Server 2003
Remote Oracle database



On 2/14/06, Stephen Earl wrote:

**
In our team we try to avoid working 'outside' AR System wherever possible, this is usually due to skills shortages and of course the fact that people are very very poor at documenting things.

To date we have not needed to write any 'code' for the work we do, and have several tie ins to other systems from our AR System, the only thing we've needed to add has been the croom consulting ARDBC plugins, which have helped us no end with many issues of data portability and enabled us to remove some old legacy scripts that did exist prior to their installation.

It may sometimes be slower or maybe a little harder to build rather than whipping out the Perl or Java API swiss army knife but so far we haven't come up against anything we haven't been able to handle 'inside' AR System.

Stephen


On 14/02/06, Will Du Chene wrote:

Personally, I would recommend some sort of programming - or at the very
least some sort of scripting - course.

There are many things which the AR System can do for you, but there is a
definite line in front of some of things that it cannot. If you want to
stretch past that point, you need to do some sort of API programming.

If you want to bridge the AR System and some of the applications on the
desktop, or develop new ones, then it is a necessity. Similarly, you can
write prorgrams or scripts to parse through large amounts of data, or
update x number of records in fairly short order.

Now before anyone starts holding their breath, let me say that programming
or scripting itself as it applies to the API does not have to be painful.
There are a number of resources available to make it an easy thing to pick
up. Hey - it looks great on the resume as well.

Some of the courses that are available from some of the external vendors
are not that bad. I remember one vendor had an intro to Perl class that
was three days. Another had an intro to VB that was about a week.

In short - it's not that bad and can really go a long ways into making
life easier.

I will also say that one of the things - perhaps this is a take off from
the other thread that I saw out here the other day and does not belong
here, but it is related - that one of things that really bugs me about the
AR System is that there is a good deal of promotion that depicts it as a
system that you can program without needing to know how to program. (The
other is that people call it 'coding' but I digress...)

IMHO - that is just so wrong on so many levels... Sure you can get by with
the basics (which is exactly what it is). Sure, you could do all of the
development within the AR System and tell yourself that it is for reasons
'portability.' Then again, you could still be using a horse and buggy
rather than a car. You could also walk to work instead of driving. My
question is: why would you?






On Tue, February 14, 2006 2:39 pm, Brad Terhune wrote:
> I seem to get really hung up on moving data from other sources into
> Remedy
> (big example, our LDAP data).
>
>
> I have taken some Remedy courses but it has been a couple of years. Do
> you have any training recommendations for me? I am going to go the
> Education
> site now and look some things over. Thanks,
> Brad
>
>
>
> On 2/14/06, Susan Palmer < suzanpalmer@gmail.com> wrote:
>
>>
>> ** Brad,
>>
>>
>> NEVER show fear. Don't let the application own you, you must own it
>> and become it's master (so to speak). Make the application work for
>> you. Doesn't mean everything you do will work at first try, then you try
>> again. Part of it is designing, write it out on paper ... do a story
>> board showing all the steps, then add to it what workflow you think is
>> needed.
>>
>> Have you had any classes lately, maybe some are in order to give you
>> more confidence. Now that you are somewhat familiar with Remedy, you'll
>> grasp the concepts better. If they don't want to put out for education,
>> start reading the manuals (especially the concepts, tips and tricks,
>> then look up what needs to be done). Experiment. Don't think of it as
>> lost time, just learning curve. But, do put it on paper first!
>>
>> Now we want updates so we know how it is progressing,
>> Susan
>>
>>
>>
>> On 2/14/06, Brad Terhune < brad.terhune@gmail.com> wrote:
>>
>>>
>>> ** I have had a request from someone from another department who
>>> wants to utilize the Remedy system as a technician. They also want
>>> anyone on campus to be able to submit tickets into the Remedy system
>>> and have those tickets assigned to them automagically.
>>>
>>> Right now, our Helpdesk sets up Remedy tickets and assigns them to
>>> technicians, so this is something I have not tried before. I have
>>> eight fixed licenses and five floating licenses. I don't have a whole
>>> lot of space for new fixed or floating licenses to be assigned.
>>>
>>> Has anyone set up a system using Remedy Helpdesk where their entire
>>> user base (we have 4000 or so) creates tickets in Remedy Helpdesk and
>>> the tickets are routed automatically. I am really afraid of this
>>> project. Frankly, I am afraid it is beyond my skill (and time
>>> allocation) to implement. What do you all think? Thank you, Brad
>>> 20060125This posting was submitted with HTML
>>> in it
>>
>>
>> 20060125This posting was submitted with HTML
>> in it
>>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it



20060125This posting was submitted with HTML in it 20060125This posting was submitted with HTML in it


20060125This posting was submitted with HTML in it

The Database tab of the Field properties (FieldID is the top left field
and the Name field in the Vendor Information box is the LDAP field name)



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Brad Terhune
Sent: Wednesday, February 15, 2006 12:04 PM
To: arslist@ARSLIST.ORG
Subject: Re: Submitter Mode and the Helpdesk Applications


**
I know I am missing something really stupid, but I don't see where to
map the field IDs to the LDAP values. I have moved all the tables over
when I created the form based on inetorgperson (the fields start with
Request ID, then move to fields out of the LDAP system). I have looked
in the form properties and the properties of the fields but I just don't
see where to map manually define what Request ID populates from.
Thanks,
Brad


On 2/15/06, Grooms, Frederick W wrote:

**
Look in the definition of your vendor form. What do you have
mapped for the EntryID (FieldID=1) field? The 2 most popular LDAP
fields to map to are: uSNCreated or sAMAccountName. uSNCreated is
probably the best since it is possible that sAMAccountName could be
longer than 15 characters.

The error is stating that the LDAP field you have mapped to
FieldID 1 does not have any data for the record you pulled up.

Fred



From: Action Request System discussion list(ARSList) [mailto:


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.o

**
OK. Well, the values seem to have mapped themselves just fine with Request ID being the only one without a value. I specified uid under the Name field for it. Strange thing, the rest of the fields under the database tab indicate an Input Length of 0. When I change it and then click save, it reverts back to 0?

When I type in my uid and run Search on my vendor form I get a 1200- no matching requests or I don't have permission to requests. I just configured permissions and saved the form and tried again but still cannot get anything to come up. Any idea what I might be doing wrong? Thanks,
Brad


On 2/15/06, Grooms, Frederick W wrote:

The Database tab of the Field properties (FieldID is the top left field
and the Name field in the Vendor Information box is the LDAP field name)



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Brad Terhune
Sent: Wednesday, February 15, 2006 12:04 PM
To: arslist@ARSLIST.ORG
Subject: Re: Submitter Mode and the Helpdesk Applications


**
I know I am missing something really stupid, but I don't see where to
map the field IDs to the LDAP values. I have moved all the tables over
when I created the form based on inetorgperson (the fields start with
Request ID, then move to fields out of the LDAP system). I have looked
in the form properties and the properties of the fields but I just don't
see where to map manually define what Request ID populates from.
Thanks,
Brad


On 2/15/06, Grooms, Frederick W wrote:

**
Look in the definition of your vendor form. What do you have
mapped for the EntryID (FieldID=1) field? The 2 most popular LDAP
fields to map to are: uSNCreated or sAMAccountName. uSNCreated is
probably the best since it is possible that sAMAccountName could be
longer than 15 characters.

The error is stating that the LDAP field you have mapped to
FieldID 1 does not have any data for the record you pulled up.

Fred



From: Action Request System discussion list(ARSList) [mailto:


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org



20060125This posting was submitted with HTML in it

**
Are you sure uid is a valid field name in the ActiveDirectory. I just looked thru our AD 2003 and we do not have any field named uid. Change uid in the Name field to usncreated and see if that corrects your problem. On our ActiveDirectory the normal network login name field is samAccountName.

One good tool to get for diagnosing AD (or LDAP) problems is the LDP tool from Microsoft. Another is a free application called Softerra http://www.softerra.com/products/ldapbrowser.php

Fred



From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brad Terhune
Sent: Wednesday, February 15, 2006 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Submitter Mode and the Helpdesk Applications


**
OK. Well, the values seem to have mapped themselves just fine with Request ID being the only one without a value. I specified uid under the Name field for it. Strange thing, the rest of the fields under the database tab indicate an Input Length of 0. When I change it and then click save, it reverts back to 0?

When I type in my uid and run Search on my vendor form I get a 1200- no matching requests or I don't have permission to requests. I just configured permissions and saved the form and tried again but still cannot get anything to come up. Any idea what I might be doing wrong? Thanks,
Brad


On 2/15/06, Grooms, Frederick W wrote:

The Database tab of the Field properties (FieldID is the top left field
and the Name field in the Vendor Information box is the LDAP field name)



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Brad Terhune
Sent: Wednesday, February 15, 2006 12:04 PM
To: arslist@ARSLIST.ORG
Subject: Re: Submitter Mode and the Helpdesk Applications


**
I know I am missing something really stupid, but I don't see where to
map the field IDs to the LDAP values. I have moved all the tables over
when I created the form based on inetorgperson (the fields start with
Request ID, then move to fields out of the LDAP system). I have looked
in the form properties and the properties of the fields but I just don't
see where to map manually define what Request ID populates from.
Thanks,
Brad


On 2/15/06, Grooms, Frederick W wrote:

**
Look in the definition of your vendor form. What do you have
mapped for the EntryID (FieldID=1) field? The 2 most popular LDAP
fields to map to are: uSNCreated or sAMAccountName. uSNCreated is
probably the best since it is possible that sAMAccountName could be
longer than 15 characters.

The error is stating that the LDAP field you have mapped to
FieldID 1 does not have any data for the record you pulled up.

Fred



From: Action Request System discussion list(ARSList) [mailto:



20060125This posting was submitted with HTML in it