According to TechNet, when the
TimeoutSec parameter of
Invoke-WebRequest is ommitted or specified as 0, the timeout is indefinite. There appears to be a bug that causes this value to default to 100 seconds, at least in PowerShell 4. I presume this is because the default value of the underlying
System.Net.HttpWebRequest.Timeout property is 100,000 ms.
The workaround is to specify a large value for
Invoke-WebRequest -UriÔÇª -TimeoutSec [int]::MaxValue
That is, assuming that you want the request to return within 68 years.
Edit: 13/08/2015: This bug has been fixed in management pack version 184.108.40.206.
I have discovered a bug in the latest SQL Server 2014 SCOM management pack (220.127.116.11).
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
FG, but, according to MSDN, there are two more possible values:
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.
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.