Hello everyone.
I have some experience with both of them. However my experience lies with SCOM 2007, not 2012. So, let me address that first. One of the things I learned through Microsoft was the functionally 2007 & 2012 were very similar (no significant architecture changes, more on that later). SCOM is primarily agent based, and its agent is very similar to sysEDGE (meaning it is designed to be "cookie cutter"). Basically you build a template, and then apply it to a bunch of servers. For example, I could build a log pattern match on any text file, given that the same path & file name are used on a bunch of servers, and apply that "rule" to each of those servers (so it doesn't have to be an Event Log as someone else mentioned). The alarm view (SCOM) is text-based, no graphics unless you purchase their mapping product. CA does have a "connector" which links Spectrum & SCOM together. At least this is how it worked between 2007 & Spectrum 9.x. Once you move to 2012, you need Orchestrator to create that "link" between the two. As to whom is responsible for that link, is presently unknown. Microsoft told me that the vendor (CA) would be responsible for building it. Last year (2013), it wasn't on CA's blackboard. Architecturally the biggest difference between 2007 & 2012 is that the function of Root Management Server [RMS] is now shared amongst all the Management servers [MS]. In 2007, you were required to have one RMS and one or more MS. A MS was supposed to manage "ideally" 500 servers, though in our environment it was managing about 800 servers. Microsoft changed the RMS requirement in 2012 and now that functionality is spread across each MS. I would say that Microsoft has a better foothold on monitoring SQL & Exchange being they have specific Management Packs (a set of rules & monitors) for each product. The way we used it. SCOM monitored our Windows environment (outside the DMZ) and its alarms reported to the Alarm view. Through CA's SCOM connector, alarms were passed to Spectrum's OneClick. If the alarm cleared on SCOM, it automatically cleared in OneClick. If you cleared the alarm in Spectrum, the communication would automatically clear it from SCOM. Unfortunately, the alarms received from SCOM all had a Generic Title (System Center Operations Manager Alert Received). Fortunately (for me), I was able to add certain keywords to the Log Pattern Rules I created. In turn (via EventDisp), I sought for those keywords and created my own Unique Spectrum alarms (so that we could route them automatically to ServiceDesk resolve groups). All in all, I see benefits to having both, however I can't see how SCOM can replace Spectrum. Hope this helps. Kind regards, Fred > From: john.villa...@sbcglobal.net > To: spectrum@listserv.unc.edu > Subject: RE: [spectrum] scom and spectrum > Date: Thu, 3 Jul 2014 08:22:30 -0700 > > Patrick, > > Roberth Edberg had an important comment in his response. His statement is > about relying on "ping" to monitor your network. My experience with SCOM was > in 2010 when we had two expert SCOM engineers try to monitor UPSs. The > fundamental way that SCOM would try to query the device was to send a request > to the device and then forget about it. SCOM had no concept of waiting to see > if the response was received; no concept of timeouts and retries. Please > understand, their experts were claiming that it could do everything better > than anyone else (we also had two engineers who worked for us and were MVPs > with SCOM). But they could not get it to work. > > I had been trying to get Spectrum in and we had a POC. During that POC, I was > able to create a management pack to monitor those same UPSs and I had not > used Spectrum for over 10 years. > > I was also quite surprised by the size of the infrastructure needed to run > the environment and provide fault tolerance. The infrastructure was larger > than what we were proposing if we were to bring in both Spectrum and eHealth; > and that was just for SCOM to monitor the production Windows server > environment (Spectrum and eHealth would have been for all network, servers, > UPSs, production and non-production, etc.) > > Since we already owned the Microsoft products in our licensing agreement with > them, we had to use them. So I hired a SCOM engineer just for this. I > interviewed dozens of engineers to find any who had experience with larger > environments and finally found one. But during the interview process, I ran > across a few who worked internally at Microsoft. They were using SCOM for > their server monitoring and forwarding all events to Micromuse. If you take a > look at their GUI, you would understand since it is not designed for a NOC. I > even had one of their consultants onsite doing working with our Exchange team > to get SCOM setup and he used to lament how Microsoft didn't even do things > they should. > > So, SCOM plays against systemEDGE, NimSoft and other server monitoring > agents. > > As you know, it is not just the cost of purchasing the software. Other > factors were the sustainability of the environment in monitoring your > critical assets. How well the GUI worked for the NOC / Operations staff that > needed to quickly resolve issues. > > If you could, have Microsoft take you to one of their customers who has > replaced Spectrum (or an equivalent system) with SCOM. See if you can sit > with them and watch how they use it to monitor their Infrastructure to > resolve issues. We were never able to find any organization who used SCOM as > the primary tool in their NOC. And I would not doubt that the only ones you > may find today are those who had nothing and then got SCOM. What you most > likely will find is that SCOM feeds a true MoM (Manager of Managers) like > SPECTRUM or Micromuse and the NOC uses that for all alerting. > > Regards, > John Villaire > > -----Original Message----- > From: Murtey, Patrick [mailto:pmur...@mgmresorts.com] > Sent: Thursday, July 03, 2014 7:42 AM > To: spectrum > Subject: RE: [spectrum] scom and spectrum > > Hi Stephen, > I agree with every body's comments so far. But that’s the problem. We don’t > know a thing about scom2012 and its capabilities, and all we have to go on is > what MS are telling us. That’s why we are asking the community to share what > they know. Does 2012 have the equivalent of NCM and SANM? Or some of the > other features of Spectrum. We would very much like to compile a comparison > checklist. Our only experience with scom was 8 years ago when it went from > mom to scom. We had just deployed a version of mom and barely had it running, > and a few months later MS came out and said that mom was rebranded as scom > and there was no upgrade path. Requiring a brand new fresh install and > re-configuration. We dropped it at that time feeling that the product was not > mature enough to take seriously. MS has assured us that this is no longer the > case with upgrades. Can anybody speak to that as well? > > Thanks > Patrick > > > -----Original Message----- > From: Schroeder, Stephen G CIV USARMY 7 SIG CMD (US) > [mailto:stephen.g.schroeder....@mail.mil] > Sent: Thursday, July 03, 2014 5:10 AM > To: spectrum > Subject: RE: [spectrum] scom and spectrum (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > If you are looking for server monitoring, they are very similar. Correct me > if I am wrong, but SCOM is not going to do NCM, SANM and other NETWORKING > functions. Where I work, we have both products and we use SCOM for Server > monitoring. Granted I do not work with SCOM so I am fully aware of what its > capabilities are but they were very similar we would not have spent the money > on getting Spectrum. > > Stephen > > -----Original Message----- > From: Murtey, Patrick [mailto:pmur...@mgmresorts.com] > Sent: Wednesday, July 02, 2014 4:51 PM > To: spectrum > Cc: spectrum > Subject: RE: [spectrum] scom and spectrum > > Hi Jason, > > We had Microsoft on site yesterday do a full court press. They are saying > that scom will do basically everything spectrum will do (minus the Fault > Isolation) . They say they can manage all flavors of Unix as well using OMI. > Besides the SQL monitoring which is a given, they are also claiming to > monitor Oracle as well. They also say that 2012 will be able to do log > monitoring. I am sure NT event logs is a given, but how comprehensive is the > third party log monitoring? They make it sound like there’s no need for 3rd > party agents to monitor logs with 2012. Anybody else able to provide feedback > as well? By the way I am referring to Spectrum IM 9.2.3. > > > > Thanks > > Patrick > > > > From: Jason Hebron [mailto:jason.heb...@gmail.com] > Sent: Wednesday, July 02, 2014 1:33 PM > To: Murtey, Patrick > Cc: spectrum > Subject: Re: [spectrum] scom and spectrum > > > > By Spectrum do you mean the CA IM 2.0 suite? > > One of the big questions - what are you wanting to monitor? > > For windows systems SCOM is highly effective > > For Network Spectrum is close to unbeatable > > For Unix/Linux using the correct agents I would use CA IM 2.0 > > > > On 3 July 2014 08:18, Murtey, Patrick <pmur...@mgmresorts.com> wrote: > > Hi All, > > We are looking for those of you out there that have had experience with > scom2012. Can you tell us what the major differences between scom2012 and > Spectrum? Like what does one do better than the other? Pros and cons ( aside > from fault isolation, which I don't believe anybody else does) . > > Thank you very much > Patrick > > --- > To unsubscribe from spectrum, send email to lists...@unc.edu with the body: > unsubscribe spectrum jason.heb...@gmail.com > > > > * --To unsubscribe from spectrum, send email to lists...@unc.edu with the > body: unsubscribe spectrum stephen.g.schroeder....@mail.mil > > > Classification: UNCLASSIFIED > Caveats: NONE > > > > --- > To unsubscribe from spectrum, send email to lists...@unc.edu with the body: > unsubscribe spectrum john.villa...@sbcglobal.net > > > --- > To unsubscribe from spectrum, send email to lists...@unc.edu with the body: > unsubscribe spectrum fjrut...@hotmail.com --- To unsubscribe from spectrum, send email to lists...@unc.edu with the body: unsubscribe spectrum arch...@mail-archive.com
