Having done the SMS to CMDB thing ... (using EIE and custom code.. a lot faster!!).... Norm is correct in specifying that the "Last Logged In User" is not necessarily correct under all circumstances. What we have done in CMDB 1.1 is only allow "one" User-to-Computer relationship to be defined for the SMS interface, but allow any number of other User-to-Computer relationships entered by anyone else for the same asset. This allows the "HAND-JAM" and SMS solution to co-exist.
So this is what happens: - If the SMS interface notices that there is a user-to-computer relationship that it (ie. the SMS interface) has created previously and the current value of the logged-in-user is different than the current relationship, it deletes the old relationship (this is audit logged) and creates the new one. - If the SMS interface notices that there are no user-to-computer relationships that it (ie. the SMS interface) has created previously for this asset, it creates a new one. - If the SMS interface notices that there is a user-to-computer relationship that it (ie. the SMS interface) has created previously and the current value of the logged-in-user is the same as the current relationship, it does nothing. That was the best that we could do... allow automation and 'HAND-JAM" to co-exist..... Terry -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Thursday, June 28, 2007 3:08 PM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB (U) The issue I'm raising isn't that there isn't a unique method of identifying a machine...there are clearly--as you well point out--several options there. Another one would be MAC address. It's probably not as good as IUID, but good enough. That's what we use here in our homegrown asset system and it works fine. The issue is related to the fact that so many people tout the User to Computer relationship as a benefit of CMDB. My heartburn is, WHERE DOES THE RELATIONSHIP COME FROM?! In many environments, I contend, the only way is to HAND-JAM it. Using a discovery tool of any sort will very often--if not MOST often--deliver the WRONG answer because the data these solutions typically rely on is the LAST LOGON attribute, which for reasons I've already pointed out in an earlier post is not reliable. So if you cannot discover it, you must HAND JAM it...and then keep it current...day in, day out, day in, day out... -----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 2:01 PM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB (U) UNCLASSIFIED Not yet using CMDB. We are using the IUID in Asset Management. Gov't purchasing requires that companies we purchase from provide it and we use a barcode scanner to bring in new data. The IUID is actually a construct; routinely make, model, serial number. Dell, for one, will provide a terrific data file for the equipment purchased, identifying items by the IUID. On receipt of the data file, usually a week or two after equipment delivery, we know just what should have been received. And from the scan at the warehouse, we know what was actually received. The scan imports directly to the Asset record and I have a form to which I import the data file. An Escalation synchs the new data with the Asset Record, matching by IUID and Serial number. After synching, the Status of a Validate record is changed to "Completed". Records that didn't synch we know by Status and know what doesn't match between the files. For the CMDB, my plan is to use a Discovery tool. BeLarc System Management Discovery tool is one product that will pull the IUID from the BIOS. YOU set up when to scan, when to synch data. 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 1:42 PM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB (U) 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" ________________________________________________________________________ _______ 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
