The first thing to consider is if your Remedy CMDB is being populated from a discovery source? What you have to know is if the Remedy CMDB is already populated with the detail data that you need for your incidents. Best practice would be to have your CMDB updated with current information, what I call "discovery". If you have a basic discovery process or procedure and you feel all your CI's are in the CMDB, then you may only need to do what I call "enrichment" which is adding specific data from other external sources that is not being populated by your discovery process. So in short you need to have your house in order with respect to your Remedy CMDB before you start inserting incidents and want to leverage additional information on the incident. If it was me, I would associate the affected CI to the incident when you do the submission through Orchestrator. You could also provide this detail in the description on the incident and forgo the association to the CI, but that would not provide the full picture. The other ITSM modules leverage incidents and associated CI's to perform to their full capacity and provide the value from your investment.
To answer your questions: 1. It can be considered similar, M$ has another product in the System Center suite that provides similar functionality as Remedy Incident called System Center Service Manager. However it does not measure up to the functionality offered by the BMC ITSM suite of applications at this time. 2. As I mentioned above, if all the data you need is in the CMDB already, then nothing is required here. If not, then you need to have an external process synchronizing the data. You could potentially do this during the incident creation so that when the incident is created, the CI is current at the time of submission. However, this would be a significant effort. You will need to get specific metrics on the timeliness of this requirement before you can ever hope to fulfill it. 3. This is a very broad question. SCCM is a system management tool. It pulls its information from the hosts that have the client installed. The direction of synchronization would be from SCCM into the CMDB. One direction only. This would involve an understanding of the reconciliation process within Remedy as well as an understanding of where the attributes "source of truth" is to do this correctly. 4. Yes this is possible, this would take multiple mappings of the data within SCCM to the CI classes and the relationships between those classes. If there is off the shelf software to do this, you would be well advised to investigate it. This can be a big job, depending on how much detail you want in your CMDB from your discovery data. Does this make it clearer? From: vivek garg [mailto:anupgar...@gmail.com] Sent: Wednesday, May 08, 2013 12:51 PM Subject: Re: Remedy Integration with SCOM ** Hi Jim, Thanks for the solution. However, Please help me understand more on this "Use data from SCCM to feed your CMDB (basically your discovery source) using AIE or AI. This will ensure you have the data in your CMDB." I know that remedy CMDB is very huge database and I am totally new to SCCM. CMDB has various classes (Endpoint, Computer system etc.) and I want to know even If I create a job using AI ,then what would I map in data mapping process on both side (SCCM and Remedy CMDB). 1. Is SCCM is similar in anyway to Remedy CMDB ? 2. Which data from SCCM I have to put into Remedy CMDB? 3. would I be able to keep both SCCM and CMDB data in sync ? 4. Could SCCM also provide us the information about all related componenets that CMDB is capable of ? Please suggest. Thanks & Regards, anup On Wed, May 8, 2013 at 8:04 PM, Jim Coryat (jcoryat) <jcor...@micron.com<mailto:jcor...@micron.com>> wrote: ** SCOM does have a list of the hosts that it is monitoring. When you install the SCOM agent, it does a register with the server. SCOM does not contain all information, it just holds what it needs to do the alerting and monitoring. Fortunately, SCCM does contain that information. :) Using the tools you have indicated, I would do this using this approach: 1) Use data from SCCM to feed your CMDB (basically your discovery source) using AIE or AI. This will ensure you have the data in your CMDB. 2) Setup monitoring on the hosts using SCOM 3) Configure Orchestrator to catch those SCOM alerts that you are truly interested in. Use the SCCM OIP to retrieve the information about the host you need to create the incident. Using that data within Orchestrator, use the standard OOB Remedy web services to submit the incident within the same workflow you retrieved the data in. The only variant on this would be to use a database query in the workflow to retrieve the detail data about the host instead of the SCCM OIP. And this would be only if for some reason the SCCM OIP did not provide the data you needed. These pieces of workflow are standard within the OOB Orchestrator environment. You will need to read up on the Orchestrator environment to build the workflow however. Hopefully this is helpful. Jim Coryat From: Saji Philip [mailto:sphili...@gmail.com<mailto:sphili...@gmail.com>] Sent: Tuesday, May 07, 2013 9:11 PM Subject: Re: Remedy Integration with SCOM ** Also, Seamless technologies offers a SCOM connector for Remedy. More expensive then Kelverion though. On May 3, 2013 10:30 PM, "vivek garg" <anupgar...@gmail.com<mailto:anupgar...@gmail.com>> wrote: ** But How would I get the data into remedy CMDB from SCOM. Does SCOM has it's own database which contains all information about CI's (like server's etc) ? First before integrating SCOM with Remedy we need to get synchronization between Remedy CMDB and SCOM as our requirement is that whenever any alert on any server comes, then the automatic incident opened in remedy should contain all information about that server (like sever name, it's configuration ,etc.). How would I ensure that ? I will try to see what could help me to integrate remedy with SCOM. The issue is that we do have a lincense for Orchestrator but we could not purchase any license for Integration packs or connectors from Keleverion so I am not sure we could use it or not :( The only tools I could use is Systems center Operations Manager and System center Orchestrator. Is this integration possible using these two ? And we have to use windows 2012 and SCOM 2012 only :( Please suggest. On Fri, May 3, 2013 at 8:31 PM, Pierson, Shawn <shawn.pier...@energytransfer.com<mailto:shawn.pier...@energytransfer.com>> wrote: ** This is something I may be looking at in the next year or two as well so I wanted to jump in and ask a question. For other integrations leveraging web services, I like to use Incident Templates, for example, to create Incidents. That way I can dynamically change the data on the Template to affect what the Integration does, without needing to actually modify code. Would that be an option in this case to make the integration easier? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Jim Coryat (jcoryat) Sent: Friday, May 03, 2013 9:15 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Remedy Integration with SCOM ** We have Remedy and System Center. We are currently upgrading to Orchestrator 2012 along with all the other components (essentially System Center 2012). What you need for this to work (IMHO) is along with SCOM is Orchestrator and the Orchestrator Integration Pack (OIP) from Kelveriron and the OIP from Microsoft for SCOM. You could roll your own Remedy OIP using queries and consume the remedy web service to submit the incident if so inclined. This is what it appears the OIP from Kelveriron is doing, but that is from a cursory examination. The plus side is that you don't have to put the client binaries on the Orchestrator server. The integration pack that worked with Opalis (now known as Orchestrator) worked a little differently and frankly I think was much easier to use, but it doesn't work with Orchestrator. The only real challenge I see with the Kelveriron OIP is mapping your data to the new Remedy incident. If you have a lot of fields it becomes tedious. Use the SCOM OIP to catch the event, use the sql query to get your information about the host that is throwing the event and then submit using the Remedy OIP. Not really all that difficult until you start getting the request to treat different hosts with unique behavior. Jim From: Saji Philip [mailto:sphili...@gmail.com] Sent: Thursday, May 02, 2013 9:10 PM Subject: Re: Remedy Integration with SCOM ** I have documentation from Kelverion I can forward to you. Systems Center Orhestrator was formerly called Opalis. If your running Microsoft you should already own it. Theres quite a few documantation on Orhestrator on the Microsoft website. Just send me your contact info to 'sphili...@hotmail.com<mailto:sphili...@hotmail.com>' On May 2, 2013 9:58 PM, "Rick Cook" <remedyr...@gmail.com<mailto:remedyr...@gmail.com>> wrote: ** I have built a couple of simple things in the Opalis Orchestrator, but that was a few years ago. I would do some digging on Microsoft's website to get more current information. Rick On May 2, 2013 7:54 PM, "vivek garg" <anupgar...@gmail.com<mailto:anupgar...@gmail.com>> wrote: ** Hi Rick ,Saji, If I start learning system center orchestrater, then how should I start and from where should I learn about it as I have no prior knowledge on orchestrator or on System center. Do you have any kind of documentation which would help me understand this type of integration. Even I read soemwhere that Using orchestrator would be best option for these type of integrations. Rick, Have you done it without using orchestrator? On Fri, May 3, 2013 at 8:15 AM, Rick Cook <remedyr...@gmail.com<mailto:remedyr...@gmail.com>> wrote: ** It seemed as though the new MS app, formerly known as Opalis, was similar in its build interface to the Remedy Abydos designer. I would think there would be a CLI/API connection that would work. Rick On May 2, 2013 7:36 PM, "Saji Philip" <sphili...@gmail.com<mailto:sphili...@gmail.com>> wrote: ** We use the Microsoft integration to create Remedy incidents from SCOM 2007. We are in the process of upgrading SCOM to 2012 and microsoft no longer supports that connection. The new way is using Systems Center Orhestrater and run books utilizing a connector developed by Kelverion. I hear Kelverion is working on a similar API connector used by Microsoft and it will be more functional (not creating just tickets). Not sure if BAO can be used to integrate with SCOM.. On May 2, 2013 9:13 PM, "Anup Garg" <anupgar...@gmail.com<mailto:anupgar...@gmail.com>> wrote: Hi, I am working on bmc remedy version 7.6.04 SP2 on windows 2008 R2 and SQL server 2008 R2 . I need some help on steps required to integrate SCOM with BMC Remedy. Our requirement is like as follows : SCOM should raise an alert whenever any server goes down and then from that alert an incident should be created automatically in BMC Remedy with the information to be picked up from CMDB about that server. Our incident should autmatically populates the entire summary about that server(CI in atrium cmdb) . Is it possible ? Please share some steps or any dcoument if anyone has done that before. Thanks, Anup _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org/> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here<http://www.energytransfer.com/mail_disclaimer.aspx>. If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
