The main reason I have to put entries for everyone active in eDir into
CTM:People and User is so that I can have the Requester Console and
Remedy Knowledge Management working for our customers
(faculty/staff/students).  They authenticate to eDir via AREA, but need
group membership in Incident Submitter and KMSAC-KMSUser in order to
operate the ITSM 7 console and forms.  Our eDir implementation contains
no group information or structure whatsoever, and since they are in the
throes of bringing up Active Directory and Exchange in the next few
months, they are planning no changes to eDir.
 
I guess I could be talking to them about AD, but since I have always had
a separate forest and will not be added to the enterprise forest, that
may not work.  What would the issues be with moving my integration for
ITSM 7 to AD???  I would need to have some _very_ specific needs defined
- they are completely immersed in a Dell-advised compressed-timeframe
conversion from NDS-GroupWise to AD-Exchange 2007 and not very receptive
to any additional requirements.  They have no immediate plan to drop
eDir since dozens of other campus systems from PeopleSoft to WebCT
authenticate to it the same way that my AR servers do, and draw
directory information from it that it loads from PeopleSoft.

Christopher Strauss, Ph.D.
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/helpdesk/ 


  _____  

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Molenda
Sent: Wednesday, May 09, 2007 1:12 PM
To: arslist@ARSLIST.ORG
Subject: Re: Why Import People into ITSM 7 at All?


** 

Very valid points on "all views and sides" of this conundrum...

 

Every customer's situation is unique, and has to be handled accordingly.

 

Many customers continue to struggle with the "Unique Data Source" for
many items, and the "people information" is just one of them. (take
Discovery / inventory tools between Unix / windows as an example)

 

Sometimes it is a very difficult and diverse topology of systems and
processes which even further complicate the issue concerning this data.

 

However, in order to provide timely and guaranteed service(s) as an ITSM
application this data "must exist somewhere".

 

At one point, during the implementation discussions of our "IDMS
(Identity Management System) -eDir solution" it was discussed as to
"what application", and obviously with the flexibility, ARSystem was on
the list... In the end, it was a tie between eDir and a ARSystem based
solution and the decision was to go with eDir. Fortunately for me, this
puts all of the "process issues" (which change on a daily cycle) in the
hands of the eDir team instead of mine :-)

 

I believe the main points in having the data inside ITSM, are:

 

You can sanity check / Clean Up the data during the data-feed-process to
prevent failures in your system (field length, value selections, etc).

 

ITSM 7 extends the permission-model using this information, and is
required for User setup (if you stay inside the box).

 

If the ITSM Application is functional, so is the "people data", because
if AD/eDir/SAP/xxx is down -or- has performance issues, the users
complain about the ITSM application and not the connected data-source

 

Unfortunately, or really fortunately for us, nothing is the same "cookie
cutter setup" at any 2 locations. Many times there are different
implementations of ITSM inside the same company. 

 

Of course this leaves me at the conundrum point to ask:

 

If companies consider people Assets instead of Expenses, why CTM:People
and not CMDB->Person Information???

 

CMDB has "Federated Data" concepts already!

 

Whoops, that is another can of worms :-)

 

GOOD TOPIC AND COMMENTS THOUGH!!! I know I like this list for things
other than "it is broken"...

 

Thanks-n-advance; 

HDT Platform Incident / Problem Manager & Architect 
Robert Molenda 
IT OS PA 
Tel: +1 408 503 2701 
Fax: +1 408 503 2912 
Mobile: +1 408 472 8097 
[EMAIL PROTECTED] 

Quality begins with your actions.

 

__20060125_______________________This posting was submitted with HTML in
it___ 

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Reply via email to