Fussy Expression

Having had the problem with Daniele’s apostrophes (“ – the punctuation apostrophe (curly) rather than the vertical typewriter apostrophe) when copying his script (which he has fixed now) I thought what else could cause a problem. I had read that you had to be careful with the case for parameters so I thought I would take a look at that.

His full guide to creating a script based unit monitor is at http://www.muscetta.com/2007/05/10/create-a-script-based-unit-monitor-in-opsmgr2007-via-the-gui/.

The key part of his test script that determines whether it is a green or warning state is:

If Err.Number <> 0 Then
    Call oBag.AddValue(“State”,”BAD”)
Else
    Call oBag.AddValue(“State”,”GOOD”)
    objTS.Write strContent
End If
Call oAPI.Return(oBag)

The key bits of that are “State” and “BAD”/”GOOD”. And in the boxes for the Unhealthy and Healthy Expression there is
Parameter Name  Property[@Name='State']
Operator                Contains
Value                      BAD (for unhealthy and GOOD for healthy)

I set it up as in the post and tested it worked. I then made a change and tested that change. After that I set it back to the original to ensure that the monitor still worked.

Here is what I found.

In the Value section I tried Good and Bad. That worked showing that the Value section does not appear to be case sensitive.

As apostrophes were a problem in the script I tried it with ” instead of ’ around State in the Parameter Name and that worked.

Then I changed Name to NAME. That did not work. I also tried name. That did not work.

Next I changed Property to PROPERTY. That did not work. Nor did using property.

I changed State to STATE. That did not work.

I went back to the script and changed both instances of State to STATE but kept State in the expression. That did not work. I then changed State to STATE in each expression box to match the case in the script and that worked.

So apart from the apostrophes you have to be very careful with case in the Parameter Name box. But you don’t have to worry about the Value box. To me, this seems back to front. If there was one box that had to be case sensitive I would have thought it would have been Value and not Parameter Name.

Looking at the Operator box I changed the operator from Contains to Equals and that worked. It also worked with Matches Wildcard. I changed the values to B* and G* with Matches Wildcard and that worked as well. So that side of it seems reasonably flexible.

The worrying thing about these changes was that not only did the monitor no longer work but there were no errors in event logs to show that monitor was not working. You do get an error if you miss off the end ] however. And there is no warning when you create the expression to tell you that it will not work. Interestingly the script carried on working as when textfile.txt did exist, the word test was appended to it every 15 seconds as per the script.

So be very careful when you are creating these expressions. To be on the safe side it is probably best to use Title case in the script, Property Name box and Value box. That way you are consistent and it seems that Title case is needed for certain bits.

Events Show Updated MP Received

How can I tell if changes I have made to an MP have been received by an agent?

You could use the resultant set of rules view as described by Pete Zerger at http://www.it-jedi.net/2007/03/returning-resultant-set-of-rules-in-ops.html. Rory McCaw has done a 10 minute video of it at http://rorymccaw.spaces.live.com/Blog/cns!2C4CD58BB2826E21!2969.entry.

But if you just need a quick confirmation, e.g. you are doing a test,  then look at the Operations Manager event log at the agent. You should see event 1200 which shows that the agent knows that an update is needed followed by event 1201 which shows that the MP has been received. In the event description it will tell you the MP name and version number. This is followed by event 1210 saying that “New configuration has become active” and the name of the Management Group. Useful if you have multiple management groups. That way you know the changes that you have made in the MP have been recieved and are running.

One thing I have noticed if that you make changes to a rule/monitor or add new rules and monitors to an MP (unsealed as those are the only ones you can change) it does not affect the version number of the MP. To change that you need to go to Administration, Management Packs and right click on the MP and chose properties and then you can update the version number. I suppose that each organisation will need to work out a change control procedure on changing rules and monitors and what changes will trigger the MP being incremented.

Scripting in 2007

For scripting in MOM 2005 Brian Wren’s excellent articles (http://www.microsoft.com/technet/scriptcenter/hubs/mom.mspx) on how to take all those scripts out there and “MOMifiy” them was essential reading. So there is good news and bad news on scripting in OpsMgr 2007.

The good news is that you do not need all that “stuff” around the scripts (ScriptObject) to make them work in 2007. Nor do you need a special tool (like ResponseTest.exe in MOM 2005 RKit) to test them out outside of OpsMgr. In fact the test is to run the script as a vbs (or js) file using cscript. That is why when you are creating script rules it asks you to give it a name which initially confused me. Although 2007 embeds the script in the XML of the management pack when it is at the agent the script is created using that file name in a directory structure. In 2005 you could see all the scripts. In 2007 that is harder with sealed MPs. (Clive Eastwood has just released a tool to do that here – http://blogs.technet.com/cliveeastwood/archive/2007/05/25/tool-to-dump-all-mp-s-as-xml-unsealed-to-a-folder-of-your-choice.aspx)

You can, however, see all the scripts that are assigned to that agent and look at how the scripts are written for some help. They are on each agent under Program Files, System Center Operations Manager 2007, Health State Service with a directory called Monitoring Host Temporary Files x where x is a number that changes. You will see a directory with a number for each script so it does not seem to matter if you give the script the same name but it would be better if it was unique. If you search on that directory for vbs or js files you will then see them all. Also note that in the wizard if you do not give the script an extension the next button is greyed out. It does not tell you why (very frustrating) but now you know.

The bad news is that there is not much in the way of documentation and examples. The best around at the moment is the SDK. There is a section called “Using OpsMgr Runtime Scripts” at http://msdn2.microsoft.com/en-us/library/bb437498.aspx and another section on the scripting objects at http://msdn2.microsoft.com/en-us/library/bb437498.aspx. Additionally Daniele has a nice screen shot step by step post on creating a script based unit monitor at http://www.muscetta.com/2007/05/10/create-a-script-based-unit-monitor-in-opsmgr2007-via-the-gui/. Note that if you cut and paste the example script you need to change the apostrophes (“) as that causes the script to fail when run. There are also examples of using a script for discovery at www.authormps.com.

What you will need to get used to, is using “MOM.ScriptAPI” in order to use the script and MOMScriptAPI.CreatePropertyBag Method to store information until you need to assign it to OpsMgr calling the Return method. Programmers among you will recognise the Property Bag concept. Unfortunately not many infrastructure people are programmers – including me.

What I have not found is how to then turn information gathered directly into an alert. Neale (from SystemCenterForum) also mentioned that in one of the news groups and suggested using the MOMScriptAPI.LogScriptEvent Method which allows you to put an event into an event log so that you can create a rule to alert on it. I did think about that but the documentation does say that its use was for checking that scripts are working properly. And in some of the AD scripts they use CreateEvent with a corresponding rule. There must be a better way. If only we had some documentation.

As the script is embedded in the MP it is not obvious how top create one script and use that with multiple rules using parameters like 2005. The documentation hints at being able to do it using “data source module type” but I have not found out how. And unsurprisingly no documentation on it. There is a parameter section which is confusing in itself as it is just a blank window but you can pass context parameters at runtime but you need to know them. Fortunately they are listed in the SDK. Try remembering $Target/Property[Type='Windows!Microsoft.Windows.Computer']/PrincipalName$ from the top of your head!

The bottom line is that we need more documentation and examples with clear explanations of what is being used and why. But once we get that then it looks like scripts will be a lot more powerful in 2007 as they run natively as cscript scripts.

Syslog

Syslog is used extensively by *Nix machines. There is a good post from Anders about using syslog and a step by step guide to creating an example – http://contoso.se/blog/?p=158.

He adds some fields so that you can get info from the host into the alert description but this is a picture. So if you want to cut and paste it then here is the text.

Alert Message: $Data/EventData/DataItem/Message$ Hostname: $Data/EventData/DataItem/Hostname$ Priority Name: $Data/EventData/DataItem/PriorityName$ Severity: $Data/EventData/DataItem/Severity$
(By the way – in this area if you want to do carriage returns it is Crtl and Enter.)

The text bits will show up in the Alert Details as is and the parameters (surrounded by $) will be replaced with the relevant values as shown below.

Information in Alert Description. Click to see full size.

You will notice that the message area is empty. That is because I mistyped that bit (hence offering a cut and paste once I corrected it). If you open the alert and go to the Alert Context tab you will see all the information that is sent and you can see where the fields come from. More fields can be added if you want that info to show up in the General tab under alert description rather than going to Alert Context.

Alert Context tab. Click to see full size.

 A new blog from Komal Kashiramka, Microsoft, also covers syslog with a sample MP so you can examine the XML. http://blogs.msdn.com/komal/archive/2007/04/26/syslog-module.aspx

Both have links to the MOM 2005 KB regarding Syslog which goes into detail about what to do on the *Nix side.

And for logs in general there is a big post by Sam Patton, a developer on the SCOM team – another new blogger, about Application Log Monitoring. http://blogs.msdn.com/sampatton/archive/2007/04/21/application-log-monitoring.aspx

 There are plenty of event creation tools to test alerts based on events but how do you test your syslog rules?  I have found Kiwi’s free syslog generating tool is excellent. It can send random stuff or you can get it to do specific priorities etc. One at a time or a steady stream of syslog messages. http://www.kiwisyslog.com/info_sysloggen.htm

 
Kiwi Syslog Message Generator. Click to see full size.

And if you are not sure what syslog is all about then here is an overview.
http://www.monitorware.com/Common/en/SeminarsOnline/Intro-Syslog.php

Here is the Syslog Level and Priority information from RFC 3164.
Numerical Code Severity
 
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages

Change no of days data is held in DW

Vitaly Filimonov, Microsoft PM, has written about how to change the number of days for data retention in the data warehouse. Not official yet in the documentation but worth capturing here for those who do not use the newsgroups.

 ”Unfortunately, OpsMgr2007 does not have UI to change data retention
settings, but you can do it by modifying columns in certain tables inside
OperationsManagerDW database.

  There are two places in the DW where we store data retention-related
settings. For “config space” (your management packs, rules they contain,
overrides you’ve created, etc) and “instance space” (objects discovered,
their properties and relationships, etc.) we store setting inside the
MaintenanceSetting table. Here are the columns of interest and their default
values:

Instance space settings:

1. LastInstanceGroomingDateTime – the last time grooming operations were
performed;
2. InstanceGroomingFrequencyMinutes – frequency of the grooming process
start (default: 480)
3. (most important) InstanceMaxAgeDays – maximum age (since the day instance
was deleted) for the instance space objects (default: 400)
4. InstanceMaxRowsToGroom – maximum number of objects to delete in one run
(default: 5000).

Config space settings:

1. LastConfigGroomingDateTime – the last time grooming operations were
performed;
2. ConfigGroomingFrequencyMinutes – frequency of the grooming process start
(default: 60)
3. ManagementPackMaxAgeDays – maximum age for the management pack (since the
day MP was uninstalled) (default: 400)
4. NonSealedManagementPackMaxVersionCount – maximum # of non-sealed MP
versions to preserve (independent of the age) (default: 3)

Based on these settings for config space, sealed MP will be removed 400 days
after it was uninstalled from all management groups that are members of the
DW. Non-sealed MPs play by the same rules, but in addition we keep up to 3
old versions of non-sealed MP maximum.

Now, to the data. Each data type is stored in a separate structure called
“dataset”. There is Performance dataset for perf data, state dataset for
monitor state transitions, event dataset for events, etc. etc. MPs may
introduce new datasets as well. All datasets in existence known today are
so-called “standard datasets”. For those, we have a set of tables that hold
description of the dataset including data retention policies. Non-standard
datasets may be introduced (we do not know of one today though) and they
don’t have to follow the same rules – data retention settings for
non-standard datasets are dataset specific.

For standard dataset data retention is set at the “aggregation” level. Such
that performance “raw” data (samples themselves) stored certain number of
days which may be different from the number of days daily aggregates of
performance counters are stored. These settings are stored in the
StandardDatasetAggregation table. Here are the columns of interest. Note
that “primary key” of the table is composite consisting of dataset id (you
can lookup which dataset is which id in the Dataset table and
AggregationTypeId which can be looked up at the AggregationType table). The
defaults very by dataset / aggregation type:

1. MaxDataAgeDays – maximum number of days to store data;
2. GroomingIntervalMinutes – grooming process frequency;
3. MaxRowsToGroom – max number of rows to delete per transaction (see note
below);
4. LastGroomingDateTime – last time grooming process run.

  One important note here is that we do not always groom data row-by row. If
data inflow is high (which is usually the case in medium-to-large
organizations for performance and event data) we create additional tables to
store data. For example, we store first 10M performance samples in the first
table. Once we get more data we leave the first table there, create second
table and start inserting into it. At the same time we calculate min and max
date for the data in the first table (and store it separately in the
StandardDatasetTableMap table). Then the grooming process works like that
(for certain dataset/aggregation type combination): Check to see if we have
only one table. If one – delete records row-by-row using DELETE TOP and
using MaxRowsToGroom parameter. If there is more then one table, find the
table with the oldest “max date” for data in it. If the “max date” is older
then retention period – drop entire table if not, leave everything there.
  So, we do not necessarily “up to date” on grooming all the time. If you
have a table which spans one month, we will keep some records one month
longer then really needed, but performance gains of dropping whole table vs.
row deletes is so huge that we think it is way better to store a bit more
data for a bit longer then to pay the penalty.

  Hope, this helps.

–
Vitaly Filimonov [MSFT]
——————————————-
This posting is provided “AS IS” with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm“

MMS UK 2007

I went to the MMS UK event today at TVP in Reading. I wanted to get a heads up on some of the other stuff as I had spent most of the MMS in San Diego doing the OpsMgr 2007 stream. And bizarrely it was warmer in Reading than it was in San Diego.

Morning session was all keynotes from Eric Berg covering the System Center family with demos courtesy of Jeff Wettlaufer and a session on Microsoft’s Infrastructure Optimisation from Garry Corcoran. http://www.microsoft.com/technet/infrastructure/default.mspx. This is based on work done with Gartner but Professor Jeanne Ross at MIT has been working in this area as well and here is a slide deck presented at a CIO Summit if you are interested in that type of thing (which I am).
http://ebusiness.mit.edu/ciosummit/weillslides.pdf

The afternoon was interesting as they had 4 time slots but had 3 different sessions you could go to. So there was a choice about what you could see and it felt a bit like a bigger event because of that. Also the sessions were only 45 mins which was good as the presenters had to keep sharp.

They also covered some Forefront stuff as security and management go together. (SMS and patch management. OpsMgr 2007 and Audit Collection Service etc.) What was a surprise is that the Forefront Client Security product (MS anti virus and anti spyware) actually uses a special version of MOM 2005 SP1 as the “management engine” behind it. Well along with WSUS. You get a special version of MOM 2005 that is dedicated to this as the schemas on the databases have been changed. Because of this limitation of only being used for this one thing it can cope with 10,000 clients. You can not use this version of MOM for any other monitoring because of the license. Although none of this seems to be mentioned on the web site.
http://www.microsoft.com/forefront/clientsecurity/default.mspxAlthough on the TechNet version of the site there is a deployment guide and also a Virtual Lab with MOM 2005 and the Forefront Client Security packages. Guess I can’t hang up my MOM 2005 skills yet!

Another point that I had missed previously was the licensing on SC VMM. It appears you will notbe able to buy it as a separate licence. You will need to buy an Enterprise SML (Server Management License) which includes OpsMgr, Configuration Manager and Data Protection Manager. I think that is a bizarre decision. http://www.microsoft.com/systemcenter/howtobuy/esml.mspx

I also stopped on for a meeting of the Windows Management User Group. They were looking on feedback on the site plus are looking to hold meetings on a regular basis in Reading and London. If you are interested in have a look at the web site where they will post dates. But there are blogs and forums there as well. Have a look at http://wmug.co.uk/