Steve Rachui's Manageability blog - ConfigMgr/OpsMgr

SCCM: Forcing a Task Sequence to Rerun

2009-11-06T20:58:15Z

There are well known methods to force an advertisement to rerun – including several add-on tools available for the SMS or SCCM console. To date, however, there are not equivalent methods to force a task sequence to rerun. Part of this may be because task sequences are typically thought of as focused on Operating System Deployment (OSD) and rerunning these types of distributions are not as common as rerunning advertisements.

While task sequences are the best solution out there for OS Deployments they are much more flexible than just that – including distributing software in very complex scenarios including support of dynamic decisions during execution, handling reboots, enabling specific sequencing of application deployment, etc. With this kind of power many organizations are using task sequences for software deployment and the ability to force a sequence to rerun on a selective basis and without having to manually logon to individual clients is crucial. The process to make this happen is very easy.

First, identify your task sequence by ID. My test sequence is CEN00027.

Note that in my lab this sequence has already run in the past.

The advertisement for the sequence is set with a mandatory execution time – which resulted in the first run. No other mandatory times have been added. Further, the advertisement is set to allow rerunning. If you had an advertisement set to not rerun you should be able to force it to rerun but this would likel require additional WMI and registry edits. I haven’t tested that specific scenario.

From here, open WMI on the client system of interest and connect to the root\ccm\scheduler namespace.

Click ‘Enum Classes’, select Recursive and then scroll to the bottom and double click on CCM_Scheduler_History() and then click instances.

In the list that shows up, find the entry that corresponds to your task sequence ID and delete it.

With the deletion made, restart the SMS Agent Host service (CCMExec) on the target client.

In a few minutes, the program balloon will pop up indicating the sequence is about to run again.

The process described is manual but could be automated if desired.

BING 411

2009-10-22T14:46:52Z

Completely unrelated to anything SCCM or OpsMgr but still worth a post – do you find yourself avoiding dialing information to get phone numbers of information because it is too expensive? Check out BING 411. This service is completely free, will provide detailed information on whatever you are searching for and will also connect the call for you – all free. And, to top all of that, the system is actually good – voice recognition is very accurate. Try it out – 1-800-BING-411.

Understanding Monitors in OpsMgr 2007 part III – Dependency Monitors

2009-10-05T20:24:08Z

This is part 3 (and last) of my series of posts describing monitors. The first post, found here, discussed unit monitors, which are the engine of monitoring. The second post, found here, discussed aggregate monitors, the ‘umbrella’ monitor sitting above unit monitors and reflecting their collective health forward – ultimately all the way to the class level.

The dependency monitor is used to link classes that are in a hosting or containment relationship together, allowing health state from one class to affect the health of another class higher in the relationship structure than itself. This type of monitor is confusing for many an OpsMgr admin. Looking at the relationship structure of classes within OpsMgr one might think that the rollup of class health happens by default – it doesn’t. Health will only roll up to the individual class level (by using unit and aggregate monitors) unless a dependency monitor is configured between classes. An illustration from the Opsmgr Authoring Guide might help and is shown below. In this scenario we have two objects, the SQL Server 2005 object (SQL Server 2005 DB Engine class) and the SQL Server Database object (SQL 2005 DB Class). Using the unit and aggregate monitors, both objects can be monitored individually – but there is nothing that will allow problems with a database (SQL Server 2005 DB class) to reflect on the SQL Server 2005 object itself (SQL Server 2005 DB Engine). If we do need the ability to link health between the objects, the dependency monitor is the mechanism to do so.

The diagram shows a dependency monitor created that links the health state between the availability aggregate of the SQL Server Database object (SQL 2005 DB object) and rolls it up under the availability aggregate of the SQL Server 2005 database object (SQL 2005 DB Engine class). You could link between the other aggregate categories or on the aggregate for the class itself, it’s up to you.

So how do we build this in the OpsMgr UI? Let’s walk through it.

First, find the two classes you want to link together and evaluate what monitors are already in place. In this case, SQL 2005 DB and SQL 2005 DB Engine

We see that there is a Database Status unit monitor already configured and it will rollup it’s health to the availability aggregate and ultimately the entity aggregate but there is no dependency to roll the state up further. Knowing that this view in the UI isn’t always as complete as we would like (more on that in a minute) and knowing that dependencies are created at the parent class in the relationship, in this case SQL 2005 DB Engine, we take a look at the SQL 2005 DB Engine objects in discovered inventory and look at health explorer for these objects and confirm there is no dependency.

Note: Here we are specifically looking at the availability aggregate since the unit monitor we want to ‘link’ into is underneath this aggregate in our target class.

      Note: Here I’m looking at health explorer for my test computer object but it really
      doesn’t make a difference which object you choose out of discovered inventory since
      the rollup, when created, will be at the class level and will be displayed on all objects as
      a result.

From this we know that there is no dependency, so we will build one. Back in authoring we select to create a dependency monitor.

Note: You could also create the dependency monitor (or any other monitor) directly on
the node of interested which will fill in some of the information for you in the wizard.

As shown above, the target for the monitor will be the class where we want health to ROLL UP and not the class that is reporting the health. In this case, SQL 2005 DB Engine will be our target.

The next page is where we link our classes

In the above screen we are configuring our dependency monitor to link into the SQL Database child object and consider the health state of this child object when calculating health of the hosting class. Notice that in this window we are actually linking to the more generic SQL Database object (the only option) rather than to the specific SQL 2005 Database object.

OK, wait a minute – this is confusing. So we want to create a dependency to link the health that results from the ‘database status’ unit monitor that is specifically created to monitor objects in the SQL 2005 DB class – but our dependency can’t link directly to the SQL 2005 DB class but, instead, has to link to the SQL DB class? Come on Steve – I look directly at the SQL DB class, the one we can link to, and it doesn’t have ANY monitors defined on it. You also said earlier that without a dependency monitor health rolls up to the top of the CLASS and stops. In this example that means health would not go past the SQL 2005 DB class so how can I get ANY health rollup by building a dependency to the SQL DB class which has no monitors? Yes, I understand the confusion but, trust me, it works. All of what I mentioned earlier is true. Health doesn’t roll up from class to class unless there is a dependency. You might call me a liar if you were to cause the database status monitor to go red and then look at the SQL 2005 DB class and the SQL DB class in health explorer. The screenshots below seem to contradict what I’m saying because when the Database Status monitor is healthy, both classes are healthy and when the Database Status monitor is unhealthy, both classes are unhealthy.

SQL 2005 DB Class SQL Database Class

While my statement that health will NOT rollup past the individual class level without a dependency is true it is also true that in some cases health generated on one class will reflect, not rollup, on it’s parent class. The reason for this is a bit complicated to explain but a good way to predict when this will be the case is where one class specializes another class but what is ultimately being described is the same. In this case, the SQL 2005 DB class is a more specialized for of the SQL DB class so the type of special relationship we are talking about exists. OK, lets continue building our dependency monitor!

On the next screen we simply configure how health should be considered.

So what impact did this change have? Take a look back at our two classes and we will now see the dependency monitor. While the UI doesn’t clearly reflect it we now know based on our configuration and earlier discussion that the new dependency monitor will evaluate the health state of the availability aggregate from our child class when evaluating health.

So with the dependency monitor in place here is how health rollup really happens. The health state changes on our unit monitor, rolling up to the availability agregate in the SQL 2005 DB class. Because or our ‘special’ situation with these classes, health from SQL 2005 DB availability aggregate will reflect on the availability aggregate of the SQL Database class. Our dependency monitor, created on the SQL 2005 DB engine availability aggregate, will ‘link’ into the availability aggregate defined on the SQL Database class and ‘roll up’ health according to the rules defined on the dependency.

For another view of this rollup taking place we look at health explorer for the SQL 2005 DB Engine class. Health explorer is generally the clearest way to see these rollups and make sense of them.

Earlier I mentioned that using the authoring section of the UI to try and follow a dependency monitor and understand the classes it links together is potentially problematic. This is illustrated by the above diagrams. The dependency is created at the SQL 2005 DB engine level – and the dependency is visible at this level. But looking at the class the dependency links to alone doesn’t give any ability to know that a dependency is actually in operation. Health explorer is the right way to visualize the total picture of the health structure. It still may be difficult to see at a glance which monitors are aggregates or dependencies but by working with the structure a bit, it isn’t that difficult to follow.

Categories Filter Missing in OpsMgr R2 Notifications

2009-09-14T08:15:26Z

In OpsMgr SP1, the option to filter notifications by category was available in the UI.

In R2, many changes were made to improve the flexibility of notification subscriptions but the category option was not included.

Does that mean you can no longer create notifications filtered by category? In the UI, yes. But it is possible to include the category filter if you edit the XML itself. All notification detail in OpsMgr is stored in the ‘Notifications Internal Library’ management pack. Just export this management pack and you are able to add back your category filters – an example is shown below. The section specifying category criteria is in italics. Note that if you choose to make edits to re-enable category filtering you should no longer plan to edit your subscriptions in the UI. If you do and save a subscription setting, the category sections will be overwritten.

<Monitoring>
<Rules>
    <Rule ID="Subscription04bafdd7_653e_46c1_aa0f_202d186150dd" Enabled="true" Target="Notification!Microsoft.SystemCenter.AlertNotificationSubscriptionServer" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">
      <Category>Notification</Category>
      <DataSources>
        <DataSource ID="DS1" RunAs="SystemCenter!Microsoft.SystemCenter.DatabaseWriteActionAccount" TypeID="SystemCenter!Microsoft.SystemCenter.SubscribedAlertProvider">
          <AlertChangedSubscription Property="Any">
            <Criteria>
              <Expression>
                <And>
                  <Expression>
                    <SimpleExpression>
                      <ValueExpression>
                        <Property>Severity</Property>
                      </ValueExpression>
                      <Operator>Equal</Operator>
                      <ValueExpression>
                        <Value>2</Value>
                      </ValueExpression>
                    </SimpleExpression>
                  </Expression>
                  <Expression>
                    <Or>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Priority</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>2</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Priority</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>1</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                    </Or>
                  </Expression>
                  <Expression>
                    <Or>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>PerformanceCollection</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>Operations</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>EventCollection</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>StateCollection</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>SoftwareAndUpdates</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>Alert</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>System</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>Custom</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>AvailabilityHealth</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>PerformanceHealth</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>ConfigurationHealth</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>SecurityHealth</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>Discovery</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>Notification</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>Category</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>Maintenance</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                    </Or>
                  </Expression>
                  <Expression>
                    <Or>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>ResolutionState</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>0</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                      <Expression>
                        <SimpleExpression>
                          <ValueExpression>
                            <Property>ResolutionState</Property>
                          </ValueExpression>
                          <Operator>Equal</Operator>
                          <ValueExpression>
                            <Value>255</Value>
                          </ValueExpression>
                        </SimpleExpression>
                      </Expression>
                    </Or>
                  </Expression>
                </And>
              </Expression>
            </Criteria>

SCCM R3 is announced!

2009-09-09T20:42:11Z

R3 will be heavy on power management. A good read on R3 is at

http://blogs.technet.com/systemcenter/archive/2009/09/08/announcing-system-center-configuration-manager-2007-r3.aspx

Understanding Monitors in Opsmgr 2007 part II Aggregate Monitors

2009-09-06T23:41:16Z

This is part 2 of my a series of posts describing monitors. The first post discussed unit monitors and can be found here. This post discusses aggregate monitors. As mentioned in the first post, unit monitors can be thought of as the workhorse of monitoring. Unit monitors are just that – a unit of monitoring. A self contained engine to monitor a specific item and reflect the result in terms of health state, alerting and diagnostic/recovery. Aggregates act as a collector and consolidator of information and ultimately reflect the collective result of unit monitors. For any defined class in OpsMgr there are 5 defined aggregate monitors – Entity Health, Availability, Configuration, Performance and Security. This is shown below for the Windows Computer object.

Until now you might have just thought of these as categories you can use for grouping similar unit monitors together – and they are useful for this – but these are much more than categories. If we look at the properties of the availability aggregate as an example we quickly see that this monitor itself can be an engine for alerting and is configurable to reflect the health of it’s contained unit monitors. We even have diagnostic and recovery options available for an aggregate monitor.

So when we configure a unit monitor we now understand that the setting to specify a parent monitor isn’t just cosmetic – it’s important. This setting directly dictates where an unhealthy unit monitor will have an impact. If we choose availability, the health state of our unit monitor (and all others under the availability aggregate) will be ‘watched’ and their collective health ultimately ‘rolled up' to and reflected on the aggregate itself. This offers some interesting possibilities. If, for example, you don’t want to generate an alert based on a single unit monitor but would prefer to alert only when all of the unit monitors are unhealthy, the aggregate allows you to do just that!

So we have the availability, configuration, performance and security aggregates and we understand that these are default aggregates that are part of every monitoring object and we understand that unit monitors that are configured under each directly ‘roll up’ their collective health to the aggregates. In addition to this, we can create our own aggregates and plug them into the monitoring structure. So, for example, if we wanted to subdivide our unit monitors under the availability aggregate we could create another aggregate inline as shown.

Here we have 6 unit monitors that operate and generate state that is collected by the FileSystem Monitors aggregate. So, the lower six unit monitors do not of their own operation have direct impact on availability health. In this example, if any of the 6 unit monitors under FileSystem Monitors go unhealthy that state will be reflected on the FileSystem Monitors aggregate itself and the health of the FileSystem Monitors object will be reflected forward to the general Availability aggregate.

OK, so we have the four categories of unit monitors and we know we can add our own aggregate monitors and specify where they should plug into the category model.

But, even these four top level categories of aggregate monitors themselves combine and are rolled up to the top most aggregate for a class – the entity aggregate.

So, ultimately, the overall health of the availability, configuration, performance, security and whatever other custom aggregates are in place on an object are taken into account based on their ‘watched’ unit monitors and rolled forward to the Entity aggregate. The Entity aggregate will reflect the overall health of the object in health explorer so at a glance we can tell if the monitored object, in this case Windows Computer, has any issue causing it to be unhealthy. I’ve put health explorer for a Windows Computer object next to the same object in the authoring > monitors view to show how they map together.

So we have the health of all unit monitors targeted to a particular class rolling their state forward to finally be shown in the health of the class itself. So once we have the health reflected on the class, where do we go from there? A common thought is that the health just continues to roll up along the relationship chain between objects. That is not correct. In terms of health state, the buck stops at the class itself. But, wait – you are about to scream that you have seen an unhealthy class roll up to and impact the health of a class higher up in the relationship chain….yes you have – but that isn’t done automatically. It requires dependency monitors and they will be the focus of part III of our series.

SCCM AMT Provisioning Flowcharts

2009-09-03T00:21:00Z

Support for AMT provisioning through SCCM was introduced in SCCM SP1. Being able to manage systems through AMT is extremely useful and there is a good amount of documentation already about using SCCM and AMT. Working through this technology I thought it would be helpful to have flowcharts that document how provisioning works both with SCCM natively supported AMT systems (AMT firmware version 3.2.1 forward) vs. legacy provisioning (firmware less than 3.2.1). There are two provisioning options – in band and out of band. The flowchart goes into depth on each and includes sample logs and step by step processing during the provisioning process. I posted another set of flowcharts on my blog previously detailing the function of other SCCM components such as NAP, SUM, DCM, etc. I released those in an html format and have since been asked many times for the Visio source files I used to create the HTML. So, this time I’m posting the Visio source but understand that these flows are designed to be used in web format so you can dynamically navigate from page to page. When you download the attached visio, open it and save it as a web page. From there you will be able to navigate as if it were hosted on a web site but don’t have to hassle with actually posting it to a website. Some sample screenshots are below.

Understanding Monitors in OpsMgr 2007 Part I – Unit Monitors

2009-08-30T21:54:05Z

At MMS 2009 I presented a topic on understanding monitors in OpsMgr 2007. According to the feedback, that session was well received so I thought I would convert some of it to a series of blog entries.

There are two key ways of delivering monitoring in opsMgr 2007 – rules and monitors. At first glance, rules appear to deliver much the same monitoring as monitors.

There are some similarities for sure but rules and monitors are actually very different things. There are two major things to understand about rules compared to monitors. Rules have zero impact on measuring the health of the object being monitored. In addition, rules can collect data and monitors don’t. An example is instructive. If you have a need to both collect performance data and also have the measurement of the same performance data impact the total health of the monitored object, you need both a rule and a monitor. Why? Again, monitors don’t collect anything – they just evaluate the data live and reflect back what is found in terms of health state changes. Rules collect data but have no impact on health state. So, in this example scenario, you need both.

Notice that in the preceding paragraph I made reference to monitors and rules being associated with an object. What I really am talking about here is the class (aka, object) against which a rule or monitor is targeted. Understanding targeting is pivotal to understanding OpsMgr 2007. If targeting is a confusing topic for you or you want to refresh yourself on proper targeting techniques, take a look at the article I published in Technet magazine discussing this topic in detail - http://technet.microsoft.com/en-us/magazine/2008.11.targeting.aspx?pr=blog

Enough about rules – the topic at hand is to discuss monitors! Monitors are where you see the power of OpsMgr 2007 and, from the list above, you can see that there is substantially more flexibility when using monitors vs. rules. Remember, monitors are al about health and that is the goal of OpsMgr 2007. To restate, monitors watch whatever they are monitoring – performance data, WMI, event logs, whatever – and tell administrators about the results of monitoring by changing the health state of the object being monitored. One point here – on the rules node you see a category for alert generating rules. Monitors can definitely generate an alert as well so don’t think you are missing out on that ability by choosing a monitor!

There are three categories of monitors – unit monitors, aggegrate monitors and dependency monitors.

Unit Monitors
Unit monitors can be thought of as the workhorse of monitoring and unit monitors drive health detection in OpsMgr. Without unit monitors you would never know a problem exists! The best way to get to know unit monitors is to work with them. A caution here – make sure you do your testing in a lab environment as if operating in the production environment, any changes made take place right away. If building multiple monitors for testing this could cause notable churn in the production environment – unexpected churn is far easier to absorb in a test lab!.

There are lots of options for unit monitors – ranging from very straight forward to very complex. Discussing each and every unit monitor is beyond the scope of this blog entry but there are a couple that are particularly interesting.

Simple Event Detection – Detecting a simple event is easy with most monitoring solutions – including OpsMgr. The Simple Event Detection monitor is, well, simple. I describe it here as a starting point and because it will provide some good discussion on building monitors in general that is applicable to any monitor.

From the create monitoring wizard select to create a Simple Event Detection monitor. For our example we will use a Windows Event Reset as the type – more about that in a minute. Make sure you choose a management pack other than the default management pack to store this monitor!

On the general properties screen, choose a target and parent monitor. For our example lets assume we will be delivering additional monitoring to SQL 2005 Servers. If the SQL 2005 Management Pack is installed we will have a target called SQL 2005 DB Engine. Select that target. The next choice is which Parent Monitor should ‘contain’ our unit monitor. For monitors, there are 4 general parent monitors that may be an option for you – availability, configuration, performance and security. You may also see one for Backwards Compatibility but that isn’t a category that you should use when authoring a monitor yourself. These categories allow grouping of unit monitors according to the general intended purpose. If, for example, our monitor will be looking for events that could impact the general availability of the monitored object , it should be placed under availability. If our monitor will be looking for events that could impact the general performance of the monitored object, it should be placed under performance. We will discuss these categories in greater detail in part II of this post because each category is actually itself a monitor – an aggregate monitor.

We are building a simple event detection monitor so the next screen will ask for the event log OpsMgr should look in for the event. We will leave the default of application but note that this could be any event log in place on the system.

So we’ve chosen the application log, now we have to specify the event to look for with our monitor.

Click next and – we are being asked again for the event log we want to use? What’s going on here? This is an excellent opportunity to discuss the option we first select when we started building our monitor. We chose that we wanted a Simple Event Detection monitor and we chose that it should be a windows event reset monitor. Remember that monitors are all about health. Monitors detect when a healthy condition goes unhealthy and can ALSO detect when an unhealthy condition goes back to health. That is, in fact, the holy grail of monitors – to detect when an unhealthy situation takes place and then automatically detect when the unhealthy condition goes away! And that is exactly what is being done here. One event, the first one with Event ID 1234, will indicate an unhealthy condition has taken place and now this second event – in the same or different event log – will indicate that the unhealthy condition has been resolved – completely automatic! Of course, not all monitoring scenarios lend themselves to that which is why that in addition to windows event reset we also have options for timer reset and manual reset. Timer reset is a situation where we detect the unhealthy condition and immediately start a timer. If the unhealthy condition has not been detected again during our timing period (defined on the monitor) then we revert the health back to a healthy state. If we detect the unhealthy condition again during the timing period, the timing period starts over. The manual reset monitor means that once the unhealthy condition is noted it will not be reset until either manually touched or reset by some scripting method. The manual reset monitor should not be in wide use and, when used, should be for very specific scenarios.

We will again select the Application event log.

And select the event criteria that will indicate monitoring is again healthy

Next we pull our two event ID’s together and select whether the first event will raise a warning or a critical health state (there is a drop down that will allow you to select warning or critical but you can’t see it until you click on warning to change if needed). The second event will return us to a health status.

The final screen of the wizard allows selection of whether or not this monitor will generate an alert

Select to create and the monitor is saved. If we go find our new monitor and select properties on it we see that there are actually additional items we can configure, such as product knowledge, diagnostic and recovery and overrides that are not part of the initial wizard. Product knowledge allows information about the monitor and how to resolve detected problems to be recorded. Diagnostic and Recovery allows specific steps to be configured as a response to the monitor changing state that may aid in diagnosing or fixing the problem and overrides are where you specify any conditions other than the default that should be in place for all monitored objects or a subset thereof. It is only possible to override values that have been authored to allow overriding.

We’ve gone screen by screen for our first example to illustrate a few important key concepts that will generally apply to all monitors. For our next examples of interesting unit monitors we won’t go screen by screen but only show the relevant screens.

WMI Performance Monitors
In some cases it would be helpful to have a performance monitor style method of collecting information about an object but there is no performance counter available. An example of this might be file size. Suppose you have a particular log file that needs to be monitored for an increase in size. You look in the performance monitor counters and there is not a counter available. What option do you have? Certainly a script would be a workable choice but you may not be comfortable scripting. Is there a way to take file size information and convert it to performance data that can be used in OpsMgr? Absolutely – and there are lots of other examples too beyond the file size example. I have previously described exactly how to setup such a scenario here so I will avoid repeating but do take a look at this example as having this ability really is powerful.

Log File Monitoring
Another monitor type that is little used but very useful is the log file monitors. Many applications have log files they write to indicate application processing, error conditions, etc. SQL has it’s error log and SCCM/SMS is chock full of logged information and there are lots of other examples. Over time there will be conditions in your environment that you know to be problems that arise when specific log entries show up. In many cases the provided SQL and/or SCCM management packs will handle the errors from tose systems for you but in cases where they don’t, being able to craft your own log monitor is useful. And it’s not difficult. Here are the relevant configuration screens.

On the Application Log Data Source screen we need to configure the directory where our log(s) are stored and then a pattern that will specify how to search. Note that wildcards are supported so it would be possible to search multiple log files of similar name.

Next, we need to configure what information in the log file we want to detect. In this case we are looking for the text bummer – but it could also be a string of text rather than a single word. Also, the parameter name will be the same regardless – this is the syntax to specify we are defining the first parameter of interest which is all I’ve ever needed.

The next step is to configure how long we will let the alert remain before automatically resetting it. This configuration is a timer based monitor. I chose this option just to illustrate another example. Note that you could have just as easily setup an event reset monitor here – all that would be needed is to define another parameter that would flag the health condition. Also note that my timer reset is set to an hour. This means that if the problem condition is not detected again for an hour that the monitor will reset but, if the problem condition is detected again, the timer gets reset and another full hour will be required before considering the problem cleared up.

There rest of the screens are similar to what has already been seen.

Repeated Event Detection
I’ve already described how to configure to detect a simple event. With such a configuration, when the configured event comes in it is detected and configure action, such as raising an alert, takes place. There could be situations though where a single event may not indicate a problem. However, if 3 of the same events happen within a 15 minute window, that may indicate a problem that we need to investigate. Taking what we already know from the simple event monitor it’s easy to configure the repeat monitor. Just choose the repeated event monitor, configure what event we care about and then you will get to the screen shown below to configure our repeat settings.

There are a few choices for counting mode but the one I find simple and useful is the Trigger on count, sliding. Basically this means that when the first event shows up we will start a timer for, in this case, 15 minute. If another of the events shows up within tat 15 minutes then we will consider this a problem and move on to take action. You can configure the repeat count however you like by adjusting the compare count settings. There are other options here you can explore as you like.

Correlated Event Monitor
A more complex but very useful monitor is the correlated event detection monitor. Using this monitor it is possible to configure OpsMgr to watch for complex event patterns, whether in the same event log of different event logs, and alert only when the pattern specified is entered. For our example I’ve chose an windows event reset monitor which means that OpsMgr will watch for a specific windows event to trigger the reset of health after a problem occurs. I won’t go through configuring every event screen because it’s all similar to what we’ve already seen in the simple event discussion. Note on the screenshot below, however, that there were 3 events to configure. The first even is the reset event while events A and B are the correlated events. The screen below also shows options for how events A and B correlate to one another.

On the correlation screen we have a few options to discuss. First, is the correlation interval. Like the repeated event detection this interval specifies how long to watch for the event pattern after receiving the first event. If the pattern doesn’t manifest in this configured time then there will be no change to health. Also, there are multiple options to correlation settings as shown below. The wording here may be confusing at first but the graphic shown on the configuration page will change as you move from option to option to illustrate what each option does. Finally, note the occurrence and Expression options. With these options you can increase the complexity of our filter by configuring how often our patter should occur as well as specific expression information that is beyond what we are discussing here.

Finally, we have the health screen that pulls this all together. Note the event raised refers to the first event configured that will trigger a healthy condition where as match to the correlated event loging we just configured will result in a warning event (you can change to a critical if you like)

Part II of our discussion will turn to the aggregate rollup monitor and how it is used in OpsMgr.

Monitoring File Size with Custom WMI Performance Counter

2009-08-30T08:53:42Z

Have you ever needed to monitor the size of a file to ensure you were alerted when it’s size changed beyond certain values? I had to help address this recently and at first glance, this may seem to be a good job for a script – and a script definitely could be used. Scripts are great but I like to avoid them when I can and this is a perfect scenario for using a custom WMI performance counter. After all, tracking a threshold is ultimately what we are after. So how can this be done? I wrote a sample monitor and rule to demonstrate. Let’s walk through the monitor since both are similar – the reason for both is that a monitor will track live data but will not collect it; a rule collects performance data.

The first things is to configure the WMI query to specify which file we want to monitor and the properties. We can do this through a very simple WMI query to the root\cimv2 namespace as shown below. All files on a system can be accessed using this same query, Just change the filename and modify the properties being monitored if interested in something other than filesize. For this example, I chose the pagefile.sys.

So we have the data through the WMI query, now we need to map this data and use it to create a custom performance counter. We do that on the performance mapper screen as shown below. Note that the Counter name and value name match.

For a rule, thats all you need to configure. For a monitor, we need to specify the thresholds where we want to generate alerts. This is done on the Threshold Range page.

We also need to map our thresholds to the appropriate health state.

And decide whether or not to alert. With all of this configured, we are in business! After our rule starts to run for a while we will see performance data start to show up for the custom counter.

OpsMgr Agent Discovery Hanging after Enabling Broker Service?

2009-08-30T08:21:59Z

When OpsMgr discovery hangs it’s because the SQL Broker service has not been enabled in the operationsmanager database. Just a quick BING search will show you tons of hits about this issue – and I’ve never seen one case where this wasn’t the case – until now. I just finished working an issue where OpsMgr discovery would hang but the SQL Broker service was enabled. I didn’t know much about the Broker service and definately had never had to troubleshoot it before.

What is the SQL Broker service? MSDN offers the following statement to describe what Broker does. A more complete discussion can be found at http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx

          This new technology, a part of the Database Engine, provides a message-based communication platform that enables
          independent application components to perform as a functioning whole. Service Broker includes infrastructure for
          asynchronous programming that can be used for applications within a single database or a single instance as well as for
          distributed applications.

So we need to troubleshoot the Broker service – cool, where can we find out information about it? The first stop is on the Broker enabled database itself. Under the Service Broker folder we can access various information about the service. But I didn’t find anything here to really help me understand what might be broken. Searching a bit I came across two very useful SQL queries – one to help me troubleshoot and one to show me data processing through the Broker.

select * from sys.transmission_queue

select * from sys.conversation_endpoints

From my limited troubleshooting it seems that when everything is running normally the first query should return no results where the second query will show data in process/queued by the system. Looking at the results of the first query in the transmission_status column I found this error ‘An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'Domain/User', error code 0x52e.’ Obviously I’ve replace the real user information with Domain\User for confidentiality reasons. Regardless, with this information I now have a clue what is going on. We have an account in play somewhere that we can use to authenticate. Error 52e confirms that and translates to ERROR_LOGON_FAILURE. Digging a bit we found the culprit. The owner of the operationsmanager database was the account that was incorrect. It’s easy to see who the database owner is, just select the database, click properties and on the general page, the owner information is displayed. Here is a screenshot from my lab. Once we set the database owner to the correct value, discovery worked like a champ!

What ports REALLY need to be open for AMT in SCCM?

2009-08-28T07:21:09Z

The question came up recently about what ports are really needed for AMT in SCCM. The documentation (http://technet.microsoft.com/en-us/library/bb632618.aspx) indicates a list of ports that are used by AMT for various communication that takes place between various AMT components during management. The documentation is correct but is also potentially confusing.

One thing to understand is that on the client AMT function is handled in the firmware – the operating system really is secondary. It’s possible to fully manage a system via AMT even when it is powered down or the OS is failing to load. Why is this important? The Windows firewall. Based on the documentation we provide listing the required ports a natural thought is that these ports need to be opened on the Windows firewall. This generally isn’t the case but there is one exception and that is on the Out of Band service point (OOBSP). The OOBSP, an SCCM site system role, listens for incoming hello messages from AMT systems on port 9971, Since this component IS part of the running operating system we do need to have port 9971 opened in the Windows firewall or hello packets will be blocked and out of band provisioning will not work. So are the ports documented in the link above relevant? Absolutely. if there are firewalls in place other than the Windows client firewall between AMT components you do need to ensure the ports listed are opened and accessible. Hope this clears up any confusion.

SCCM Unleashed is Unleashed

2009-08-21T08:03:00Z

A bit of a self-servng post I suppose and I know I'm a bit late in posting this (couldn't decide if I would do it or not) but SCCM Unleashed has been published and it is a very complete book and an easy read. I served as tech reviewer for the book so you can guarantee there are no mistakes! Now please don't shatter my world and point out everything I missed! :)

Update SQL Management Pack posted to catalog!

2009-07-24T21:25:18Z

If you haven’t seen it, the update SQL Management Pack which resolves issues monitoring clustered SQL servers has posted to the management pack catalog.

http://www.microsoft.com/downloads/details.aspx?FamilyId=8C0F970E-C653-4C15-9E51-6A6CADFCA363&displaylang=en&displaylang=en

Understanding the R2 Process Monitoring Management Pack Templates

2009-07-17T20:20:49Z

Management pack templates have been around since RTM of OpsMgr 2007 and R2 introduced a new one specifically for process monitoring. This is a cool template and allows the ability to setup some useful process monitoring, but what is the wizard actually building behind the scenes, and is this what you want? Let’s walk through an example.

In the authoring node of the OpsMgr console, right click on Management Pack Templates and select add monitoring wizard.

Select the Process Monitoring template and select next.

Title your monitor and select a management pack where it should be stored and click next.

Choose to monitor the notepad.exe process and select a group that will be used to populate the resulting target. Let’s stop here for a minute. Choose a group for targeting? Sounds very MOM 2005ish. Well, what really happens here is that the membership of the group you select is copied into the new target class that the wizard creates. We will see that in a minute. Click next.

For our demo we will accept the defaults on the next two pages.

So we finish up the wizard by clicking Create on the Summary page and thats it. Easy enough? Using this wizard we now have created monitoring that will run on just the SQL servers that were in my group looking for notepad. Very easy and targeted appropriately. So what pieces were actually created? Let’s take a look.

First, if we review our list of Process Monitors we have the one just created and two others. The other two will come into the discussion shortly.

As we explore the results of the wizard, remember that one of the items requested by the wizard is the group name. We chose SQL 2005 Computers. The membership of this group is as follows

As mentioned, this group is not the target for our monitoring but is used to seed the class created by the wizard. If we take a look at discovered inventory and choose the class that was created we see the the class membership is exactly the same as our group. So, essentially, the membership is a direct copy of the group.

One thing to bear in mind here, if an agent is listed in a the target group but that agent is having problems it may not run the discovery and, as a result, may not populate into the new target class that the wizard creates.

At this point you might be thinking that you just stumbled across a cool way to build a new target class without having to use the authoring console. Why not just create a group that has all of the systems in it that you want to target for monitoring and use the process monitor wizard to specify the group you created as the target group and convert it to a new class that you can use for targeting something completely unrelated. After all, you can just delete the process monitor when done and you are good to go. Well, good thought but it fails on a couple of fronts – when the process monitor is deleted so is the target class that was created. There is another potential problem as you will see in a minute.

OK, continuing on. What monitoring objects were created by the wizard? To find out just right click on the new process monitor template created in the authoring node and select to view management pack objects. To populate the new target class we have to have an object discovery. Click on object discoveries from the right-click menu and you will see the new discovery created.

From the same right-click menu select monitors to see the associated monitors that were created.

In addition to monitors, a couple of rules were created. Choose rules from the right-click menu to see them.

Notice that all of the monitors and rules are targeted at the newly created target class Test Notepad.exe Process Monitor.

So what do we know so far? We know that the wizard created a new target class that is populated by the newly created object discovery and we know that both rules and monitors are targeted to this new target class. So where does this new target class fit into the overall health structure? If we take a look in the add component menu from distributed application designer and do a bit of searching we find our new target class.

Interesting. So what the wizard actually does is create our new process monitor target class as a child class of the Base Monitored Process Class which is related to Windows Local Application and so on. So anytime our monitors detect an issue the resulting health will be reflected on Windows Local Application and on up the chain.

But, wait, I’m monitoring a process on my SQL server. What if that process were a critical piece of SQL server? Shouldn’t a failure of that process impact the health state of SQL server? And now we have arrived at the second issue I mentioned above. If the process is critical to SQL server and you want the health state of SQL server to be impacted when the process fails then this wizard isn’t the answer for you. Very likely you will need to build other monitoring to meet your need. Further evidence of this in the diagram is the fact that I created three total process monitors, two targeted to my SQL server group and one targeted to Windows computer, yet they all reside in the same node illustrating that using this wizard will result in proper monitoring but may not meet your needs in terms of properly fitting in your health structure. For that, creating customized monitoring is your answer.

Will you PROVISION already?!

2009-07-11T02:51:00Z

Have you tried your hand at vPRO yet? If so, you know how cool it is. f not, you should….and, just wait for ConfigMgr SP2. Things get easier and better! Two of the notable improvements are the ability to manage wireless systems and the ability to have control over auto-provisioning. The later is a huge benefit. With the SP1 version of vPRO the automatic provisioning will take place but it may be 24 hours before it is even attempted. There really isn’t much control to speed things along – or is there? Our handy trusty sendsched.vbs tool will do the trick! Just like many other ConfigMgr client componens, the provisioning cycle has a schedule token we can ‘kick’ the client so that it asks for provisioning NOW! The command line for running the tool locally is

cscript sendsched.vbs {00000000-0000-0000-0000-000000000120}

The tool can be used remotely tool with a slight modification of the command line to include the name of the remote system.