You're putting this information in your CMDB through some automated process? How often does it run?
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Thursday, June 28, 2007 11:55 AM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB (U) UNCLASSIFIED *****You don't set the owner relationship from a last logon value!" OK, fine...where does it come from, then?**** Using the Item Unique Identification (IUID) label, read from the system BIOS (Label is also affixed to machine) is one method to determine "the" machine. Sandra Hennigan Enterprise Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant Apparently, there is nothing that cannot happen today. Mark Twain -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Thursday, June 28, 2007 12:09 PM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB ** I don't know folks...I'm still not seeing it. Again, I understand the theory, but in the REAL WORLD I don't much practicality in it. You made a great point-if I want to link incident to asset, I could pull from the auto-discovery inventory...not pull from redundant data in the Remedy server. That alone presents issues-how, exactly, do you identify the true user of a workstation? Here in our environment we have thousands of machines that are logged onto by multiple users. Who's the owner? One day a fighter pilot logs onto machine A to check his email. The auto-discovery runs and "identifies" the pilot as the "owner" of machine A. The next day, the navigator logs onto machine A and gets an error when he tries to open email. So he calls the Help Desk. The Help Desk analyst says, "Hey...let's use this newfangled ringy-dingy ITSM thing to figure out what machine he's working on..." but lo and behold the thing does not show that the navigator is using machine A, because as far as it knows, machine A is owned by the fighter pilot... So then you say, "Oh, no, no, no, Norm! You don't set the owner relationship from a last logon value!" OK, fine...where does it come from, then? My point-data does not "magically" appear in the CMDB. It gets there via two different methods-some automated pull or by hand-jam. But the automated pull runs on some delayed schedule from another data source that, in turn, may run on an automated schedule. Thus, the data is STALE. In order to realize the benefits a lot of folks are touting, DATA MUST BE REAL-TIME or darned-near close to it. _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of David Sanders Sent: Thursday, June 28, 2007 10:40 AM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB Hi Norm Well, look at it from another angle. Does a CMDB add value at the center of your service desk operations when all break/fix incidents and planned change requests are linked to the relevant CI records? For Incidents, you build up a picture not only of frequent Requesters (training issues highlighted?), but also of problem hardware types or patterns of issues that can then be addressed separately (as Problem tickets?). For change requests, the ONLY way you stand a chance of managing changes is if you have clearly identified what assets or other CIs are being changed, evaluate and authorize the changes, and than afterwards review what has been done. Discovery tools may give you an asset inventory to do part of this, and may discover some physical topology (this database runs on this virtual server, on this hardware; it uses this switch/router etc.). What auto-discovery can't give you is how this fits into business processes, like this database is used for payroll, which is part of HR systems, and who the dba is, who the Payroll and HR business owners are, etc. If changes are planned to this database, the owner of the HR processes may need to be informed and to approve the change and the schedule. The change may need to be assigned to the correct dba. The Incident linking part you can probably do with just auto-discovered asset inventory, but the change stuff really needs the business context information to be useful. A decent CMDB will provide the business context around the asset inventory, and will include people and process links. It will allow you to assess risk, business disruption and costs, and plan changes properly. There is value there, but I'm not sure if that value justifies the cost and effort involved in acquiring and maintaining Atrium and SIM for your organization. Only you can answer that question. Regards David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS Concepts Guide <http://www.westoverconsulting.co.uk/downloads/ESS_Concepts_Guide.pdf> tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk <http://www.westoverconsulting.co.uk/> _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Thursday, June 28, 2007 2:40 PM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB I think we're coming at this from two different perspectives. Agreed--the CMDB might be somewhat useful if you are in an environment where NO OTHER AUTOMATION TOOLS EXIST. But I was coming at this from the perspective that certain "standard" network monitoring/management tools are already in place--HPOV, AD, SMS, SNMP, etc. For the sake of keeping a fruitful discussion alive, allow me to counter: __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
