Windows Server Discovery fails with error Get-CimClass : Access is denied - Support and Troubleshooting

Windows Server Discovery fails with error Get-CimClass : Access is denied Issue If Windows Server Discovery fails with the error Get-CimClass : Access is denied , see this article for additional information and steps to resolve the issue.

Example error An example error may look like the following:

Get-CimClass : Access is denied. At C:\MidServer\EAPPSVCNOWMID01\agent\scripts\PowerShell\WMIFetch.psm1:421 char:20 + ... $reg = Get-CimClass -Namespace "root\default" -ClassName "StdReg ... + CategoryInfo : PermissionDenied: (root\default:StdRegProv:String) [Get-CimClass], CimException + FullyQualifiedErrorId : HRESULT 0x80070005,Microsoft.Management.Infrastructure.CimCmdlets.GetCimClassCommand + PSComputerName : 10.10.4.51 We can see similar error in input payload:

Cause Admin share access and PowerShell access checks are performed before running WMIRunner probes on a target. The error described in this knowledge base article is often seen when the admin share access test fails and the WMI request falls back to legacy, pre Madrid release. For more information on this topic, please see KB0752537: Differences between Windows PowerShell Discovery and legacy Windows Discovery

To confirm if the admin share test is failing:

Set mid server parameter mid.log.level = debug Set mid server property mid.property.powershell.log_info = true Run a test discovery Review the MID Server agent log The following message will be present in the logs: PowerConsole- >stdout DEBUG: STDOUT : Beginning admin share access test with cred: PowerConsole- >stdout DEBUG: STDOUT : admin share access: False PowerConsole- >stdout DEBUG: STDOUT : PowerShell access: False When admin share access fails then the WMI query will fallback to legacy and the following is executed on the MID server:

Get-CimClass -Namespace "root/Default" -ClassName "StdRegProv" -CimSession $session Note: $session is a CIMSession created earlier in the code and passed as an argument.

The error is then returned. The issue is because the namespace "root\default" might not be available on the target devices when running PS commands.

Resolution Login to the target device using the same discovery credentials and run below PS script in PS editor.

Get-CimClass - Namespace "root/Default"

The namespace should get returned successfully as below.

If not, please work with the windows admin team responsible for maintaining the device to determine why the namespaces are not returned.

Alternatively, allow admin share access from the MID server to the target device so that the WMIRunner probe can run in the non legacy way.

One way to test admin share access is to:

Log into the MID Server Open PowerShell with the account used for discovering the target device Run Test-Path -Path "\\ \admin$" The reason why admin share access failed in some cases was due to the "netlogon" service Startup Type being set to Manual on the target device. Once set to automatic the remote share access issue was resolved and the probe was executed successfully.

Related Links For information about the Identification Engine: Discovery status is FAILURE, CI Type cmdb_ci_certificate cannot be created since there are no attributes defined error message, please see KB1441458 .