How often do you get the question: “What Monitors, Rules and Discoveries are running on an OpsMgr Agent?” from your co-workers? Especially when they don’t have a clue what is being monitored for their servers.
Most of the time you just use the EffectiveConfigurationViewer from the OpsMgr Resource Kit. It let’s you pick different objects, besides the Agents you are monitoring with OpsMgr.
It’s shows quite some interesting information and let’s you export the result to an XML file. But that’s not always your co-workers want’s to see. IMO they often want to have an Excel sheet with all the Monitors and Rules running on a specific Agent. That’s what they understand and can easily read.
What options do you have now?
Let’s look at the options.
Build some wrapper around the exported XML file
This is possible, but would not give us all the information we would like to see. It can only give us the Monitor/Rule or Discovery Name and it’s state. We are interested in much more, like: Name, Description, Type, Management Pack, Overrides, etc.
So let’s skip this option.
Use a third-party tool
In the next version of MP Studio a new feature called Silect’s Agent Explorer will be added. I’m lucky to be able to test the latest evaluation version of MP Studio and it will be able to give you almost all the information you probably need.
If you want to see what Monitors, Rules and Discoveries are running on an Agent, you can use the Explore workflow tasks feature (Agent Explorer) to view all workflows running on all agents or a specific server.
It will give you an overview of all Workflows running on a specified Agent and you can export the result to Excel.
This is almost what I want to see. The only thing I’m missing in the current Agent Explorer feature is if there are overrides configured for a Monitor, Rule or Discovery. I talked with Randy Roffey from Silect about this, and he told me that would be challenge, because there can be be multiple override settings for the same workflow. Good point, but it would be nice to see if there are any overrides for a workflow, than you can always manually check the configured overrides later.
PowerShell script that does the magic
The last option we have is to create a PowerShell script that does all we want. And what do we want? We want an Excel sheet with all Monitors, Rules and Discoveries running on an Agent, with their Type, DisplayName, Description, possible Override and ManagementPack.
Here you can see again 768 workflows running on the OpsMgr Agent (just like in MP Studio) but it also shows if there is an Override* being configured for the Monitor, Rule or Discovery. This still does not mean that the override is applicable for the Agent though.
* Retrieving the Override information can be a time (CPU and Memory) consuming exercise, so I commented that part of the PowerShell script.
Drawback I found using this script is the impact on the CPU and Memory when running this script and the time it takes before this script finishes. So you may take that into consideration when you run this script. First it retrieves all the Monitors, Rules and Discoveries and saves that in Memory and loops through this data in memory for finding the workflow information.
When I tested this script in my small OpsMgr 2007 R2 environment it took 1:47 seconds to run.
But it can also take much longer , like 27 minutes in another larger OpsMgr 2007 R2 environment.
If you are still interested to give the script a try, here it is:
############################################################################### # Get OpsMgr 2007 Running Workflows using PowerShell # This script retrieves the workflows running on an OpsMgr Agent # Authors: Jeremy Pavleck & Stefan Stranger (Microsoft) # Example usage (run from OpsMgr Command Shell): Get-OpsMgrWorkflows_v1.ps1 -agentname "myagent.contoso.com" | export-csv -path c:\temp\workflows.csv # Date: 30-11-2010 # Name: Get-AgentWorkflows_v1.ps1 # Remarks: Warning: Script is CPU and Memory intensive!! # Retrieving the overrides for the Monitors, Rules and Discoveries turned out to be a time, CPU and Memory consuming exercise and I disabled it. # You can enable it by Uncommenting that part of the script if you want to. # Script needs to run in PowerShell version 2. # v1.000 - 30/11/2010 - stefstr - initial sstranger's release ############################################################################### param ([string]$agentname = $(read-host "Please enter OpsMgr Agent Name")) function Get-AgentWorkflow($agentname) { #Original Script from Jeremy Pavleck. #http://www.pavleck.net/2008/06/sp1-gem-finding-rules-running-on-remote-agents/ #Use the OpsMgr Task Show Running Rules and Monitors. $taskobj = Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.GetAllRunningWorkflows"} # Grab HealthService class object $hsobj = Get-MonitoringClass -name "Microsoft.SystemCenter.HealthService" # Find HealthService object defined for named server $monobj = Get-MonitoringObject -MonitoringClass $hsobj | Where-Object {$_.DisplayName -match $agentname} #Start Task GetAllRunningWorkflows $taskOut = Start-Task -Task $taskobj -TargetMonitoringObject $monobj [xml]$taskXML = $taskOut.OutPut #Get Workflows $workflows=$taskXML.selectnodes("/DataItem/Details/Instance/Workflow") #Retrieve Monitors $monitors = get-monitor #Retrieve Rules $rules = get-rule #Retrieve Discoveries" #Used the Group-object because there are some discovery rules with the same DisplayName $discoveries = get-discovery | select-object -Unique #Get Overrides" #monitoroverrides = foreach ($monitor in Get-ManagementPack | get-override | where {$_.monitor}) {get-monitor | where {$_.Id -eq $monitor.monitor.id}} #$rulesoverrides = foreach ($rule in Get-ManagementPack | get-override | where {$_.rule}) {get-rule | where {$_.Id -eq $rule.rule.id}} #$discoveryoverrides = foreach ($discovery in Get-ManagementPack | get-override | where {$_.discovery}) {get-discovery | where {$_.Id -eq $discovery.discovery.id}} #Check for each workflow if it's a Rule or Monitor or Discovery. foreach ($workflow in $workflows) { #Check for Monitor $monitor = $monitors | where-object {$_.Name -eq $workflow."#text"} if ($monitor -eq $null) { #Check for Rule $rule = $rules | where-object {$_.Name -eq $workflow."#text"} if ($rule -eq $null) { #Check for Discovery $discovery = $discoveries | where-object {$_.Name -eq $workflow."#text"} if ($discovery -eq $null) { } else { #Get ManagementPack $mp = $discovery.getmanagementpack() #Check if Discovery has an override #$flag = $discoveryoverrides | Where-Object {$_.DisplayName -eq $discovery.DisplayName} #if ($flag -eq $null) #{ # $override = "false" #} #else #{ # $override = "true" #} $discobject = new-object System.Management.Automation.PSObject $discobject = $discobject | add-member -membertype NoteProperty -name Type -value "Discovery" -passthru $discobject = $discobject | add-member -membertype NoteProperty -name DisplayName -value $discovery.DisplayName -passthru $discobject = $discobject | add-member -membertype NoteProperty -name Description -value $discovery.Description -passthru #$discobject = $discobject | add-member -membertype NoteProperty -name Override -value $override -passthru $discobject = $discobject | add-member -membertype NoteProperty -name ManagementPack -value $mp.DisplayName -passthru $discobject } } else { $mp = $rule.getmanagementpack() #Check if Rule has an override #$flag = $ruleoverrides | Where-Object {$_.DisplayName -eq $rule.DisplayName} #if ($flag -eq $null) #{ # $override = "false" #} #else #{ # $override = "true" #} $ruleobject = new-object System.Management.Automation.PSObject $ruleobject = $ruleobject | add-member -membertype NoteProperty -name Type -value "Rule" -passthru $ruleobject = $ruleobject | add-member -membertype NoteProperty -name DisplayName -value $rule.DisplayName -passthru $ruleobject = $ruleobject | add-member -membertype NoteProperty -name Description -value $rule.Description -passthru #$ruleobject = $ruleobject | add-member -membertype NoteProperty -name Override -value $override -passthru $ruleobject = $ruleobject | add-member -membertype NoteProperty -name ManagementPack -value $mp.DisplayName -passthru $ruleobject } } else { #Get ManagementPack for Monitor $mp = $monitor.getmanagementpack() #Check if Monitor has an override #$flag = $monitoroverrides | Where-Object {$_.DisplayName -eq $monitor.DisplayName} #if ($flag -eq $null) #{ # $override = "false" #} #else #{ # $override = "true" #} $monitorobject = new-object System.Management.Automation.PSObject $monitorobject = $monitorobject | add-member -membertype NoteProperty -name Type -value "Monitor" -passthru $monitorobject = $monitorobject | add-member -membertype NoteProperty -name DisplayName -value $monitor.DisplayName -passthru $monitorobject = $monitorobject | add-member -membertype NoteProperty -name Description -value $monitor.Description -passthru #$monitorobject = $monitorobject | add-member -membertype NoteProperty -name Override -value $override -passthru $monitorobject = $monitorobject | add-member -membertype NoteProperty -name ManagementPack -value $mp.DisplayName -passthru $monitorobject } } } Get-AgentWorkflow $agentname
Disclaimer
This sample is not supported under any Microsoft standard support program or service. This sample is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of this sample and documentation
remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of this sample be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use this sample or documentation, even if Microsoft has been advised of the possibility of such damages.
This week I’m busy preparing a PowerShell v2 Essentials workshop I’ll be delivering next week. One of the Modules of this PowerShell v2 Essentials Workshop is PowerShell Remoting. If you don’t go to my workshop or don’t know what PowerShell remoting is, I suggest reading the Administrator's Guide to Windows PowerShell Remoting.
In this blog article I’ll show you how you can use PowerShell Remoting on your workgroup machine to connect to the OpsMgr Root Management Server to execute OpsMgr Cmdlets remotely. I want to thank Theo Kostelijk (a colleague of mine) for providing me with some examples he used in Opalis.
Overview of my OpsMgr environment:
On my Windows 7 workstation I configured the next Trustedhosts setting (read Administrator Guide to Windows PowerShell Remoting for info on Trustedhosts)
So what do we need to do, to get an overview of all alerts in the OpsMgr Management Group using PowerShell Remoting?
Steps:
$RMSSession = get-pssession
#Load OpsMgr Snapin Invoke-Command -Session $RMSSession -ArgumentList $rmsName -ScriptBlock {param ($rmsName) $rms=$rmsName} Invoke-Command -Session $RMSsession -ScriptBlock {add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"} Invoke-Command -Session $RMSsession -ScriptBlock {Set-Location "OperationsManagerMonitoring::"} Invoke-Command -Session $RMSSession -ScriptBlock {New-ManagementGroupConnection -connectionString:$rms} Invoke-Command -Session $RMSsession -ScriptBlock {Set-Location $rmsName}
Here is an overview of the complete PowerShell script I used to retrieve the Alerts Remotely.
#Using OpsMgr Cmdlets using PowerShell Remoting
#Variables $rmsName = "opsmgrrms.contoso.com"
#Create a connection with the Remote Server (RMS) $RMSSession = New-PSSession -ComputerName $rmsName -Credential (Get-Credential)
$alerts = Invoke-Command -Session $RMSSession -ScriptBlock{get-alert} Write-Host "Return Alerts" $alerts.count
#Close Remote PowerShell Session with RMS Remove-PSSession -Session $RMSSession
Have fun with PowerShell Remoting and OpsMgr!
Update! Thanks to Rikard Ronnkvist I found a new way for connecting to the Root Management Server using PowerShell Remoting. Thanks Rikard!
#Using OpsMgr Cmdlets using PowerShell Remoting#Info from Rikard Ronnkvist#http://www.snowland.se/2010/08/23/maintenance-mode-via-powerhsell-remoting/
function OpsMgrRemoteConnection { param ([string] $rmsHostname)
Invoke-Command -ComputerName $rmsHostname -credential (Get-Credential) -scriptblock {
Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" Set-Location "OperationsManagerMonitoring::" New-ManagementGroupConnection -ConnectionString:localhost #Enter OpsMgr Cmdlet you want to use $OpsMgrcommands = Get-OperationsManagerCommand $OpsMgrCommands | select Name, CommandType } #End scriptblock} #End Function
OpsMgrRemoteConnection -rmsHostname "opsmgrrms.contoso.com"
Source: TechEd
I had not time to go to Microsoft TechEd 2010 in Berlin this year, but hopefully I’ll be able to go to MMS 2011, if no vulcanoes stop me from going
If you also did not go to TechEd Berlin this year, and are interested in the Next Generation of System Center Operations Manager you should take a look at this video by Justin Incarnato and Vlad Joanovic.
Source: http://beta.microsoftatlanta.com
What is Microsoft Codename Atlanta?
Microsoft Codename Atlanta (http://beta.microsoftatlanta.com) is an online service that analyzes installations of Microsoft SQL Server 2008 (and later versions) and provides proactive alerts to help you avoid system downtime and follow best practices with regard to configuration and usage. Atlanta is developed by the Microsoft Atlanta product group in partnership with Microsoft Support engineers to ensure that the issues customers report to Microsoft are detected before they affect your environment. Atlanta is regularly updated to reflect the most recent experiences of these engineers, who support SQL Server customers around the world.
The Atlanta environment
The Atlanta environment is made up of the Atlanta web service, hosted in the cloud, and the on-premise software, installed in your local environment. The on-premise software consists of one gateway and at least one agent. The agent collects data from your server and analyzes it using a set of rules (similar to a management pack in System Center Operations Manager) known collectively as Atlanta knowledge. The analyzed data is regularly sent from the agent to the gateway for upload to the Atlanta web service. If the data indicates an issue or a deviation from best practices, an alert is generated. By connecting a web browser to the Atlanta portal, you can view the alerts and the associated remediation guidance.
Agent
The Atlanta agent is a software component that you install on each server being monitored by Atlanta and relies on Atlanta Management Packs (MPs). These MPs define the types of data the agent monitors and collects. The monitored data is collected periodically (daily by default) and sent to the gateway for subsequent transport to the cloud. The agent obtains its desired set of MPs from the gateway.
Gateway
The gateway is another software component that you install and acts as a proxy between the agents and Atlanta and is responsible for communication with the Atlanta service from your monitored servers. It aggregates data collected from one or more agents, uploads the collected data packages to Atlanta, and downloads the desired configuration and required MPs from the cloud for each of its agents and makes it available for those agents to consume.
Screenshot of the MPs on the Gateway server
If you open the Atlanta SQL 2008 Discovery MP with the OpsMgr SQL 2008 Discovery MP you see that the are completely the same. (left Atlanta and right OpsMgr)
Co-existence with Operations Manager 2007 R2
Atlanta uses the System Center Health Service to collect and analyze data. The version that is used by Atlanta is the same as the System Center Operations Manager 2007 R2 agent. Because of this, when you view the programs installed on your server, you will see System Center Operations Manager 2007 R2 agent software, particularly in Add/Remove Programs. Do not remove these as Atlanta is dependent on them. If you remove the Operations Manager agent software, Atlanta will no longer function.
When you install an Atlanta agent on a computer that has a System Center Operations Manager 2007 R2 agent installed, the Health Service will be configured to run in multi-homing mode so that existing Operations Manager management groups are not impacted. For more information on multi-homing configurations, see Configure an Agent to Report to Multiple Management Groups, available in the System Ceenter Operations Manager 2007 R2 library, at http://go.microsoft.com/fwlink/?LinkID=204945.
When you uninstall Atlanta, be sure to use the Uninstall.exe program located in the directory where you installed Atlanta (and not Add/Remove Programs). The uninstall program will uninstall Atlanta and update the System Center Operations Manager agent to remove Atlanta-specific configurations while ensuring that the Operations Manager agent continues to work. On computers with only Atlanta installed (and no Operations Manager), the agent is completely uninstalled.
Atlanta is only supported with the System Center Operations Manager 2007 R2 agent and not with previous versions of System Center Operations Manager.
Screenshots of installation of Agent and Gateway on the same server.
First you need create an Account for Atlanta.
Follow the next steps to deploy the Atlanta Agent and Gateway
Run AtlantaSetup.exe
Choose installation option. (I choose to install the agent and gateway on the same server)
Browse to downloaded Registration certificate.
Open de Altanta Dashboard and check if your server is added.
Links:
Help on Atlanta: http://onlinehelp.microsoft.com/en-us/atlanta/default.aspx