Database sizing, and really - filesystem I/OPs are the key to something large like this. SCOM can more than handle it, as long as things are implemented using good practices and the like - of which I don't doubt you know all about so I don't need to go into more about that. Per Program Group, using an environment scoped to align with what the Sizing Guide recommends, SCOM can discover 1.2 million entities and calculate 120,000 group memberships in under 24 hours (Approx. time is 20 hours), so the infrastructure is no problem - as long as the DB backend is solid.
When teams get all hand wavey and try to push the requirements gathering off onto you, it can be rough. Especially when you're trying to monitor an application with disparate systems - some of which we can monitor easily, others not so much. I've run into this a lot. To a lot of customers a "Distributed Application" is just "We move data from one place to another". They try to use our DA designer to model it and get frustrated - because they aren't *really* using a distributed app as we see it - as the modern world sees it. In those cases, you might want to throw together some handouts for them. If they want you to monitor their system, you need to know things: 1. When they come into work in the morning, how do they know the system (Or the part they're responsible for) is running correctly? Do they login to something, click somewhere, check a few things? If so, what? 2. If the application has an issue, how do they find out? Do the end users call in, or do they notice it? How do they notice it? 3. What are the initial troubleshooting steps they take to figure out whats wrong, or which layer of their app the problem lies? And when I say "What are the steps", I mean literally "Tell me what you do". If it's a grumpy system that has a lot of slow downs and/or downtime, I ask them to call me as soon as something happens and then watch over their shoulder and take notes. You have to build the groundwork before you can give them an over-arching monitor and dashboards. You know this though, I'm sure. About licensing, the way you worded it "Because of how we're licensed for the System Center Suite" makes me think you really need to prod a little bit more. Based on that, I assume he is telling you you are licensed for the Datacenter System Center Suite. Part of that says: "# of Managed Operating System Environments (OSEs) Per License: UNLIMITED" A Windows desktop is not considered a Managed OSE. Managed OSEs are Servers, basically. Linux, Unix, Windows, doesn't matter. If its a server environment, it's part of that 'unlimited'. To use it on a desktop environment, you need a Client license. Now, a lot of customers are licensed for clients - but only (and typically) for SCCM and/or Endpoint protection. Those licenses are included in the "Core CAL Suite". The license that allows for the desktop monitoring with SCOM is only available in the "Enterprise CAL Suite", which also gives you rights to use Orchestrator, DPM, SCSM as well as SCOM on the desktop side. So the question to ask him is "What kind of CAL suite are licensed for?" I like tiered Management Groups when it comes to monitoring a mix of Servers AND Desktops. Mainly because you have to modify a lot of how the core of SCOM works on the client side (Assuming we're talking about more than just desktops, but laptops) to clean things up; re-working/disabling how heartbeats work, adjusting queue sizes to take into account systems that are on but not connected to the corp, etc. Sure, you could do all of it in one group - but to me it just seems so much cleaner to do it in tiers. Also, it's good to be back - though to be honest I've been lurking forever, its just you brought up something that I've just been working on! On Fri, Jan 8, 2016 at 11:56 AM, Steven Peck <[email protected]> wrote: > Hmm… hadn’t thought about database sizing. Our major in house > application is client based to a back end. Parts of which are Linux > hosted, parts are on Windows and some bits still on mainframe. They seem > to have this vague vision of’ monitoring something and when you ask about > details they get all hand wavey and try and make the requirements my > responsibility (which is so not going to happen). > > Our licensing guy claims we are licensed for desktop because of the way we > are licensed for the System Center Suite… I suspect he asked about > something else but that’s not my issue at the moment. If it looks more > serious then I will insist on a more specific answer. Depending on ‘what > they actually mean’ it could be 200 desktops to 2000. it’s unlikely to be > all 5000 of them. Unfortunately I have some monitors that I may be forced > to revisit for alerting on (system grey agent’ for one). I will also be > suggesting an additional head count. > > Tiered…. hmm… going to have to look at that. Currently both > environments (Preproduction and Production have separate SCOM installs, > it’s not as clean cut as I would like though) have 2 Management servers > each and a couple of gateways. > > > Oh, and good seeing you again Jeremy. > > Steven > > > ------------------------------ > Date: Wed, 6 Jan 2016 14:12:46 -0500 > Subject: Re: [msmom] SCOM Desktop monitoring > From: [email protected] > To: [email protected] > > > Yup, seriously. And I work for Microsoft. Cost is an issue - 13,000 client > licenses cost $150,000, but the larger part is that they were all laptops. > Someone mentioned Systrack, which is actually what SCOM replaced. > It hasn't been completely rolled out, I'm still trying to instill some > things into the customer - mainly, when you have laptops that aren't using > DirectAccess or some other 'always on' vpn, it will make SCOM not work - > unless you OMS, which is has a monitoring agent (The same agent in v.next) > that allows reporting to a SCOM MS & an OMS workspace - you have to write a > lot of things to deal with offline agents. > > That being said, the customer has an employee that basically got > everything in place, had licenses ordered, kicked out systrack, etc - so > our job was to show it could work, and it can. They also monitor servers, > but in a tiered fashion. The SERVER-MG is parent and CLIENTS-MG is child > and handles communication between laptops and SCOM. > Hardware wise, it wasn't bad. 6 MS will cover all of them. But the DB > servers have to be beastly. In fact, the DW server consists of a 40 disk > RAID10 just for the data. But we were able to show that it would work, and > even show some neat additional things, like being able to detect when users > need a beefier machine, etc etc. I'll try to go into more detail this > evening. > > On Wed, Jan 6, 2016 at 1:15 PM, Marcum, John <[email protected]> wrote: > > Seriously? Every time I’ve even thought about doing that all the SCOM guys > and MS folks tell me it’s insane to even think about doing it. I only have > 1000 desktops where I am now and I was told it was an insane idea. > > > * ------------------------------ * > > * John Marcum* > > MCITP, MCTS, MCSA > * Desktop Architect* > > * Bradley Arant Boult Cummings LLP* > * ------------------------------ * > > > > [image: H_Logo] > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Jeremy Pavleck > *Sent:* Wednesday, January 6, 2016 11:57 AM > *To:* [email protected] > *Subject:* Re: [msmom] SCOM Desktop monitoring > > > > I will get back to you in more detail when I can, but yes I have > experience. In fact, we just rolled out SCOM monitoring to 13,000 desktops. > > > > On Wed, Jan 6, 2016 at 12:07 PM, Steven Peck <[email protected]> wrote: > > I am beginning some research into monitoring desktops with SCOM. Does > anyone know of a good best practices document or write up on doing this? > Currently all my experience is with server monitoring. The request is > typically vague at this point but I want to at least get an overview. > Checking on the current sources now (TechNet docs) but figured I would ask > if anyone knew of something more specific. Like is it even a good idea to > mix server and client monitoring in a mid sized environment? (~1300 > servers monitored currently) > > > > Thanks, > > Steven Peck > > http://www.blkmtn.org > > > > > > > > > ------------------------------ > > > Confidentiality Notice: This e-mail is from a law firm and may be > protected by the attorney-client or work product privileges. If you have > received this message in error, please notify the sender by replying to > this e-mail and then delete it from your computer. > > > > >
