Edit: 13/08/2015: This bug has been fixed in management pack version 6.6.0.0.

---

I have discovered a bug in the latest SQL Server 2014 SCOM management pack (6.5.1.0).

The problem is that file groups are not discovered for databases containing filestreams or partition schemes, due to a bug in the discovery script. The health service subsequently goes on to discover the files associated with all the file groups, regardless of whether the file group has been discovered, and forwards the data to the management server. Upon receipt of the discovery data for the files, the management server rejects it because some of the files are associated with file groups that haven’t yet been discovered, i.e. the management server is unable to map some of the files to file groups. The result is that all files for the database aren’t discovered and are therefore not monitored.

The symptoms are event ID 10801 on management servers, when the management server processes the discovery data, and missing database file groups and files in the inventory. The cause is a bug in the DiscoverSQL2014FileGroups.js script in the Microsoft.SQLServer.2014.Discovery management pack, where it only accepts file group types FX and FG, but, according to MSDN, there are two more possible values: FD and PS.

I have logged this bug on Microsoft Connect. Please vote for this bug if it’s a problem for you.

I’ve implemented a workaround, until Microsoft resolve the problem, which restricts file and log file discovery to those file group types that have previously been discovered, i.e. FX and FG. This allows monitoring of these file group types, but does not monitor the missing types. Unfortunately I can’t distribute the updated management pack as it contains Microsoft code.

The cause of an error code of 2147954430 from a web application transaction monitor can be difficult to determine, especially as it’s often intermittent. In my case, investigating the watcher node revealed that too many long-running calls had been included in the monitor and this had caused a backlog on the node, as described by event ID 10503 in the Operations Manager log:

The HTTP URL Monitoring Module detected that a backlog of processing has happened. It might be an indication of too many URL monitors configured for this watcher node.

The solution was to increase the interval between executions of the monitor to one that more realistically reflected the likely execution time. And it might be useful to create a rule to raise alerts from these events on the watcher nodes.

The requested view will contain at least x objects and may require substantial time to render.

For anyone that uses SCOM regularly, the warning prompt that pops up when entering the diagram view can become quite frustrating. The default threshold for this prompt is 50 objects.

Thankfully, it’s fairly easily disabled. Just create a key in the registry:

HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console\DiagramViewParameters

and a DWORD value called MaxNodesThreshold with a significantly higher value.

If the SDK service fails on a SCOM management server with event ID 26325, the problem is in accessing the authorisation manager store in the OperationsManager database, and is most-likely caused by a SQL login having been granted dbo access to the database, which is an invalid state.
To correct this, revoke all SQL login accounts’ dbo access to the database and start the SDK service.

In order for SCOM to be able to access the management pack web service, the console must have either direct access to the web or, if a web proxy is in use, the following may be configured.

The Windows proxy settings must be correctly defined. These are not the same settings as in IE, but can be copied from IE:

1. Configure a proxy setting in IE. This must be explicitly defined, i.e. automatic configuration scripts cannot be used.
2. Start a command prompt with administrative rights.
3. Copy your IE proxy settings to the local machine proxy settings.
   For XP/Server 2003:

   proxycfg -u

   For Vista/Server 2008 and above:

   netsh winhttp import proxy ie

4. Start the SCOM console and access the web service.

NB: the configuration changes must take place on the computer running the console; no modifications to management servers are necessary.

For information, the URL of the web service is https://microsoft.com/mpdownload/ManagementPackCatalogWebService.asmx.

Requirements

1. An agent-managed computer to act as the agent proxy. This server is used to query the Azure platform.
2. Details of the DNS prefix, subscription ID and deployment slot of the application.
3. A copy of the certificate, including the private key and its password.
4. Access to the Azure platform through an unauthenticated web proxy. This includes the following URLs:
1. https://application DNS prefix.table.core.windows.net/*, e.g.
   https://application.table.core.windows.net/*;
2. https://management.core.windows.net/*;
3. http://crl.microsoft.com/PKI/*; and
4. http://www.public-trust.com/cgi-bin/crl/2018/cdp.crl
5. The IP address and port number of the aforementioned proxy.

Configuration

1. Create an account of type binary authentication to contain the certificate, and distribute it to the agent proxy computer.
2. Create an account of type basic authentication to contain the password to access the certificate.
3. Create a new Windows Azure Application object:
1. entering the DNS prefix, subscription ID, deployment slot of the application;
2. select the certificate and authentication accounts; and
3. select the proxy agent and enter the IP address and port of the web proxy.
4. Wait for the application become available under Monitoring > Windows Azure.
   Any problems connecting to the platform will be logged in the Operations Manager event log on the proxy agent.

Custom performance monitoring

1. Import an existing management pack from SCOM into the Authoring Console.
2. Create the rule:
1. select Health Explorer > Rules > New > Custom Rule;
2. enter an ID and name;
3. select Windows Azure Role Instance as the target;
4. create a data source module of type Windows Azure Role Instance Performance Counter Collection Simple Data Source called DS;
5. edit the data source and configure the values as appropriate;
6. if a specific instance is to be monitored, create a key called InstanceName;
7. if all instances are to be monitored, create a key called AllInstances and set its value to true;
8. create two actions:
1. one of type Performance Data Collection Write Action called WriteToDb; and
2. the other of type Performance Data Publisher called WriteToDw; and
9. disable the rule.
3. Export the management pack to SCOM.
4. Create a group in SCOM containing the instance(s) of Azure to which the rule is to be applied.
5. Override the rule to enable it for the group.

Custom monitors in SCOM may, unless the Authoring Console is used or custom XML employed, only execute VBScript. PowerShell scripts can still be executed though, as long as they’re Base64-encoded and wrapped in VBScript.

1. Write a PowerShell script that places its output on the console as easily-identifiable strings, the output from which can be easily parsed by VBScript, e.g.

   Success: 0
   Error message: Insufficient memory.

2. Encode the PowerShell script to Base64, where {Script} is the script:

   $Command = '{Script}'
   $EncodedCommand = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($Command))
   $EncodedCommand > EncodedCommand.txt

3. Create the monitor, implementing a VBScript similar to that below, but inserting the contents of EncodedCommand.txt into the PsScript variable.

   PsScript=""
   Command="PowerShell.exe -EncodedCommand " & PsScript
   Set Shell=CreateObject("WScript.Shell")
   Set Executor=Shell.Exec(Command)
   Executor.StdIn.Close
   varPSResult=Executor.StdOut.ReadAll
   
   varSuccess=Mid(varPSResult, InStr(varPSResult, "Success: ") +
   Len("Success: "), 1)
   varErrorMessage=Right(varPSResult, Len(varPSResult) - (InStr(varPSResult,
   "Error message: ") + Len("Error message: ") - 1))
   
   Dim oAPI, oBag
   Set oAPI=CreateObject("MOM.ScriptAPI")
   Set oBag=oAPI.CreatePropertyBag()
   
   Call oBag.AddValue("Success", varSuccess)
   Call oBag.AddValue("Error message", varErrorMessage)
   Call oAPI.Return(oBag)
   		

4. Configure the healthy, unhealthy and other components as appropriate.

Monitoring SharePoint Foundation/Server with SCOM requires some additional configuration following the installation of the management pack.

1. Download and install the latest version of the SharePoint Foundation and, if appropriate, SharePoint Server management packs to SCOM.
2. If using SCOM 2012 or later, also download and install the 2012-specific management pack for SharePoint.
3. Create or utilise an existing domain user account, e.g. Domain\ScomMonitorSharePoint, granting it the following permissions:
   1. membership of the Farm administrators SharePoint group;
   2. membership of the sysadmin SQL Server role; and
   3. membership of the local administrators group on all servers in the farm, except those that exclusively run SQL Server.
4. Create or utilise an existing Run As account in SCOM for this user account, configuring the distribution of the credential to all servers in the SharePoint farm.
5. Ensure that the SharePoint Discovery/Monitoring Account profile is configured to use the configured account.
6. Create (copying from the management pack installation directory) or modify the SharePoint Server management pack configuration file on the RMS (emulator), which is stored as C:\Program Files\System Center Management Packs\SharePointMP.Config: under <Association>, modify as appropriate, depending on whether or not a new Run As account has been created. Further instructions are located in this file.
7. Run the SharePoint server discovery: select Monitoring > SharePoint Products > Administration > Tasks > Microsoft SharePoint Farm Group Tasks > Configure SharePoint Management Pack > Run.
   Resolve any errors presented.
8. Wait for approximately 30 minutes for SCOM to discover the instance(s) of SharePoint.
   NB: any problems will be reported in the member servers’ event logs.

Rule-generated alerts in SCOM do not automatically close when the problem that triggered the alert has been resolved; they will remain open until they are closed by SCOM when they reach the automatic resolution threshold, the default for which is 30 days, or until they are closed by a user.

If you have a requirement for rule-generated alerts to be automatically closed after a defined period, try this PowerShell script. For best effect, the script should be scheduled to be executed every few hours. NB: this script has been tested with SCOM 2007 R2; it may have to be modified to function with 2012.

$Rms = "Localhost"
$LogFile = $Pwd.ToString() + "\Close rule-generated alerts.log"
$MaximumAlertAge = ((Get-Date).AddHours(-4.0).ToUniversalTime())
$StateClosed = "255"
$ServerFqdn = (Get-WmiObject Win32_ComputerSystem | Select-Object -expand Name) + "." + (Get-WmiObject Win32_ComputerSystem | Select-Object -expand Domain)
$ClosureComment = "Rule-generated alert closed by '$($MyInvocation.MyCommand.Name)' on $($ServerFqdn)."

# Initiate the SCOM snap-in.
If ((Get-PsSnapin | Where-Object {$_.Name -eq 'Microsoft.EnterpriseManagement.OperationsManager.Client'}) -eq $null)
{
	Add-PsSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorAction "SilentlyContinue" -ErrorVariable "Err"
}
If ((Get-PsDrive | Where-Object {$_.Name -eq 'Monitoring'}) -eq $null)
{
	New-PsDrive -Name "Monitoring" -PSProvider "OperationsManagerMonitoring" -Root "\" -ErrorAction "SilentlyContinue" -ErrorVariable "Err" | Out-Null
}

# Connect to the RMS.
Set-Location "OperationsManagerMonitoring::"
New-ManagementGroupConnection -ConnectionString $Rms | Out-Null
Set-Location "Monitoring:\$Rms"

# Write to the log.
Add-Content $LogFile "---Begin execution: $(Get-Date -format "dd/MM/yyyy HH:mm:ss").------------------------------------------------"

# Obtain details of rule-generted alerts (i.e. IsMonitorAlert = 0) due to be closed.
$AlertsToBeClosed = Get-Alert -criteria "ResolutionState != $StateClosed AND IsMonitorAlert = 0 AND TimeRaised < '$MaximumAlertAge'"

# Close the alerts.
If ($AlertsToBeClosed)
{
	$NumberOfAlertsToClose = $AlertsToBeClosed | Measure-Object | Select-Object -expand Count
	If ($NumberOfAlertsToClose -eq 1)
	{
		Add-Content $LogFile "1 alert to close.`r`n"
	}
	Else
	{
		Add-Content $LogFile "$($NumberOfAlertsToClose) alerts to close.`r`n"
	}

	# Close the alerts.
	ForEach ($Alert in $AlertsToBeClosed)
	{
		Resolve-Alert -Alert $Alert -Comment $ClosureComment
		Add-Content $LogFile "ID:`t$($Alert.Id)`r`nHost:`t$($Alert.PrincipalName)`r`nName:`t$($Alert.Name)`r`nRaised:`t$(($Alert.TimeRaised).ToShortDateString() + " " + ($Alert.TimeRaised).ToLongTimeString())`r`nClosed:`t$(Get-Date -format "dd/MM/yyyy HH:mm:ss")`r`n"
	}
}
Else
{
	Add-Content $LogFile "No alerts to close."
}

# Write to the log.
Add-Content $LogFile "---End execution:   $(Get-Date -format "dd/MM/yyyy HH:mm:ss").------------------------------------------------`r`n"

Enabling the proxy setting for agents in SCOM is required for several management packs to function correctly. Although enabling this option on all agents is a potential a security risk, in reality most environments are secure and consequently this action will pose little risk. You should, however, understand and be aware of the risk of spoof data entering SCOM should this option be enabled.

To enable the proxy setting for all agents in SCOM, use the PowerShell script appropriate for your version. These scripts may be scheduled and executed throughout the day to ensure that new agents have this setting enabled.

2007 R2

<#
	Enables the proxy function for all agent-managed computers.
	This script is only compatible with SCOM 2007 R2.
	To exclude a computer or list of computers, add them to $Exclusions.
#>

$Rms = "Localhost"
$Exclusions = @("")

# Initiate the SCOM snap-in.
If ((Get-PsSnapin | Where-Object {$_.Name -eq 'Microsoft.EnterpriseManagement.OperationsManager.Client'}) -eq $null)
{
	Add-PsSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorAction "SilentlyContinue" -ErrorVariable "Err"
}
If ((Get-PsDrive | Where-Object {$_.Name -eq 'Monitoring'}) -eq $null)
{
	New-PsDrive -Name "Monitoring" -PSProvider "OperationsManagerMonitoring" -Root "\" -ErrorAction "SilentlyContinue" -ErrorVariable "Err" | Out-Null
}

# Connect to the RMS.
Set-Location "OperationsManagerMonitoring::"
New-ManagementGroupConnection -ConnectionString $Rms | Out-Null
Set-Location "Monitoring:\$Rms"

# Obtain the list of agents to which the modification is to be made, excluding $Exclusions.
$AgentProxyNotEnabled = Get-Agent | Where-Object {$_.ProxyingEnabled -match 'false'}
$AgentProxyToBeEnabled = @()
ForEach ($NotEnabled in $AgentProxyNotEnabled)
{
	If (($Exclusions -NotContains $NotEnabled.PrincipalName) -and ($AgentProxyToBeEnabled.PrincipalName -NotContains $NotEnabled.PrincipalName))
	{
		$AgentProxyToBeEnabled += (, ($NotEnabled))
	}
}

# Apply the modification.
ForEach ($AgentToBeEnabled in $AgentProxyToBeEnabled)
{
	Write-Host "Enabling the proxy on $($AgentToBeEnabled.DisplayName)..."
	$AgentToBeEnabled.ProxyingEnabled = $True
	$AgentToBeEnabled.ApplyChanges()
}

2012

$Exclusions = @("")

# Initiate the SCOM snap-in.
Import-Module OperationsManager

# Obtain the list of agents to which the modification is to be made, excluding $Exclusions.
$AgentProxyNotEnabled = Get-ScomAgent | Where-Object {$_.ProxyingEnabled -match 'false'}
$AgentProxyToBeEnabled = @()
ForEach ($NotEnabled in $AgentProxyNotEnabled)
{
	If (($Exclusions -NotContains $NotEnabled.PrincipalName) -and ($AgentProxyToBeEnabled.PrincipalName -NotContains $NotEnabled.PrincipalName))
	{
		$AgentProxyToBeEnabled += (, ($NotEnabled))
	}
}

# Apply the modification.
$AgentProxyToBeEnabled | Enable-ScomAgentProxy