I didn't size/build this environment but I got it handed back to me after the previous two people who were 'going to do it right' didn't do anything for X to long. They did build it with input from some burned premiere consulting hours, but it was sized for a set number of servers and then left un-deployed for 4 months. It wasn't sized for desktops or the intermittent connections that occur with them. My view on the licensing is pretty much what you've just said. Our licensing guy can be a little lazy on details. Nothing I have ever participated in has gotten dinged but perhaps others might have had to 'true up' at the end of the year and had those wonderful meetings where 'how did this happen' discussions occur. It may very well be that we have these Enterprise CAL suite licenses. We are not small and he was complaining about cost so we'll see. Anyway, with the thread I have enough basic information to force them to give me some numbers, goals and what they want to accomplish with some equally vague 'there will be design work involved and maybe bigger database, etc' as a reply. Along with THIS IS A PROJECT I need headcount as well. Right now it's literally just me. In theory I just got moved to the 'Enterprise Systems Management' team which is monitoring. HP OMU, SCOM (now) and one other. There are three of us. My new manager expects us all to fully cross train on all three products ( "underneath they're just the same thing right?" <- direct quote). So far time has remained lacking and elusive. Honestly, with major senior management changes here, obvious outsourcing in some areas and the improving economy, I may update my resume as well. :). Bah we'll see. Thanks, Steven
Date: Fri, 8 Jan 2016 16:04:54 -0500 Subject: Re: [msmom] SCOM Desktop monitoring From: [email protected] To: [email protected] 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 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.
