The Windows Server 2012 R2 Remote Access (7.1.10181.1) management pack contains a bug that prevents any discovery from taking place with the default configuration. There are also unusual permission requirements.
The bug is that, by default, the discovery runs using the default run-as account for the server, which is usually
NT Authority\System, and no run-as profile exists to override this. Given that the discovery process must read GPOs, which are stored on network shares, this will always fail. It’s possible to change the default account for individual servers, but this would affect all the other workflows on that server. A workaround can be put in place by creating a new management pack that disables the default discovery, Remote Access Server PS Discovery, and adds an identical discovery from the Microsoft management pack, but with the addition of a run-as profile, which can then be set to use a domain account. None of the monitors need to run in the context of a domain account, so the run-as profile need only be applied to the discovery.
The following permissions are required by the account used for discovery:
- Administrator on every Remote Access/DirectAccess server. This is required to read from the SQL Server (WID) instance, and can be achieved by creating a GPO to assign this permission to the OU that contains the servers.
- Edit access to the client settings GPO. Read access, contrary to the documentation, is insufficient.
- Edit access to the server settings GPOs. Read access, again contrary to the documentation, is insufficient.
The above permissions should be provided by creating a (domain-local) group that contains the monitoring account, and assigning permissions to the group.
The final step is to distribute the run-as account to the servers that are to be monitored.
There is a known bug in SCOM, whereby PowerShell scripts that are embedded in rules or monitors (i.e. where the script is visible in the data source of the rule/monitor) can’t contain references to variables whose names start with
Database. More specifically, such variables can’t be accessed using the dollar notation, e.g.
$Database. VSAE will throw an exception when attempting to build a project containing such references:
The configuration specified for Module DS is not valid.
: Incorrect expression specified: $Database
Unable to resolve this expression. Check the expression for errors.
There are two workarounds. The easiest is to simply rename all the affected variables; e.g.:
A more complex solution, although it allows the existing variable names to be used, is to change the method of access: using the
Get-Variable cmdlets. For example:
Set-Variable DataSet (New-Object System.Data.DataSet)
Get-Variable DataSet -ValueOnly
Care must be taken, however, to ensure that the value is unboxed; e.g. this will always return a value of
Set-Variable SomeValues (1..5)
(Get-Variable SomeValues -ValueOnly | measure).Count
Instead, to obtain the count, use:
((Get-Variable SomeValues -ValueOnly) | measure).Count
I recently came across an unusual case of SCOM not discovering certain elements of an SCVMM instance, including the applicable storage objects and associated file server objects. The connection between SCVMM and SCOM was active; as evidence, the connection was visible in SCVMM, and the internal connectors to the SCVMM instance were in place in SCOM, as were the Management Group objects in SCOM. However, no error messages had been logged in SCOM or in the event log on the SCVMM servers.
After manually executing the discovery scripts from the SCVMM management packs, I discovered that one of the discovery scripts was failing due to a missing registry key.
The type or name syntax of the registry key value IndigoTcpPort under Software\Microsoft\Microsoft System Center Virtual Machine Manager Administrator Console\Settings is incorrect.
The cause of the problem was that a registry value,
IndigoTcpPort, was missing from
HKLM\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Administrator Console\Settings\. It appears that this value was removed by an update rollup prior to UR7, which have been installed automatically. Adding the value with its default data,
8100), and allowing time for the discoveries to run, resolved the problem.