Here are some useful scripts to check and update AD Integration settings using the Command Shell.

Check current Ldap query

get-managementserver | where {$_.name -eq "fqdn"} | foreach-object {$_.getAgentAssignments()} | select LdapQuery

Update LDAP Query

$LdapQuery = "ldap_query"

$ms = get-managementserver | where {$_.name -eq "fqdn"}

$currentassignment = $ms.GetAgentAssignments() | where {$_.domain -eq "dn"}

$ms.EditAgentAssignment($currentAssignment.Domain, $LdapQuery, $currentAssignment.ExcludeList)

Command Shell Main Menu

This will set a failover Management Server for a Gateway role, leaving the currently configured primary Management Server.

Beware of word wrap on the last two lines (should be one line).

$gw = get-GatewayManagementServer | where {$_.Name -eq "gw_fqdn"}
$pms = $gw | get-PrimaryManagementServer
$fms = get-ManagementServer | where {$_.Name -eq "failover_fqdn"}
set-ManagementServer -GatewayManagementServer: $gw -PrimaryManagementServer: $pms -FailoverServer: $fms

Verify primary and failover Management Servers with the following.

$gw | foreach-object {
$_.getPrimaryManagementServer() | select Name
$_.getFailoverManagementServers() | select Name}

command shell main menu

So, here’s a quick post on this error.  I did a quick web search for this, just to see if anyone posted the same, and didn’t get any hits (something I always do before posting).

Problem

This is very common during an upgrade from SP1 to R2.  In fact, I don’t remember ever upgrading and not seeing this error.

Take a look at the text in the error dialog.

Error 25351 .Failed to stop services. Error Code: –2147023835 (The service cannot accept control messages at this time.).

Kind of funky, right?  I don’t know who’s putting these strings together, but I would think we’d have better sentence structure than this. ;-)

Solution

Click Ok.  This is a known issue in the setup process, and can be ignored.

More Information

If you take a look at the Application event log, you’ll see the event details shown in the error dialog.

What was happening when this error occurred?  Take a look at the Operations Manager event log.

While creating some content late last year and playing around with the getClassPath script, I put together this chart of the Windows Server 200x Operating System class structure.  I stumbled across it while perusing my file system and, since I had put a fair amount of effort into it, I figured I would post it out here for everyone else to see.  I hope this will help in solidifying the concept of classes and hosting relationships.

Graphical display of each of the Windows Operating System classes.

* Microsoft.Windows.Server.2000.OperatingSystem
* Microsoft.Windows.Server.2003.OperatingSystem
* Microsoft.Windows.Server.2008.OperatingSystem

Agent Proxy needs to be enabled for several different management packs features to work properly.  Active Directory, Cluster and Exchange are few common management packs requiring Agent Proxy to be enabled, just to name a few.  Enabling the Agent Proxy security setting allows an agent to submit data on behalf of another source.  By default, this setting is not enabled for any agents.  So when we import a management pack which expects an agent to submit data not originating from that agent (other sources), we need to enable this security feature in order for some workflows to function.

There are several scripts available in various posts which help accomplish this task, as it can be quite tedious selecting individual agents and configuring this manually.  There are even a couple tools published that have helped many administrators accomplish this task, both GUI and command line.

Since it’s usually a particular type or role which an agent hosts that requires Agent Proxy to be enabled, I thought it would be nice if we could run a script that would enumerate all agents that host a particular type or role and enable Agent Proxy in one pass.

Test this script thoroughly in your lab environment before attempting to use in production to avoid mistakenly enabling or disabling agent proxy on unintended targets.  If you choose to run it against Windows Computer class, it will enable or disable it for all agents in the management group.

This script works its way up the parent class path, until it finds a Windows Computer object.  It then resolves the Agent Base Managed Entity Id and sets the Agent Proxy property.  If the class you choose does not resolve to a Windows Computer object, the script will fail. Keep in mind, this is a fairly raw script without error handling and many bells and whistles.

	Here are a few classes I tested the script against, enabling Agent Proxy on agents which commonly need it enabled.
	* Microsoft.Windows.Server.DC.Computer – all domain controllers
	* Microsoft.Windows.Cluster.Node – all cluster nodes
	* Microsoft.Exchange.ServerRole.2003 – all exchange 2003 server roles
	* Microsoft.Exchange2007.ServerRole – all exchange 2007 server roles
	If you want to return a list of all classes, run the following command:
	Get-MonitoringClass | Select DisplayName,Same | Sort DisplayName

Usage: Copy the entire script below, everything between ##--Begin and ##--End, and paste into a text file in some location.  Name the file ClassProxyEnabler.ps1. Open Operations Manager Command Shell and type in the path to the script and the required parameters, and hit enter. Parameters Class Name: This is the class system name, not the friendly name. $True/$False: $true to enable, $false to disable Output directory: The script logs all actions to this directory, with file name “class_date_time.txt”.  This directory must exist.  If there are spaces in the path, the path must be enclosed in quotes. Example: c:\ClassProxyEnabler.ps1 Microsoft.Windows.Server.DC.Computer $true c:\out\

##--Begin ClassProxyEnabler.ps1

Param($className,$bTF,$fileDir)
##--Get the class in which you want to set Agent Proxing
$class = Get-MonitoringClass | Where {$_.Name -eq $className}
##--Get all objects in that class
$objects = Get-MonitoringObject -monitoringClass:$class
##--Create an array of BME's
$arrBME = @()
Foreach ($object in $objects)
    {
    Do
        {
        $parent = $object.getParentPartialMonitoringObjects()
        Foreach ($oParent in $parent) {If ($oParent.FullName -match "Microsoft.Windows.Computer:") {$object = $oParent}}
        }
    Until ($object.FullName -match "Microsoft.Windows.Computer")
    $arrBME += $object.Id.ToString()
    }
##--Create an array of agents to help script performance.
$agentArray = @()
Foreach ($agent in Get-Agent)
    {
    $agentArray += $agent
    }
##--Create output file
$localTime = (get-date).ToLocalTime()
$year = $localTime.year.ToString()
$month = $localTime.month.ToString()
$day = $localTime.day.ToString()
$hour = $localTime.hour.ToString()
$min = $localTime.minute.ToString()
$fileName = $class.name + "_" + $year + "-" + $month + "-" + $day + "_" + $hour + "-" + $min + ".txt"
$filePath = $fileDir + $fileName
##--Walk through the array and set Agent Proxying for each agent
Foreach ($BME in $arrBME)
    {
    $i=0
    While ($i -ne $agentArray.count)
        {
        If ($BME -eq $agentArray[$i].Id.ToString())
            {
            ##--Screen formatting
            $space = " "
            $spaceCount = 30 - $agentArray[$i].ComputerName.length
            ##--If already set to preference, skip with message.
            If ($agentArray[$i].ProxyingEnabled.Value -eq $bTF)
                {
                $agentArray[$i].ComputerName + $space*$spaceCount + "No action taken"
                $agentArray[$i].ComputerName + $space*$spaceCount + "No action taken" | out-file $filePath -append
                $i = $agentArray.count
                ##--Allow operator to track screen output
                Start-Sleep -m 200
                }
            ##--If not set to preference, modify with message.
            Else
                {
                $agentArray[$i].ComputerName + $space*$spaceCount + "Modifying..."
                $agentArray[$i].ComputerName + $space*$spaceCount + "Modifying..." | out-file $filePath -append
                $agentArray[$i].set_proxyingEnabled($bTF)
                $agentArray[$i].applyChanges()
                $i = $agentArray.count
                ##--Allow operator to track screen output
                Start-Sleep -m 200
                }
            }
        Else
            {
            $i+=1
        }
    }
}
Write-Host "`n`n`n`nResults saved to $filePath"

##--End ClassProxyEnabler.ps1

Schedule this script to run on a regular basis for the domain controller or cluster classes.  Whenever new domain controllers or cluster nodes come online, Agent Proxy will be enabled automatically. This script ONLY makes modifications if required.  In other words, there is no harm in running this multiple times.  Agent Proxy will only be modified if it does not match the $true or $false parameter supplied.

Get-NotificationRecipient | foreach-object {$_.devices | where {$_.protocol -eq "smtp"}} | select name,address

Command Shell Main Menu

Do you have some domain controllers that are appearing in a “not monitored” state?

There are several reasons why an object would have a “not monitored” state.  There are two very common reasons why a domain controller appears in this state if you are running the AD MP.

There is an option to remove these domain controllers that appear in a “not monitored” state.  You can refer to the Active Directory Management Pack Guide for details on this, but there are a couple points I will note here that will help answer some lingering questions.

This is not intended to explain when or why you should remove this discovered inventory, rather some observations and notes I ran across while performing these steps in my lab.  Refer to official documentation to help determine if you really want to remove these not monitored domain controllers.

As of the date of this post, the current version of the AD MP is 6.0.6452.0.  The AD MP may change in subsequent versions.

How these object get discovered

Forests, Domains, sites, site links, subnets, and domain controllers are all seeded in the AD Topology Discovery, which resides in Microsoft.Windows.Server.AD.Library.  This workflow runs on the Root Management Server.

At a very high level, in this discovery, a connection is made to Active Directory and returns all domain controllers in the domain.  Each domain controller returned from Active Directory will be submitted as discovered inventory and all the corresponding relationships (e.g., connection points) will be created.  This is an all-inclusive discovery pass; no domain controller left behind.

Whether or not the domain controller has an agent installed, the objects and relationships will be discovered and created in Operations Manager.  This is why we may see several, and in some cases hundreds of domain controllers that are in a “not monitored” state.  Because the state of a Windows Computer object cannot possibly be evaluated without first having an agent installed on that computer; with the exception of agentless monitoring, of course, but that’s a separate discussion.

This explains case 1; the domain controller does not have an agent installed.  What about case 2; the domain controller has an agent installed, but it doesn’t report to this Management Group?  Read on.

DiscoveryAgentOnly override

If you decide that you don’t like having all these domain controllers in a “not monitored” state, you can use this override option to remove this inventory and the associated relationships.  Be aware that the Active Directory Topology will no longer be completely accurate, and some monitoring workflows may not work as expected.

I will not discuss the effects of removing this inventory, only steps to remove and observations while removing.

See “Gotcha!” and “Workaround” sections below before enabling this override.

How domain controllers are discovered if DiscoverAgentOnly override is enabled

Here’s a high-level overview of discovery process in the AD Topology Discovery if this override is enabled.

This explains the two cases above.

I enabled DiscoverAgentOnly, but this inventory didn’t go go away!

First, let’s double check the work.  Is this what you did?

Override the AD Topology Discovery for all objects of class: Root Management Server

Wait… This discovery runs every 24 hours, by default.  You’ll need to wait for the next interval to see results.

A couple things to verify

You want to see results now?

If you want immediate results, also check the IntervalSeconds parameter and change this value to a smaller number (e.g., 300 = 5 minutes).  Wait for that duration and inventory should reflect desired results.

Remember to change this IntervalSeconds parameter back! Default = 86400 (24hours)

Gotcha!

There is a gotcha I haven’t mentioned yet, and it’s not documented.

The Management Server Action Account requires Operations Manager Administrator User Role to run Get-Agent in Command Shell.

The Default Action Account, which is usually a special Management Server Action Account which all Management Servers use by default for all workflows, may not have require privileges to run the Get-Agent cmdlet in Command Shell.

The MSAA does not need to be an Operations Manager Administrator for normal operations, but it does need Operations Manager Administrator privileges to run the AD Topology Discovery successfully if the DiscoveryAgentOnly override is set to TRUE.

Workaround

Be sure the Management Server Action Account domain account is a member of the Operations Manager Administrator domain security group.

This is necessary for the MSAA account to inherit privileges to perform the Get-Agent command in the discovery workflow.

If the MSAA account is not added to Operations Manager Administrators prior to setting the DiscoverAgentOnly override to TRUE, you’ll notice that CMD.exe and Powershell.exe processes on the RMS will never return.  These will hang indefinitely and the discovery will not spawn any new thread until these are killed or the RMS Health Service is restarted.

If the MSAA account is added to Operations Manager Administrator after setting the DiscoverAgentOnly override to TRUE, and at least one interval has passed, you need to kill those processes running under the MSAA or restart the Health Service on the RMS.

This gotcha has been bugged and will hopefully be addressed in the next version of the AD MP.  My suggestion was to run this workflow under a privileged Run As Profile, which has permissions to run Get-Agent.

UPDATE: 11/05/2009

The latest release of the AD MP guide (6.0.7065.0) has been revised, and now states that the Management Server Action Account must be a member of the Operations Manager Administrators group in low-privilege environments (page 27).  This means that the MSAA domain user account needs to be added to the Operations Manager administrator domain group, which will receive the Operations Manager Administrators User Role.

Keep in mind that this is ONLY required if you plan on using the Discover Agent Only option for the AD Topology discovery.  Otherwise, the MSAA does not require Operations Manager Administrators User Role.

I ran across an issue recently where several CScript processes would peg the CPU for several seconds at a time.  You may have run across the same issue, and read some other articles about updating CScript to the latest version (5.7).  But, what if CScript.exe is already at version 5.7, like it was in this particular instance?

Short answer

Apply the update package again.

I knew it was a problem with CScript, but after looking at the version and verifying it was the latest version, the problem was elusive.  I applied the update package again, simply because I was running out of ideas and figured it couldn’t hurt.  Well, it didn’t hurt.  It solved the problem.

Here’s what I observed that made it so clear it was still a problem with CScript, in case you are having similar issues and need to prove this case in your environment.

Quick verification

How to quickly verify CScript is root cause in this situation.

1.  Create a text file
2.  Paste WScript.echo "hello" into it
3.  Save as %temp%\test.vbs
4.  Open a command prompt
5.  Type CScript.exe %temp%\test.vbs and hit enter

You will see this:

So, what’s so special about that?  Well, how long did it take for hello to output to screen?  If it took more than a millisecond, that’s too long.  In my case, it took 2 seconds just to echo a string.  That’s a problem!

Verify issue with Procmon

If you really want to see how this is affecting your agent machine, follow these steps.

1.  Open up Procmon on the agent machine in question
2.  Setup your filter like so:



3.  Capture for a couple minutes.  You’ll see some CScript processes logged fairly soon, like so:

 

Take a look at the Exit Status on all these CScript processes.  They are all over 2 seconds, and that’s why CPU is pegged for so long.

4.  Take a look at the properties for any one of these CScript processes.

As you can see from above, this is the current version of CScript.exe (5.7.0.165335) for Windows Server 2003.  But, after RE-applying the CScript update (same version), all these processes that were taking more than 2 seconds are now running in fractions of a second.

In this series, I’m going to talk about multiple Management Groups sharing a single Data Warehouse.  I’ll try to clarify two common questions that come out of this scenario.

Part 1 – Operations Manager Reporting Instance
Where do these components get installed?

Part 2 – ReportServer and ReportServerTempDB
Where do these databases reside?

Here we go with part 2…

While planning a consolidated reporting deployment, some thought needs to be given to where the reporting databases will be hosted.  However, the restrictions set forth by the SCOM Reporting Instance do not apply for the reporting databases.  As described in part 1, the SCOM Reporting Instance needs to be unique for each Management Group.  The reporting databases can be hosted by any SQL DB Engine, which is not dependent at all on any Management Group.

Before I get into some common scenario’s for the reporting databases, I want to mention one caveat.  The Product Group does not officially support the reporting databases in a clustered configuration.  Although I have seen this configuration work well in some cases, I cannot recommend this configuration for obvious reasons.  This article from the MOM Team has served as an official statement of this configuration.

Scenario 1

I commonly see all reporting databases for each Management Group hosted on the Data Warehouse SQL DB Engine.  For example, a Data Warehouse shared between three Management Groups looks similar to the following.

Scenario 2

Another option is to host the reporting databases on another SQL Server.  I can see this as an option for a situation where a Data Warehouse is shared amongst more than two Management Groups, and performance may be of concern.  More specifically, if the Data Warehouse is currently being shared between two Management Groups, sharing this Data Warehouse to an additional Management Group may push these hardware resources over the top.  If this happens, there may be data insertion issues, especially during times of heavy report usage in either of the Management Groups.

Scenario 3

Another option is to host the reporting databases on the same machine that is hosting the SCOM Reporting Instance, as follows.

Conclusion

As outlined here, the reporting database can be hosted by virtually any SQL DB Engine.  The scenario’s don’t end with what is listed above.  These are just some of the more common scenario’s.

The most important thing to consider is performance.  If your initial design was to host all reporting databases on the same server hosting the share Data Warehouse, and your report users start observing latencies and performance degradation, there are options to move these reporting databases to another SQL DB Engine.  Feel free to mix and match these databases to optimize your reporting experience.

Ever wonder which Management Pack you stored a particular group in?  Here’s the answer.

ForEach ($Group in get-MonitoringObjectGroup) {If ($Group.DisplayName -eq "<group_name>") {get-MonitoringClass | where {$_.Id -eq $Group.Id.ToString()} | Foreach-Object {$_.getManagementPack()} | Select @{Name="Group Name";Expression={$Group.DisplayName}},@{Name="MP Name";Expression={$_.Name}},@{Name="MP DisplayName";Expression={$_.DisplayName}} | fl}}

Command Shell Main Menu

In this series, I’m going to talk about multiple Management Groups sharing a single Data Warehouse.  I’ll try to clarify two common questions that come out of this scenario.

Part 1 – Operations Manager Reporting Instance
Where do these components get installed?

Part 2 – ReportServer and ReportServerTempDB
Where do these databases reside?

Before I get started, I want to make one thing clear about clustered configurations.  The SCOM Report Server role is not cluster-aware, so the Report Server role cannot be installed in a clustered configuration.  The SSRS Instance cannot participate in a scaled-out deployment.  Nor is the reporting databases hosted in a clustered configuration officially supported.  This article by the MOM Team has served as the official statement on these configurations.

Here we go with part 1…

Throughout this post, I’ll talk about the SCOM Reporting Instance.  When I mention the SCOM Reporting Instance, I am referring to three components that make up SCOM Reporting.

Components of a SCOM Reporting Instance

· SCOM Report Server role

· SQL Server Report Server (SSRS) instance

· Computer

You might be wondering why I include “computer” as a component.  No kidding, we need a computer?  I added this as a component to help the reader visualize the concept, which you’ll understand in just a moment.

There is a dependency between each of these components. We must think of the composition of the SCOM Reporting Instance as a single package that cannot be split. Also, a SCOM Reporting Instance cannot coexist with another SCOM Reporting Instance serving another Management Group.

During the installation of the SCOM Report Server role, SSRS security is reconfigured to make use of SCOM security features (User Roles) which are implemented in the SDK. Because of this, only one installation of the SCOM Report Server role can exist on a computer.

Since the SCOM Report Server role installation has a dependency on a local installation of a SSRS instance, we can deduce that there is a 1:1:1 relationship between the SCOM Report Server role, the SSRS instance and the computer in which these components are installed.

We can also determine from these rules that the 1:1:1 relationship is strict, and that these components can neither be split, nor can these components be mixed and matched with other SCOM Reporting Instance components serving other Management Groups.

Of course, we need not be concerned about these rules in single Management Group scenarios that are not sharing a Data Warehouse.  But if you are sharing a Data Warehouse amongst two or more Management Groups, these rules apply.

Customers often get hung up on the “unique computer” for each SCOM Reporting Instance rule. Often I hear customers asking if they can combine SCOM Reporting Instances in a multiple Management Group scenario. This isn’t possible, as a SCOM Reporting Instance cannot coexist with another SCOM Reporting Instance serving another Management Group.

Another point of confusion for customers is they have installed a SCOM Reporting Instance for the first Management Group on the server hosting the Data Warehouse. Later, they have deployed additional Management Groups and want to share the Data Warehouse. This is fine. But, again, the rules state that we cannot install another SCOM Reporting Instance on the server hosting the Data Warehouse. We must find another server to install the SCOM Reporting Instance. Additionally, each subsequent Management Group deployed that will share the Data Warehouse will require yet another unique server to install the SCOM Reporting Instance.

In case there are any lingering questions, I provided a simple table that should solidify these rules.

Even though this seems like a simple concept, I get these questions on a regular basis.  I hope this clarifies the SCOM Reporting Instance and where these components are installed.  Next I’ll be talking about where the report server databases can be created, and describing a caveat if these databases are located on a Data Warehouse in a clustered configuration.

Came across an issue today that was really just a matter of me not reading the fine print.  I figured a quick post on this could help someone with the same issue.

The problem

While attempting to install a database using DBCreateWizard, I was receiving the following error.

The Cause

I was installing an operational database for a second Management Group in an instance already containing an operational database, so I attempted to name the database OperationsManager-MG2.

Note: It’s not recommended to host more than one OperationsManager database on a single instance in most environments.  Usually this would be done in a lab or development environment.

The Solution

Name the new database OperationsManagerMG2.

After research most every avenue, I popped open the deployment guide to see if there was anything I was missing about DBCreateWizard.  I didn’t find anything directly pertaining to DBCreateWizard, but after further reading I had a memory refresh.

Page 103, number 12, of the R2 Deployment Guide states, “…do not insert a ‘-‘ in the database name…”.  Doh!

I was working with a large customer last week, and found some very interesting performance metrics which impact console sessions.  This particular customer pushes the limits of Operations Manager 2007 in every way.  They have 6000+ agents in a single Management Group, and have an average of 50 concurrent console sessions at any given point in time.  Achieving these limits was a work in progress over several months, but eventually we got there.

However, there was one very curious point of failure, where connected console sessions would become extremely sluggish or even freeze for a period of ~10 minutes.  It was something that eluded us for quite some time, until last week.

If you are familiar with KB956240, you know that this hotfix updates the Operations Manager 2007 Data Abstraction Layer component (Microsoft.mom.dataaccesslayer.dll).  Although KB956240 helps reduce the performance impact that the types configuration changes mentioned in the article will produce, there has been no change to the underlying configuration update process in Operations Manager 2007.

The good news

This configuration update process has been changed in Operations Manager 2007 R2.  This change will also be included in the Post SP1 Rollup.  In R2 and Post SP1 Rollup, Management Group configuration updates that occur during certain types of configuration changes will not produce such a performance impact.

Am I affected by this issue?

It depends on the number of agents in your Management Group, how heavily your company employs the console (concurrent connections), and how long it takes for configuration updates to reach agents in your environment.

If you’ve got 6000 agents in your MG, you likely have a dynamic environment in which new servers (agents) are deployed regularly, and expired or failed servers (agents) are decommissioned on a regular basis.  You are likely affected by this issue.

If your administrators are always in the console, you’ll likely have some complaints that the console became extremely slow or maybe even froze for a duration of ~10 minutes.  You are likely affected by this issue.

If your Root Management Server and/or OperationsManager database server cannot handle the “bursty” type of traffic and transactions that configuration updates produce, or if there is significant network latency effecting the time it take configuration updates to reach your agent population, you are likely affected by this issue.

Although each of the abovementioned conditions are true, every Management Group is affected by this issue.  It’s really a matter of how frequently you are affected, and to what degree your environment will be impacted.

What can I do now?

From what I’ve observed in the field, the biggest performance impact is produced from approving agents.  The only guidance I could give to help reduce the impact, at least during peak times where having poor console performance isn’t an option, is to schedule agent approval during times in which you know will not impact your console users quite as much.

One thing to note

Whether a single agent is approved, or a batch of 200 agents are approved, the same configuration update process is initiated.  If there are multiple agents waiting to be approved, select each agent and approve all at the same time.  Or, use an agent approval script that batches agent approval.

If you have auto-approval turned on (indicated below in yellow), unfortunately there is no way to control the approval process.

UPDATE:  04-26-2009

While using this script at a customer site, outside of my small lab environment, I realized I could have made this script perform more efficiently.  My customer had ~500 agents, and this script took about 10 minutes to complete.

I figured this was an important enough update to warrant a new post, so those that subscribe can grab the updated version.

This is a very good question that has come on occasion.  However, this question cannot be answered by means of looking in the Operations Console or querying the Operations Manager databases.

We can easily find out which Management Server is acting as a Primary for an agent.  We can also set Failover Management Server using AD Integration and using Powershell scripting methods.

Everyone wants to know, after configuring failover servers (or not), which Management Server their agents are currently talking to.  We all want to know if our agents are reporting to the Management Servers we configured them to report to.  And, if they failover, are they failing over to the appropriate MS configured in the failover list?

Here’s one way to find out!

Simply copy the script below into the Command Shell on any Management Server, including the Root Management Server.  The results will show you a list of agents currently connected to that Management Servers Health Service.  It will also output whether an agent is currently in a Failed Over state.

Screenshot of script output 
 

Here’s the script.  Copy everything between the first ## and the last ##, and paste directly into the Command Shell on each of your Management Servers.

##--Start copy here, include this line

$AgentArray=@()
$Space = " "
foreach ($agent in get-agent | select Computername,@{name='IpAddress';expression={$_.IpAddress.split(",")[0].ToString()}},@{name='PrimaryMS';expression={$_.PrimaryManagementServerName.Split(".")[0]}})
    {$AgentArray+=$agent}
foreach ($RemoteEndPoint in [System.Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties().GetActiveTcpConnections() | where {$_.LocalEndPoint -match "5723"})
    {
    $i=0
    while ($i -ne $AgentArray.count)
        {
        if ($AgentArray[$i].IpAddress.ToString() -contains $RemoteEndPoint.RemoteEndPoint.Address.IPAddressToString)
            {
            $SpaceCount = 30 - $AgentArray[$i].Computername.length
            $FAgent = $AgentArray[$i].Computername + $Space*$SpaceCount
            if ($AgentArray[$i].PrimaryMS -eq $env:ComputerName)
                {
                $FStatus = "OK"
                }
            else
                {
                $FStatus = "Currently Failed Over"
                }
            Write-Host $FAgent $FStatus
            $i=$AgentArray.count
            }
        else
            {
            $i+=1
            }
        }
    }

##--End copy here, include this line

Caveats

*Any agent that has more than one IP Address, only the first IP Address discovered will be used.  If the first IP Address discovered does not match the Active TCP Connections list on the MS, this agent will not appear in the list.

**I’ve had problems in some network adapter configurations, where the results were not accurate.  This is immediately evident by spot checking the results.  I haven’t identified the exact cause of these rare cases.

command shell main menu

/*Get each logical disk size, for each agent computer, by OS version.
This helps in calculating the Logical Disk Free Space Monitor from my
earlier post.  You can copy results into Excel, sort by system and
non-system drives, and perform an average disk size formula.  Then
plug Min, Max and Avg sizes into my Logical Disk Free Space Calculator
to find your unique MB and % thresholds for your company's unique
requirements.*/

SELECT     PrincipalName AS 'Windows 2000', DisplayName_55270A70_AC47_C853_C617_236B0CFF9B4C AS 'Drive', CONVERT(bigint,
                      Size_486ADDDB_2EB8_819A_FA24_8F6AB3E29543) / 1024000000 AS 'Size'
FROM         MTV_LogicalDisk
ORDER BY 'Windows 2000', 'Drive'

SELECT     PrincipalName AS 'Windows 2003', DisplayName_55270A70_AC47_C853_C617_236B0CFF9B4C AS 'Drive', CONVERT(bigint,
                      Size_486ADDDB_2EB8_819A_FA24_8F6AB3E29543) / 1024000000 AS 'Size'
FROM         MTV_LogicalDisk_0
ORDER BY 'Windows 2003', 'Drive'

SELECT     PrincipalName AS 'Windows 2008', DisplayName_55270A70_AC47_C853_C617_236B0CFF9B4C AS 'Drive', CONVERT(bigint,
                      Size_486ADDDB_2EB8_819A_FA24_8F6AB3E29543) / 1024000000 AS 'Size'
FROM         MTV_LogicalDisk_1
ORDER BY 'Windows 2008', 'Drive'

I’m starting a new post here, similar to my Command Shell reference.  This will include some useful SQL queries that I happen to need and direct my customers to on a daily basis.  If you don’t see something here, check Kevin Holman’s blog.  He’s already got a library of useful queries posted, in which I will not duplicate here.

I will continue to update this table periodically.  If you subscribe to my blog, you will receive each new example as I post it.

Note: The queries in each link are a direct paste from the SQL query editor.  They do not look pretty.  Simply copy the content into your query editor to see proper formatting.

Replace any text in red in each example with your specific parameters or criteria.

SELECT     SourceMonitoringObjectDisplayName AS 'Group', TargetMonitoringObjectDisplayName AS 'Member'
FROM         RelationshipGenericView
WHERE     (SourceMonitoringObjectDisplayName IN
                          (SELECT     ManagedEntityGenericView.DisplayName
                            FROM          ManagedEntityGenericView INNER JOIN
                                                       (SELECT     BaseManagedEntityId
                                                         FROM          BaseManagedEntity WITH (NOLOCK)
                                                         WHERE      (BaseManagedEntityId = TopLevelHostEntityId) AND (BaseManagedEntityId NOT IN
                                                                                    (SELECT     R.TargetEntityId
                                                                                      FROM          Relationship AS R WITH (NOLOCK) INNER JOIN
                                                                                                             dbo.fn_ContainmentRelationshipTypes() AS CRT ON R.RelationshipTypeId = CRT.RelationshipTypeId
                                                                                      WHERE      (R.IsDeleted = 0)))) AS GetTopLevelEntities ON
                                                   GetTopLevelEntities.BaseManagedEntityId = ManagedEntityGenericView.Id INNER JOIN
                                                       (SELECT DISTINCT BaseManagedEntityId
                                                         FROM          TypedManagedEntity WITH (NOLOCK)
                                                         WHERE      (ManagedTypeId IN
                                                                                    (SELECT     DerivedManagedTypeId
                                                                                      FROM          dbo.fn_DerivedManagedTypes(dbo.fn_ManagedTypeId_Group()) AS fn_DerivedManagedTypes_1))) AS GetOnlyGroups ON
                                                   GetOnlyGroups.BaseManagedEntityId = ManagedEntityGenericView.Id))
ORDER BY 'Group'

SELECT     ManagedEntityGenericView.DisplayName, ManagedEntityGenericView.FullName
FROM         ManagedEntityGenericView INNER JOIN
                          (SELECT     BaseManagedEntityId
                            FROM          BaseManagedEntity WITH (NOLOCK)
                            WHERE      (BaseManagedEntityId = TopLevelHostEntityId) AND (BaseManagedEntityId NOT IN
                                                       (SELECT     R.TargetEntityId
                                                         FROM          Relationship AS R WITH (NOLOCK) INNER JOIN
                                                                                dbo.fn_ContainmentRelationshipTypes() AS CRT ON R.RelationshipTypeId = CRT.RelationshipTypeId
                                                         WHERE      (R.IsDeleted = 0)))) AS GetTopLevelEntities ON GetTopLevelEntities.BaseManagedEntityId = ManagedEntityGenericView.Id INNER JOIN
                          (SELECT DISTINCT BaseManagedEntityId
                            FROM          TypedManagedEntity WITH (NOLOCK)
                            WHERE      (ManagedTypeId IN
                                                       (SELECT     DerivedManagedTypeId
                                                         FROM          dbo.fn_DerivedManagedTypes(dbo.fn_ManagedTypeId_Group()) AS fn_DerivedManagedTypes_1))) AS GetOnlyGroups ON
                      GetOnlyGroups.BaseManagedEntityId = ManagedEntityGenericView.Id
ORDER BY DisplayName

get-alert | where {$_.name -match "Alert Name"} | get-AlertHistory | select Time*

command shell main menu

This will return the list of Failover Management Servers for specified agent.

get-agent | where {$_.computername -eq "netbios computername"} | Get-FailoverManagementServer | select computername

command shell main menu