Windows Server Discovery fails with error Get-CimClass : Access is deniedIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #6e9db4; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: 500px !important; width: auto; height: auto; } } If Windows Server Discovery fails with the error Get-CimClass : Access is denied, the following information and steps can help to resolve the issue. 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 A similar error displays in the input payload: Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #6e9db4; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: 500px !important; width: auto; height: auto; } } All releases Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #6e9db4; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: 500px !important; width: auto; height: auto; } } 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, see KB0752537: Differences between Windows PowerShell Discovery and legacy Windows Discovery To confirm if the admin share test is failing: Set the MID Server parameter mid.log.level = debugSet the MID Server property mid.property.powershell.log_info to trueRun a test discovery.Review the MID Server agent log.The logs present the following messages: <date_time> PowerConsole-<ecc_queue_sysId>>stdout DEBUG: STDOUT : <SNC_LOG><date_time> Beginning admin share access test with cred: <credentail_name></SNC_LOG><date_time> PowerConsole-<ecc_queue_sysId>>stdout DEBUG: STDOUT : <SNC_LOG><date_time> admin share access: False</SNC_LOG><date_time> PowerConsole-<ecc_queue_sysId>>stdout DEBUG: STDOUT : <SNC_LOG><date_time> PowerShell access: False</SNC_LOG> When admin share access fails, the WMI query will fallback to legacy and the following is run 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 PowerShell commands. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #6e9db4; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: 500px !important; width: auto; height: auto; } } Log in to the target device using the same discovery credentials and run the following PowerShell script in the PowerShell editor. Get-CimClass - Namespace "root/Default" The namespace should return successfully as shown in the following image. If not, 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 nonlegacy way. One way to test admin share access is to: Log in to the MID Server.Open PowerShell with the account used for discovering the target device.Run Test-Path -Path "\\<target_ip_address>\admin$" Admin share access failed in some cases because the netlogon service Startup Type was set to Manual on the target device. Once this was set to automatic, the remote share access issue was resolved and the probe ran successfully. Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #6e9db4; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: 500px !important; width: auto; height: auto; } } 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, see KB1441458: Unable to perform discovery of Microsoft CA with error "Identification Engine: Discovery status is FAILURE, CI Type cmdb_ci_certificate cannot be created since there are no attributes defined".