• What Monitors, Rules and Discoveries are running on an OpsMgr Agent?

    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.

    image

    image

    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?

    1. You can try to build some wrapper around the exported XML file, with PowerShell.
      image
    2. Use a third-party tool, like MP Studio to export the Monitors, Rules and Discoveries (workflows) running on an Agents
    3. Create a PowerShell script that does the magic Winking smile

    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.

    image

     

    It will give you an overview of all Workflows running on a specified Agent and you can export the result to Excel.

    image

    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.

    image

    image

    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.

    image

    But it can also take much longer Sad smile, like 27 minutes in another larger OpsMgr 2007 R2 environment.

    image

     

    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.

  • Microsoft Codename Atlanta

    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.

    Atlanta

     

    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

    image

    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)

    image

    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.

    image

    Follow the next steps to deploy the Atlanta Agent and Gateway

    image

     

    Run AtlantaSetup.exe

    image

    Choose installation option. (I choose to install the agent and gateway on the same server)

    Browse to downloaded Registration certificate.

    image

    image

     

    Open de Altanta Dashboard and check if your server is added.

    image

    image

     

    Links:

    Help on Atlanta: http://onlinehelp.microsoft.com/en-us/atlanta/default.aspx

  • Using PowerShell Remoting to connect to OpsMgr Root Management Server and use the OpsMgr Cmdlets

    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:

    • Workstation with Windows 7 on Microsoft Corp domain
    • OpsMgr Root Management Server in demo domain

    On my Windows 7 workstation I configured the next Trustedhosts setting (read Administrator Guide to Windows PowerShell Remoting for info on Trustedhosts)

    image

    So what do we need to do, to get an overview of all alerts in the OpsMgr Management Group using PowerShell Remoting?

    Steps:

    1. First we need to create a new session with the Remote Server (RMS)
      $RMSSession = New-PSSession –ComputerName OpsMgrRMS.stranger.local -Credential (Get-Credential)
    Because the Root Management Server is in a different domain than my workstation I need to enter credentials.

    Result:
    image
    • Next we need to add the OpsMgr Snappin in the session we created in the first step.

      $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}


      Result:
      image

      We now have a connection with the RMS.
    • Now we can try to retrieve the Alerts using the Get-Alert OpsMgr Cmdlet
      $alerts = Invoke-Command -Session $RMSSession -ScriptBlock{get-alert}

      Result:
      image
    • When we are finished we can close the Remote Session.
      Remove-PSSession -Session $RMSSession

      Result:
      image

    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)

    #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}

    $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"

  • Video: Introducing the Next Generation of System Center Operations Manager

    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 Winking smile

    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.

    Get Microsoft Silverlight