Latest Blogs

Blog: Enable Certificate Web Enrollment without SSL(HTTPS) in Windows 2008

Mon, 09 Nov 2009 04:35:18 GMT

Windows 2008 introduces a couple of annoyances with the Certificate Web Enrollment form (/certsrv) that are worth mentioning, and pointing out the workarounds in case you need them. There is a third annoyance (also with a workaround), that is a somewhat more lengthy discussion and will be addressed on it's own.

Problem #1:

The first is the deprecation of the components we use for Web Enrollment. If we look at KB922706, we can see the details of what happened. This KB article is titled:

How to use Certificate Services Web enrollment pages together with Windows Vista or Windows Server 2008

"The Windows Server 2003 Certificate Services Web enrollment functionality relies on an ActiveX control that is named Xenroll. This ActiveX control is available in Microsoft Windows 2000 and in later versions of Windows. However, Xenroll has been deprecated in Windows Vista and in Windows Server 2008".

In short, the components are not present in Windows 2008 by default, but can be downloaded from this KB and implemented if you need them.

Problem #2:

The second is the fact the SSL (HTTPS) is required in order to use the Certificate Web Enrollment form in Windows 2008. When you attempt to access the forum with HTTP://, you receive the following error at the top of your browser:

"Internet Explorer has blocked this site from using an ActiveX control in an unsafe manner. As a result, this page might not display correctly"

It's true that SSL is more secure and definitely a best practice, but especially in lab testing and intranet environments, SSL may not be considered strictly necessary. You can work around this issue.

1. In IE Internet Options, Security Tab, make sure the Certificate Web Enrollment site is in the list of Trusted Sites.

2. With Trusted Sites highlighted, click the Customize Button.

3. In the Security Settings, set "Initialize and script ActiveX controls not marked as safe for scripting" to ENABLED, as shown in the image below.

Conclusion

As always, take care in choosing when it's appropriate to lower your defenses in this area. But when the situations fits, these are some of the tools and methods at your avail to make your work easier.

Blog: How to create a PowerShell Script Discovery including On-Demand Discovery Task using the Authoring Console – Act I

Sun, 08 Nov 2009 20:44:33 GMT

This is a step-by-step guide in multiple parts:

Preface

Part 1 will cover the Class

Part 2 will cover the Probe Actions Module Type

Part 3 will cover the Data Source Module Type

Part 4 will cover the Discovery

Part 5 will be our Discovery Test

Part 6 will cover the Write Action Module needed for the Task

Part 6 will cover the On-Demand Discovery Task

Part 7 will be our On-Demand Discovery Task Test

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 and Authoring Console R2 !

Preface

It’s best practice to not just attach a Script to a single Workflow but create Modules holding the Scripts that can be used by Workflows like Monitors or Discoveries. In this Blog, I will walk you through creating a Management Pack that does just this, in the second Act I want to get into more detail on the Powershell side of this, therefore the coding stuff.

Also check out Stefan Koell’s Blog that covers the Monitors.

In this example we assume that we want to provide a Monitor that an Administrator can configure himself using the Registry. However, this example will only cover the Discovery and not the Monitor.

Part 1: Creating the Class

In the first step we create a class that has the properties for all the configuration parameters that are needed for the Monitor. In the case of the File Content Check Monitor we have: File and ErrorText. Additionally we need a Key-Property called: ID.

Open up the “Authoring Console” (needs to be installed separately and can be found on the SCOM R2 media) and let’s create a new management pack using File->New…->Empty Management Pack

The MP ID is: code4ward.Sample.PowerShellDiscovery

The Display Name is: code4ward Sample PowerShell Discovery

Now let’s navigate to the Service Model space, and select Classes in the tree view.

Right-click in the Classes and select New->Custom Class.

Type in an ID: code4ward.Sample.PowerShellDiscovery.Classes.CheckFileContent

Type in a Name: Check File Content

Set the Base Class to: Microsoft.Windows.LocalApplication

Navigate to the Properties Tab.

There's already a property there called DisplayName, it's a property every class has, and it must be set.

Additionally we create the following properties: File, ID and ErrorText

For this, right-click in the left pane under DisplayName and select Add Property.

Enter a name for the property: File

Click OK.

Additionally we give our property a Display Name: File

Repeat that process for the ErrorText property so we have both parameters that are needed.

For the ID property, do the same but tick the Key box.

Click Apply and OK.

Part 2: Probe Action Module

We are not going to just use a Script Discovery as we want to have our Script available for a Task as well. Therefore we will create a Probe Action Module first and afterwards a Data Source Module.

The Probe Action Module will contain the script and therefore the discovery Logic, the Data Source will then add the Interval and the SyncTime configurations that are needed so we can use it as a Discovery Module.

The reason for doing it this way is because we can use the Probe Action Module for a Task as well. Therefore if we just made changes to the Registry and need to discover them NOW we can just fire the On-Demand Discovery Task from the Console.

This is the configuration needed for the Probe Action later, it’s pretty much the same as a commond Discovery Script configuration but the SyncTime and Interval are not needed:

DiscoverFileContentChecks.ps1

                

param($mapElement, $targetID, $computerName, $debug) 

  

#Error-Handler

trap 

{ 

    continue;

}

  

function Main

{

    trap{continue}

    #Set Error and Debug Strings

    $Error.Clear()

    if ($debug -ne "true"){$debug = [bool]$false}else{$debug = [bool]$true}

    $Script:Err             = @()

    $Script:API             = new-object -comObject "MOM.ScriptAPI"

    $Script:LOG_ERROR       = 1

    $Script:LOG_WARNING     = 2

    $Script:LOG_INFORMATION = 4

    $Script:ScriptName      = "code4ward.Sample.PowerShellDiscovery.ps1"

    $Script:Arguments       = "Received Arguments: `r MPElement = $mapElement, `rTargetID = $targetID, `rComputerName = $computerName, `rDebug = $debug"

    

    #Set the Discovery Object and the Check-Hive

    $Script:Discovery        = $Script:API.CreateDiscoveryData(0, $mapElement, $targetID)

    $Script:CheckHive         = "HKLM:\SOFTWARE\code4ward\SCOM"

    

    # Discover File-Content-Checks all Checks

    Discover-FileContentChecks("$Script:CheckHive\FileContentChecks")

    

    #Return Discovery Data

    Write-DebugInfo("Returning Discovery Data")

    $Script:Discovery

}

  

function Discover-FileContentChecks([string]$fileContentChecksPath)

{

    Write-DebugInfo("Running Discovery for the FileContentChecks")

    

    if (-not (Test-Path $fileContentChecksPath))

    {

        Write-DebugInfo("The path specified for the FileContentChecksPath [$fileContentChecksPath] can't be found on this computer, skipping this Discovery.")

    }

    else

    {

        $FileContentChecks = @(Get-ChildItem $fileContentChecksPath)

        

        foreach ($FileContentCheckPath in $FileContentChecks)

        {    

            #Get Values and add them to Variables

            #Inherited Properties

            $PropertyName = $FileContentCheckPath.Name.Replace($fileContentChecksPath.Replace("HKLM:", "HKEY_LOCAL_MACHINE") + "\", "")

            $PropertyID = "FileContentCheck." + $PropertyName.Replace(" ", "")

            

            #Class-Properties

            $PropertyFile = $FileContentCheckPath.GetValue("File")

            $PropertyErrorText = $FileContentCheckPath.GetValue("ErrorText")

      

      write-debuginfo("Received Name: $PropertyName ID: $PropertyID File: $PropertyFile ErrorText: $PropertyErrorText")

                        

            $Instance = $Script:Discovery.CreateClassInstance("$MPElement[Name='code4ward.Sample.PowerShellDiscovery.Classes.CheckFileContent']$")

            $Instance.AddProperty("$MPElement[Name='System!System.Entity']/DisplayName$", $PropertyName)

            $Instance.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", $computerName)

            $Instance.AddProperty("$MPElement[Name='code4ward.Sample.PowerShellDiscovery.Classes.CheckFileContent']/ID$", $PropertyID)

            $Instance.AddProperty("$MPElement[Name='code4ward.Sample.PowerShellDiscovery.Classes.CheckFileContent']/File$", $PropertyFile)

            $Instance.AddProperty("$MPElement[Name='code4ward.Sample.PowerShellDiscovery.Classes.CheckFileContent']/ErrorText$", $PropertyErrorText)

            

            #Return Instance to Discovery Data

            Write-DebugInfo("Adding discovered Instance to Discovery")

            if(-not $Error.Count -gt 0){$Script:Discovery.AddInstance($Instance)}else{Write-ErrorInfo("Discover-FileContentChecks-$TargetID")}

        }  

    }

}

  

function Write-DebugInfo

{

    param ([string] $msg)

    if ($debug -eq $true) 

    {

        $API.LogScriptEvent("$ScriptName",100,$Script:LOG_INFORMATION,"`r$Arguments`r`r$msg")

    }

}

  

function Write-WarningInfo

{

    param ([string] $msg)

    $API.LogScriptEvent("$ScriptName",200,$Script:LOG_WARNING,"`r$Arguments`r`r$msg")

}

  

function Write-ErrorInfo

{

    param ([string] $msg)

    $API.LogScriptEvent("$ScriptName",500,$Script:LOG_ERROR,"`r$Arguments`r`r$msg")

}

  

#Call the MainFunction

Main

       ]]>

                

                  

                    MapElement

                    $Config/MapElement$

                  

                  

                    TargetID

                    $Config/TargetID$

                  

                  

                    ComputerName

                    $Config/ComputerName$

                  

                  

                    Debug

                    $Config/Debug$

                  

                

                600

	Navigate to the Type Library space, and select Type Library\Module Types\Probe Actions in the tree view. Right-click in the Probe Actions and select New->Composite Probe Action. Type in an ID: code4ward.Sample.PowerShellDiscovery.Probe.DiscoverFileContentCheck Type in a Name: Discover File Content Check Switch to to the Member Modules Tab.
	Click Add... and look for microsoft.windows.powershelldiscoveryprobe. Select it, give it an ID and click OK.
	You will then be prompted for the Configuration. Click Edit... (I personally use Notepad as the Editor, if you want to use something else, feel free to do so.
	Replace the XML stuff inside the element with the code above. Save and close.
	As you may notice, the values for the parameters are using variables $Config/TargetID$. We are going to create them soon. Click OK.
	Select Module Output in the drop down list in the Next Module column. Switch to the Configuration Schema Tab.
	Under Simple Configuration Schema click Add... Enter the name: MapElement Click OK and verify that it's type is String. Do the same for TargetID and ComputerName. For Debug, do the same but set it's type to Boolean. Switch to the Overrideable Parameters Tab.
	Click Add... Choose MapElement and give it the unique identifier MapElement, click OK. Verify that the type in the Configuration Element column is String. Do the same for TargetID and ComputerName. For Debug, do the same but set it's type to Boolean. Switch to the Data Types Tab.
	Set the Input Data to This module requires Input data and in the drop-down list choose System.BaseData. Set the Output Data Data Type to: System.Discovery.Data Switch to the Options* Tab.*
	Change the Accessibility property to Public. This is optional and may be useful when you seal your MP and provide these modules to use in other MPs. Click Apply and OK.

Part 3: Data Source Module

	Navigate to the Type Library space, and select Type Library\Module Types\Data Source in the tree view. Right-click in the Probe Actions and select New->Composite Data Source. Type in an ID: code4ward.Sample.PowerShellDiscovery.DataSource.DiscoverFileContentCheck Type in a Name: Discover File Content Check Switch to to the Member Modules Tab.
	Click Add... and look for code4ward, you should find our previously created Probe Module. Select it, give it an ID and click OK.
	You are then prompted for the configuration of the Module. Clear all the values. At each value box, click the arrow on the right side and choose Promote. Once finished, click Apply and OK.
	We need an additional Member Module now that extends the Data Source with the Interval and SyncTime configurations needed for the Discovery Module later. In the Member Modules Tab click Add... and look for System.Discovery.Scheduler Select it, give it an ID and click OK.
	You will then be prompted for the configuration. Clear the Interval and SyncTime and use the right arrow next to these values again and choose Promote. Click Apply and OK.
	Now we need to configure the sequence order of the Member Modules. At the Discovery Scheduler set the Next Module to the ID of the Discovery Probe. At the Discovery Probe set the Next Module to Module Output. Consider the Discovery Scheduler as our trigger that then launches the Discovery Probe. Switch to the Configuration Schema Tab.
	As you can see, the Simple Configuration Schema items have already been created. That's what Promote did earlier. All we need to do is changing the Type of Debug to Boolean. Switch to the Overridable Parameters Tab.
	Click Add... Choose MapElement and give it the unique identifier MapElement, click OK. Verify that the type in the Configuration Element column is String. Do the same for TargetID, ComputerName and SyncTime. For Debug, do the same but set it's type to Boolean. For Interval, do the same but set it's type to Integer. Switch to the Data Types Tab.
	Set the Output Data Data Type to: System.Discovery.Data Switch to the Options* Tab.*
	Change the Accessibility property to Public. This is optional and may be useful when you seal your MP and provide these modules to use in other MPs. Click Apply and OK.
	It can happen that the values in the Probe Action Module configuration get cleared which causes an error once you click Apply. In this case, switch back to the Member Modules Tab and edit the Probe Action Module again. As you can see (in case it happened), the previously created values were cleared, I guess this is some weird Authoring Console Bug that may be fixed by now (with the new version containing the Workflow Debugger). On the right side of each value click the arrow and select the matching $Config\. For MapElement it’s $Config\MapElement$ For TargetID it’s $Config\TargetID$ And so on… Once finished click Apply, Apply, OK.

Part 4: Discovery

Now that our modules are ready, we can create the actual Discovery. The Discovery will use the DataSource module we just created and will discover instances of the class we created earlier.

	Navigate to the Health Model space, and select Discoveries in the tree view. Right-click in the Discoveries and select New-> Custom Discovery Type in an ID: code4ward.Sample.PowerShellDiscovery.Discoveries.DiscoverFileContentCheck
	Type in a Name: Discover File Content Checks Change the Target to: Microsoft.Windows.OperatingSystem Switch to the Discovered Classes Tab.
	At Discovered Classes and their attributes click Add... and select Add discovered type.
	Look for code4ward and you should find our previously created class. Select it and click OK. Switch to the Configuration Tab.
	Click Browse for a type...
	Look for code4ward and you should find our previously created DataSource Module. Select it, give it an ID and click OK.
	Now we need to configure our Discovery. SyncTime, IntervalSeconds and Debug is variable. Therefore adjust them so they fit your needs. (For testing you should set the IntervalSeconds way lower). SyncTime: 00:00 IntervalSeconds: 600 MapElemenet: $MPElement$ TargetID: $Target/Id$ ComputerName: Click the arrow on the right side and choose Principal Name under (Host = Windows Computer). Debug: true Click Apply and OK.

Part 5: Testing the Discovery

So, now that we have our discovery ready we want to test it of course. For this we will create our Registry Keys and import the Management Pack, afterwards we will check the Discovered Inventory to see if our Instance has actually been discovered.

	Open the Registry on the machine of your choice with Start->Run->regedit->OK
	Open the HKEY_LOCAL_MACHINE tree, right-click SOFTWARE and choose New->Key
	Name it code4ward and hit Enter.
	Under code4ward create another Key SCOM, under SCOM create another Key FileContentChecks and under FileContentChecks another Key called TestCheck (or anything else, this will be the DisplayName of our Check and it will also be contained in our ID).
	Time to configure it. All we need to provide now are 2 String Values called File and ErrorText. Select the TestCheck Key, and in the right pane right-click, New->String Value. Name it File, double-click it and give it a Value data: c:\test.txt <- or something else. Create another String Value called ErrorText and give it some Value Data like: ERROR.

Now we have everything set up in the Registry so we have some data we can discover. Time to Import our Management Pack.

	In the Authoring Console click File->Save As->Standard Management Pack And drop it somewhere called: code4ward.Sample.PowerShellDiscovery.xml
	Now it's time to switch to the Operations Console. Let’s navigate to the Administration space, right-click Management Packs in the tree-view and select Import Management Packs...
	Click Add->Add from disk... We don't need to search for dependencies, therefore click No.
	Locate the Management Pack, select it and click Open.
	Next, click Install and wait for the Import process to be finished.
	Navigate to the Monitoring space, select Discovered Inventory in the right pane under Actions select Change Target Type... Look for code4ward and you should see our Class we created in the Management Pack. Select it and click OK.
	And after a while, depending on the Interval you chose and the SyncTime, our Instance should be discovered. In our case the Discovery will run at every full 10 minutes, therefore 15:00, 15:10, 15:20 and so on. If it doesn't, check the Event Log for Operations Manager, the Debug Information and Error Information from the Script should be there.

Part 6: Write Action Module

Since our Discovery Probe only provides the Discovery Data and doesn't write into the Operations Manager Database we need an additional module that does that Write Action for us.

	Open up the Authoring Console again and open our previously created Management Pack. Navigate to the Type Library space, and select Module Types->Write Actions in the tree view. Right-click in the Write Actions and select New-> Composite Write Action...
	Give it the ID: code4ward.Sample.PowerShellDiscovery.WriteAction.OnDemandFileContentCheckDiscovery Click OK.
	Give it the Display Name: Discover File Content Check Switch to the Member Modules Tab.
	Click Add... and look for Microsoft.SystemCenter.DiscoveryDataWriter Select it, give it an ID and click OK.
	Leave the configuration alone and just click OK.
	Since we need our Discovery Probe as well, click Add... again and look for code4ward. You'll find 2 available modules, choose the one of type Probe Action. Give it an ID and click OK.
	You are then prompted for the configuration of the module. Clear all the values and use the right arrow next to each value and choose Promote.
	For the module Write Action choose Module Output as NextModule. For the module Probe Action choose the Write Action as NextModule. This launches the Probe Action first and then forwards the Discovery Data to the Write Action. Switch to the Configuration Schema Tab.
	As you can see, the Simple Configuration Schema items have already been created (by Promote). Verify that ComputerName, MapElement and TargetID are of Type String and that Debug is of Type Boolean. Switch to the Overridable Parameters Tab.
	Click Add... Choose MapElement and give it the unique identifier MapElement, click OK. Verify that the type in the Configuration Element column is String. Do the same for TargetID and ComputerName. For Debug, do the same but set it's type to Boolean. Switch to the Data Types Tab.
	Verify that the Input Data type is System.BaseData. Switch to the Options Tab.
	Change the Accessibility property to Public. This is optional and may be useful when you seal your MP and provide these modules to use in other MPs. Click Apply and OK.
	It can happen that the values in the Probe Action Module configuration get cleared which causes an error once you click Apply. In this case, switch back to the Member Modules Tab and edit the Probe Action Module again. As you can see (in case it happened), the previously created values were cleared, I guess this is some weird Authoring Console Bug that may be fixed by now (with the new version containing the Workflow Debugger). On the right side of each value click the arrow and select the matching $Config\. For MapElement it’s $Config\MapElement$ For TargetID it’s $Config\TargetID$ And so on… Once finished click Apply, Apply, OK.

Part 7: On-Demand Discovery Task

So, finally we can create our Task using the previously created Write Action module.

	Navigate to the Health Model space, and select Tasks->Agent Tasks in the tree view. Right-click in the Agent Tasks and select New-> Custom Task
	Give it the ID: code4ward.Sample.PowerShellDiscovery.AgentTasks.OnDemandFileContentCheckDiscovery and click OK.
	For Display Name: Discover File Content Checks And for Target: Microsoft.Windows.Computer Switch to the Configuration Tab.
	Click Browse for a Type... and look for code4ward. You should find 2 modules, Discovery Probe and the Write Action we created earlier. Select the one containing WriteAction, give it an ID and click OK.
	Now we need to configure our Write Action. Debug is variable. You can set it to false as well. MapElemenet: $MPElement$ TargetID: $Target/Id$ ComputerName: Click the arrow on the right side and choose Principal Name. Debug: true
	Since we want to verify that the Task works we will now disable the Discovery. Navigate to the Health Model space, select Discoveries and open the properties of our Discovery.
	Switch to the Options Tab. Set Enabled to false. Now save the Management Pack again.

Part 8: Testing the Agent Task

	In the Operations Console, delete the previous Management Pack first (so our previously discovered Instance gets deleted) and import the "new" one. Navigate to the Monitoring space, and select Windows Computers in the tree view. Select the Computer on which you created the Registry Keys and in the right pane under Windows Computer Tasks click Discover File Content Checks. In the Run Task configuration you can override parameters, the only interesting parameter here would be the Debug parameter. Since it's already set to true and the rest looks just fine, click Run.
	The Task will then start to run. Wait for it to be finished.
	Once finished, you'll receive an Information that it was either successful or not.
	Navigate to Monitoring again and select Discovered Inventory in the tree-view. Change the Target to our class again and check if it's been discovered. If it doesn't, check the Event Log for Operations Manager, the Debug Information and Error Information from the Script should be there.

Blog: Microsoft System Center and Virtualization Community Contribution Contest.

Sat, 07 Nov 2009 15:37:26 GMT

Do you want to make an impact? Get your name out there other than blogging on System Center Central this maybe a great way to make your mark!

Here is your chance to be an Influencer in the System Center and Virtualization Community and be rewarded! We want to give a blogger in our Sys-tem Center Influencer program the opportunity to win a $100 Gift Certificate!! Want in on the action? Find out how you can become a winner be-low.
First of all, what do I win? By becoming a part of our System Center Influencer community you get a chance to win a $100 USD Gift Certificate. But, we aren’t giving it away to just anybody…..

Ok, How do I win? You have to be an Influencer member to be eligible for the contest. Signing up is easy! Simply join Connect (You will need to create a Live ID Account if you do not already have one) at connect.microsoft.com. Then email scnetsup@Microsoft.com (also in the email mention that you learnt about this from the System Center Central site) to gain access to the Influencers portal. There you will have access to great materials, only available to the insider community, as well as an opportunity to inter-act with other members of the influencer community to help grow in your knowledge of System Center. The gift certificate will be awarded to the community members who are most active in posting blogs and commenting on other blogs. That’s it!

Sounds Good! What do I do first? Review the complete contest rules then signup on connect and email scnetsup@microsoft.com. Once you gain access to the Influencer portal we will register you in the contest and you are on your way to becoming a winner with System Center and Virtualization.

NO PURCHASE NECESSARY

 Contest ends at 12:00 pm PT on April 30th, 2010.
 For full contest rules please visit the web page: blogs.technet.com/systemcenter

Learn more about the Influencers Program at:
http://technet.microsoft.com/en-us/ee532416.aspx

Blog: Part 4: Creating DCM packs with SCCM 2007

Sat, 07 Nov 2009 14:55:25 GMT

There maybe a reason why you need some code from an existing Configuration Item but each item has a lock on it to stop you from editing the configuration.

Here is a more close up view of the ‘Golden Padlock’

And as you can see everything is greyed out! Why is it like Operations Manager where you can seal a Management Pack? NO, it is not if you write a DCM within in a SCCM environment it will remain open no padlock all is changeable) as soon as you import it into another SCCM server it will lock automatically. There is is code generated with the XML that controls this.

So how can we get around this? Hey that’s the easy part right click on the locked Configuration Item and click ‘Duplicate’

Save with a name to suite you, or leave with the ‘[1]’ the wizard adds

Now you now have an unlocked Configuration Item

See the padlock has been removed

And all properties are now changeable

I hope this 4 part series will help you in getting started with DCM pack creation. Also if I can help you achieve this then message me on simon at skinner.fr.

Here is the other 3 parts to this series listed;

http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexId/46753/Default.aspx

http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexId/48787/Default.aspx

http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexId/49396/Default.aspx

Blog: OpsMgr: Command Shell tips and tricks when using a criteria with a monitoring class

Fri, 06 Nov 2009 23:53:10 GMT

Here's an update to a guest post in a Powershell series from Marco Shaw, Powershell MVP and Co-director of the Powershell Community. Marco is also very active in supporting users with questions on the OpsMgr Command Shell, and in fact recently had a TechNet article published on the topic. In this post, Marco tackles some of the finer points of working with the OpsMgr 2007 Command Shell.

I’ll let Marco take it from here…

A few months ago, there was an online discussion on how to use the –criteria parameter with the Get-MonitoringObject cmdlet.
Running this in the Command Shell:

$mc = Get-MonitoringClass -name “Microsoft.Windows.Server.Computer”
Get-MonitoringObject -MonitoringClass $mc

Resulted in a list of “NoteProperty” properties such as this one:

Get-MonitoringObject -MonitoringClass $mc | Get-Member -Type NoteProperty *.DNSName

TypeName: Microsoft.EnterpriseManagement.Monitoring.MonitoringObject

Name MemberType Definition
—- ———- ———-
[Microsoft.Windows.Computer].DNSName NoteProperty System.String [Microsoft.Win..

So the issue was how to properly do something like this:

Get-MonitoringObject -MonitoringClass $mc

-Criteria ‘[Microsoft.Windows.Computer].DNSName=’something’’’

No matter what combinations of quotes or escape characters I used, nothing worked. Then it struck me that this was a “NoteProperty” and that these types of properties aren’t actual members of the original object, but special properties added by the PowerShell Extended Type System (ETS). My first guess that these properties were being added by some custom .ps1xml files, but that wasn’t the case. These properties must be embedded in the C# code of the cmdlets likely.

So a bit of searching through MSDN, and I came up with a method named GetValidPropertyNames. This method allows me to check what are the valid property names that I can use in my criteria expression.

So with a bit of OpsMgr SDK magic from the Command Shell:

# Get a connection to the local management server.
$mg = New-Object Microsoft.EnterpriseManagement.ManagementGroup(”localhost”)

# Get the class we’re looking for.
$computerMonitoringClass = $mg.GetMonitoringClass([Microsoft.EnterpriseManagement.Configuration.SystemMonitoringClass]::WindowsComputer)

# Create a criteria object. We leave the first part of the constructor as $null.
$criteria = New-Object
Microsoft.EnterpriseManagement.Monitoring.MonitoringObjectCriteria($null,$computerMonitoringClass)

# Use the method we discovered.
$critera.GetValidPropertyNames()

The result from the last command:

$criteria.GetValidPropertyNames()
PrincipalName
DNSName
NetbiosComputerName
NetbiosDomainName
…

So, what we should really be using for our criteria value is:

Get-MonitoringObject -MonitoringClass $mc -Criteria ‘DNSName=’something’’’

Which works great!

Blog: OpsMgr: Finding Grey Agents with Powershell

Fri, 06 Nov 2009 10:00:28 GMT

Here's a winner from OpsMgr guru and blogger Andreas "Tenchuu" Zuckerhut.

Q: Can I retrieve a list of uncommunicative (grey) agents with Powershell?

If you search the Internet for this topic, you'll find T-SQL queries everywhere you look, but no Powershell alternative. T-SQL is an options, but generally never as a first choice. Powershell is faster and safer given there's no chance you will inadvertently take something offline or delete in SQL Mgmt Studio.

A: The answer appears very simple – 3 lines of Powershell.

$WCC = get-monitoringclass -name "Microsoft.SystemCenter.Agent"
$MO = Get-MonitoringObject -monitoringclass:$WCC | where {$_.IsAvailable -eq $false}
$MO | select DisplayName

The SQL (listed here) works, but with a Powershell solution in hand, should be avoided.

SELECT     ManagedEntityGenericView.DisplayName, ManagedEntityGenericView.AvailabilityLastModified
FROM         ManagedEntityGenericView
INNER JOIN  ManagedTypeView ON ManagedEntityGenericView.MonitoringClassId = ManagedTypeView.Id
WHERE     (ManagedTypeView.Name = 'microsoft.systemCenter.agent') AND (ManagedEntityGenericView.IsAvailable = 0)
ORDER BY ManagedEntityGenericView.DisplayName

NOTE: Several of us have tested this side-by-side with the T-SQL and seen identical results. We'd be interested to hear your experience when comparing the results of the Powershell versus the T-SQL query.

Well Done Andreas!

Blog: Part 3: Creating DCM packs with SCCM 2007

Thu, 05 Nov 2009 20:59:50 GMT

In part 2 we created a new DCM Pack. Here in part 3 I would wanted to cover a particular aspect in the saving process, version can be a problem when saving your DCM so here are the steps to get around this problem, go to your DCM in the SCCM Console

Right click to export the DCM, which is just a cab file

save to your desktop

When saved it will look like this

Right click on the Cab file

Open then extract the XML. Note the 6 files!!

When extracted we can start to modify, also delete the RESX files we do not need these.

You can use Notepad but if you have a lot of files I use Visual Studio

Here are is the raw XML code, we are only interested in the Build Version

As we entered no info the Build Info shows just Zero’s

Modify to the the Version you want and remove ServicePackMajorVersion and ServicePackMinorVersion entries so it looks like line below

You could just use the Find and Replace in Visual Studio to do this

These next steps are optional if you wish to make it posh like for a client, as the files where saved with number you could find the ‘Display Name’ and save as this name as I have below. This makes the XML a little neater.

When the above steps are completed we need to re package the XML back into a Cab file, I use ‘Cab File Maker’ it’s simple and easy to use. Just drag and drop the 3 XML files into the Cab File Maker name the files and click start

Then when you have a re packaged Cab file import back into the SCCM Console

Then away you go with your DCM. I have to be careful of an NDA I have but I will say this, really BIG companies do it like this!

Blog: OpsMgr: How to enable OpsMgr Module Logging to Troubleshoot Cross-Platform Discovery Failure

Thu, 05 Nov 2009 08:38:45 GMT

These logs are used mainly to investigate discovery issues. The logs show details about agent push, installation, and certificate signing. Calls made outside of Windows Remote Management (WinRM) are made using SSH/SFTP. These components rely on a separate logging mechanism than Operations Manager.

To enable UNIX native module Logs

Create a blank file named EnableOpsmgrModuleLogging in the \Temp directory for the user account calling these modules by typing at a command-line prompt

COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging

NOTE: Generally, it is the SYSTEM account making calls during this process. The C:\Windows\Temp directory is the default SYSTEM temp folder, thus the reason for using this location.

DEMO: How to Enable Module Logging

OpsMgr MVP David Allen has created a short webcast on how to enable module logging, step-by-step.

Blog: System Center Central Sponsor: Bridgeways

Thu, 05 Nov 2009 00:16:37 GMT

Microsoft have created an incredibly powerful monitoring application, Bridgeways is making the reach into ‘Foreign’ territories of this monitoring tool. I remember whilst reading the brief of R2 ‘Cross Platform’ monitoring I was so excited by this and truth be told I didn’t give any thought to the applications that would run on these Cross Platform servers.

Bridgeways has given thought to these applications, in fact a great deal of thought and it’s really exciting. Oracle, MySQL, Apache and others ..." are being brought together with Microsoft by a Bridge, way! Yea Bridgeways.

So now we can monitor our Microsoft applications as well as other non MSFT applications with the exact same precision, Bridgeways are monitoring a good range of day to day apps that we may have in our mixed environment allowing us to monitor with the one application.

BridgeWays Management Pack for VMware ESX

Virtualization technology has improved dramatically over the last few years. As more and more companies look to virtualize their environments, additional vendors come to market, spurring competition and accelerating feature growth. Today’s hypervisors open even more opportunities for server consolidation and create a new (some would argue a return to the old) operational paradigm in which resources are centralized and workloads are distributed to the hardware that can best accommodate the resource requirements.

Monitoring virtualized environments has become critical to optimizing hardware performance and achieving maximum ROI. This requires a consolidated view that allows for monitoring of both the hypervisor and the individual workloads in order to identify bottlenecks and correct any problems before they have a major impact on the performance of the virtual environment.

BridgeWays Management Packs for MySQL Database and Apache HTTP Server

The LAMP stack is a common framework for both internal and public web sites, including many of the largest sites on the internet. LAMP stands for Linux, Apache, MySQL and PHP (could also be Perl or Python). While the Linux is the predominant OS, the “AMP” parts can also be run on Solaris, Windows, Mac, or other operating systems.

Administering and monitoring the LAMP stack cannot be done efficiently by separately monitoring the individual components. Using one tool to monitor the OS, another for the database, and a third tool for the web server fails to reveal how each component impacts the others. Without a contextual overview, administrators often lose a great deal of time chasing false leads, while failing to identify the root causes of issues that arise.

BridgeWays Management Packs for JBoss Application Server and Oracle Database

In most organizations, the availability of workflows associated with mission-critical applications is crucial to the success of their business. Unplanned outages are costly, and in extreme cases these applications can never be down at all, proactive monitoring is needed to ensure the availability and performance of the services that are being provided. It is not enough to know that the database is up, or the application server is running. Capturing detailed information through monitoring of the components and the service in general is how IT organizations are able to ensure that service level objectives applied to the service and the underlying workflows are met or exceeded at all times.

These critical services are often n-tier applications that include components such as JBoss Application Servers and Oracle Databases. When monitoring an n-tier application, it is not enough to monitor each workflow in a silo. Monitoring Oracle, JBoss, the network, the operating systems, and even the base hardware in isolation can lead to problems being missed until a minor symptom grows into a full scale epidemic. Getting the depth of information necessary to certify service levels requires a view of the entire service to ensure harmonious interaction, and to pinpoint where action must be taken to maintain system performance and avoid downtime.

For example, a minor increase in database query times may be within acceptable thresholds for a generic database, yet it may damage workflow equilibrium if JBoss starts queuing up requests and the queue eventually caps out, leading to timeouts and dropped requests.

BridgeWays are committed to constantly building new management packs based on customer and community demand, this is helping to expand the reach of System Center Operations Manager; giving more and more people the direct benefits that come from using Operations Manager for their entire environment. To see the complete list of currently available MPs, go to the Product Overview

Their Product Overview Page where you can also request trials in order to see if their MPs can help you. Or if you are going to TechEd Berlin why not schedule a Personal Demo

Blog: TechEd Berlin: Using Microsoft System Center to Manage Beyond the Trusted Domain

Wed, 04 Nov 2009 21:22:03 GMT

Rory McCaw and myself will be in Berlin at TechEd next week and hope to see you there!

We will be co-presenting in a level 300 breakout session on Monday, November 9th titled "Using System Center to Manage Beyond the Trusted Domain". We'll be discussing how to leverage PKI in Windows 2008 R2 to extend the reach of System Center to systems outside the Active Directory trust boundary. I've included a preview agenda below. We hope to see you there!

Preview Agenda

Windows 2008 PKI Drill Down
Using PKI to Extend the Reach of System Center
Changes in Provisioning Certificates in Windows 2008
Bulk Certificate Provisioning for System Center
Managing Internet-Based Clients with ConfigMgr 2007
Troubleshooting Certificate Issues
Monitoring CA and Certificate Validity

Blog: Jalasoft Xian Wings 2010 Pending Announcement

Wed, 04 Nov 2009 21:17:10 GMT

Jalasoft sent us a note a couple days ago on a new product announcement coming Friday. Wonder if this is a competitive offering to Derdack?

“Jalasoft informed today to a close network of contacts that they are going to announce the release of Xian Wings 2010. Wings 2010 will be part of the Xian suite and will make it possible for network and server administrators to gain better control of their environments thanks to a special client application that works on their mobile device”

Blog: Part 2: Creating DCM packs with SCCM 2007

Wed, 04 Nov 2009 17:09:20 GMT

After Part 1 really just an intro in DCM we look at creating a new DCM Pack with Scripts, this is a long document and there are a few steps. So navigate to Desired Configuration Management (DCM) with in the SCCM Console.

Right click on Configuration Items, click new and in this case I have selected Operating System Configuration Item, if you want to chose another you can.

With the wizard open enter a name and description.

I want you to pay attention to this screen, this is a place where things can go wrong. I will go into detail in Part 3 which will follow soon why we leave this as is seen. I will detail how we edit this in XML so we can remove some of the fields making it a better to detect different versions.

The Objects section is not required for script but we will address it function in Part 4

In the setting section is where we are going to make it all happen with our script so click on “New”

When you click on New select “Script”

This will open this window, note it asks which script language. Our script today is VBScript so I have it selected on VBScript

Enter a name, description and your script, just cut a paste. Make sure your script has been tested as a VBScript before using it.

Here is another very important part, do we know what we are looking for as a response, well Read Only SNMP Community String have a DWORD setting of 4 in the registry.

So we are looking for the value of 4, if we where to change this to ‘Does not Match’ 4 then we could set the severity to Warning

Click OK, the Validation will look like this.

Click OK,

And again

Last time

And now are on the on the way to create the DCM but still have some more steps

Rick click on the newly create Item and select ‘Create child configuration Item’

This trys to add the date and time remove those

So it looks like this

Now you have 2 Items, the child needs no extra work and will always be a replica of the Parent and is used for the deployment of the XML

Now lets go to the Configuration Baseline and right click ‘New Configuration Baseline’

In the wizard give it a name (this is going to be the name of the DCM Pack)

Click next

And again

Click next

So you get a Configuration Baseline

Then right click on it select ‘Add’ the ‘Operation System Configuration Item’

You will get loads of item show up here is you have already imported DCM so you can use the ‘Look for’ as I have to narrow down the search, click on the two items (child as well)

So than when you look in the Rules it shows you the added rules

Click OK. Less the OS version we are ready to go.

I will follow up with the Part two this week which is also a heavy going document.

Blog: Powershell: OpsMgr Alert-to-Speech (cool idea from Gary Broadwater at Quest)

Wed, 04 Nov 2009 09:48:32 GMT

A customer request had me looking around the support community of one of our community sponsors - Quest. (The site is management-extensions.org). While I was there, I ran across something that raises some interesting possibilities for audible alarms using the OpsMgr Command Notification Channel. This would be especially with remoting in Powershell 2.0 so we could execute the audible alarm on a system that is NOT the RMS.

Gary Broadwater (eXc-turned-Quest architect) posted the most simple Powershell snippet HERE.

If you save this as a text_to_speech.ps1 file and pass a text string to it, your computer will recite the words. Text-to-speech in 3 lines. They don't call it Powershell for nothing.

################################
# Company: Quest Software
# Author: Gary Broadwater
################################

$q = new-object -com SAPI.SpVoice
$q.speak($args)
$q = $null

Sample Run

I ran exactly this on my computer, and I could make the words out very clearly!

.\text_to_speech.ps1 Quest extends system center to the non-windows world!

Calling the script remotely from the RMS

Then, from your OpsMgr RMS, you could use the notification command channel to call the remote script. I have Powershell 2.0 running on an OpsMgr lab server, so I would expect this should be okay, but you'd want to test carefully I think. I don't think I'd do this without Powershell 2.0, because you need it for remoting to avoid running this on the RMS. Here's PoSh 2.0 syntax to do it.

invoke-command -computername RemoteAlertComputer -filepath c:\Scripts\text_to_speech.ps1

NOTE: You could work out how to pass the OpsMgr alert description with the standard XPath as a script argument, but I think this would work best with a short message hard-coded in the script.

And a Personal Comment on Quest

I have talked with the technical folks at Quest about what they're doing with PRO and virtualization, application virtualization, extending Configuration Manager to support non-Windows systems, and they are working on some pretty cool answers for difficult technology and business problems. I have to say I am genuinely excited to see what develops. And I want to add this personal note about the tech support I've received from these guys. In short, the best of any ISV I have worked with. Gary, Tony and gang have delivered for me whenever I needed an assist.

Take a look at the ways Quest extends System Center at http://www.quest.com/system-center/

Visit the Quest Heterogeniuses Blog

Blog: Error code 80070102 deploying SCOM agent

Wed, 04 Nov 2009 07:48:59 GMT

Ran into an issue today trying to both push deploy an agent and manually install an agent on a Windows Server 2008 server. The resultant error code was 80070102 when the push installation failed.

Looking at the agentinstall.log for the server in c:\Program Files\System Center Operations Manager 2007\AgentManagement\AgentLogs, this had to do with the Windows Firewall on a Windows Server 2008 server.

The solution was to disable the Windows Firewall General, Public, and Private settings and stop the Windows Firewall service and then attempt a push deployment again. This time it worked flawlessly.

Technorati Tags: SCOM,Error Code 80070102,SCOM Agent deployment failure,Infront Consulting Group,Rory McCaw,OpsMgr 2007,Training

For great technical information on System Center, check our Infront Consulting Group’s training classes at www.infrontconsulting.com/training.php.

Blog: The Springboard Series Community Partei @ Microsoft TechEd Berlin

Wed, 04 Nov 2009 03:53:39 GMT

Cool party announced for TechEd Europe on the TechNet Plus Blog.

If you plan to attend Microsoft TechEd in Berlin, join us for a special celebration!

Party Details and Registration URL

On Tuesday, 10 November, at 21:00, get ready to rub shoulders with some of the world’s most powerful IT Professionals and community influencers.
Exclusively for Springboard Series Technical Expert Panelists (STEP), Microsoft MVPs, TechNet Plus Subscribers, and Microsoft Certified Trainers (MCTs), the Springboard Series Community Partei held the week of TechEd Europe in Berlin, Germany, is your opportunity to network with industry peers and key Microsoft executives, learn about other communities and special offerings, and enjoy an evening full of music (DJ’d by our very own Joey Snow and David Lowe), food, drinks, and fun—all compliments of Microsoft.
Party attendance is limited, so be sure to register today to reserve your spot at TechEd Europe’s only community party!

Brought to you by Springboard Series, TechNet+ Subscriptions and Microsoft Server

Registration Site: https://microsoft.crgevents.com/CommunityPartei/

Registration Code: TE-TN

Blog: Extending System Center Configuration Manager 2007 (SCCM) to Unix, Linux and Mac systems - Overview

Wed, 04 Nov 2009 02:57:41 GMT

Presenter: Richard Haddock, Senior Product Manager | Quest Software

IT Administrator's are challenged with complex heterogeneous systems to manage. For many, System Center Configuration Manager (SCCM) 2007 is their tool of choice to manage their Windows environment. This blog series will discuss a solution called Quest Management Xtensions (QMX) for Configuration Manager 2007 that natively extends SCCM to Unix, Linux and Mac systems. This first video is an overview of what this solution can do for IT administrators. Future blog entries will drill down into other topics including architecture, platform support and feature demos.

View the Video

This Flash video is best viewed with IE7+
Best viewed in maximized screen
Expect to see an ActiveX Control prompt for this SWF file
The file will take a moment to buffer

SCCM end users - check out SystemCenterCentral.com

Quest Software is a proud, gold sponsor

Heterogeniuses Blog

Blog: How to create a Two-State PowerShell Script Monitor using the Authoring Console (Part 3)

Tue, 03 Nov 2009 21:17:19 GMT

This is a step-by-step guide in multiple parts:

Part 1 will cover the Probe Actions Module Types: Part 1 is available on SCC or on code4ward
Part 2 will be about creating a Data Source: Part 2 is available on SCC or on code4ward
Part 3 will cover creating a Monitor Type
Part 4 will cover the Unit Monitor itself

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 !

Part 3: Monitor Type

What’s a Monitor Type?

A monitor type actually defines the workflows for a monitor. So, before you can create a monitor you need to hook up different modules and specify how these play together and what the monitor should do. The first two parts showed how to create these modules and data sources and now all those modules are coming together…

Creating the Monitor Type

	Let’s navigate to the Monitor Types section in the Type Library space. Right-click on the Module Types panel and select New –> Composite Monitor Type. Type in an ID like: code4ward.Sample.PowerShellMonitor.MonitorType.CheckFileContent Also provide a Name like: Check File Content Monitor Type
	Click on the States tab and provide some meaningful IDs for the two states our monitor can have. In our case: ID of state 1 will be Healthy and ID of state 2 will be Unhealthy A three state monitor is not much different than a two state monitor. If you go through this guide you should also be able to create a three state monitor.
	The Member Modules tab is a bit different in this case. What here happens, is basically just the definition of modules and their configuration. There’s no order of execution of these modules. So here we define all our modules we need for our workflow and we start with our Data Source we created in Part 2. Click on the Add… button and look for the Data Source code4ward.Sample.PowerShellMonitor.DataSource.CheckFileContent As ID we specify DS (again, as mentioned in the previous parts, this ID must only be unique for the modules we need here, it doesn’t need to be unique through the whole MP!)
	After you hit OK, the configuration window of our module will show up. All the parameters for our data source will be set to $Config/…$ (see screenshot). You can use the fly-out button and select the Promote menu item to automatically fill in the $Config/…$ values. Just to repeat this one, here we define that our consumer (in this particular case the unit monitor) will provide these values. Every value you will set here “hardcoded” will not be configurable in the unit monitor. Also, remember, that if you have defined optional (non-required) parameters in the data source, you may need to add them manually by clicking on Edit… and use a XML editor (such as Notepad.exe or Visual Studio) to put in your parameter. A side note: when you use Visual Studio, an XML schema will be generated and used automatically which speeds up XML editing! In our case, no optional parameters are defined or needed, so nothing special to do here.
	Next we need two modules to evaluate our health state. Remember, our script returns a property bag, so we need to look for a value in our property bag (in our case “Status”) to determine if the health state is “Healthy” or “Unhealthy” (as we defined those IDs for our health states). So click on Add… again and look for the System.ExpressionFilter module and give that one the ID HealthyExpression. When the Configuration window appears, do not bother to insert data into the generic XML mask, click on Configure… to open up the expression builder UI.
	There we specify our expression for the Healthy state: Property[@Name=’Status’] Equals OK Click on OK and let’s do the same for the Unhealthy expression
	Same procedure as 2 steps above. We just specify another ID: UnhealthyExpression
	Type in the following in the expression builder: Property[@Name=’Status’] Equals ERROR
	At this point we would have already enough to create a two state monitor. Our data source which basically executes our script probe on a schedule and two expressions, one for each state. We will add two more modules. We need them to configure “On Demand” detection (= Recalculate Health button in Health Explorer).
	To enable on demand detection, we need our script probe we created in Part 1 of this guide and a PassThrough module (which is simple and doesn’t need any configuration). Click on Add… again and look for our Probe Action from Part 1 (NOT the one we created for our Tasks!) The ID will be something like “Script”.
	In the Configuration window we will again Promote the parameters with the fly-out button, except the ExecutedAsTask parameter can be set to false, because the situation where we use this module will never see that parameter set to true. One question will arise here: We already configured the parameters $Config/File$, $Config/ErrorText$ and $Config/Debug$, what will happen now? The answer is fairly simple: In this case both modules will use the same parameter. When we configure the unit monitor we provide the parameter for $Config/File$ once and will be used in both modules. Our On-Demand detection will now execute our Probe Action module and use the same parameter as the Data Source we defined in this workflow. So when we set the Debug parameter to true on the monitor level, we will get debug information every time the monitor is executed and every time we do a Recalculate Health. Let’s say we always want to avoid debug information when we click on Recalculate Health, we just need to “hardwire” this parameter to false in this Configuration window and it will always be false in this workflow.
	The last module we need, is a PassThrough module. This module doesn’t need to be configured at all and is just needed to kick-off the workflow in the On Demand module. Do not ask me what it does exactly, I just know it is needed. Now let the fun part begin and change to the Regular tab to setup the workflow.
	In this tab we define for each health state (in our case two states) the workflow. So select the Healthy state in the list and check all modules we need in this workflow to evaluate a healthy state: We need our Data Source, we called it DS and our HealthyExpression. When those two modules are enabled, we need to define the execution order of these modules using the drop down lists in the Next Module column. The start of our workflow is the Data Source (DS), so here the Next Module must be set to HealthyExpression. The HealthyExpression is the last module in this workflow, so the Next Module must be set to Monitor State Output.
	Let’s move on to the Unhealthy state. Check all modules we need in this workflow to evaluate a unhealthy state: We need our Data Source again and this time the UnhealthyExpression Again, when those two modules are checked and enabled, setup the execution order: The start of our workflow is again the Data Source (DS). The Next Module must be set to UnhealthyExpression. The UnhealthyExpression is the last module in this workflow, so the Next Module must be set to Monitor State Output. That’s it for our two state monitor. Now we will setup the On Demand detection.
	First we need to check the Use On Demand Detection check box. On top of this dialog you have again both available health states. We need to setup a workflow for each health state. Select the first state (Healthy) in the list if not already selected and enable the modules needed for this workflow. In this case we need the PassThrough module, the Script (our Probe Action) and again the HealthyExpression. For the On Demand detection the first module is always the PassThrough module, so we select the Script module as Next Module for the PassThrough module. The Script module will return our property bag which needs to be passed on to the HealthyExpression module. The HealthyExpression module is our last in this workflow, so we set Monitor State Output as Next Module.
	Select the Unhealthy state in the list and let’s do the same workflow but in the end we will use the UnhealthyExpression module instead of the HealthyExpression. After that we finished all our workflows. Each workflow (healthy and unhealthy) will always be executed independently each time the monitor will run. So if you use other criteria in your expression (some performance value instead of a status text, or some and/or logic), be sure that each expression will uniquely identify each health state.
	As in our previous modules we need to be sure that the configuration schema is correct. The authoring console doesn’t always pre-set the right data type for each configuration value. So double check that Interval is an Integer and Debug is a Boolean.
	Now to the Overridable Parameters tab. Use the Add… button on the bottom to allow overrides on individual parameters. You may notice that I do not want to provide a way to override the File to monitor. This of course is up to you what you allow to be overridden and what not. I think it’s always a good idea to allow an override on Debug and Interval, this way you can look into issues on a specific server or change some configuration for a group of computers or so. As mentioned in the previous parts, you can mark this Monitor Type as Public, so that other MPs can reference your MP and use your Monitor Type (if sealed, of course). Click on OK and you are done!

That’s it for part 3. The next step will be creating the unit monitor and a task.

cheers,
Stefan Koell
http://www.code4ward.net

Blog: OpsMgr: T-SQL Query to retrieve Top Alerts by Alert Count

Tue, 03 Nov 2009 07:11:26 GMT

Here's a T-SQL query to retrieve the top alerts by alert count from the OperationsManager database. It should be cut-and-paste for any environment and should work with SCE 2007 as well.

SELECT TOP 10 SUM(1) AS AlertCt, AlertStringName, AlertStringDescription, MonitoringRuleId, Name 
FROM Alertview WITH (NOLOCK) 
WHERE TimeRaised is not NULL 
GROUP BY AlertStringName, AlertStringDescription, MonitoringRuleId, Name 
ORDER BY AlertCt DESC

Blog: OpsMgr R2 by Example: the SharePoint MP

Mon, 02 Nov 2009 21:31:44 GMT

The Office SharePoint Server 2007 management pack and SharePoint Portal Server 2003 management pack are separate management packs. This discussion focuses on the Office SharePoint Server 2007 management pack, as this is the more current version of the two.

How to Install the SharePoint MP

If your environment is running SharePoint 2007, download the Office SharePoint Server 2007 Management Pack from the Management Pack Catalog. The Office SharePoint Server 2007 Management Pack Guide is included in the download and labeled “Microsoft_Office_SharePoint_Server_Management_Pack_Guide.doc.”
Read the Management Pack guide, which includes tips such as resizing the Windows System and Application logs to at least 10240 in size.
Import the Office SharePoint Server 2007 management pack (using either the Operations console or PowerShell).
Create a SharePoint_Overrides management pack to contain any overrides required for the MP.

The Office SharePoint 2007 management pack does not support agentless monitoring.

SharePoint MP Tuning / Alerts to look for

The following alerts were encountered and resolved when tuning the various SharePoint management packs (listed in alphabetical order by Alert name). Alerts from the SharePoint Portal Server 2003 management pack are also provided as additional information in the event similar issues are found in the SharePoint 2007 version of the management pack.

Alert: Can not load virus scanner

Issue: SharePoint 2003 alert. This looks for event number 1000 from the source of Windows SharePoint Services 2.0 containing the description.

Resolution: There is no virus scanner on this system specifically for SharePoint, so this rule was disabled for this system.

Alert: Failed to load index

Issue: This appears to be a side effect of an underlying corruption that occurred on an index. See http://objectmix.com/sharepoint/298641-sharepoint-search-index-corrupt.html.

Resolution: This environment had three SharePoint servers; two of them were for SharePoint content and the third server to provide indexing. In SharePoint Central administration it was determined there was no indexing server. Configured the third server to perform indexing and these issues no longer occurred.

Alert: Failure in loading assembly

Issue: Per the management pack guide: Discovery for the SharePoint Portal Server Management Pack relies on the file wssDiscovery.exe. This file is run automatically when you import the Management Pack. You must configure the Agent Action Account so that is has administrative access to the SharePoint Portal Server API and administrator rights to the SQL Server databases.

Resolution: For this to work correctly, you must enable Proxy. Be sure to enable Proxy for each of the SharePoint (including SharePoint 2003) servers.

Alert: IIS Stop Command

Issue: IIS was stopped on the server while a portal protection program was installed on the system. This action was performed by a system administrator. This is an alert rule so it will not close automatically.

Resolution: Created a web monitor for the SharePoint website. Changed the severity of this item from 2 to 1 (critical to warning) as this is by itself not a critical situation. If the website was down as a result, that would be a critical situation but these are checked separately with web monitors.

Alert: Index is corrupt

Issue: Index corruption identified on multiple SharePoint servers.

Resolution: This environment had three SharePoint servers; two of them were for SharePoint content and the third server to provide indexing. In SharePoint Central administration, it was determined there was no indexing server. Configured the third server to perform indexing and these issues no longer occurred.

Alert: Query server removed from rotation

Issue: This appears to be a side effect of an underlying corruption that occurred on an index. See http://objectmix.com/sharepoint/298641-sharepoint-search-index-corrupt.html.

Resolution: This environment had three SharePoint servers; two of them were for SharePoint content and the third server to provide indexing. In SharePoint Central administration, it was determined there was no indexing server. Configured the third server to perform indexing and these issues no longer occurred.

Alert: Sweep Synch failed

Issue: Errors reported on various SharePoint servers in the server farm. This appears to be a side effect of an underlying corruption that occurred on an index. http://objectmix.com/sharepoint/298641-sharepoint-search-index-corrupt.html

Resolution: This environment had three SharePoint servers, two of them were for SharePoint content and the third server to provide indexing. In SharePoint Central administration, it was determined there was no indexing server. Configured the third server to perform indexing and these issues no longer occurred.

Alert: The Microsoft Single Sign-on Service State

Issue: This service is not running on the SharePoint 2007 servers in the environment. This service is used to store login credentials for 3rd party applications so you can create links from SharePoint to those apps and auto login users if they aren’t using Windows Authentication. That is the only reason you would need to have it running.

Resolution: This functionality was not in use in the environment, so created an override to disable the alert, and stored it in a Sharepoint_Overrides management pack.

Alert: The Office SharePoint Server Search Service State

Issue: Office SharePoint Server Search is not running. This appears to be a side effect of an underlying corruption that occurred on an index. See http://objectmix.com/sharepoint/298641-sharepoint-search-index-corrupt.html.

Resolution: This environment had three SharePoint servers; two of them were for SharePoint content and the third server to provide indexing. In SharePoint Central administration, it was determined there was no indexing server. Configured the third server to perform indexing and these issues no longer occurred.

Alert: Unable to discovery sharepoint components

Issue: Per the management pack guide: Discovery for the SharePoint Portal Server Management Pack relies on the file wss Discovery.exe. This file is run automatically when you import the management pack. You must configure the Agent Action Account so that is has administrative access to the SharePoint Portal Server API and administrator rights to the SQL Server databases.

Resolution: For discovery to work correctly, you must enable Proxy. Be sure to enable Proxy for each of the SharePoint (including SharePoint 2003) servers.

Blog: ReSearch This! KB - Alert Parameter Replacement Failure

Mon, 02 Nov 2009 20:44:56 GMT

Alert: Alert Parameter Replacement Failure

Alert: DHCP Service Running Alert

Issue: These alerts occurs when the DHCP service is stopped on a DHCP server. This occurs at the same time as the critical DHCP Service Running Alert occurs. The DHCP Service Running Alert closes itself automatically, but the Alert Parameter Replacement Failure does not.

Resolution: Restarted the DHCP server service on the system which identified the error. Manually closed the Alert Parameter Replacement Failure alert. This alert appears to be able to be disabled as the DHCP Service Running Alert provides more relevant information than the warning.

Submitted By: Alexandre Verkinderen (MVP) and Cameron Fuller (MVP)