Quae Nocent Docent

New samples and documents repository

Daniele Grandini — Fri, 27 Jan 2012 10:07:20 +0000

All the QND contents in terms of samples and documents have been moved to this location https://www.sugarsync.com/share/c3rp89z0ggxrx. Past articles and posts could result in broken links.

System Center Advisor has been released

Daniele Grandini — Thu, 26 Jan 2012 17:00:35 +0000

Eventually the first product of the System Center family arrives, it’s System Center Advisor completely operated from the cloud and a natural complement to OpsMgr.

Advisor, as the name implies, is a monitoring product built to give advices and best practices to run your infrastructure, these information are based on a scheduled upload of data hence they cannot be relied upon for immediately reactive actions, for this kind of needs OpsMgr is the product.

Supported Workloads

Advisor currently supports the following workloads:

· SQL Server 2008 and SQL Server 2008 R2 (focus on the relational engine)

· Windows Server 2008 and Windows Server 2008 R2 (focus on Hyper-V and Active Directory)

Proactively Avoid Problems

Increase awareness around the state of server deployment through assessment of configuration, and alerts for configuration-related issues.
Resolve issues before they become critical through ongoing assessments of the server environment for undetected configuration issues.
Assess and understand server configurations from virtually anywhere with from a secure cloud service with security features that meet customer needs.

Resolve Issues Faster

Decrease time to resolve issues by easily viewing configuration changes over time with historical data.
Decrease time to resolve issues with the ability to share server configuration data with internal support staff or Microsoft Customer Support Services.
Accelerate problem solving with instant access to step by step guidance, self-help information and community forums related to identified issues.

Help Reduce Downtime and Improve Performance

Increase performance and availability of servers by understanding configuration state and receiving suggestions for improvement to help ensure availability.
Help reduce server downtime by getting notifications for key updates specific to the configuration of the server environment.
Increase collaboration between IT professionals through centralized data of an organization’s deployment configurations.

- Daniele

This posting is provided “AS IS” with no warranties, and confers no rights.

Troubleshooting Sharepoint Ping Web Application Failed monitor

Daniele Grandini — Fri, 20 Jan 2012 15:34:49 +0000

Recently I’ve been engaged by my support engineers that were stuck on several critical alerts raised by the Sharepoint management pack. The most cryptic of them all was relates to the "Ping Web Application failed" monitor. The alert message states "A critical incident has occurred where the ping to the Web Application has failed." Not very friendly indeed, the linked Knowledge base article is fairly generic and doesn’t help either.

I had to dissect the monitor a write a quick guide to troubleshooting such an alert, since it is raised for many different error conditions. In this post I’m going to share this guide.

First of all some basic info on the monitor:

the monitor simply uses the URL monitoring standard probe to try an http GET to the discovered web apps
if the http status code is > 400 then an error is raised, an error is raised for any communication issue as well
the monitor runs every 1,800 seconds (30′)

<ProbeAction ID="Probe" TypeID="SCWebApp!Microsoft.SystemCenter.WebApplication.UrlProbe">
                <Proxy />
                <ProxyUserName />
                <ProxyPassword />
                <ProxyAuthenticationScheme>NoneProxyAuthenticationScheme>
                <CredentialUserName />
                <CredentialPassword />
                <AuthenticationScheme>NoneAuthenticationScheme>
                <FollowRedirects>trueFollowRedirects>
                <RetryCount>0RetryCount>
                <RequestTimeout>0RequestTimeout>
                <Requests>
                  <Request>
                    <RequestID>1RequestID>
                    <URL>$Config/Url$URL>
                    <Verb>GETVerb>
                    <Version>HTTP/1.1Version>
                    <HttpHeaders>
                      <HttpHeader>
                        <Name>User-AgentName>
                        <Value>Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)Value>
                      HttpHeader>
                    HttpHeaders>
                    <Body />
                    <CheckContentChange>falseCheckContentChange>
                    <ContentHash>00000000-0000-0000-0000-000000000000ContentHash>
                    <Depth>0Depth>
                    <ThinkTime>0ThinkTime>
                    <CheckInternalLinks>trueCheckInternalLinks>
                    <CheckExternalLinks>falseCheckExternalLinks>
                    <CheckResources>trueCheckResources>
                    <RequestEvaluationCriteria>
                      <StopProcessingIfWarningCriteriaIsMet>falseStopProcessingIfWarningCriteriaIsMet>
                      <StopProcessingIfErrorCriteriaIsMet>falseStopProcessingIfErrorCriteriaIsMet>
                      <BasePageEvaluationCriteria>
                        <WarningCriteria />
                        <ErrorCriteria>
                          <NumericCriteriaExpressions>
                            <NumericCriteriaExpression>
                              <NumericRequestMetric>BasePageData/StatusCodeNumericRequestMetric>
                              <Operator>GreaterEqualOperator>
                              <Value>400Value>
                            NumericCriteriaExpression>
                          NumericCriteriaExpressions>
                        ErrorCriteria>
                      BasePageEvaluationCriteria>
                      <LinksEvaluationCriteria>
                        <WarningCriteria>
                          <StatusCodeCriteria>
                            <ListNumericRequestMetric>StatusCodeListNumericRequestMetric>
                            <Operator>GreaterEqualOperator>
                            <Value>400Value>
                          StatusCodeCriteria>
                        WarningCriteria>
                        <ErrorCriteria />
                      LinksEvaluationCriteria>
                      <ResourcesEvaluationCriteria>
                        <WarningCriteria>
                          <StatusCodeCriteria>
                            <ListNumericRequestMetric>StatusCodeListNumericRequestMetric>
                            <Operator>GreaterEqualOperator>
                            <Value>400Value>
                          StatusCodeCriteria>
                        WarningCriteria>
                        <ErrorCriteria />
                      ResourcesEvaluationCriteria>
                      <WebPageTotalEvaluationCriteria>
                        <WarningCriteria />
                        <ErrorCriteria />
                      WebPageTotalEvaluationCriteria>
                      <DepthEvaluationCriteria>
                        <WarningCriteria />
                        <ErrorCriteria />
                      DepthEvaluationCriteria>
                    RequestEvaluationCriteria>
                    <FormsAuthCredentials />
                  Request>
                Requests>
              ProbeAction>

The real useful info, as often it is, is in the state change context. This implies healthexplorer needs to be invokes from the alert, you won’t find any useful clue in the alert context itself. In the state change context you can find all the info returned by the http GET, the most important of them are:

the URL that’s actually been probed (so that you can try by yourself)
the HTTP status Code
the Error Code

In the screenshot the error 2147954402 states the GET has timed out (the defuel timeout is 20" and cannot be changed by an override, sigh). You can check this table (http://technet.microsoft.com/en-us/library/dd348508(WS.10).aspx) for the error code meaning. A timeout error can be considered a transient error (if it resolves) while other types of error for example 2147954429 (cannot connect) is more concerning.

In conclusion:

this monitors tries a GET, it needs to have the proper rights to connect to the web app and it needs to resolves the web app name correctly
Sharepoint strictly check for headers a site can have more than one name if the monitor checks on a decommissioned URL it can turn in error even if the users are able to connect to the same site using a different URL
sometimes Sharepoint hosts under heavy load can take a long time to initialize web apps especially if they are apps scarcely used by the users, this can cause a lot of noise. The monitor doesn’t expose the timeout paramater so you have just two choices: disable the monitor for such an app or write your own monitoring using the standard web monitor capabilities of OpsMgr.

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Using SCOM as a basic configuration audit system – Part 6 monitoring

Daniele Grandini — Sat, 07 Jan 2012 16:46:05 +0000

Previous posts on the subject:

Eventually we get to the end of the story, now we miss the most important, but easiest of all components: the compliance checking monitor. As a design choice I targeted the unit monitor to the generic windows operating system class, I set it to disable and used a bunch of overrides to set the correct properties for the different baselines. This way I just have one single monitor that applies to all windows operating system and it is implemented via overrides for the supported baselines. If you need to add a baseline just add a new override for such an operating system (obviously as far as the generic checks we implemented are valid for that operating system, you should recall that we decided to use vbscript to remain as generic as possible).

The monitor itself is just an instantiation of our unit monitor type where we set the alerting part using our handy “Message” property . The script will set the message property to a list of missing fixes or operating system version mismatch or wsh version mismatch. I know this breaks localization in terms of alert description but as long as the alert parameters substitution is implemented the way it is, I can’t see a better way to do this.

<AlertOnState>WarningAlertOnState>

<AutoResolve>trueAutoResolve>

<AlertPriority>NormalAlertPriority>

<AlertSeverity>WarningAlertSeverity>

<AlertParameter1>$Data/Context/Property[@Name='Message']$AlertParameter1>

AlertParameters>

AlertSettings>

Obviously the monitor will contribute to the configuration health model and it will set the health to warning at worst (after all such a configuration mismatch can hardly be considered a service failure). In any case you’re free to adjust the monitor health state to error if you prefer so.

OperationalStates>

In the end the while UnitMonitor will look like the following (remember it must be pasted to the monitoring section under Monitors:

<UnitMonitor ID="QND.Compliance.WindowsOS" Accessibility="Public" Enabled="false" ConfirmDelivery="true" Priority="Normal" Remotable="false"

ParentMonitorID="Health!System.Health.ConfigurationState" Target="Windows!Microsoft.Windows.OperatingSystem" TypeID="QND.OSCompliance.MT">

<Category>ConfigurationHealthCategory>

<AlertOnState>WarningAlertOnState>

<AutoResolve>trueAutoResolve>

<AlertPriority>NormalAlertPriority>

<AlertSeverity>WarningAlertSeverity>

<AlertParameter1>$Data/Context/Property[@Name='Message']$AlertParameter1>

AlertParameters>

AlertSettings>

OperationalStates>

<OSVersion>OSVersion>

<QFEList>IgnoreQFEList>

<WSHVersion>5.7WSHVersion>

<ScriptTimeout>300ScriptTimeout>

<IntervalSeconds>14400IntervalSeconds>

Configuration>

UnitMonitor>

By default the monitor will run every 4 hours and will just check for wsh version.

To complete the monitor we need the alert string resource and the corresponding display strings. Under the monitoring section of the management pack just add the definition for the resource string

StringResources>

Presentation>

Then in the language pack section add the corresponding string

<Name>Windows OS not compliant with minimum version and QFEsName>

<Description>The Windows OS isn’t compliant with the minimum baseline required for monitoring.

{0}

Check the alert context for more information.Description>

DisplayString>

Finally don’t forget the display string for the monitor itself

<Name>Prerequiste compliance for monitoringName>

DisplayString>

And we better add some knowledge base as well, we must add the knowledge base in the KnowledgeArticles section in our language pack:

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Summarymaml:title>

<maml:para>The monitor check for Operating System compliance in terms of:maml:para>

<maml:list>

<maml:listItem>

<maml:para>Operating System versionmaml:para>

maml:listItem>

<maml:listItem>

<maml:para>Windows Scripting Host Versionmaml:para>

maml:listItem>

<maml:listItem>

<maml:para>QFEs installedmaml:para>

maml:listItem>

maml:list>

<maml:para>Missing requirements can impair the monitor capabilities and/or effects agent and operating system performance maml:para>

maml:section>

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Configurationmaml:title>

<maml:para>Proper overrides have been defined for each operating system version, the list of requirements can be adjusted using custom overridesmaml:para>

maml:section>

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Causesmaml:title>

<maml:para>Fix are not installed or operating system has not been updated to the proper service pack levelmaml:para>

maml:section>

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Resolutionsmaml:title>

<maml:para>Install the missing prerequisitesmaml:para>

maml:section>

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Externalmaml:title>

<maml:para>

For an up to date list of requirements check: <maml:navigationLink>

<maml:linkText>Things to make and do for agent healthmaml:linkText>

<maml:uri href="http://nocentdocent.wordpress.com/2009/10/15/strongly-recommended-non-opsmgr-patches/" />

maml:navigationLink>

maml:para>

maml:section>

MamlContent>

KnowledgeArticle>

Now that the monitor is set up let’s build the overrides for the specific baselines, the overrides need first to enable the monitor

<MonitorPropertyOverride ID="QND.Compliance.Win2008.Enable.OR" Context="Win2008!Microsoft.Windows.Server.2008.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Property="Enabled">

<Value>trueValue>

MonitorPropertyOverride>

and the to set the proper monitor parameters, typically the minimum OS version required

<MonitorConfigurationOverride ID="QND.Compliance.Win2008.OSVer.OR" Context="Win2008!Microsoft.Windows.Server.2008.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="OSVersion">

<Value>6.0.6002Value>

MonitorConfigurationOverride>

and the comma separated list of required QFEs:

<MonitorConfigurationOverride ID="QND.Compliance.Win2008.QFE.OR" Context="Win2008!Microsoft.Windows.Server.2008.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="QFEList">

<Value>KB968967,KB981936,KB2458331Value>

MonitorConfigurationOverride>

The overrides section must be added just after the monitoring section, the complete section should look like this:

<MonitorPropertyOverride ID="QND.Compliance.Win2008.Enable.OR" Context="Win2008!Microsoft.Windows.Server.2008.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Property="Enabled">

<Value>trueValue>

MonitorPropertyOverride>

<MonitorConfigurationOverride ID="QND.Compliance.Win2008.OSVer.OR" Context="Win2008!Microsoft.Windows.Server.2008.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="OSVersion">

<Value>6.0.6002Value>

MonitorConfigurationOverride>

<MonitorConfigurationOverride ID="QND.Compliance.Win2008.QFE.OR" Context="Win2008!Microsoft.Windows.Server.2008.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="QFEList">

<Value>KB968967,KB981936,KB2458331Value>

MonitorConfigurationOverride>

<MonitorPropertyOverride ID="QND.Compliance.Win2008R2.Enable.OR" Context="Win2008!Microsoft.Windows.Server.2008.R2.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Property="Enabled">

<Value>trueValue>

MonitorPropertyOverride>

<MonitorConfigurationOverride ID="QND.Compliance.Win2008R2.OSVer.OR" Context="Win2008!Microsoft.Windows.Server.2008.R2.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="OSVersion">

<Value>6.1.7600Value>

MonitorConfigurationOverride>

<MonitorConfigurationOverride ID="QND.Compliance.Win2008R2.QFE.OR" Context="Win2008!Microsoft.Windows.Server.2008.R2.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="QFEList">

<Value>KB981314,KB981936Value>

MonitorConfigurationOverride>

<MonitorPropertyOverride ID="QND.Compliance.Win2008R2SP1.Enable.OR" Context="Microsoft.Windows.Server.2008.R2.SP1.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Property="Enabled">

<Value>trueValue>

MonitorPropertyOverride>

<MonitorConfigurationOverride ID="QND.Compliance.Win2008R2SP1.OSVer.OR" Context="Microsoft.Windows.Server.2008.R2.SP1.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="OSVersion">

<Value>6.1.7601Value>

MonitorConfigurationOverride>

<MonitorConfigurationOverride ID="QND.Compliance.Win2008R2SP1.QFE.OR" Context="Microsoft.Windows.Server.2008.R2.SP1.OperatingSystem" Enforced="false"

Monitor="QND.Compliance.WindowsOS" Parameter="QFEList">

<Value>ignoreValue>

MonitorConfigurationOverride>

Overrides>

If you want to use the 2008 R2 SP1 baseline, don’t forget to add an override to enable the discovery at the top of the overrides list:

<DiscoveryPropertyOverride ID="QND.Compliance.Win2008R2SP1Discovery.Enable.OR" Context="Win2008!Microsoft.Windows.Server.2008.R2.OperatingSystem" Enforced="false"

Discovery="QND.Compliance.Win2008R2SP1.Discovery" Property="Enabled">

<Value>trueValue>

DiscoveryPropertyOverride>

Are we all set? Not yet, we miss one last monitor, the monitor that sets the dependency of the healthservice configuration health to the compliance check we just implemented. By default we set it as disabled, but you can change it via an override or modifying the management pack code.

<DependencyMonitor ID="QND.Compliance.OSPrereq.DM" Accessibility="Public" Enabled="false" Target="SC!Microsoft.SystemCenter.HealthService"

ParentMonitorID="Health!System.Health.ConfigurationState" MemberMonitor="QND.Compliance.WindowsOS"

RelationshipType="QND.Compliance.HealthServiceReferenceOperatingSystem" Priority="Normal" Remotable="true">

<Category>ConfigurationHealthCategory>

<Algorithm>WorstOfAlgorithm>

DependencyMonitor>

Ok one last display string:

<Name>OS Prerequisite complianceName>

DisplayString>

And… the knowledge article associated to the management pack:

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Summarymaml:title>

<maml:para>This set of rules checks for Operating System and Operations Manager Agent configuration compliancemaml:para>

maml:section>

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Configurationmaml:title>

<maml:para>By default the non compliance status is not projected to the agent (health service) health state, to enable such a projection turn on the QND OS Prerequisite Compliance dependency monitormaml:para>

maml:section>

<maml:section xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

<maml:title>Externalmaml:title>

<maml:para>

<maml:navigationLink>

<maml:linkText>Things to make and do for agent healthmaml:linkText>

<maml:uri href="http://nocentdocent.wordpress.com/2009/10/15/strongly-recommended-non-opsmgr-patches/" />

maml:navigationLink>

maml:para>

maml:section>

MamlContent>

KnowledgeArticle>

That’s it, you can find the complete unsealed management pack here:

https://skydrive.live.com/embed?cid=558EC647EEF17F8D&resid=558EC647EEF17F8D%211112&authkey=AEY4_JajC8QqAB0

As usual use it at your own risk.

By the way, this project focused on OpsMgr agent required hotfixes, but the same technique can be used for other baselines. For example we used it to track hyper-v hosts compliance with “the better to install” fixes for such an environment.

Now that we finished the monitoring and alerting part and now that alerts are starting to flow into our OpsMgr console we probably want a way to have a report with all the non-compliant systems. This is going to be a tough job and it will be the subject of the following posts. (they will take a little longer since my vacation has finished).

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Using SCOM as a basic configuration audit system – Part 5 discoveries

Daniele Grandini — Sat, 07 Jan 2012 08:27:39 +0000

Previous posts on the subject:

In my first post I defined the following baselines to be checked for compliance:

· Windows Server 2008

· Windows Server 2008 R2 RTM

· Windows Server 2008 R2 with Service Pack 1

While the first two are already discovered by standard management packs, the latter is missing, so we’re going to define a new class and discover it. There are plenty of choices here, but I chose to follow the pattern established by the Windows Server 2008 Management Pack in which the R2 operating system is derived from the Windows 2008 operating system. This will be the new hierarchy:

This choice deserves some explanation since it’s going to have some side effects. What we have is that Windows 2008 R2 is a Windows 2008 and that Windows 2008 R2 SP1 is a Windows 2008 R2, this implies that all the rules targeted to Windows 2008 also apply to R2 and R2 SP1, and that all the rules targeted at R2 also apply to R2 SP1. Since our monitor will be generically targeted to the Server Operating System we will have an effect that I call slow convergence, what will happen on a newly discovered Windows 2008 R2 SP1 system is:

· First it will be discovered as a Windows 2008 R2 system and the compliance rule for such an OS will be applied resulting in a non-compliance. The Windows 2008 management pack has one discovery rule that returns the proper Operating System Version (2008 or 2008 R2)

· Then it will be discovered as a Windows 2008 R2 Service Pack 1 system and the rules for R2 SP1 will be applied, resulting in the correct compliance assessment

I think this slow convergence is acceptable, if not the Windows Server 2008 R2 SP1 class should have been derived from the Windows.Server.OperatingSystem class and the whole discovery retargeted to discover the OS. It’s really up to you, the mod should be easy enough if you followed what we have built so far.

So in the TypeDefinitions, EntityTypes section we need to add at the top the following snippet

ClassType>

ClassTypes>

And don’t forget the corresponding display string in the language pack section

<Name>Windows Server 2008 R2 Operating System with SP1Name>

DisplayString>

With this latest entry our types definition is complete, we can now focus on the monitoring section starting obviously with the discoveries needed for the new operating system baseline and for the loose reference between the HealthService and the operating system. For the relationship discovery we’re going to use the previously defined data source, the target is the source of the relationship i.e. the HealthService class, the source and target settings of the relationship are the key properties of both classes (HealthService and OperatingSystem), incidentally they’re the same the WindowsComputer class PrincipalName property.

<Category>DiscoveryCategory>

DiscoveryTypes>

<Frequency>86400Frequency>

<SyncTime>SyncTime>

<RelationshipId>$MPElement[Name="QND.Compliance.HealthServiceReferenceOperatingSystem"]$RelationshipId>

<Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$Name>

<Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$Value>

Setting>

Settings>

SourceRoleSettings>

<Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$Name>

<Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$Value>

Setting>

Settings>

TargetRoleSettings>

DataSource>

Discovery>

For the Windows 2008 R2 SP1 discovery we’re going to use a simple registry discovery and matching the operating system build with 7601. I guess you can find many sample of this kind of discovery on the web so I won’t speculate further. One last thing, just notice the discovery is disabled by default, we’re going to enable it via an override I just don’t dare assume everyone wants such a baseline.

<Category>DiscoveryCategory>

DiscoveryTypes>

<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$ComputerName>

<AttributeName>WindowsCurrentVersionAttributeName>

<Path>SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersionPath>

<PathType>1PathType>

<AttributeType>1AttributeType>

RegistryAttributeDefinition>

<AttributeName>WindowsCurrentBuildAttributeName>

<Path>SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentBuildPath>

<PathType>1PathType>

<AttributeType>1AttributeType>

RegistryAttributeDefinition>

RegistryAttributeDefinitions>

<Frequency>14400Frequency>

<ClassId>$MPElement[Name="Microsoft.Windows.Server.2008.R2.SP1.OperatingSystem"]$ClassId>

<Name>$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$Name>

<Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$Value>

Setting>

Settings>

InstanceSettings>

<And>

<XPathQuery Type="String">Values/WindowsCurrentVersionXPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="String">6.1Value>

ValueExpression>

SimpleExpression>

Expression>

<XPathQuery Type="String">Values/WindowsCurrentBuildXPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="String">7601Value>

ValueExpression>

SimpleExpression>

Expression>

And>

Expression>

DataSource>

Discovery>

Discoveries>

The discovery section is completed, just add the corresponding display string to our language pack:

<Name>QND HealthService Reference OS DiscoveryName>

<Description>Sets a reference to the OS for the HealthService needed for projecting the fix compliance to the agent stateDescription>

DisplayString>

<Name>QND Windows 2008 Server R2 with SP1 discoveryName>

DisplayString>

The next post will be the last for the monitoring part, I’m going to show the monitoring section with the overrides needed to make the compliance check work across different baselines. Then we’ll start to tackle the reporting portion of our basic configuration auditing project.

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Using SCOM as a basic configuration audit system – Part 4 more types and strings

Daniele Grandini — Thu, 05 Jan 2012 13:57:19 +0000

Previous posts on the subject:

We are almost done with the types, we still need to define the HealthService to operating system relationship discovery data source and the monitor type for compliance checking.

The discovery data source is based on a handy condition detection module I found in the documentation: System.Discovery.RelationshipSnapshotDataMapper. In reality the documentation is not so clear since it misses an example that fits our situation, but with some management pack digging it’s not so difficult to end up with the correct usage. What we’re going to do is to combine a scheduler with the condition detection module to compose a data source we can use in discovery. The data source type just wraps the scheduler and the data mapper together and exposes the needed parameters, when we’ll define the discovery itself we’re just going to combine the key properties of both classes to obtain the relationship.

<SchemaType>System!System.Discovery.MapperSchemaSchemaType>

IncludeSchemaTypes>

<xsd:element minOccurs="1" name="Frequency" type="xsd:integer" />

<xsd:element minOccurs="0" name="SyncTime" type="xsd:string" />

<xsd:element name="RelationshipId" type="xsd:string" />

<xsd:element name="SourceTypeId" minOccurs="0" maxOccurs="1" type="xsd:string" />

<xsd:element name="TargetTypeId" minOccurs="0" maxOccurs="1" type="xsd:string" />

<xsd:element name="SourceRoleSettings" type="SettingsType" />

<xsd:element name="TargetRoleSettings" type="SettingsType" />

<xsd:element name="InstanceSettings" minOccurs="0" maxOccurs="1" type="SettingsType" />

Configuration>

OverrideableParameters>

<Interval Unit="Seconds">$Config/Frequency$Interval>

<SyncTime>$Config/SyncTime$SyncTime>

SimpleReccuringSchedule>

Scheduler>

DataSource>

<RelationshipId>$Config/RelationshipId$RelationshipId>

<SourceTypeId>$Config/SourceTypeId$SourceTypeId>

<TargetTypeId>$Config/TargetTypeId$TargetTypeId>

<SourceRoleSettings>$Config/SourceRoleSettings$SourceRoleSettings>

<TargetRoleSettings>$Config/TargetRoleSettings$TargetRoleSettings>

<InstanceSettings>$Config/InstanceSettings$InstanceSettings>

ConditionDetection>

MemberModules>

Node>

Composition>

Composite>

ModuleImplementation>

<OutputType>System!System.Discovery.DataOutputType>

DataSourceModuleType>

The monitor type is the last type we need before we’re ready for the monitoring section of our management pack. We have all the basic plumbling and most importantly the data source needed to check the compliance. The monitor will be a two states monitor, our operating system will simply be Compliant or NonCompliant

MonitorTypeStates>

To address the compliance we’ll use the summary Boolean properties returned by the data source:

· OSCompliant

· QFECompliant

· WSHCompliant

For the compliance condition detection we’ll put all the properties in AND following this pattern:

<XPathQuery Type="Boolean">Property[@Name="OSCompliant"]XPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="Boolean">trueValue>

ValueExpression>

SimpleExpression>

Expression>

For the non-compliance condition detection we’ll use the same properties in OR checking on false. Since this is the only type we’re going to spend in the monitoring section of the management pack it’s time to define overridable parameters, while the configuration section resembles the data source one. That’s it, here is our MonitorTypes section

MonitorTypeStates>

<xsd:element name="OSVersion" type="xsd:string"/>

<xsd:element name="QFEList" type="xsd:string" />

<xsd:element name="WSHVersion" type="xsd:string" />

<xsd:element name="ScriptTimeout" type="xsd:integer" />

<xsd:element name="IntervalSeconds" type="xsd:integer" />

<xsd:element name="SyncTime" type="xsd:string" />

Configuration>

OverrideableParameters>

<OSVersion>$Config/OSVersion$OSVersion>

<QFEList>$Config/QFEList$QFEList>

<WSHVersion>$Config/WSHVersion$WSHVersion>

<ScriptTimeout>$Config/ScriptTimeout$ScriptTimeout>

<IntervalSeconds>$Config/IntervalSeconds$IntervalSeconds>

<SyncTime>$Config/SyncTime$SyncTime>

DataSource>

<And>

<XPathQuery Type="Boolean">Property[@Name="OSCompliant"]XPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="Boolean">trueValue>

ValueExpression>

SimpleExpression>

Expression>

<XPathQuery Type="Boolean">Property[@Name="QFECompliant"]XPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="Boolean">trueValue>

ValueExpression>

SimpleExpression>

Expression>

<XPathQuery Type="Boolean">Property[@Name="WSHCompliant"]XPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="Boolean">trueValue>

ValueExpression>

SimpleExpression>

Expression>

And>

Expression>

ConditionDetection>

<Or>

<XPathQuery Type="Boolean">Property[@Name="OSCompliant"]XPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="Boolean">falseValue>

ValueExpression>

SimpleExpression>

Expression>

<XPathQuery Type="Boolean">Property[@Name="QFECompliant"]XPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="Boolean">falseValue>

ValueExpression>

SimpleExpression>

Expression>

<XPathQuery Type="Boolean">Property[@Name="WSHCompliant"]XPathQuery>

ValueExpression>

<Operator>EqualOperator>

<Value Type="Boolean">falseValue>

ValueExpression>

SimpleExpression>

Expression>

Or>

Expression>

ConditionDetection>

MemberModules>

Node>

RegularDetection>

Node>

RegularDetection>

RegularDetections>

MonitorImplementation>

UnitMonitorType>

MonitorTypes>

To complete this first Management Pack snippet let’s add the manifest section, here I put several dependency we’re going to use later in the management pack.

xml version="1.0" encoding="utf-8"?>

<ID>QND.AgentComplianceID>

<Version>6.1.7221.11Version>

Identity>

<Name>QND Agent ComplianceName>

<ID>System.LibraryID>

<Version>6.0.4941.0Version>

<PublicKeyToken>31bf3856ad364e35PublicKeyToken>

Reference>

<ID>Microsoft.Windows.LibraryID>

<Version>6.0.4941.0Version>

<PublicKeyToken>31bf3856ad364e35PublicKeyToken>

Reference>

<ID>Microsoft.Windows.Server.2003ID>

<Version>6.0.4941.0Version>

<PublicKeyToken>31bf3856ad364e35PublicKeyToken>

Reference>

<ID>Microsoft.Windows.Server.2008.DiscoveryID>

<Version>6.0.4941.0Version>

<PublicKeyToken>31bf3856ad364e35PublicKeyToken>

Reference>

<ID>Microsoft.SystemCenter.LibraryID>

<Version>6.0.4941.0Version>

<PublicKeyToken>31bf3856ad364e35PublicKeyToken>

Reference>

<ID>System.Health.LibraryID>

<Version>6.1.7043.0Version>

<PublicKeyToken>31bf3856ad364e35PublicKeyToken>

Reference>

References>

Manifest>

Finally let’s add the LanguagePacks section with the proper display strings (kept at a minimum actually)

<Name>Quae Nocent Docent Agent ComplianceName>

<Description>Checks for OS compliance for monitoringDescription>

DisplayString>

<Name>HealthService references Operating SystemName>

DisplayString>

DisplayStrings>

LanguagePack>

LanguagePacks>

In the next post we will complete our types section adding the Windows 2008 R2 Service Pack 1 baseline to the picture and performing some discovery.

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Using SCOM as a basic configuration audit system – Part 3 types

Daniele Grandini — Tue, 03 Jan 2012 14:04:22 +0000

Previous posts on the subject:

Now that we have the core data provider in place we need to formalize the design defining the proper management pack constructs. In this post we will first define the loose relationship between the Operating System and the Health Service in such a way we can add a dependency monitor to the health service to project the compliance status, secondly we will define the data source embedding the script and the unit monitor type for compliance checking.

To define a loose relationship we’re going to define simple System.Reference relationship under the TypeDefinitions section. The source for the relationship is the HealthService and the target is the generic Microsoft.Windows.OperatingSystem class, I chose to define the relationship as “Internal” since I don’t think I will use it outside this Management Pack, but you define it as “Public” if you think this relationship is useful in general.

<Source>SC!Microsoft.SystemCenter.HealthServiceSource>

<Target>Windows!Microsoft.Windows.OperatingSystemTarget>

RelationshipType>

RelationshipTypes>

EntityTypes>

TypeDefinitions>

For the definition of our data source I prefer to be little more organized so I’m going to define a Probe embedding the script itself and then a DataSource based on the probe, I always build my data source this way to privilege code reusability, but obviously you’re free to directly embed the script in the data source. As you’ll see I always put my scripts inside a CDATA section this way I don’t have to encode / decode the script to edit them.

Let’s start, in the TypeDefinitions section let’s add a ModuleTypes section under the TypeDefinitions and then our probe module. The only member of our probe will be a ScriptPropertyBagProbe, the configuration section is straightforward and resembles the script parameters plus a script timeout value used by the ScriptPropertyBagProbe. We don’t need to define overridable parameters here since we do not plan to use the probe directly in the Management Pack Monitoring section:

<xsd:element name="OSVersion" type="xsd:string" />

<xsd:element name="QFEList" type="xsd:string" />

<xsd:element name="WSHVersion" type="xsd:string" />

<xsd:element name="ScriptTimeout" type="xsd:integer" />

Configuration>

<ScriptName>QND.GetOSCompliance.vbsScriptName>

<Arguments>$Config/OSVersion$ "$Config/QFEList$" $Config/WSHVersion$Arguments>

ScriptBody>

<TimeoutSeconds>$Config/ScriptTimeout$TimeoutSeconds>

ProbeAction>

MemberModules>

Composition>

Composite>

ModuleImplementation>

<OutputType>System!System.PropertyBagDataOutputType>

<InputType>System!System.BaseDataInputType>

ProbeActionModuleType>

ModuleTypes>

Now that we have defined our probe type module let’s use it in a datasource, we are going to use the datasource in the monitor type. In the ModuleTypes section, let’s add the datasource right *before* the probe type. The datasource module will be composed with the previously defined probe type and a simple System.Scheduler module so that we can run our probe at specified intervals optionally synced at a specific time. So here we go:

<xsd:element name="OSVersion" type="xsd:string"/>

<xsd:element name="QFEList" type="xsd:string" />

<xsd:element name="WSHVersion" type="xsd:string" />

<xsd:element name="ScriptTimeout" type="xsd:integer" />

<xsd:element name="IntervalSeconds" type="xsd:integer" />

<xsd:element name="SyncTime" type="xsd:string" />

Configuration>

<Interval>$Config/IntervalSeconds$Interval>

<SyncTime>$Config/SyncTime$SyncTime>

SimpleReccuringSchedule>

Scheduler>

DataSource>

<OSVersion>$Config/OSVersion$OSVersion>

<QFEList>$Config/QFEList$QFEList>

<WSHVersion>$Config/WSHVersion$WSHVersion>

<ScriptTimeout>$Config/ScriptTimeout$ScriptTimeout>

ProbeAction>

MemberModules>

Node>

Composition>

Composite>

ModuleImplementation>

<OutputType>System!System.PropertyBagDataOutputType>

DataSourceModuleType>

Once again we don’t define overridable parameters, we’re going to do it in our unit monitor type.

That’s enough for today, in my next post I will add the unit monitor type, some needed display strings and obviously the Management Pack manifest.

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Using SCOM as a basic configuration audit system – Part 2 the script

Daniele Grandini — Mon, 02 Jan 2012 15:26:18 +0000

Previous posts on the subject:

Using SCOM as a basic configuration audit system – Part 1

The first step for our compliance management pack is to develop the core checking script. This is not to say that this must be the approach for every MP, probably a better start would be the health model, nevertheless I want to immediately check if there’s any showstopper in the core stuff so I will address the health model in the following post.

To build the script we need to keep in mind that:

- the output will be used to assess compliance on one side and to return data that can be used in reporting and in alerts to show what’s going on.

- The script must be generic enough to work across different OS versions, this is why we’re using vbscript

- The script will be targeted to a specific baseline

- The patches list must not be hard coded since the whole list can change between OS versions and can be adjusted to address specific needs (via overrides)

- The script will need to check for proper OS version, proper Windows Scripting Host version and proper patches

Given these requirements the script will take in input:

- Desired OS version (for the given baseline, for example we can set that for Windows 2008 the minimum service pack supported is service pack 2)

- Comma delimited list of required patches (IGNORE to skip the check)

- Required Windows Script Host version (typically at least 5.7, IGNORE to skip the check)

The script will return a property bag with the following properties for generic assessment:

- OS compliance

- Patches compliance

- WSH compliance

And the following properties for descriptive purposes:

- OS version

- WSH version

- One entry for each patch listed telling if the patch is present or not

- A description to be used in alerting with the reason for the missing compliance

The script logic is pretty simple:

- Load all the required patches into a dictionary, the dictionary will tell if the patch is present or not and will be the base for building the patches part of the returned property bag

- Check for OS version using Win32_OperatingSystem wmi class

- Check for windows scripting host version, id the parameter is set to IGNORE then it is assumed wsh is compliant

- Check for the presence of the required patches using the Win32_QuickFixEngineering wmi class. As stated in the comments, I will first check for an exact match and if not successful I will check for patches version using the –v? postfix

- Finally using the results gathered the script builds the property bag and a descriptive property to be used in alerting

Note. The following code will miss all the error checking stuff. Before you put anything in production I strongly suggest a strong parameters checking and some WMI error management. I left the error checking code out of the picture to make the script shorter and more readable.

Option Explicit
SetLocale ("en-us")

'Globals
Dim g_API, g_oXML
Dim g_StdErr
Dim P_TraceLevel, P_OSVer, P_QFEList, P_WSHVersion

'On Error Resume Next

Dim dtStart, oArgs
Dim dicQFEs, qfe, oQFEs
Dim i, oWMI, oWMIOS, OSVersion, Keys
Dim oBag, bOSCompliance, os, bQFECompliance, bWshCompliance

      dtStart = Now

    Globals

    Set oArgs = WScript.Arguments

    P_OSVer = oArgs(0)
    if UCASE(TRIM(oArgs(1)))="IGNORE" Then
        P_QFEList = Split("", ",")
    else
        P_QFEList = Split(oArgs(1),",")
    end if
    P_WSHVersion = oArgs(2)
    Set dicQFEs = CreateObject("Scripting.Dictionary")
    dicQFEs.CompareMode=vbTextCompare

    for I=0 to ubound(P_QFEList)
        dicQFEs.Add P_QFEList(i), false
    next

    'Now get the info we need via WMI
    Set oWMI = GetObject("winmgmts:\\.\root\cimv2")
    Set oWMIOS = oWMI.ExecQuery("Select Version from Win32_OperatingSystem")
    for each os in oWMIOS
        OSVersion = os.Version
    next
    bOSCompliance = (OSVersion >= P_OSVer)
    bWshCompliance = (WScript.Version >= P_WSHVersion or UCASE(P_WSHVersion)="IGNORE")
    Set oQFEs = oWMI.ExecQuery("Select * from Win32_QuickFixEngineering")

    for each qfe in oQFEs
    'sadly I cannot use an exact match to take into account the KB123456-v? fix naming
        if (dicQFEs.Exists(qfe.HotFixID)) Then
            dicQFEs(qfe.HotFixID) = true
        else
    'if I have not an exact match then check for patch versioning
          keys = dicQFEs.Keys
          for I=0 to dicQFEs.count -1
            if UCASE(keys(I) & "-v") = UCASE(Left(qfe.HotFixID, Len(keys(I)&"-v"))) then
              dicQFEs(keys(I)) = true
              exit for
            end if
          next
        end if
    next

    'Now prepare the data to return
    Dim sMessage
        If Not bOSCompliance Then
            sMessage = sMessage & "OS is not compliant required version: " & P_OSVer & " Detected Version: " & OSVersion & vbCrLf
        end if
        If Not bWshCompliance Then
            sMessage = sMessage & "WSH is not compliant required version: " & P_WSHVersion & " Detected Version: " & WScript.Version & vbCrLf
        end if
        Set oBag = g_API.CreateTypedPropertyBag(StateDataType)
        call oBag.AddValue("OSVersion", OSVersion)
        call oBag.AddValue("OSCompliant", bOSCompliance)
        bQFECompliance = True
        for each qfe in dicQFEs.Keys
            if false = dicQFEs(qfe) Then
                bQFECompliance = false
                sMessage = sMessage & qfe & " is missing" & vbCrLf
            end if
            call oBag.AddValue(qfe, dicQFEs(qfe))
        next
        call oBag.AddValue("QFECompliant", bQFECompliance)
        call oBag.AddValue("WSHCompliant", bWSHCompliance)
        call oBag.AddValue("Message", sMessage)
        'finally resturn the property bag
        g_API.AddItem oBag
        Call g_API.ReturnItems

    ClearGlobals

'**********************************************
'**** HELPER FUNCTIONS SCOM sempre necessarie
'**********************************************

Sub Globals
    P_TraceLevel = TRACE_VERBOSE
    Set g_API = CreateObject("MOM.ScriptAPI")
    Set g_oXML = CreateObject("MSXML.DOMDocument")
    Set g_StdErr = WScript.StdErr
end Sub

Sub ClearGlobals
    Set g_API = Nothing
    Set g_oXML = Nothing
End Sub

- Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Using SCOM as a basic configuration audit system – Part 1

Daniele Grandini — Sat, 31 Dec 2011 08:41:01 +0000

I’m going to start a series of articles, I don’t know how many yet, on how to use your OpsMgr infrastructure to check for proper configuration of the managed systems. Then number of posts will be based on how much I can write in one hour J. The basic need started with the growing number of patches needed to guarantee a complete and hassle free monitoring experience “Things to make and do for agent health”. Obviously OpsMgr is not the first choice tool to solve this kind of problem, it has not any standardized building block or formal architecture whereas System Center Configurations Manager has. So if you have SCCM agents deployed on the same systems managed by OpsMgr this series of posts is not for you, you better use the SCCM DCM feature to address the compliance checking and if you have Service Manager in place then you can have the formal plumbing, too.

This first installment will set the scope of this project and some background on the health model needed.

At the end of our effort we’ll have a management pack that will address these requirements:

it needs to check for a minimum service pack level given a specific operating system
it needs to check for the presence of a set of patches for a given operating system and service pack level
optionally it needs to integrate the health model of OpsMgr agent (HealthService) with the compliance level
it needs to report on non-compliant systems with a detailed status regarding missing patches

For the sake of these posts I will concentrate on Windows Server 2008 and Windows Server 2008 R2, but the same technique can be applied to other systems (for example Windows 2003), for this reason I will use vbscript instead of powershell for any scripting needed. Moving away for the official support statement for OpsMgr I will target any reporting need to SQL Server 2008 schema, so the reports will work on SQL Server 208 and superior, but not on SQL Server 2005.

Regarding the health model I’ll need to set a new baseline (with baseline I’m referring to the operating system + service pack combination) for R2 SP1, the baselines I’m going to tackle are:

· Windows Server 2008

· Windows Server 2008 R2 RTM

· Windows Server 2008 R2 with Service Pack 1

for these baselines I’ll set up a monitor (targeted at the OS) under the configuration branch to assess the proper agent compliance

At the same time I’ll establish a loose relationship with the HealthService to project the compliance status to the agent health. This projection will be disabled by default

The next post will address the core scripting needed to assess the compliance level.

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

What do you think about Microsoft Management Packs?

Daniele Grandini — Thu, 15 Dec 2011 11:32:41 +0000

Marnix Wolf, a fellow MVP, has started an online survey to collect community feedbacks on Microsoft Management Packs quality. The results will be shared with Microsoft to drive proper attention on this key topic. If you read this blog you know how much MPs quality can make a difference in your monitoring effectiveness. So let’s share our experiences filling in Marnix’s survey:

http://booroo.com/app/rendersurvey.asp?sid=4ufdnwk8d1gs4ju20246

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.