Databases
StackOverflow2013
Postsdbo
POWhy is a Remote WMI call to Win32_Printer Coming Back With An Empty Set For Some Machines?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy is a Remote WMI call to Win32_Printer Coming Back With An Empty Set For Some Machines?
    primarykey
    data
    text
    <p>I am using WMI (prototyping everything in VBScript first, as examples are more plentiful and it removes VBScript/Python impedence) to connect remotely to a fresh PC (we will call this PC2). Most <code>Win32_*</code> classes can be remotely read, yet <code>Win32_Printer</code> returns an empty set when queried, but only when I query remotely. The resulting <code>SWbemObjectSet</code> always has a <code>.Count</code> of zero. No error. I can connect to PC1 and receive a <code>SWbemObjectSet</code> with a non-zero <code>.Count</code>, can iterate through it, etc. If I run the script locally (after removing the superuser username and password from the <code>.ConnectServer</code> method, naturally), I get a non-zero <code>.Count</code> back and can iterate through it. Even if I foolishly use my own Domain Administrator account, the problem persists. The Script:</p> <pre><code>strComputer = "nnn.nnn.nnn.nnn" username = "DOMAIN\superuser" password = "thisisaverygoodpassword" Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator") objSWbemLocator.Security_.ImpersonationLevel = 3 objSWbemLocator.Security_.AuthenticationLevel = 6 Set objSWbemServices = objSWbemLocator.ConnectServer(strComputer, "root\cimv2", username, password) Set colSWBemObjectSet = objSWbemServices.ExecQuery("Select * From Win32_Printer") WScript.Echo colSWBemObjectSet.Count &amp; " Found." For Each objPrinter in colSWBemObjectSet For Each Property in objPrinter.Properties_ If TypeName(Property.Value) = "Variant()" Then Wscript.Echo """" &amp; Property.Name &amp; """, """ &amp; TypeName(Property.Value) &amp; """, ""Skipping ...""" Else Wscript.Echo """" &amp; Property.Name &amp; """, """ &amp; TypeName(Property.Value) &amp; """, """ &amp; Property.Value &amp; """" End If Next Next </code></pre> <p>Commenting and error checking have been omitted for brevity.</p> <p>It does not appear to be a firewall problem. </p> <ul> <li>Reason 1: Where a firewall blockage does exist, I receive an error back from <code>SWbemLocator</code>, "The RPC server is unavailable."</li> <li>Reason 2: I can access and run through the WMI class <code>Win32_ComputerSystem</code> with ease.</li> </ul> <p>It does not appear to be a username/password problem. </p> <ul> <li>Reason 1: I can retrieve information from <code>Win32_ComputerSystem</code>.</li> <li>Reason 2: I ought to get an error.</li> </ul> <p>It does not appear to be an OS version problem:</p> <ul> <li>Reason: PC2 and PC1 are both running Windows 7 Professional. PC1 is running the 64-bit version, PC2 the 32-bit.</li> </ul> <p>Although I started trying to reach a 32-bit machine from a 64-bit server, it does not appear to be a 32-bit vs. 64-bit problem. </p> <ul> <li>Reason 1: I added a value of <code>32</code> for <code>__ProviderArchitecture</code> in a <code>SWbemNamedValueSet</code> prior to my <code>.ConnectServer</code> attempt (with that <code>SWbemNamedValueSet</code> in the arguments to no avail), although I was unable to later add that same context to the <code>.ExecQuery</code> method of the connected server without a type mismatch operator.</li> <li>Reason 2: I later ran the script from a 32-bit server with the same result.</li> </ul> <p>It does not appear to be a corrupted WMI problem.</p> <ul> <li>Reason: Once I stop using credentials, I can run the script from the target machine itself and receive a result set with more than zero items and can iterate through it.</li> </ul> <p>It does not appear to be a credential/namespace mistake within my script.</p> <ul> <li>Reason: Using <code>WBemTest.exe</code> from the same source machine and using identical username, password, authentication level, impersonation level, namespace, and so forth, I receive the same null set for an answer.</li> </ul> <p>It does not appear to be an issue of WMI Namespace security on the target machine.</p> <ul> <li>Reason 1: Logging in to the target machine with the same credentials as the script uses generates results.</li> <li>Reason 2: <code>Win32_Printer</code> is in the same namespace as <code>Win32_ComputerSystem</code>. <code>Win32_ComputerSystem</code> works.</li> <li>Reason 3: After using the <code>Wmimgmt.msc</code> Microsoft Management Console (MMC) to give the superuser full permissions, starting in the root namespace, propagating to "This namespace and subnamespaces," rebooting, and checking again, I still receive the same empty set.</li> </ul> <p>It does not appear to be the respective OUs of PC2 and PC1 that are the problem. </p> <ul> <li>Reason: I swapped the OUs each machine was in and rebooted. No change.</li> </ul> <p>It does not appear to be the Local Computer Groups:</p> <ul> <li>Reason: I made the membership of groups in PC2 look like PC1 and rebooted. No change.</li> </ul> <p>It does not appear to be something magical about <code>Win32_Printer</code> in that remote access does not work.</p> <ul> <li>Reason: I can read PC1's <code>Win32_Printer</code> class.</li> </ul> <p>It does not appear that my WQL is unusual.</p> <ul> <li>Reason: "<code>SELECT * FROM Win32_Printer</code>" is my test case.</li> </ul> <p>It does not appear that my DCOM settings are off.</p> <ul> <li>Reason: They appear identical when I go through PC1 and PC2.</li> </ul> <p>I have even gone so far as to hit the Trace logs in WMI-Activity, print them out for both PC1 and PC2, then sort by <code>GroupOperationID</code>, <code>OperationID</code> (the <code>TimeCreated SystemTime</code> is not granular enough and <code>EventID</code> seems ... out of order. I can see events from the following actions:</p> <pre><code>IWbemServices::Connect Start IWbemServices::ExecQuery - Select * from __ClassProviderRegistration Start IWbemServices::GetObject - __Win32Provider.Name="WmiPerfClass" Start IWbemServices::ExecQuery - references of {__Win32Provider.Name="WmiPerfClass"} Start IWbemServices::GetObject - Win32_Printer Start IWbemServices::ExecQuery - Select * From Win32_Printer Provider::CreateInstanceEnum - Win32_Printer </code></pre> <p>in both sets of logs, and if I sort by <code>GroupOperationID</code>, <code>OperationID</code> they appear to happen in identical order. Sorting by <code>EventID</code> shows a somewhat different order. That's the closest I can see to a difference. I'm stumped at this point.</p> <p>I know this verges perilously close to a system administration issue.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USMetaHyperBolic
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhy is a Remote WMI call to Win32_Printer Coming Back With An Empty Set For Some Machines?
      1. USMetaHyperBolic
      1. VTBountyStart
    2. VO
      singulars
      1. POWhy is a Remote WMI call to Win32_Printer Coming Back With An Empty Set For Some Machines?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWhy is a Remote WMI call to Win32_Printer Coming Back With An Empty Set For Some Machines?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload