Book Review: System Center 2012 Configuration Manager: Mastering the Fundamentals

There are handful of books on SCCM 2012, all of them good in their own right, but what I love about this book is its practicality. The book is not about giving you a history of SCCM, or explaining the inner complexities of features, or in deriving much of its content from blog posts that are curated together in a mildly organized fashion. The book is about giving you an efficient primer of how to install and put SCCM 2012 and many of its most commonly used features into production in your environment.

One of my biggest criticisms of some of the other System Center books is that there is a tendency to gloss over huge pieces of relevant information–like how to install SQL for example. All too often there will be a Step One- find a SQL DBA and have them install SQL properly for you. This is great, but not everyone has a competent SQL DBA. Kent is not afraid to get his hands dirty with SQL, and gives invaluable best practice advice like setting min and max values for memory consumption in SQL Management Studio as well as sharing his entire SQL Configuration.ini file so that you can setup your SQL server exactly as he does for his clients. (Granted the storage/hardware that you run it on will vary and this must be kept in mind, but this type of instruction is sadly lacking from most of the large orange books that while I find useful are often more suited to killing scary insects.)

The key to understanding this book is it teaches, where other books tell. I don’t want you to tell me how awesome SCCM can be, I want to be taught how to put in into production so that I can tinker with it and learn and then I can take a deeper dive at a later date with a thicker book.

I used this as a guide to setup SCCM 2012 SP1 with SQL 2012 SP1 so I had to be a little creative at times on the SQL side, but for the most part it still serves a great introduction to SCCM 2012 and SCCM 2012 SP1.

System Center 2012 Configuration Manager Kent Agerlund

System Center 2012 Configuration Manager: Mastering the Fundamentals

I am also very excited to learn that the SP1 2nd edition to this book is due to be out anytime now.


How do I: Monitor a service and automatically restart it if it stops (SCOM 2012)

1. Go to Authoring – Management Pack Objects – Monitors

SCOM Monitor 001

2. Right Click Monitors – Create Monitor – Unit Monitor…



3. As always do no save anything to the Default Management Pack, if you have a custom management pack where you want to save the monitor if now click New


4.  Name your Management Pack – Next


5. Click Create


6. Windows Services – Basic Service Monitor – Next


7. a. Name your Monitor (I recommend the naming convention: unique prefix which should be a part of every custom rule/monitor/group-Servername-ServiceName)

b. Select a Monitor Target (Monitor Target Scope must apply to the server that contains the service you want to monitor. If you target Server 2003 and the Server that contains the service you want to monitor is Server 2008 you monitor won’t work)

c. Uncheck Monitor is enabled (You do not want to leave the this checked. If you do SCOM will try to monitor for this service on all Servers based on the monitor target even if they don’t contain the service you are trying to monitor. You will narrow the scope further and enable the monitor via an override once you are finished building it.)


8.  If you know the name the of the Service you can just type it in, but I recommend clicking the …selection button to point the monitor to the exact name of the service you want to monitor to avoid troubleshooting later on.


9. By default it will pull the available services from the management server you are running the console to see services from a different server click the … button and browse to your desired server.


10. For this example I am selecting the WMI Winmgmt service


11. Next


12. Generate alerts for this monitor – Automatically resolve the alert when the monitor returns to a healthy state – Create


13. Find your newly created monitor by searching for your custom prefix: ops-


14. Right click your new monitor – Overrides – Overide the Monitor – For a specific object of class: Windows Server 2008 R2 Full Operating System


15. Select the specific server that you want to monitor:


16. Enabled – Override Value – True (This will activate this service monitor for the associated server) – Apply – Show Monitor Properties


17. Configure recovery tasks – Add

Diagnostic and Recovery tasks2

18. Add – Recovery for critical health state

add recovery task

19. Run Command

run command

21. Name Recovery – Run recovery automatically – Recalculate monitor state after recovery finished

Start Service

22.  Enter the following items Parameter will vary based on the name of the service you are trying to recover automatically.


23. Once your Override and recovery are in place schedule a time when it is ok to stop the service you are trying to monitor/recover so that you can observe the behavior to insure you made no errors as well as to see if you want to tweak the timeout.

Intelligent thoughts from MMS on BYOD/VDI/MDM and IT Strategy

Even though most of my day to day work life is grounded in the operations and infrastructure space I still like to try to keep informed of what my former colleagues in the desktop world are up to. Lately at work there has been increasing  rumblings about BYOD in conjunction with VDI. It is strange, because while I can think of very specific use cases in which these are fantastic ideas, all too often the enthusiasm for the shiny new technology or approach seems to outpace and even forget the problem it was seeking to solve in the first place.

It is with this in mind that I highly recommend you take some time and listen to Eduardo Kassner’s talk from MMS 2013 this year entitled “Develop a Successful Flexible Desktop Strategy in Today’s Digital Era.” Eduardo is a former CIO and veteran of the IT industry who has a certain talent for cutting through technology hype/BS in a way that is blunt, honest, and refreshing. What he has to say is not always easy to hear, but it is definitely worth your time.

“When I ask you what is your strategy I am looking for you to look really really well into what you want to achieve?

Are you here to make to your end user experience better?

Are you here to give them more flexibility?

Are you here to reduce your cost of operations?

You can’t say yes to all those. It doesn’t work.

So if you say, I want cheaper, faster, better, and prettier– it’s a NO.

So you are going to have to let go of something there. What I am trying to say is if you don’t have this goal defined everything else that I am going to talk about today doesn’t matter. It is the hardest part, it is the most boring part, and it is the most critical.”

Channel 9


Building Better Service Level Dashboards

Microsoft has added a lot of functionality into SCOM 2012 to make creating dashboards easy. The only problem is they have given you a blank canvas without much in the way of guidance. This can be great, but it can also be problematic. The fact that you can make a 9 cell grid layout filled with graphs and data doesn’t mean that you should.

What you should do, is strive to build effective dashboards.  What is an effective dashboard? There is no right answer– I am making up the phrase– though I would argue that effective dashboards are ones in which the dashboard is designed to give insight into a service with a specific audience in mind.

A dashboard that is useful for your engineers or sysadmins is going to–OR SHOULD–look very different from a dashboard for Tier I support. Much like a dashboard for Tier I should look different from a dashboard for non IT customers. I like to break down service level dashboards into specific sub categories based on audience.

For the sake of this post lets divide potential dashboards into three groups:

1. Dashboards for non technical internal clients often published on an internal sharepoint site.

2. Dashboards for Tier I Support and upper IT management published via limited rights login to SCOM web console.

3. Dashboards for Systems engineers and Sysadmins.

Obviously this is going to vary greatly depending on what business you are in, but you get the idea.

I think in general we tend to do a pretty good job with 1 and 3.  Service Level Dashboards for non technical internal clients just need to provide basic information: is the service up or down, and to the best of our monitoring ability how well are we meeting the SLA?

The out of box Service Level Dashboard in SCOM 2012 does this quite effectively:

I say to the best of our ability above, because even with synthetic transactions there is always the possibility that a complex service can be degraded or down in some respect without your monitors picking up on it. (Exchange servers are up and running perfectly, but your BES server for Blackberries is down.) Or alternatively, your monitoring picks up a problem, but isn’t smart enough to correlate it into a change in the dashboard.  At best service monitoring is an evolutionary process not one that you set up and leave alone. IT Managers may not want to hear it, but ultimately your ability to track  a service depends on the accuracy of your monitors, and building accurate monitors requires iteration and time.

Dashboards for engineers and sysadmins are often built with very specific requirements in mind, or are redundant and aren’t needed so they tend to not be a problem either.

Where I most see the most potential for people to get into trouble is in creating dashboards for their Tier I support, and also for senior IT management. The easy answer is to just have them use the simple up/down  service level dashboard. The problem is that while this is a perfectly acceptable level of transparency to provide to Non IT, it often isn’t enough info, especially for the occasional situation when your up/down dashboard says everything is fine, and users are calling in complaining with issues.

Below is an example of a dashboard I would create for an e-mail or messaging service  for Tier I operators and upper level IT management that seeks to find the middle ground:

– In the Upper left you have a state widget. It is pegged to a group which contains all servers related to e-mail service. It should be made up of not just exchange servers. Mine contains BES and ISA servers to provide a more complete picture of the health of all related parts. Some would say build a simple distributed app to do this, but this starts to get troublesome when dealing with load-balanced systems, or systems where a negative status of one system doesn’t need to roll up to the status of the entire app.

– Upper middle is a Service Level Widget which is tied to the Exchange 2010 Application from the Exchange 2010 MP. It’s not perfect, but it does a decent job of generally showing when core e-mail functionality is up or down.

– Upper right: An alerts widget which looks at anything related to the health of the servers in the group on the left.

– Middle: Graph of outlook latency. Honestly, it is unlikely that Tier I is going to gain useful info from this graphic. You can, and I have been able to see noticeable shifts if one member of a load balanced or clustered pair is down, but this falls into the category of behold the power of pretty graphs. Sometimes its nice for your Tier I and upper IT management to feel empowered, and for whatever reason I have found that pretty graphs can do that even if they may or may not know exactly what they are looking at.

– Bottom: Again empowerment via pretty graphs.


The contents of this site are provided “AS IS” with no warranties, or rights conferred. Example code could harm your environment, and is not intended for production use. Content represents point in time snapshots of information and may no longer be accurate. (I work @ MSFT. Thoughts and opinions are my own.)