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"